Animatronic Avian 1: Planning and History

Since I was a kid, I was always into Disney Imagineering.  For many years, I always thought that designing and building attractions and such for them was something I would aspire to but never reach.  I always held WED/WDI up on this pedestal, thinking that they were so far above me, and I'm sure that in some areas they are.  Over time, I've come to realize that I can do that stuff too.  I have always wanted to be an "Imagineer", and there's really nothing stopping me from becoming one... Perhaps I won't be working for Disney, but I can do the same stuff.  That's where this project comes into play.

These birds sing words.

Disney introduced The Enchanted Tiki Room in 1963, and it's probably my favorite attraction at Disneyland and The Magic Kingdom.  It's got everything... Great music by the Sherman Brothers, wonderful island-tiki themes, humor, animatronic birds that sing words, flowers that croon... I've wanted to bring this home somehow, and I think that the time is right to make this happen.  It's a really big project and will likely take me years to complete, but I'm sure that it will be a welcome addition to my son's playroom (and/or my office.)

These flowers croon.

The project covers a lot of subprojects.  I'll try to outline here the various subprojects which I will be working on and blogging about here as I work on them. (I will list them here in arbitrary order, as I will be working on and posting about multiple projects simultaneously.)

My goal is to make this as repeatable/reproducible as possible.  The things I make may be one-offs prototypes, but the goal is to make them easy to duplicate.  I won't rely on specific items from stores, other than materials, and many of the parts I will either vacuform, 3D print, or craft.  (Things like the MST3K bots relied on specific parts, which have become difficult to find, turning those components from "cheap old junk" into "collectible, rare, expensive parts".  I hope to avoid this situation.)  I also plan on doing this as inexpensively as possible without it becoming "cheap".  I may offer kits, parts, downloads, templates for the various aspects of the projects in time as well.  All of that will become clear to me while I work on this.

Looking around for items to purchase "out of the box" shows that a simple playback unit might cost $500, a servo controller $300... so that's $800 before you even buy a single material or piece of wire for it. The controller boards I'm going to use are Arduinos, at $22 each, and they will be controlled from my Mac computer, which I already have.  I may consider automating this in the future, which will require further design consideration, but may be accomplishable via a Raspberry Pi $25 and a USB audio device ($5)  I'm going for "in my house" not "industrial", although the concepts are the same.

Project 1: Vacuum Forming Rig

To construct the outer body of the birds in a quickly reproducible fashion, I've decided that it's time to build a simple vacuum forming rig.  I will be building this at Interlock, using some scrap material there, the vacuum there, and their heat gun.  I can build a heating element rig too, but to get started i'll just use a heat gun.  I plan on only making a 12" square working area (or perhaps a little smaller).  I will be using this to make at least the beak of the animatronic bird, but probably also shells for the head and body, onto which feathers or fur can be added.

The idea is that I would make molds of these various parts, and then vacuform plastic sheets over the molds, cut them out, and I will have easily reproducible parts.

Here's a link to a video of something similar to what I want to build.


Project 2: "Walter" Motion Capture Hardware

The most intiuitive (and fun) way to capture the performance to play back on the puppet is to build a puppet motion capture system.  I'm vaguely basing this design on the "Waldo" rig that Jim Henson is demonstrating here.  I may use a lot of PVC and CPVC parts to construct this, and perhaps some 3D printed parts.  I'm not entirely sure yet.  I will likely use simple adjustable resistors/potentiometers at the joints to capture the angular data, hooked up through an Arduino's analog inputs, then recorded on a host computer.  The test app for this will be a simple display that records motion events.

This is the one section of the project where I will likely only be building one, and will do a lot of hacks to get it working for my needs.  If there is demand for it, I can figure out a way to reproduce it but that is not the goal for this section.


Project 3: "Elias" Motion Capture and Replay Software

