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]


  1. osgeld says:

    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. ril3y says:

    Very cool… I love the tubing as a “reel”.


  3. Yeah says:

    That’s actually pretty cool. If I had a lot of chips to burn one day I’d build something similar.

  4. addidis says:

    very cool , but wow that programs sloooooow I can see where the motivation to design this came from.

  5. Will says:

    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.


  6. ssh says:

    not very fast but as a set it and forget it i thinks its very well done

  7. osgeld says:

    @ 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

  8. Slime says:

    The use of English in these story posts has been horrendous of late. C’mon editors, proof read before posting!

  9. mowcius says:

    Yeah it’s not the fastest thing but it’s not exactly very high risk so it could just be left to get on with it.


  10. Amos says:

    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…

  11. andrew says:

    I’m impressed

  12. KC8RWR says:

    Wow! Very nice!

  13. JustInTimeGuy says:

    SkyNet uses something similar to program its Terminators.

  14. walt says:

    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

  15. Masta Squidge says:

    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

  16. Nitori says:

    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.

  17. Rollyn01 says:

    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.

  18. mosheen says:

    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.

  19. Rollyn01 says:


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

    Of course, all include files and definitions are in the “” 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?

  20. neimad says:

    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.

  21. Alan Parekh says:

    Great idea for cranking out the chips while you go and do something more interesting. Where do the failed chips go?

  22. wow very very cool!

  23. Lovely setup!

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

    For lots more on ISP programming, see:

    Still, it’s neat to see this pick-and-place type machine!

  24. Ugly American says:

    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.

  25. caff says:

    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.

  26. JB says:

    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.

  27. spyder_21 says:

    nice project

  28. j s says:

    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: Logo

You are commenting using your 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


Get every new post delivered to your Inbox.

Join 96,742 other followers