Alright, I've been called out...

It's true, I haven't visited this site until now...sorry about that. Gotta say I'm impressed now that I've finally read through it though. Really does justice to all the hard work behind the magic. Hopefully with his thoroughness and inspirational storytelling Chris has somehow managed to whet your appetite for an inside look at the hardware and firmware that make up the electronic subsystem - or what I like to call the Serial User-authenticated Power Ring Identification System (SUPRIS). If not, come back later and hopefully I'll have a picture up.

Overview:
The main goal of the electronic subsystem is to communicate with the iButtons and release the sliding platforms when all five iButtons have been locked in. It will be battery operated so that the table doesn't have to be plugged in and it can be switched to manual mode so that the sliders can be released with the push of a button in the event that one or more of the iButtons are missing.

Hardware:
The core of the electronic subsystem is a PIC 16F690 programmable microcontroller. In a small dip package, this bad boy packs a shit-load of features including 15 I/O ports, which is enough to cover our 5 iButton data lines, 5 output LEDs, motor driver, manual override switch and release button inputs. The I/O pins can source or sink 25mA, which is enough to drive our LEDs directly. And since it was a leftover from an old project, it also has a nice little board with a 5V regulator and Molex connectors all wired up.

The PIC extracts the serial number from the iButtons via one line serial communication. It issues commands by raising or lowering the data line for precise periods of time as brief as 15 microseconds. Once the iButton has been initialized, it reports its unique 64 bit serial number one bit at a time.

The motor that drives the spring-loaded latches is a small geared DC door lock motor that you might find in a small car. It is controlled via a half-bridge motor driver chip.

Power for the electronic subsystem is provided by a 7.2V rechargeable NiCd battery.

Basically, we don't have to do to much design on the electronics. We've got all the pieces and we don't need any fancy circuits - it's just a matter of testing it and wiring it up.

Firmware:
The one major downside of most low-cost PICs is that they must be programmed in assembly language. Once you get used to it, assembly isn't that bad, but it's definitely more time-consuming than programming in C. In any case, the firmware for the microcontroller was designed using the classic "events and services" structure. What that means is that after some initialization, the microcontroller runs continuously through a loop in which it checks to see if a new event has occurred (new iButton detected, input switch flipped, timer expired, etc.) . If there is a new event, then the microcontroller services the event depending on the "state" that it's currently in and continues checking for new events. In our case the state diagram is really simple - basically just two main states: Manual Mode and Waiting for Rings.

All the real complexity of the code is associated with the iButtons. They need a pretty precise, clean signal before they'll talk. I have old code that successfully communicates with the iButtons, but it requires fine tuning to accommodate the changes in our hardware and code. So for now, I'm pretty much stuck until I can get access to an oscilloscope.

That's the story. I can't wait till it's done so we can start integrating the hardware with the table itself. Come back soon for pictures.

PK