This software, which I lovingly call "Elias", named after a certain guy who was quite influential, will work with project 2 above.  It will play back an audio file, and log input from the puppet control Arduino in some yet to be defined data format.  It will represent the angular information on the computer's display, while playing the audio.  It will also be able to replay the angular information down through a target Arduino (in the future, embedded inside of each puppet), synchronized with the audio.  This software could easily be re-purposed to control relays to turn on and off lights to make simple light shows and such.  It will handle up to 7 analog tracks, and 7 digital tracks at a sample rate of somewhere around 500-1000 samples per second, capable of going over a 9600 baud connection.  The first version of this will be used to drive my xmas lights this season.


Project 4: Flora Design and Construction

Here's where it starts getting REALLY fun.  To start with, I will build a simple flower, possibly like the second image seen above.  Those flowers have basically one point of articulation; just the mouth open or closed.  I may add a second point, rotation of the entire flower.  The flower petals will be vacuformed and spray painted.  They will likely then be glued together to some sort of plastic armature. The mouth may be actuated via solenoid or something similar.  The rotation, if implemented, will be made by directly mounting the lightweight flower puppet on a servo's control arms.

The goal of this isn't specifically to make an animatronic flower, although that will be one of the products of this, and will be needed for background/fill for my Tiki extravaganza.  Rather, this will be a good way to integrate everything together, without constructing the complete avian, which will take significantly more time and effort to complete.  Get something done quick, get another "win" under my belt, get motivation to follow through with the following item...


Project 5: Avian Design and Construction

Similarly to the flower, this will have a plastic or maybe foam-core skeleton which will hold the electronics and servos.  For all birds, this skeleton will be identical.  I'd love to make four birds, but one will be awesome.  On top of the skeleton, vacuformed skin will be affixed somehow, perhaps using cotter pins like the hood on a remote control car, or perhaps using just Velcro.  These skins will be painted and have feathers glued to them.  I can picture this being made of seven pieces:  left body, right body, belly, lower beak, upper beak. top of head, bottom of head.  I'll have to figure this out further. I'll also have to figure out how to add the articulation points in the skeleton, as well as the best way to affix feathers, or a feather-like skin on them.


At this point, everything will be done, and I should be able to make a tiki bird performance!

Now that I've spelled this all out here, I feel a bit overwhelmed by the whole thing! ... but I have to admit, each item is achievable.  I'm anxious to get to the final product!

Repairing a Digital Camera: Battery Explosion!

I like to collect old pocket computers and gadgets. One of the things I encounter often is exploded batteries.  I recently rescued a Canon Powershot A520, and it seemed to be completely dead, probably due to poor battery contact due to the previous batteries exploding.

I've read stories of other people using watered down vinegar to remove the alkaline, but I instead use just vinegar.  I dip a paper towel in it, and saturate the affected areas.  If you listen closely, you can hear it fizzing.  Ssszszszsszszszs!

After a few saturations and wipes with paper toweling, I had removed most of the alkaline gunk.  From here you can clean it with a baking soda paste, but for this, I just decided to scrape the contacts a bit.

Once it was cleaned up, I put in some old AA batteries and it powered right up!  I dropped in my old 2 gig EyeFi Geo card ($20 from Woot many moons ago), and it worked!  I recharged some high capacity AAs overnight and dropped them in.  Then things started going badly...

It would power on, then immediately turn off.  I tried my second set of rechargables, and the same thing happened.  I re-cleaned the contacts, but that didn't seem to help.  It was at this point that I thought I knew why it had been dropped in the recycle pile.

Then I realized that my AA rechargables put out 1.2v each, rather than the 1.5v of alkalines.  The camera has a requirement printed on it of 3.15 volts.  1.2 plus 1.2 does not equal 3.15.... I found a fresh pair of alkalines and dropped them in, and sure enough, it works perfectly!

As a sidenote, I also set up my computer at home to host the EyeFi software, and it drops the downloaded pictures into a Dropbox directory.  Now, all of the pictures taken with the camera are instantly shared when I'm home. I have no reason to manually sync the card physically now. Yay!

Timer Repair

Our kitchen timer has been acting up recently, and with Thanksgiving quickly approaching, I needed to do something about it.  The push button for the start/stop function has been getting harder and harder to use.  In the past, I've cracked it open and cleaned out the pad underneath the rubberized button membrane, but this time, doing this didn't work. I also  wanted a more permanent fix.

