Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Embedded
?
?
Embedded??

How can they learn?

Posted: 27 Dec 2004 ?? ?Print Version ?Bookmark and Share

Keywords:digital logic? computer programming?

Part Rube Goldberg, part Tinker Toys, Jack's retro toys are taught the basics of digital logic and computer programming in an unusual way.

Pity the poor, underprivileged school kids of today. Oh, sure, they have their X-Boxes and PlayStations and Gameboys. They can watch educational shows on TV like Discovery Channel, Learning Channel, Cartoon Network-er, Science Channel and such. They can play organized hockey (ice, field, or roller), gymnastics, swimming, and soccer, and get driven to and from them all in their moms' SUVs.

But can they learn by doing?

It was different in my day. Before I was six, I had taken apart my model railroad engines and cars and my mother's clocks. By the time I was seven, I could get them back together again, working better than before. Before I was twelve, I had taken apart my bike's Sturmey-Archer 3-speed hub, figured out how it worked, and put it back together (hey, if you've ever seen the inside of one of those planetary wonders, you'll appreciate what an accomplishment that is. When you open it up, little springs go flying out in all directions, and dozens of loose ball bearings come bouncing across the workbench).

Of course, we had Erector sets, electric trains, and chemistry sets. Those things are still around-sort of-but greatly emasculated by safety concerns. Can't have a motorized Erector set; Junior might pinch his fingers. Can't have a chemistry set; he might drink the acid. Can't have a model steam engine; he might get burned.

When I was a kid, I got burns and pinches galore, but I learned a lot.

Contrast that with the kids of today. Say a kid opens up a clock; what does he see? He sees a battery, a chip, and a digital display; not much else. How does he figure out how that works?

Today's electronic gadgets are wonderful to have and handy to use, but as mechanisms for learning they're useless. Everything that goes on, goes on inside little plastic chips and happens much, much too fast for any human to see, even if you could somehow see the electric voltages. What the world needs now is gadgets that let kids understand what's going on inside their electronics.

We've wrapped up the series on digital circuits and symbolic logic. But before I move on to the next topic, I want to tell you about a couple of guys who sought to fill the void of understanding of things digital, and the wonderful machines they built. A few of you may have heard of them; most will not.

DigiComp
The desire to teach kids about digital gadgets inspired ESR Inc. to devise machines that behaved like computers. In their manual for their first offering, they explained that digital electronic circuits are just too cold and impersonal for kids to understand. Even if you slow the circuits down from nano- and microseconds to seconds, you still don't get any hint as to what the circuits are doing. First they're on, perhaps, then they're off, but you have no clue as to what happened to make them change state, or how they did it.

The DigiComp people wanted something that a kid could hold in his hands; that he (or she) could feel, touch, and watch operate. They decided that the best solution would be something that was not electrical, but mechanical. Being hand-operated, the kid could operate it as slowly as he pleased, and watch the exquisite motions to his heart's content.

ESR Inc. is long gone, and the names of the principals have faded into history. But interest in them remains. See the Yahoo group for a picture of the first DigiComp, plus all sorts of background info. See also the manual for detailed pictures of it. I won't attempt to draw the mechanism here, but I can give a brief overview and description. (Additional pictures of Digicomp I and II are available online

DigiComp doesn't really compute anything. Its purpose is not to teach digital computing, but rather digital logic like gates and flip-flops. The general layout is shown in Figure 1.


Figure 1: The DigiComp layout

A DigiComp flip-flop is the ultimate in reductionism. It's simply a flat plate that can sit in one of two states (can we say, bistable?). The three flip-flop plates slide through slots in the supporting structure, and the bumps on the bottom keep them from sliding out of position. Attached to each flip-flop is a numeral 0 and 1. Depending on the position of the flip-flop, one of the numbers shows through a window (white in the figure). Right is 0, left is 1. So the flip-flops in Figure 1 indicate 101, which could mean the binary number five, or any set of three binary digits. The DigiComp can represent any logic state that can be encoded by three bits.

