Automated chip burning

[Alexsoulis] needed to burn the Arduino bootloader to a slew of ATmega328 chips. Instead of sitting there and plugged the chips into a programmer one at a time, he build a robotic microcontroller programmer.

It starts with the DIP package microcontrollers in a tube, with a servo motor to dispense them one-by-one. An arm swings over and picks up the chip with a fish pump powered vacuum tweezers similar to the pick-and-place head we saw recently. From there the chip is dropped into a ZIF socket and programmed by an Arduino. Once the process is complete it is moved to the side and the process repeats.

We’ve reported on using an Arduino as an AVR programmer but we’ve never actually done it ourselves (we use an AVR Dragon programmer). Take a look at the video after the break and let us know if you think the actual programming seems incredibly slow.

Actually, it looks like the writing takes less than two seconds, and the slow bar shows the progress of reading the data back to verify. Around 1:50 and after you can read “Reading” to the left of it and a couple lines above that the string “reading on-chip flash data” is visible.

Cool robot, though. I wonder how much those cheap Chinese servos were…

Very nice, the speed does not seem to be that much of an issue, given the fire and forget nature of the setup.

Had I the skills to make this, I would have built a better unloading method than just dropping the chip into a foil bin. It seems like it does not lose suction immediately, though the program acts as if it does. Leading to the awkward pile in the corner of the bin. You might very well come back to a pile of chips outside of the bin.

Might I ask why he is programming so many? Sales?

If so you could easily set up a small conveyor type deal and have it drop them into anti static packaging, then roll them off into a box to be sealed and shipped after. I mean, he clearly demonstrated his ability to create such a system already lol

Would multiplexing be out of the question? I mean, he could load one, and while it’s writing to that chip, add another one and so on. Then go back to the first one to throw in the bin and down the line.

But for day-to-day ATmega programming, I use a home-grown 4-fold stand-alone programmer. It’s faster because it has 4 burns running in parallel (or staggered, I just keep replacing chips in a round-robin fashion).

The late chip drop into the finished tray could be fixed by turning off the suction before the arm is finished stopping, that would allow the lag from the sucking tube time to let go of the chip & hitting the end stop for the arm would help make the release point more predictable.

The finished chips could also be dropped onto a rail made out of anti-static packing tube with the top cut off the last few inches instead of a bin.

As ean-Claude Wippler pointed out, adding more burn stations with everything else the same would increase the throughput.

I think the ‘lag’ in the drop is intentional, it looked messy for the first chip but then I noticed the second bumped up against the first one before it fell off, they will be stacked up in the sequence they were programmed without the need to calculate a new drop position each time.

The sequence is important because the system looks like it allows for my than one type of job in the job queue.

ASTlab in Hungary built a robotic AVR programmer about four years ago. It is a very robust platform which even has a blinking LED to indicate the robot is cycling. Cycling time is a bit slower, though.