I decided to replace the membrane switch for that function with one of these tactile buttons.  I just had to make sure that the solder pads would line up.  I worked out an orientation in which the solder pads would match the pushbutton pads, as you can see in the next image.

The only issue is that rather than the rubber membrane sitting flush with the board, it now had to accomodate the shape and size of the switch along with the button which extended out quite far.  I used a pair of diagonal cutters to nip away at the rubber from behind to recess the switch into the button itself, Ben Heck style.

You can see this in the top right of the gray membrane.  The two contact pads have been removed, and instead there is the hole, into which the switch recesses.  The hole was made fairly crudely, but it works!

It's been accidentally abused over the years, and as a result, the screws on the bottom no longer hold it together as the plastic has broken enough.  The strip of electrical tape around the base does well to hold it together while still looking super stylish! NOTE: It's not actually very stylish, but rather, functional and should last for many years more to come.  No reason to throw it out, when an hour or so of work will get it fully functional again!

EPROMs part 2: Success!

NOTE: This article was originally posted over at the Interlock blog.

This is a continuation of a previous article.  Quick summary: I tried to build a device for dumping an EPROM via Arduino, and I constructed a device that had no chance of working.  Oops.

This post will continue where that one left off.  I'll walk through some of the process to hopefully get to a solution that works...

To summarize the overall project;  I want to build a device that will illuminate an UV light-erasable ROM (EPROM) device, and also dump out its contents. I will then take the contents, display them as a graphic, and animate them over time as the bits fade away into an erased oblivion.

When we last left this, the above circuit was what I was going to work with.  The Arduino would shift out a 16 bit address, which will be stored in the 74HC595 serial-in, parallel-out shift registers.  Those would output to the address lines of the EPROM device. The 8 data line outputs of the EPROM then are read in directly by the Arduino.  I started to look around for the parts, and I was planning to buy them from Sparkfun.com, for a very reasonable price.  I was all set to place the order, but then I started thinking about other ways to sample the data, and then it hit me...

In the late 1980s, I had an Amiga 1000 computer (see previous post about restoring it).  We used Macintosh SE computers in High School, and as a result, we bought the "AMAX" Macintosh emulation system for the Amiga.  It was a lot easier to carry a floppy or two, rather than a SE or SE/30 in a plastic milk crate, not to mention that MacWrite was a substantially better word processor than TextCraft. ;)

AMAX consisted of software you run that emulated the Mac's hardware, as well as a "cartridge" that plugged into the floppy drive port of the Amiga.  I remember hearing that they went with the floppy drive port because it was the only appropriate port identical on all Amigas that were available at the time. (Amiga 1000, 500, 2000).

The cartridge served two functions. First, it let you plug in a Mac floppy drive right into the Amiga so that you could read and write 800k Mac floppies directly.  There was something about Amiga drives and Mac drives supporting a different number of drive speeds, so full Mac compatibility on the Amiga's drives was directly impossible.  Future versions of AMAX that used an internal card on the Amiga 2000 worked around this issue.  It was possible to make a floppy that supported just the sectors/speeds that were the same on both, but they only stored 272k of content.  But I digress...

The other function of the cartridge was that you needed to plug in Mac roms into it, which the software would read in as it starts.  Rather than storing the ROM on the Amiga, this protected the copyrights or whatever.  But the important thing here is the function.  I had picked up a few AMAX cartridges for $2 apiece at the awesome Active Surplus on Queen Street in Toronto a bunch of years back, so I dug one out.

Left-to-Right, you see: Amiga D23 floppy connector, for connecting it to your Amiga, two 28 pin rom sockets, two 74LS393s, one 74LS165, a resistor, some diodes, a 74LS139, the Mac D19 floppy connector on the bottom, then the Amiga D23 floppy connector for adding additional Amiga floppy drives.

I've started to trace out the circuit, but it became obvious quickly that it was optimized for board layout rather than what I would consider to be a sane arrangements of data lines.  For example the 8 data output lines of the ROMs go into the 74LS165 PISO shift register out of order, so they need to be reshuffled once captured in the host computer.

