There's nothing worse that being asked to support a piece of hardware and after a number of years wanting to upgrade the firmware and having to desolder microcontrollers off their controller boards; who knows what damage you do when taking them off - and can you be sure they go back on and are fully working?
If you de-solder the chip, change the firmware and reinstall it and it doesn't work, how do you trace the fault? It could be the new firmware doesn't work as expected - but it might be that you're a genius coder, got everything right first time, and just haven't quite soldered all the pins back correctly, or have a dry joint or something.
It's the main difference I see between "hobbyists" and "commercial" developers.
A hobby developer will "work forwards" - find the things that make something work and follow the route to a conclusion. Usually, a "commercial" developer (and particularly one with lots of experience of the "forward working" method) will "work backwards".
That means, start from a point of failure.
Put yourself in the shoes of the poor sap who, in four years time, when the thing has failed or needs upgrading, is standing in front of your hardware, screwdriver in hand, cursing the one who could have made their life so much easier, with just a simple tweak of the design. That poor sap might even be you one day! Commercial developers tend to start with failure and work back - if this goes wrong, how do I put it right? Before this can happen, what conditions have to be met? If these conditions are not met, should my device even be allowed to run?
And in the "industrial" microcontroller world - where PIC still reigns (or, at least, did up until about ten years ago, when I stopped being seriously involved with industrial electronics and become more of a "hobbyist" myself) that means one of two things:
Either put every chip in a socket.
That's the easiest method.
But also - particularly for a hobbyist trying out ideas - the most expensive, leading to larger, more cumbersome looking designs (and in this time of miniaturisation, smaller is almost always better/more preferable).
The other method is to put an ICSP header on everything.
That's what I normally do.
Any PIC-based design, I'll make sure my programming pins are easily accessible so, should the time every come, it's dead easy to whack on a programmer and update the firmware. And, although ICSP programming isn't quite as common in Arduino-land, it's not unheard of.
Since using Arduino/AVR chips in a few projects this year, I've found the 0.8mm SMT pitch chips are great for hand-soldering (0.5mm pitch PICs on the other hand are a real pain to solder onto home-made PCBs). Since smaller is better, and a few of the other nerds have been pushing for AVR- rather than PIC-based projects, I thought I'd try to leave off the programming header on a few homebrew projects, to get the design-size down as small as possible (quite often my programming header is about the same size as the rest of the entire PCB!)
Which is where little beauty comes in.
It's a 32-pin TQFP socket on a DIP-sized breakout board. We looked at these a few years back, and back then they were £70 or more. If you find them on Farnell, they're still stupid money.
Thankfully, the Chinese pirates are happy to knock them out at less than £15 and sell them on eBay. So it seemed like a no-brainer to get one to try out.
You can either program your AVR chips "properly" using an AVR programmer and Atmel Studio/avrdude. Or you can find the serial and reset pins, and program them using the bootloader over serial.
Since our chips are to be used for "one time" projects, we just burned the firmware directly onto the chip, without using the bootloader. It seemed a bit silly to burn the bootloader using the ICSP pins, then have to use a completely different set of pins to program the firmware, so we just dumped the firmware straight on.
The only thing that wasn't quite so straightforward was location of the pins.
We couldn't just assume that "pin one" on the breakout board (the top-left-most pin) was connected to pin one on the TQFP chip. In fact, it turned out not to be the case at all.
But after a bit of poking around with a multi-meter we managed to map out which of the socket pins went to which of the DIP pins on the breakout board.
No comments:
Post a Comment