Rapid prototyping with TI Stellaris: Easy and...fun?

At Nuvation, we like to do a little something different when one of our engineers gets married. Oh sure, we treat him to the standard bachelor party “festivities,” but we also use the engagement as an excuse for ever more ridiculous pranks and ever more fear-inducing stunts. I am happy to say that so far nobody has died.  This time around, my colleagues and I decided to kidnap, and then forcibly confine the lucky bachelor in a contraption that would require all his engineering skill to escape from. The task of building the confinement apparatus was taken on by myself and my good friend and colleague, Eliot Barker.  I would do the firmware, he would handle the mechanicals, and we’d share the electronics effort.  By the time this bright idea took shape, there was only one week left to design the confinement system, so this prank ended up being a fun application of rapid prototyping!

To get the job done, we turned to an ARM Cortex-M3 based MCU evaluation platform to bring the puzzle to life.  These kinds of easy-to-use development kits are often used as rapid prototyping platform in our “day jobs.” This article reveals the diabolical details of our design, and of course, how the event unfolded on the big day.

The Design
Nuvation is staffed by passionate engineers, and many of us spend our free time building combat robots, electric vehicles, RF/MCU-controlled flamethrowers, and other fun projects that tread the line between awesome and lethal. For this bachelor-party prank, we wanted to include a puzzle, giving the bachelor the ability to think his way to freedom.

We came up with the idea of confining the bachelor to a custom-built crate. Escape from the crate required some careful interaction with its contents.  The first thing one is confronted when thrown in the crate (aside from total darkness) is the “mystery box”.  The mystery box was to be utterly incomprehensible at first, but would reveal its secrets as the cause and effect relationships it exhibits are discovered through careful observation and analysis. The face of the mystery box is shown in Figure 1. It consists of the following:

1.   A four digit, seven-segment display
2.   Twelve relays, clearly wired in series, with 12V incandescent light bulbs to illuminate them when energized
3.   A push button between the seven-segment display and relays labeled “Test”
4.   A series of user inputs along the bottom of the mystery box consisting of
       1.   A push button labeled “Engage”
       2.   A key lock
       3.   A three-connection screw terminal strip

We also left a brown paper mystery sack of seemingly random passive and active electronic components.  The bag was accompanied by a breadboard on the floor of the crate.  Datasheets were stapled to the walls for inspiration.


Figure 1: The Mystery Box in all its glory. The decimal point is a soldering error I was too tired to debug after all this night-work.

Once the lock engages, the 7-segment display is initialized to “3987”. Pressing the “Engage” button decrements the number displayed. The “Test” button causes the relays to light up in a seemingly random order. The box’s functionality is otherwise hidden, but waiting to see what happens is a bad idea. After three minutes, a deafening sound emanates from the box and the seven segment display flashes “8888”. All the bachelor can do at this point is reset the device using the key lock, which returns the display to “3987”.

The trick to escaping is figuring out that the relay pattern is not random, but is in fact a twelve-bit binary representation of the value in the seven-segment display. It then follows that to engage the twelve series-connected relays, the seven-segment display must read “0000”. In other words, the number must be decremented 3987 times before the next three minute timeout. After some frantic experimentation, it will soon be deduced that this is an impossible feat to accomplish by hand. (Cue maniacal laughter!) And so the problem has been defined.

The solution lies in the miscellaneous electronics sack. In short, the counter must be decremented electrically by connecting an oscillator to the screw terminal strip. Some experimentation with the “IN” terminal and some jumper wire will show that it is possible to decrement the counter the same way as the “Engage” button does. The bag of components provides the means to build a multitude of different oscillators, from ring oscillators, to relaxation oscillators, to crystal oscillators, 555 timers, you name it! However, the simplest and most elegant solution is to use an ordinary relay, the one unique item in the bag.

The Implementation
How did it all come together? Well, after a couple all-nighters leading up to the event, I’d say it came together rather splendidly!

At the heart of the mystery box design the LM3S811 Evaluation Kit from Texas Instruments. It’s cheap, small, and it breaks out every usable I/O pin to 0.100” pitch pads on the board, with each peripheral function clearly labeled. It has a JTAG programmer/debugger built right onto the PCB.

Firmware development took advantage of the StellarisWare peripheral driver library, which is a set of functions that utilize every peripheral and system control feature on the MCU. The library comes complete with detailed documentation and examples. The library is designed more for clarity than for efficiency. There is some processing overhead in using these functions, as most are simply wrappers for simple register accesses. There is also some overhead in keeping the functions flexible and generalized. For a production application, this overhead may or may not be acceptable, but the library is an excellent way to quickly get started and prototype basic functionality.  Using a tested, known-good peripheral driver library meant that there was less concern over finding bugs in MCU configuration and peripheral interaction, allowing us to focus on the problem at hand.