Every computer needs a clock, and DigiComp has one. This one is manually operated. The clock consists of two more sliders, one of which has a handle at one end. The two sliders are connected through a crank mechanism, so that when one slider goes left, the other goes right. Figure 2 shows the general idea, though the real linkage is not quite as simple as I've shown.


Figure 2: The DigiComp clock

The next part of the "circuit," I won't even try to draw; it's both complicated and ingenious. This is the real guts of the system. You can get an idea of the way the parts look from the Yahoo group.

Affixed to the frame of the DigiComp are twelve C-shaped levers bent from heavy wire, six in front, six in back. The levers run the height of the framework and can pivot as driven by the clock. They are spring-or, rather, rubber-band-loaded.

The wires in front are sense wires; they allow the machine to tell if a given flip-flop is in the 0 or 1 state.

The wires in the back are actuator wires. They move the flip-flops to the left or right, which is another way of saying that they can set or clear them.

Molded into the front of each flip-flop are six tabs about three millimeters wide. They're spaced to contact sense wires. There's another set of similar tabs on the back.

Now, here's where it starts to get good. Both the sense wires and actuator wires are moved inwards and outwards by cam-shaped ramps on the clock plates. A set of plastic links loosely connect the sense wires and actuator wires, in such a fashion that if a sense wire moves inwards, it pushes the corresponding actuator outwards. If a sense wire is allowed to fall inwards (from back to front), it holds its corresponding actuator wire out and prevents it from being engaged by the clock sliders. If not, the actuator wire is grabbed by the clock and dragged sideways, which allows it to set or reset a flip-flop.

Now for the best part of all: The system can be programmed by pushing little plastic tubes-they look like sections of plastic soda straw-onto the tabs on each flip-flop. The tabs are too short to contact the wires directly; only if a programming tube is pushed onto a tab does it hold the corresponding sense wire out. Likewise, tubes on the back side determine whether an actuator wire actually does anything. If a tube is present on the back, the flip-flop is moved left or right by the corresponding actuator wire.

The end result is a set of three flip-flops and six gates, able to set or clear each flip-flop according to the current state. Each state can cause a new state upon the next clock cycle, and the progression is entirely programmable. Is that neat, or what?

The simplest DigiComp "circuit" does nothing at all. Whatever state the system is put into, it will stay there. That's achieved simply by putting no action tubes on the back side.

Perhaps the next simplest is to set or clear all three flip-flops, regardless of their current state.

I guess the circuit programmed most often by most of us was the simple binary counter, counting on a scale of eight. With only three bits, you can't make a decimal counter, but a base-5 counter is easy.