Instead I decided to desolder the chips!  My guess at the original function is something like: the Amiga issues a clear to the 74LS393 binary counter chips, ganged together to yeield a 16 bit output, rather than two dual-4 bit outputs.  This will reset their 16 bit output value to 0.  The 74LS165 parallel-in, serial-out register then latches the 8 bit output from the ROM, and provides it through shifting to the Amiga via the floppy port.  From there, you need to simply pulse the clock on the '393, and it will increment through every address. Then you just latch and shift in the data. There's also a 74LS139 demultiplexer, which might be responsible for sequencing through those events, or perhaps something to do with the Mac floppy drive. I had a slight mishap and lost the 74LS165, which is okay since I didn't need it for this project anyway.  Regardless, $2 plus some time -- I'm already ahead and I haven't even removed the D23s yet (which are the same size as Amiga RGB Video connectors! Perfect for another project...)

For fun, here's the board with no components on it.

With a slight change in gears I can adapt my design to use the parts I now have in my toolbox thanks to my desoldering tools.  Instead of the Arduino shifting out an address, it will instead do the process described above.  It will first clear the 393s, then alternately cycle between clocking out a pulse to increment their values, and reading in the value directly. Since I'm accessing the ROM data from start to finish, sequentially anyway, this solution works out perfectly.  I also show four LEDs in the above diagram. Three for various status, one for UV illumination.

Here is a close up of a 27C128 part. This one has Pac-Man programmed onto it... of course.  You can see through the quartz window, and down onto the EPROM silicon itself.

Here we see the pins on the Arduino, and how they connect to the shield's bus connections, along with the LEDs.  I could draw this up in a computerey drawing program, but sketching it out in Sharpie on graph paper is just quicker... ;)

Here are the  two 74LS393's.   You can see their connection to the address lines on the ROM, as well as the cascading of the counter, e.g. from 1QD to 2A, and from 2QD to 1A on the second chip.

And the wiring for the 28 pin socket, including the 3 pin (two-way) jumper so that i can use smaller 24 pin parts as well.

About the UV illumination...  The data sheets for the EPROMs show that they should be erased with 253.7 nanometer light, at 15-20 minutes, 2.5cm distance at 15 Watt/seconds per cm^2.  I dont know how to measure this with respect to LEDs, but I'm going to just wing it and see what happens.  The sheet also says that 253.7nm is the optimal wavelength for erasing them, but anything below 400nm should work.  I believe the UV LEDs I have are somewhere between 350nm and 400nm, so it should work.  The other issue is that the LEDs are substantially less powerful, probably a tenth to a hundredth the power. We'll see once we get this going, but I expect it will take on the order of weeks to erase a rom, rather than minutes.

The good thing about this project, in comparison to using EPROMs functionally, is that you want speed of erasure for functional use.  I personally found that my eraser worked on most of the devices I own in about 10 minutes.  I would often have a chip or two in the eraser, while programming and debugging others.  It worked out fairly well.  For this project, it's completely okay if it takes on the order of hours to erase a device.  I'll find out how well it works once I get it going.  I may use more than one LED just to speed it up a little, in case it takes on the order of days instead of minutes or hours.

I started laying out the board at home, wiring in just the LEDs, and figuring out the best layout for the chips.  I used the DIY shield for Arduino from AdaFruit.com as the foundation to build this upon.  I wanted to leave space for possibly using larger chips in the future, so what is the bottom of the board here has space for a few extra data lines if i re-route that red power line.  The '393's are layed out so that the one on the right, which addresses bits A0-A7 has four of its lines directly lined up.  This was to try to make it a little easier to wire up.

I bought some wire wrap wire for address, data, and control lines, and did most of the work of wiring those up one evening at Interlock.  I used red for control (counter clear, clock data cascade lines) as well as eprom address lines.  I used blue for data lines.  In the above pictures you can see how the wires were routed around (there was some more writing on the bottom, obviously.) You can also see how the UV LEDs are mounted with some stiff solid core wire.  I reduced the number of LEDs to two plus the UV LEDs for no real reason at all.  (There is an Arduino underneath there somewhere...)