Below is an excerpt of the “mcu_init()” function that sets up the clocking and enables the required peripherals. All we need are a few simple function calls and we’re off and running.

//initialize system clock to 50Mhz and use the external oscillator
SysCtlClockSet(SYSCTL_SYSDIV_4  |
               SYSCTL_USE_PLL   |
               SYSCTL_XTAL_6MHZ |
               SYSCTL_OSC_MAIN);  //reset peripherals
SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOA); SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOB); SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOC); SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOD); SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOE); SysCtlPeripheralReset(SYSCTL_PERIPH_TIMER0);  //default configuration: MCU will not enter sleep modes SysCtlPeripheralClockGating(false);  //enable peripherals
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD); SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE); SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);

                

The convenience of the driver library illustrates the broader design philosophy of the Stellaris MCU family. After reading through the LM3S811 datasheet, it becomes clear that the MCU was designed with ease of use (i.e., lower NRE) in mind. One example of design for ease of use is the fact that peripheral pin functions are muxed only with a GPIO pin. This eliminates the need to meticulously allocate peripheral utilization, and makes it clear what functionality can be achieved with a given part in the MCU family. Another example is the predefined set of usable crystal oscillator frequencies. Being limited to a fixed number of frequencies may seem constraining at first, but these correspond to commonly available crystals, and it simplifies the clock setup considerably.  The net result?  Getting up and running quickly and writing C code to frustrate our victim, instead of being victimized by frustrating C code.

To return to the mystery box, the system design is shown in Figure 3. The seven-segment display was hand-wired to a controller IC. The relays and the buzzer were toggled through a couple of 8-input Darlington transistor arrays. These arrays are handy for high current GPIO buffering, and they even have protection diodes built in for inductive loads! The lightbulbs were hand wired directly to one of the two relay outputs.


Figure 2: System block diagram. See larger version.

The whole contraption was hand-wired well into the morning of the event, with software being tested incrementally as the electronics took shape. In the end, two chunks of prototyping board were used and directly wired into the MCU eval board with ribbon cable to keep things neat and tidy. (Oh who am I kidding, it’s still a rats nest in there…) All electronic components were sourced as 0.100” pitch through-hole (usually DIP) to accommodate the use of the prototyping boards. The prototyping boards themselves were sourced as plated double sided parts to reduce the wiring effort, well worth the extra cost. The confinement crate, door lock pneumatics, and mystery box enclosure were developed in parallel with the software/electrical effort.

The software came together fairly well once the seven segment display driver timing issues were debugged. (Who needs setup and hold times anyway?) The basic program flow is pretty straightforward. Program logic was implemented with polling loops to keep things simple and avoid any difficult to find bugs that often occur with haphazardly written interrupt driven code. Edge detection is done by polling on high and low levels from the button/auxiliary input. Even the button debouncing is done by simple, dumb, ugly delay loops.

The only interrupt used was the Timer0 timeout interrupt to count the three minute timeout delay. The use of this interrupt was simplified since after the three minutes was up, the program simply became unresponsive. (The ISR actually has an infinite loop right in it--don’t try this at home!) The intention is that the program hangs here intentionally until the key lock resets the board, starting the program all over again; a convenient simplification. See a flowchart depicting the program flow. In summary, an elegant implementation was intentionally traded off against debugability, low implementation effort, and deterministic and robust operation in order to meet our tight deadlines.

How it Went Down
A lot of effort was invested in making this challenge not only memorable but challenging and creative as well.  After having worked through the night, and transported the crate to the bar where the unsuspecting bachelor thought he was done with his ordeal, we finally sprung it on him.  What we find is a little unsettling, but should in no way be surprising.  There he is, big smile on his face, eyes slightly glazed, happy to see everyone.  Our otherwise smart, clever, studious bachelor was…in no shape to think coherently; much less solve cleverly designed engineering challenges.  It became clear at that moment that this may not go as smoothly as we had hoped…

Nevertheless, we “introduced” him to his new home, and sure enough, he did open the bag of components.  I know this for a fact because the first screams emanating from the air holes were not, “let me out!” or, “it’s dark in here!” but rather, “electrolytic capacitors?!  I hate electrolytic capacitors!!!” Success!


Murat Ozkan is a Lead Design Engineer with Nuvation and is based in San Jose, CA.  He is a graduate of Computer Engineering from the University of Waterloo in Canada.  In his spare time he likes to take long walks on the beach and building things that shoot fire.  Murat assures us all that no bachelors were harmed in the making of this article and the bachelor fully passed acceptance testing with his future wife after the event.”