But flip-flops, like light bulbs, don't have to represent only binary numbers. Any input states can be used, and any output states, and they don't necessarily have to mean the same thing. For example, I programmed a "circuit" to simulate a house environmental control system. Some of the rules went like this:

  • If it's hot inside and hot outside, shut the windows and turn on the AC.
  • If it's hot inside and cool outside, turn off the AC and open the windows-unless it's raining.
  • Get it? The three inputs are temperature inside, temperature outside, and rain. The three outputs are AC, heat, and windows.

    Sadly, ESR is no longer with us-they didn't last long. But those among us who loved their products mourn their loss.

    DigiComp II
    The company's next product was, in many ways, even more cool. Though radically different from the first DigiComp (which I'll now call DigiComp I) it was far more ambitious and a lot more intriguing to use.

    DigiComp II was a true computer. Unlike DigiComp I, it couldn't be programmed except in the sense that it would do different math operations. Its purpose was to show kids how the operations of a real computer can be implemented.

    DigiComp II had an inclined board, much like a pinball machine. It was actuated, not by hand, but by marbles rolling down its surface. Its operation was asynchronous rather than synchronous; the treatment of each flip-flop depended on the state of the previous one. In the world of counters, we'd call it a ripple counter.

    As with DigiComp I, the heart of this machine was the flip-flop. Only instead of being actuated by a master clock, this one was actuated by a marble. The DigiComp II flip-flop was much more simple. Figure 3 gives the general idea.


    Figure 3: DigiComp II flip-flop

    The flip-flop is a simple piece of plastic, rotating about a pivot. It's weighted to be bistable in either position (stops keep it from going further). Little numbers (not shown) on it denote the 0 or 1 state.

    Whenever a ball rolls down from above, the flip-flop changes state. Further, the ball is deflected left or right, depending on the current state. This lets us do two things. First, we can change the state; second, we can sense what the previous state was or, if you prefer, what the new state is.

    Now look at the truth table in Table 1, which shows the states of a binary counter.

    PB Table 1: Binary counter truth

    Before After
    0000

    0001

    0010

    0011

    0100

    0101

    0110

    0001

    0010

    0011

    0100

    0101

    0110

    0111

    If we're willing to settle for a ripple counter rather than a synchronous one, the operation is ridiculously simple: A given bit only changes state if the previous (lower-order) one has just changed from 1 to 0. This property lets us build a binary counter from a set of flip-flops like those in Figure 3. I'll show just two bits of such a counter. Extension to more bits is obvious. The DigiComp II had seven bits (pity it wasn't eight).

    As you can see, if the flip-flop is currently a 0, as shown, the marble changes it to a 1, and then rolls harmlessly into a hole, that takes it "out of play." It rolls beneath the active surface to a trough at the bottom.

    But if the flip-flop is a 1, the marble resets it, then ripples down to the next stage. There you have it: A working binary counter, implemented in marbles and plastic. It's great fun just to sit there and watch the counter go through its cycle.

    What about arithmetic?
    A counter implemented in marbles and plastic may be cool, but it's hardly a computer. Much more is needed. And DigiComp II had it.

    The key to understanding the arithmetic unit is to see that counting and adding are obviously related. One simple way to add two numbers would be to include a second counter, into which we could set the addend. Count the addend down, while counting the augend up. But that takes awhile. Worse yet, to keep things synchronized we have to have one marble ripple through both counters (even though its path is different when a bit is 0 or 1).

    A much better approach, and the one implemented, would be to add the same way we might do by hand: Add the 1's column to the 1's column, the 2's column to the 2's column, and so forth. Done this way, we only need one marble for each bit, not one per count.

    In this design, the addend doesn't need to count, because each bit is only used once. Therefore the addend register doesn't have the bistable flip-flops, but simply toggle switches that happen to route marbles in the proper direction. If a given addend bit is a 1, the marble for that column goes to the corresponding bit of the accumulator. If it's a 0, the marble simply falls out of sight.

    The next step shows the extent of the designers' ingenuity. To add the two numbers, we have to send a marble into the trough for each bit of the addend. But that would require us to steer it manually. Not good. So the DigiComp folks gave us yet another register; this one a three-bit counter that counted down from seven, then started over. At each count, it routed the marble into one of seven troughs, thereby adding all seven bits. Is that cool, or what?

    Subtraction
    If you think adding with marbles is cool, wait'll you see subtraction. The key to subtraction is the use of 2's complement arithmetic. As in real computers, a number with the high bit set is interpreted as a negative number. To subtract two numbers, change the sign of one of them, and add.

    Most of us remember that, to get the 2's complement of a number, you first take the 1's complement, then add 1. To get the 1's complement, you simply flip every bit to its complement.


    Figure 4: A DigiComp II counter

    The counter shown in Figure 4 can't accomplish the 1's complement, because a marble drops out if the bit was a 0. To give the 1's complement, the DigiComp designers had another stroke of genius. The added a second set of flip-flops and troughs, connected by short shafts to the first set, and residing in a sub-floor below the visible accumulator. It took two marbles to complement the number; one to flip all the bits, and a second to add 1 to the result. Yet another counter, this time a 1-bit counter, took care of the sequence.

    Multiplication and division
    Multiplication was accomplished the hard way: By successive addition. The multiplicand was dialed into yet another register, this one counted down as we considered for the addend. The multiplier was dialed into the addend register, and the multiplicand register fed it marbles until the counter reached zero.

    Division was done in the usual fashion, by subtracting rather than adding the multiplicand. Because division requires us to know when the subtraction has gone far enough, there was a gadget to sense overflow of the high bit.

    Automating the process

    You might think that it could get really tedious, not to mention error-prone, to route all those marbles down the proper channels, and know when to stop sending them. Relax. DigiComp II did it all automatically.

    At the top of the pinball-like machine, was a trough able to hold a couple dozen marbles. An escapement mechanism, operated by a lever, released only one marble at a time. At the bottom of the gadget, marbles rolled out of a trough that tripped the lever, releasing the next marble.

    Now comes the coolest idea of all: Each operation, be it addition, complementation, or multiplication, had an end condition. In the case of multiplication, for example, the end condition came when the multiplier was counted down to zero, and the last bit of the addend had been added. When that happened, the marble fell into a different hole that bypassed the trigger and ended the sequence.

    Using this mechanism, you could add, subtract, complement, multiply, and divide, all under the guidance of a series of flip-flops that routed marbles down the right troughs. You specified the operation by manually set guides, also known as switches.

    DigiComp II represented a huge advance in teaching digital arithmetic by means of mechanical devices, but it wasn't perfect. Its Achilles' heel was its construction. To make all the features work, the machine needed a set of ball guides that routed the marbles to the right places. Those guides were built into a vacuum-formed plastic cover that was bonded to a heavier cardboard surface.

    Unfortunately, vacuum-formed plastic gadgets tend not to be perfect. The sharp corners in some of the guides tended to get wrinkles, and those wrinkles could, and sometimes did, send marbles bouncing out of play completely. When that happened, which was fairly often, the computation was ruined.

    To be honest, I don't think it mattered all that much that the thing was imperfect. After all, no one in their right mind would attempt to use DigiComp II as a desk calculator. It wasn't intended for serious computation, but rather to teach principles. In that department, it excelled mightily. Even so, the occasional failure was not fun, and if you were demonstrating the thing to someone-which we tended to do regularly-the effect was thoroughly lost when a marble went astray.

    The modern DigiComp-a proposal
    I've thought of the DigiComps a lot over the intervening years. At one time, I dreamed of building the ultimate, precision DigiComp II, say with its "playing board" machined out of billet aluminum. Needless to say, that would be a very expensive toy for anyone but Bill Gates.

    There is a way, however, that one can develop zero-defect versions of both DigiComps: Simulate them in a computer. While we're at it, we could make the accumulators as long, and the gates as numerous, as we choose. Perhaps we could start with a default set-three flip-flops and a seven-bit accumulator, but the user could add bits to his heart's content, from a collection of parts. We could also make the clock speed anything we choose. Slow it down to many seconds to watch the details; crank it up to kilohertz or higher, if we're impatient to see the result.

    If I were going to write such a program, I think I'd want to implement more than one kind of machine. Some could be serious, like marbles or even electronic flip-flops; some could be whimsical, like Rube Goldberg machines.

    Some years ago Scientific American ran an April Fools' article where some explorer claimed to have discovered remnants of an ancient computer, built by Aztecs out of rocks and vine-derived ropes. I forget the details, but an or-gate, for example, involved a rock with two ropes tied to it. An inverter was a simple rope over a pulley.

    If I were writing a computer simulator, I'd definitely want to include the Aztec computer.

    You may have noticed a certain irony in the direction of this column. I began by bewailing the fact that today's kids never get their hands dirty anymore. They don't have clocks or bicycle transmissions to take apart. I'm ending by proposing yet another PC-based excuse for going out of doors.

    Yes, I agree, it is ironic. But in this case, I think the fun and the opportunity for learning might very well outweigh the loss of Vitamin D.

    - Jack W. Crenshaw
    Embedded Systems Programming

    Jack Crenshaw is a senior software engineer at Spectrum-Astro and the author of Math Toolkit for Real-Time Programming, from CMP Books. He holds a PhD in physics from Auburn University. E-mail him at jcrens@earthlink.net




    Article Comments - How can they learn?
    Comments:??
    *? You can enter [0] more charecters.
    *Verify code:
    ?
    ?
    Webinars

    Seminars

    Visit Asia Webinars to learn about the latest in technology and get practical design tips.

    ?
    ?
    Back to Top