On the two images above, you can see a jumper on the left of the first image, bottom of the second image... this changes what one pin is used for.  For smaller EPROMs, pin 26 of the 28 pin footprint is used for VCC, powering the chip.  In the larger packages, VCC is moved to pin 28, and pin 26 is used for Address line 13.  It's confusing.  A table that shows all of the pinouts doesn't really help too much, but it was necessary so that I could figure things out for wiring it up.

Next is firmware. I wrote a pretty simple program for the Arduino that simply enables the EPROM, resets the counters, then clocks through the addresses, reads them in and sends that data down through the serial link.  After getting the enable lines wrong (active low, rather than active high), I managed to get it spitting out actual accurate ROM contents.  As you can see in the above, it read out of the ROM (right half) 0xf3, 0x3e, 0x00, and so on.  In a disassembly of Ms PacMan on the left, you can see these bytes in cyan, just to the right of the red numbers 0000, 0001, and so on.

The other half is a simple program that runs on a host computer that simply reads in serial data and logs it out to a file.  That content looks like this:

f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812 

f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812 

f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812

I've now had this running for 12 hours with no change in the bits at all.  I'm thinking that it will require running for upwards of a week or two to have any affect on bits.  I may need to just drop the Arduino and ROM shield into my eraser to get the results I'm looking for... or at least a "control" to prove that the idea has a chance of working from here.

If nothing else, I now have a way to read EPROMS from an Arduino.  Awesome!

EPROMs and Failure

One of the things that comes with working on a lot of projects is failure.  Not everything works.  I've had my share of projects that for one reason or another, just didn't work out.  Tonight, I worked on one of these.

For a long time now, I've had some ideas that center around EPROMs.  I've been using EPROMS since I started getting into arcade machine collecting.  EPROMs are programmable devices where you can store bytes of memory in a fairly stable method.  They look like any other microchip, except that they have a transparent window on the top (usually quartz, even though it looks like glass).  If you look in the window, you can see the chip die in there, which I usually think looks like a tiny tennis court.

The above image shows a few different size.  The one on the right is a 2716, 16 kilobit (2 kilobyte) device.  The one in the middle is a 27C256, 256 kilobit (32 kilobyte) device.

To use an EPROM, you place it in an eraser, which is usually a ultraviolet light (often a fluorescent, non-filtered black light tube) with a timer, for about 10-12 minutes or so.  This sets all of the bits in the device to 1's.  (0xff hex).

Then you take the chip, and plug it into a programmer.  A computer tells the programmer what zeroes to write and where, and you end up with a chip that has a program or some data stored in it, so that it can be read out later.  Often, the window is then covered up so that they are not accidentally erased over time from ambient UV light. One data sheet I read said that 1 week in direct sunlight, or 3 years in normal office lighting will erase a device.  The programmer above is my Needham's EMP-10.  It has a 30 pin simm-looking slot on the side with 3 snap-in cards that configure the programmer pins so that it can handle a variety of different target device EPROMs.

This process has fascinated me since I started burning ROMs for use in arcade machines.  This is where this project comes in. I've had a few thoughts about things to explore here...

First of all, it should be possible to determine which bytes are in which physical locations on the device by casting a shadow or projecting an image onto the die from the eraser.  It should be possible to determine this by projecting different patterns on the die with the UV erasing light.  Obviously, it has to be well focused; this has to be quite precise.  A project for another day...

Secondly, I thought a fun project might be to read the pattern produced by erasing the device.  I would program all zeroes to the EPROM.  The chip would be plugged into an Arduino, to read the data out of it.  The Arduino would also control a UV LED or two which would illuminate the window on the EPROM, erasing it.  It would then alternate between illuminating the window and reading the content out of it.  The data pulled out would then be displayed as an image with pixels white if the content is a '1', and black if it is a '0'.  This should show all white at the start, and all black at the end, with some amount of dithering in the middle somehow.

