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.

[Thanks Kyle via Let’s Make Robots]

28 thoughts on “Automated chip burning

  1. i use avrisp (arduino isp) all the time with my arduino, its 19200 baud and as fast as you would expect

    yea this is pretty darn slow, so I dunno? wtf?

    otherwise cool bit of robot action

  2. If you break the programming up into two steps you can program at least @ 115200 using an Arduino’s FTDI as the programmer.

    First you need to set just the fuse bits properly at the slower speed, then you can come back now that it is initialized and do the rest at the higher speed.

    Will

  3. @ will

    yea but really its 2kb and the bit bang mode requires much more effort than “load sketch add 4 wires”

    even at 19200 2k will only take like 100ms

  4. 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…

  5. for those of you with your sound off, it goes like this:
    ……… Toooot! Verrrnt. ChaClick. CHOO CHOOOO! chuga-chuga-chuga-chuga Vernt BUZZZZZZZZZZZZZZZZZZZZZZZZZZZT Veernt weeeerrn Veeernt Plop

  6. 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

  7. One step closer to a homebuilt self replicating machines.

    Really I should try this as I been wanting to try a swarm robotic project which would require flashing several chips.

  8. 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.

  9. If your servo doesn’t have to hold anything once it has moved, you can set he signal pin to low and it will hold its position, and shut the hell up.

  10. @mosheen

    ld idiot, mute
    ld video, shaky
    set_self vomit
    set_idiot high

    Of course, all include files and definitions are in the “wtf.inc” file.

    Back on track, I really do like. My question is, if he happens to try to optimize the program, will it still work the same or will there be more lag due to the changes?

  11. VERY cool. I especially liked the alignment step, where a small servo nudges the chip against a stop, to put it into a known position, ready for the next step ZIF insertion. Well done.

  12. This is useful.

    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.

  13. 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.

  14. OMG, in the time this machine program a single chip, I could have called my distibutor and have them program the devices before delivery.

    In the time this machine program a single chip, you could have programmed 2 or 3 using regular methods.

    In the time it must have taken to build this machine, I could have programmed more devices that you’ll ever need.

  15. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s