Having considered digital inputs and outputs, you’ve already seen more than 50% of a toy’s hardware. Oh sure, we should talk about the fancier sensors, motor control, and audio outputs but those are one-offs, specific to a toy’s particular function. Many toys don’t have them or only have one; buttons and lights are enough for some toys.

I’ve mentioned the processors in the toys a few times. I can’t show you what is inside the software (partially because the designers sensibly locked out the ability to read the code from their processors). I can show you how to figure out what is in the software without breaking any laws or copy protection.

The very first thing you’ll want to identify in your system is the state machine. These can be hideously complex but, like the electronics, it is easier if you look at smaller parts, building up to a whole picture.

I’m going to start by showing state machines with flowcharts. I have a friend who calls them “flaw charts” because they are never quite right. It is easy to make mistakes and, with anything that’s complex enough to be useful, flowcharts are invariably messy. Also, as programming tools, they can lead to truly awful code (if you are considering a goto as the easiest way to make a desired change, please rethink that decision). However, as a discovery tool, drawing a flowchart is fast and easy. It will give insight about the workings of the software in ways that simply interacting with the device can’t.

Let’s start with a simple one in karaoke.

Karaoke Disco Lights

If the disco button is off, pushing it turns it on. This causes the LED 1 string to turn on until a timeout occurs. Then LED 1 string turns off and LED 2 string turns on. This timeout event repeats until disco button is pressed, turning both LED strings off.

As unpretentious as the flashing lights are, it is a state machine: what happens next depends on what is happening now (its current state) and what new event occurred. Events can include user events, like pressing a button, or internal events like timers expiring. Look for loops that occur, cycling through one state after another. Many times we look at state machines through flowcharts as in Figure 4-1.

This state machine isn’t complete: I didn’t put in states to indicate the LEDs turning off. I let them be implied because including it would have doubled the size of my chart. That’s ok, we know how it works, but the designers of a toy have to be careful to specify all the details. My favorite bugs occur when someone failed to think about what happens when a user presses an unrelated button.

While most state machines are implemented in software, the one controlling the karaoke disco lights is entirely electronic. Figure 4-2 shows the schematic for this flasher circuit.

So, that’s a flowchart and a state machine. The electrical circuit implementation is far more complicated than the concept of states and events.

Quadcopter Power On

The controller has to pair with your quadcopter. It has a state machine that runs when you power it on so that it can connect (aka “pair”) to your quadcopter instead of your friend’s. As shown in Figure 4-3, you have to put the throttle joystick all the way down, switch on the quadcopter, turn on the controller, wait for beeps, throttle up, wait for another beep, throttle down, one more beep then ready to fly. It’s simple really. (Not really.)

As before, the state machine has states, user events, and internal events (such as controller ready, indicated with a beep or two). There are transitions between the states, caused by user events. When I’m trying to figure out (or even write) a state machine, I often try to imagine myself as the device and keep asking “what happens next?” If we wanted to write this as software code, it would be a series of actions separated by conditional (if) statements.

Note that this state machine is not from the device’s perspective. In the power-on sequence in Figure 4-3, you are the computer. You are the one who puts the throttle up, waits for a beep, puts the throttle down; you are running through states, choosing when to go to the next one based on input from the quadcopter (LED) and the controller (beeps).

If we look at what is happening from the controller’s perspective, the state machine looks a bit different as shown in Figure 4. All the pieces are similar but since you are doing the work, the controller spends time waiting for your events.

State machines often depend on perspective. When you create or document a state machine, you have to choose which way you're looking at the state machine: as the user or as the processor. Getting the perspective confused while making a state machine doesn’t work (I know, I’ve tried).

Next week I'll have a much more complicated state machine to show you and a different way of looking at them.

This is a series. If you’d like to read them in order, check out the Taking Apart Toys index.