I have a bunch of chips pulled from various electronic gadgets over the years, and the most prevalent of them was this 2732.  It has a nice small package, small data size (4 kilobytes), so downloading the content from it should be fairly quick... and I have a whole lot of them, so if a few get destroyed in the process, it's no big deal.

At first I considered hooking this EPROM up directly to the Arduino, but I need 24 lines to control it.  16 for address to the chip, 8 for data from the chip.  Not to mention a line to drive the LED.  I could go with an Arduino Mega, or Due, but I do not own either.  I only really needed 12 of those 16 address lines, which would bring it to 20 IO needed, which is still more than was available.

I do have a spare Mayhew Labs Mux Shield, (mine is a previous version) so I decided to just run with that.  Unfortunately this is where the story goes south.  I went from idea to making the board in one day. I really should have spent more time thinking about it, and less time being impulsive and just creating the thing.  I was too excited, incorrectly thinking that I had what I needed for the project.

I should note that I often enjoy when a project fails.  It really helps me learn what I did wrong, why it didn't work, and then it's like a puzzle to figure out how to make it work.  Sometimes, things just get frustrating and I will shelve a project indefinitely, but often I figure things out.

I wired up a socket, cobbled together from smaller DIP sockets, onto a piece of strip board.  I also threw a few indicator LEDs onto the board for various runtime display. After an evening of work, I came up with the board as seen here:

It was wired on the circuit side of the board (I do not recommend this) because then I could easily plug it in to the Mux Shield using the pin connectors I had.  The three red LEDs are wired to a few unused port pins on the mux, and the frosted LED on the right is an amber LED which I scuffed the top of to make it glow more than illuminate.  I have yet to power this up, because it was at this point, when I was done building it that I realized the problem.

The Mux Shield is an excellent device. I use it for my Jasper Box to read inputs.  For inputs, it's awesome.  It'll do 48 IO, even analog input.  For output, that's where it gets a bit non-intuitive.

The chips used on it are unbuffered.  That is to say that there's no way to specifically sample or store data out or in on it.  You pick a line, and then immediately read or write from it.  Think of it as a valve, not a view.  This is to say that at any one point in time, you're only setting or reading one bit.  When reading the EPROM, I want to specify a single address (16 bits of digital output) then read in the data from the chip (8 bits of digital input).  I can only do one bit at a time, so it is impossible to set the 16 bits simultaneously.

In order for this to work, I need to add a latch of some kind to the circuit to store the 16 bit address, so that I can then read in the 8 bits of data for that address in the EPROM.

Here's a sketch for the next version of this project.  As you can see, instead of using the Mux Shield, I'm now using a pair of 74HC595 serial-in, parallel-out shift registers chained together.  The idea here is that I would shift in the address I want to read through both of the '595s, then latch in the data on the 74HC165 parallel-in, serial-out shift register. This is actually taking it one step too far, since the '165 is unnecessary.  The thing on the left is the UV LED and its resistor.

So here's a simplifed version where the data lines of the EPROM are hooked directly into the Arduino.  It also shows three indicator LEDs on the top, which will be used to show the state of the device at runtime.

I need to order some parts to build this, and once I get them, I will be posting further results on the project.

"Failure is always an option." - Adam Savage

(This article was originally posted at the Interlock blog.)

Reverse Engineering a Stepper Motor Controller

I often check the recycle pile on the loading dock at work.  I sometimes find smallish hard drives, old laptops, and various other bits and bobs that I might use for various projects.  Often, most of them are useless, broken, beyond any sort of repair, but occasionally, I find something that is really useful to me, or I see the potential in something I find there.

One day, I went back there and found a few boxes of stepper motors attached to motor controller widgets.  There were a few different models of these widgets, but they all seemed similar.  They have a standard D-15 connector on one end and a 4 pin Molex pin connector on the other side.  When the guy who put them out there saw that I had grabbed a lot of them, his only comment was "You don't want those... they're (explative deleted)!"  I was about to prove him wrong.

The little stepper motor controller widgets intrigued me.  I figured that I could use them to drive the motors or do something interesting along those lines.  Turns out that the motors themselves are in fact... garbage, but the controllers would show to be very useful.  I got access to some code that would talk to them, along with a few of the original wiring adpaters as seen above, with a D9 for serial RS232 control, and a two pin molex for power.  I figured I could hook up power and drive them directly.

There are two different versions of the D15 widgets.  One has a metalized plastic shell, the other has a metal shield wrapped around it and appears to have been potted with epoxy or hot glue.  I cracked open one of the plastic shelled ones, and was checking out the innards.  I figured i had a lot of them, might as well see what was in there.  Both of these different styles have the same inner board.

As you can see, there is a power regulator (8 pin package), power transistors for the stepper motor coils, an LED, a 7.37 MHz crystal and a micro.  The micro is an ATMega 168. This is the same chip used in the older Arduino boards, albiet at 7.37MHz instead of 8, 16, or 20 MHz.  If I could figure out a way to get the Arduino bootloader onto one, or just make a programmer interface for one, then I could use them all as Arduino-compatible micros.

At this point, the possibilities of use for these things became apparent.   I went back to the loading dock recycle pile and snagged the rest of the widgets, leaving the (mostly broken) stepper motors there to be recycled.

I sat down and with very sharp eyes, traced out the wiring of the ATMega chip to the D15 header, the various components and everything.  I also mapped out what the components on the widget are in Arduino parlance.  In retrospect, I should have taken a photo or scanned the board and enlarged the image on my monitor.  Live and learn.

As you can see, there's a few pins missing, such as most of the analog inputs (lower left) but there's a lot that's there.  The important things to note are that the D15 carries all of the things important to reprogram these things, as well as to make them useful for other projects.  Power, D0/D1 for serial, reset, a couple analog, and the programmer header pins D10-D13.  I color coded the pins on the D15 connector side to match the wiring harnesses I made.  L is the LED. 0,1,2,3 are the stepper motor outputs, and T is a test point header on the board.

The first thing that I made is pictured above.  It's a D15 to FTDI header cable.  This would let me find out a few important things.  First of all, I can power it, and talk with it via Serial to see if i can even
do that much.  Sure enough, I set the Arduino IDE's serial monitor to 57600 baud, and was seeing text have affect.  If nothing else, I can use these as stepper motor controllers.

I had a few concerns about reprogramming these things.  First of all, I wasn't sure if the chips have had their write protect fuses burned or not.  This would prevent me from shoving any code of any kind onto them.  The other major concern was that with the crystal at 7.37 MHz, it was an unknown if the Arduino bootloader would even operate correctly.  It requires a RS232 connection to the host computer.  If I were to use an 8mhz crystal on it, the baud rates would be outside of the RS232 tolerances and it wouldn't work. (It would be about 9% off.)

I decided that for this whole exercise, the best plan of attack was to do each step along the way with minimal effort, so in case I hit a dealbreaker snag, I could just walk away from the project without too much loss of effort.

The next step was to make the above cable.  This let me program a D15 with minimal effort.  The idea is that I would install the "ArduinoISP" software on a "host" Arduino, and just plug this, with a D15, directly into it.

I loaded up the host with the programmer, and plugged this in to the D15.  I was able to program the widget with an 8mhz Arduino bootloader. (select the proper device type, then "Tools", "Burn Bootloader")  Sure enough, it worked!  Well, it wasn't able to run properly when hooked up through direct FTDI, because of the baud rate issue I mentioned being concerned about earlier.  I took the "Blink" sample code, changed it to use D8 for the LED, held SHIFT while hitting the upload button to upload through ISP programmer, and bam!  The LED was blinking (although slightly slow).  Needless to say, I was very excited at this point.  If nothing else, I could program my own code from the Arduino IDE using this method..

There was a problem though.  It was only able to successfully program about 1/4 of the widgets I tried.  3 out of 12 worked, the rest failed.  Even at this rate, I'd still have 25 widgets I could use.  I looked into the problem more, and it turned out that the issue was with the programmer itself.

The problem was that as the Arduino interface connected to the host Arduino, so that it can send the new firmware through it and down to the target widget, the act of it connecting to the programmer forced a reboot onto the host Arduino, shoving it into an awkward state, unable to react properly.  After some scouring the net (the use of Arduinos as host programmers is fairly scarce.. It's mostly in forums in the form of "I can't get this to work" ... "nevermind. I got it to work.")

I came to the realization that I had to somehow prevent the host from resetting.  There were two different versions of this that I've found.  One is using a 120 ohm resistor to power, or a 10 uF capacitor to power.  I deicded to combine the two, because why not, and came up with the right top portion of the following diagram:

The right side of this also shows the indicator LEDs, which show what the programmer is doing.  I figured I had to make a board for the reset circuit, I might as well add the indicator LEDs too.  I unfortunately arranged the board poorly.

I later rearranged it to have space on the board for a ZIF socket to direclty program ATMega or ATTiny chips, which I'll show in a future post. (Yes, the layout bugged me to the point that I wanted to rearrange it.)

In any event, using this new circuit was easy.  Plug the board in. remove the 3 pin jumper, dump the ArduinoISP project onto the host.  Then shove the jumper back in place, plug in the target, select the target device type, and shift-click "upload", and I was able to get 100% success rate on every single widget I wanted to program.

The next issue was the crystal speed.  I posted to the Arduino forums, asking how to rebuild the bootloader myself.  Long story short (which you can read there), after some suggestions for replacing crystal and such, which I was about to do, Tom Carpenter responded with not only a compiled bootloader for this specific frequency, but with very detailed instructions about how to get it working.  Thanks again, Tom!

I got this all set up on my system, downloaded the firmware to the widget, then plugged it in through the original FTDI cable I made earlier, and I was able to get the modified blink code above to work, while programming it through the standard Arduino interface without issues!  I then extended the code to read and write serial to control the LED, just to prove that I was able to do everything on this.

I felt that the next important step was what I call "self hosting".  This step replaces the host Arduino, the one that runs the ArduinoISP software, with another D15 widget.  With the help of getting the definition of the board above, this was just as hard as making up a wiring harness.  On this one, since I could disable the reset line by simply disconnecting it, I did this instead.  On the FTDI interface board, there's a small white jumper that I can remove or install if I want to enable or disable the reset from the host computer.

This gets a little complicated to look at, but basically the top D15 connector is the host that runs the ArduinoISP software, and the bottom is the target device that will be getting programmed. If you notice D10-D13 are connected from the target (pins 4-7) directly up to 5-8.  The reset line of the target is connected to D10 on the programmer, so that it can reset the target.

In execution, it's a little easier to understand.  The above shows the FTDI board connected to a USB cable on the left, and the interface board with its white jumper in the top center.  Next is the host device in the bottom right, which contains the programmer software.  Then the center-left connector is where the target plugs in.

I was concerned about the timing being slightly slow (9% as mentioned above) affecting programming of the target devices, but it turned out to not be an issue.  Like the above one, using a shield and a real Arduino, this is also 100% reliable as far as reprogramming target devices.

At this point, it's basically done.  I've fully documented the widgets, I'm able to reliably program them... Next up was to show off a bit.  The first thing I did was the above. I wrote a simple Arduino sketch that rotates the stepper 360 degrees, then rotates it the other direction a random amount, blinking the LED.  I set this on my desk at work with a Tron Light Cycle, using a stepper that mostly worked, just as a slap in the face to them saying "look... these things are actually usable!"

I decided I wanted to play with charlieplexing some LEDs, (article to come in the future), so I made the above interface board (which I could also plug into a standard Arduino for debugging it).  I plugged this one in to a 9V battery, and left it on my desk.  On the display I had it flashing the text "(company name) RULES! !"


All of this happened a couple hours here and there, a few hours at the workbench at home, a few hours at the workbench at Interlock.  Probably 20 hours total, stretched out over a couple of weeks, with the end result that I now have a huge amount of Arduino-programmer-compatible microcontrollers for free!

Soon, I'll tell you about a project to use these things; using dental floss containers as project boxes!

NOTE: There is an addendum to the circuits in this post over here.