Digital Logic in Javascript...

I needed some time off from my main project right now, and I had this bug in my brain to try out some of this, so I did a thing.  It uses javascript, jquery, bootstrap, and css stuff to do the whole thing. I use some of this at work, so this was a great chance to learn a bit more about that tech.

So here's a link to the quickly and horribly named "Logicr", pronounced "lä-jik-ər".

It's essentially a tiny javascript library/set of classes that simulate digital logic.  I'm not going to start drawing out diagrams of class hierarchies because that would take too long to do.  Instead, i'll quickly explain a bit of it, and then explain what the interface is showing.

At the bottom level, there are objects that are "pins".  This is a thing that can be set with a low, high, or floating data level.  I made the level actually a value from 1-100, below 25 is "low", above 75 is "high" and in the middle is "floating".  When you read them, you get back a true/false value, and you can write the 0..100 level, or true/false.  I made it this way so that i can eventually simulate pullups/pulldowns in the circuits.

Those pins are included in "nodes", which have a collection of inputs and outputs.  One example of a node is a logic gate.  A typical gate has two inputs, A, B, and one output, Y.  When the nodes get their update() call, they do whatever math is necessary to read in from their inputs and set their outputs.   Currently the system supports the basic 1-2 input logic gates: Not, And, Nand, Or, Nor, Xor, as well as one-pin output "sources" that generate High, Low, and Float output.

Another node is a "clock".  This one toggles its output once a second (1000ms) between high and low levels.

Another type of thing in the system is a "wire".  Wires are just lists of connections "from" and "to" pins on nodes in the system.

In the above example, there's a clock node (XTAL1), whose output Y goes to the first LED, named "clk".  There's a second wire from XTAL1's output that goes to the input of a Not gate (Inverter), in-turn, whose output goes to the second LED, "!clk".

You may notice that they don't change instantaneously.  That's because the system is set up to update all of the nodes first, then update all of the wires.  This prevented having to actually generate a real directed graph, and deal with loops and recursion and loops and recursion and stuff.  It probably simulates propagation delay on real parts, but i'm sure it has its own unique quirks.

So every 50ms, it goes through and tells all of the nodes to do their math, then immediately goes through the list of wires, reading from their FROM and writing to their TO.

So for the clock circuit:

• Nodes:
• Clock XTAL1 running at 1000ms
• LED D1, blue, labelled "clk"
• LED D2, blue, labelled "!clk"
• Not gate IC1
• Wires
• XTAL1.Y to D1.A -- connects the clock to the first LED
• XTAL1.Y to IC1.A -- connects the clock to the not gate
• IC1.Y to D2.A -- connects the not gate to the second LED

That's the basics of it.

But there's more.

I added a few input devices and output devices.  First is the switch.  The switch is essentially a html checkbox at its core.  When the switch node gets called to update, it reads the value directly out of the checkbox widget in the browser, and sets its output pin to the appropriate value.  Similarly, the LEDs are just a "div" that's made round and the right color (dim/bright red, etc) via CSS.  When the LED nodes are updated, they read the value from their input pin, then apply the appropriate "on" or "off" class to their html div.  The browser and CSS take care of the rest.

There's a couple other things happening in the circuit there too...

The amber switches are the A and B inputs to an XOR gate.  The A and B switches also go to the amber LEDs with the same labels, so that you can see what's going on there.  The output from the XOR gate goes to the green LED labelled Y.

The four red switches labelled 0x01, 0x02, 0x04, and 0x08 are run into a sort-of ROM, implemented as just a simple 16 value lookup table.  The ROM has 4 inputs and 8 outputs.  The 8 outputs are wired to the red seven-segment display node's "a"-"g" inputs, which light up the segments of the display on the web interface.  As you toggle the switches, the appropriate number is displayed.  The ROM data is basically a lookup table of which segments to drive for each value 0x0..0x9,0xA-0xF.  The equivalent of the 74LS47 ic chip.  I was originally going to build this circuit using logic gates, but it got really complex...  I may still do it eventually, once i have a better editor.

Mess with it...

In the interface, if you scroll down, you'll see an editor section at the bottom. Press the "Load Default" button to fill the text box with the circuit description that's running, and you can see all of the logic nodes and wire connections. Press the "Run Circuit" button to read in the JSON content from that window and rebuild the internal logic to use it.  The content there has to be valid JSON, otherwise it won't work.  The "Run" button will have a green border when it's valid, red when it's not.

Future

So yeah. This was meant to be a quick test to see how well it could quickly be done, and expanded upon for a possible future project that I've been thinking about for a while. There are still more component classes I want to add, such as "packages" which can group together circuits... for example, creating flip-flops using gate logic, or building that 7-segment decoder, or more complex things...

I also would like to make an in-browser editor of the circuits.  I've been looking at jsPlumb as well as a few other solutions for doing "create movable boxes with connection magnets that are connected with wires" type of things.  I may just spin up something of my own, as having draggable boxes is fairly easy to do using CSS/JS and then connections are just SVG lines between them, etc...  Although i'm sure the nuances of the interface make it more complex than it seems...

Oh. and this is running in my tiny page thingy, llmin... It's basically a wrapper for a page that sets up jQuery, bootstrap, and some other stuff, so that I don't have to create that boilerplate every time I want to make a page to test stuff. ;)

RC2014/LL Showing ROM/RAM switching, 64k!

So I thought I'd just make a quick post to show how I know that the ROM swap hardware in my RC2014/LL is working. I'll walk through the procedure here...

First, I booted up the RC2014 as usual, which drops me into BASIC.  From there I wrote this short program:

10 FOR A = 0 to 8192

20 B = PEEK( A ) 

30 POKE A, B40 PRINT A 

50 NEXT A

What this does is goes through the lowest 8 kbytes of memory, reads (peek) and then writes (poke) the byte it finds right back to the place it got it from.   For example:

1. Read from memory address 0
2. Write to memory address 0
3. Switch to the next memory address, repeat 

Which seems stupid, that it does nothing.  But if you remember from a previous post, when the ROM is enabled, it's only enabled for reads.  Writes still happen to the RAM in the same addresses.  So the above program copies the BASIC ROM into RAM.

Next, we switch off the ROM by doing this:

 OUT 0,1

The lowest bit, '1' turns off the ROM, and switches to the RAM for read operations.  To confirm we're working out of the RAM, we can poke a 0 in somewhere down there.

PRINT PEEK( 0 )
 243
POKE 0,0
PRINT PEEK( 0 )
 0

So we can see here that memory address 0 has been changed from 243 to 0.

I also went one step further and yanked the ROM board out of my RC2014.  This is not recommended. ;)  But it did continue to run without any problems... until I really tried to muck things up, for fun:

I wrote a program to clear RAM, and then ran it in BASIC.  Here is the listing:

And here's what happened when i typed 'run'.  It completely locked up after it printed the '8'. Starting at memory address 0x0008 is the text output routine, so it cleared out the boot code before that (0x0000-0x0007), erased the beginning of the print handler, then went to print out something to the screen, and crashed.  Well, I assume it crashed. It got an invalid opcode and who knows what it's actually doing. The code there used to be a "jump" which is 3 bytes.  Instead it got a NOP, which does nothing, (0x00)  and then two garbage bytes which map to something incorrect. Boom!

RC2014/LL and RC2016/10

The RetroChallenge is upon us again!

This time around, I plan on working on my Z80 homebuilt computer, the RC2014.  (Website for RC2014, Order a RC2014) For a few months now, I've had my RC-2014 computer built, and modified to be an RC2014/LL computer. What this means is, is that I have some modified modules using no additional external hardware.

The above picture shows my RC2014/LL system with its extra RAM module, and the C0 Serial expansion board to the left, with the SD card interface board (SSDD1) on it.

The basics of this design:

Unmodified RC2014 modules:

• Z80 CPU module
• Clock module (* see below)
• Serial console interface
• RAM module (for RAM in the range $8000 through $FFFF

Modified RC2014 modules:

• Second RAM module
• ROM module
• Digital IO module

Additional hardware:

• Second ACIA Serial port at $C0
• SSDD1 (Serial SD Drive)

(*) While the clock module is unmodified, it technically is modified. I have added a 10 uF (50V) cap between the reset line and ground to be a quick-and-dirty power-on reset circuit. It works perfectly.  Every time I power on the computer, it "presses the reset button" for me. ;)

The plans to mod these parts are available here.  This is currently fully functional and tested. The modifications use unused gates on the boards, so that it requires no extra additional hardware or boards to implement. The basic theory to the /LL modifications are as follows:

Bit 0 (0x01) of the Digital IO module is tied to one of the extra bus lines on the backplane.  Let's call this "Extra-A".  When you do an "out" to that port of "0x01", it will trigger the Extra-A line.

The ROM module "out of the box" is configured such that if there is a memory access, which is a read from address $0000 through $7FFF, it will enable the ROM, and it will put its data on the bus.  My modification adds in one extra condition to this.  It adds in that only if the Extra-A line is LOW, that the ROM will be enabled.  This means that when Extra-A is 0, the ROM works. When Extra-A is 1, it's as though the ROM doesn't exist.

The RAM module "out of the box" sits at the high half of memory space ($8000-$FFFF), and is always enabled on memory READ or WRITE to those addresses.  The modification to this module is threefold.  First, it sits the RAM at the low half of memory space ($0000-$7FFF). Secondly, it is set up that WRITEs to this memory space will always work, regardless of Extra-A.  Thirdly, it is set up that READs to this memory space will ONLY work when Extra-A is HIGH.

The end result of this is that when Extra-A is low, reads in the low half of memory will come from the ROM.  When it is high, reads will come from RAM.  Writes ALWAYS go to RAM.

This is quirky...

I admit this.  It means that you can (and I will) write a bootloader/monitor ROM that is enabled on power-on, will read from a mass-storage device and write into anywhere in RAM... It can load a 64 k byte memory image into RAM, and then switch off the ROM and it will all work.  The quirkyness is that you cannot verify the loaded-in memory in the low range of ram, since reads will come out of the ROM.   Obviously, you also need to do this routine completely out of registers, as your stack variables will get overwritten if you're not careful.

Anyway....

If you want it to behave like a stock RC2014, remove the jumper from the IO board to Extra-A, and instead add a jumper from ground to Extra-A.  I have added a switch to mine to force this in the case where the IO board comes up in the wrong state.

Additionally, I have added a second serial port, which basically follows the circuit for the first port, but it sits at $C0, and does not have an interrupt line wired to it.  The RX/TX on that one comes out to a FTDI-like pinout header, which is where my SSDD1 module plugs in.  The plans for this serial port are available here, and can be seen as the brown perf-board on the left of the topmost image of this post.

The SSDD1 module...

The Serial SD Drive module is the mass storage module that I've created for my Z80 to interface with. I know that I can push the FAT filesystem support onto the Z80, but that would require substantial effort.  I instead decided to go with the model where I have a smart serial-based device that you tell it "i want this file" and it sends it out.  Like a local BBS. ;)

The use of a serial-driven drive is not unprecedented.  It's somewhat modeled after the Commodore 64/Vic 20's "IEC" serial interface for floppy drives.  It also mirrors it in that the drive has some smarts in it to deal with the drive architecture.

I also went this route for the ultimate form of this computer, which is to run CP/M.  CP/M expects drives with a Drive+128 byte Sector layout.  While other Z80-CP/M computers implement this by having direct interface to the sectors on the spinny disk/cf/sd card, I will do it by having files on the SD card, for the most amount of flexibility.  There will be a "drives" folder on the card containing folders named "A", "B", "C", and so on.  These letters are the drives.  In each of those will be directories for the tracks, named "0000", "0001", etc and in each of those, files named "0000" "0001" "0002" etc. These files are the simulated sectors on the disks.  It will be easy to build virtual drives for other use out of this.  It also means that I won't need some special interface on a modern computer to talk with this.  I won't have to do 'dd' style transfers to get at the data... It's all just sitting on a FAT filesystem.

The implementation of this module is based on an Arduino with a microSD breakout module.  The serial interface communicates directly with it, and it sends the content via serial back to the Z80 host.

The above picture shows the SSDD1 module off of the RC2014/LL expansion board, and instead wired to a breakout board where I have a second FTDI serial-USB interface so that I can debug the hardware more easily.

And that brings me to the current Retro Challenge...

My goals for this month is to do a few things here, to finish up this computer system...

• Finish up the firmware for the SSDD1
• Sector load/save support
• File load/save of intel hex files
• directory create, list, remove
• Write the SSDD1 emulation for the emulator
• Finish up the loader and burn it to a ROM
• Write a CP/M bios that uses the SSDD1 interface
• Build CP/M disk/sector files 
• Play Zork

Stretch goals:

• Extend the NASCOM BASIC to support the SSDD1 for loading and saving.

6502 - 24 Bit Math and a little BCD (RC2016/1)

I decided that another experiment/lesson to do on my way to making my calculator app was to learn how to do multibyte math and possibly experiment with BCD/Decimal vs Hexadecimal. (Or as Mark Watney calls them "Hexidecimals".

I kinda like breaking down this project into multiple "lessons" as it were.  It makes me feel like I'm following along lesson plans in a book.  Perhaps I should go the other way around and actually make the book I would be following if I were following a book to make this thing.

The code for this can be found in my github repository.

I broke down the application into a few main steps:

1. display the last result
2. add together the two previous results
3. store that sum into a result variable
4. repeat

When broken down further, we see that we also have to have some method for "kickstarting" it, as it were, since the first two numbers in the sequence do not follow the standard fibonacci sequence. (quick reminder: each value in the fibonacci sequence is the previous two values added together. very simple.  So, for the first two values, there is no "previous two" so they are just hardcoded as "0, 1"

Computation of the sequence can be described as :

1. hardcoded "0"
2. hardcoded "1"
3. use algorithm to sum previous two values
4. same as 3
5. etc

For doing the math, I wanted to have variables that mimiced the 3 bytes we are able to display on the KIM, so I use 24 bits (3 bytes) to store them.  I broke down the math functions to be generic in that they can perform using two variables ("i" and "j") and store their result in a third variable "RESULT".  From there, additional functions were created to move the values around between them.  For example, we need to "roll" the values through if we want to make this repeatable. So the computation sequence can be described as:

1. RESULT, I and J all set to '0'
2. refresh display RESULT "0"
3. RESULT gets "1"
4. refresh display RESULT "1"
5. shift the values through:
1. J gets I's value
2. I gets RESULT's value
6. add:  RESULT gets the value from adding I and J
7. repeat at step "4"

And this is basically the procedure as seen in the source.  

The multibyte addition was actually a lot simpler than I thought it was going to be. My first thought was "how could this possibly work if i were to add like 100 to 100... you end up with "2" for the carry instead of "1"."  Obviously, you can see the error here, but for some reason this got stuck in my head and suddenly, all of the multibyte (16+ bit) math seemed near impossible to deal with.  I think it was the multiplication that seemed hard, but when you break it down as multistep additions instead of multiplications, it all makes sense.  I blame this on the cold and fuzzy head I have right now.  I'm just not thinking right... also extra time at work... sure... and um... an ARP storm.  all contributing factors to not thinking clearly. ;)

The basic procedure for doing multibyte math is to observe the carry bit.  The carry bit is set when math on two 8 bit values exceeds the 8 bit container.  If you think of it in decimal, when you add 1 to 9, you get "0" with a carry of "1" which ends up in the next digit space, resulting in a "10".  So if you were to add 99 and 04, you end up with 03 with a carry of 1, resulting in "103".  Math on the 6502 is no different, other than we're (probably) using hex where the value can go from 0-9,a-f rather than just 0-9 for each digit.  The math for addition is basically:

1. for each byte (starting from the least significant on the right)
1. add one byte to the other, with the carry bit from the previous byte
2. store that result in the RESULT

Or, more precisely

1. clear "Carry" (Carry = 0)
2. register A gets I0 (A = J0)
3. add j0 to A.  (A = A + J0 + Carry)
4. store the result in RESULT0
5. A = I1
6. A = A + J1 + Carry
7. RESULT1 = A
8. A = I2
9. A = A + J2 + Carry
10. RESULT2 = A 

I think you can see that this can be carried out indefinitely for multiple bytes.

The "display the result" was pretty straightforward as well.  The "RESULT" bytes were stored into INH, POINTL and POINTH, and then the SCANDS function is called. This refreshes those three values out to the KIM's LED display.  Then a call to GETKEY stores the current key press value into the accumulator register.  If nothing is pressed, this fills A with $15, or KEY_NONE as I have it defined.  Then it just sits in a tight loop refreshing the display and waiting for any key to be pressed.

1. refresh display
2. check for key press
3. no key press? repeat at 1
4. return

So the end result is a program that advances to the next sequence number each time you press a key.

When it fills all the digits, when we get a "carry" on the third digit while doing the math, i display "EEEEEE" as a cheesy error display and wait for a press.  When something is pressed then, it resets and starts all over agian.

As for BCD, I basically have run the code both in BCD (decimal) mode and hex mode, just to see how it works out.  Turns out i was worried for nothing,  It all 'just worked' fine in both modes.

So yeah.  My throat is sore, and I'd love to just go to sleep right now.

6502 Learning (RC2016/1)... Video buffer sidetrack...

I got a little sidetracked while working on the KIM-Uno calculator, playing with video buffers. I had added a video buffer to the desktop Kim Uno Remix project. Ultimately, I want to make a compressed image decoder and viewer.. to draw sprites to the screen or full-screen images.

I've written stuff like this before back on the Z80 for Pac-Man hardware, so I thought it would be a fun exercise to see how something like this would be implemented on 6502. It gives me a good chance to learn addressing modes and methods for this architecture... which is very different than Z80's.

You can attempt to play along by using this web-based assembler system. I based the video buffer in KIM Uno Remix on this system.  There are a few differences though...

6502asm.com:

• 32x32 pixels
• 16 colors
• Commodore 64 palette
• starts at $0200, continues horizontally then down, starting top left
• one byte per pixel
• bottom nibble indicates the color ($00..$0F)
• top nibble is ignored
• code starts at $0600

KIM Uno Remix:

• is 32x32 pixels
• 16 colors
• Modified Deluxe Paint palette
• starts at $4000, continues horizontally then down, starting top left
• one byte per pixel
• bottom nibble indicates the color ($00..$0F)
• top nibble is ignored
• code starts at $0200

Here's the output from a small program (shown below) that shows off the palettes of the systems. The KIM Uno is on the left, and shows the very reasonable "rainbow" palette.  The one on the right shows the more convoluted "Commodore 64 palette" of the web tool.

The colored sections are 8 rows of 32 pixels across. Since there's only 16 colors, the color stripes get repeated twice along the horizontal of the screen.

The code to run the above was essentially identical on both systems but there are some tweaks to accommodate the addresses and some minor differences between the CC65 tools that I use and the web-based tool.

Here's the source code listing used for CC65, which generated the image on the left above.  You can see that it writes to two of the four banks of memory space, at $4000 and $4200, while not doing anything with the $4100 and $4300 banks, which is why we see two segments of stripes, and two segments of black in the above image. It is a very simple program that simply increments "X" and writes it to videobuffer[x].

And here's the source for the web-based tool.  I colorized it to match the above CC65/KIM Uno Remix listing.  Notice that the program is the same, although it uses $0200 and $0400 for the screen memory, skipping the $0300 and $0500 sections.  I also switched the "unnamed label" from the above code to be a label named "loop" for this one.  It apparently doesn't support that.

Living Room Planetarium (work in progress)

This was just a quick brainstorm that I'm trying to poke at with a pointy stick to see if I can make anything interesting happen with...

The basic concept is to turn as much of the entire ceiling of my living room into a planetarium as possible.  Earlier, I had the idea to project video onto the ceiling, and lie down on the floor to watch movies.  The issue here was that I was getting ghosting of the image since I didn't have a front surface mirror to use.  The image was also fairly small compared to the size of the ceiling.

This brought in the idea of using a tele-expander, magnifier or convex mirror to expand the image on the ceiling.  While cleaning the basement I found a somewhat scuffed, convex plexiglass baby seat mirror. Just the perfect thing to try out!

You can see in the above picture the results of this first experiment.  The projector is precariously hanging on the back of a cat scratching post thingy that our cat refuses to use.  It's pointing down onto the mirror, sitting on the floor.

The image projected onto the ceiling is nice and big, although there's a hell of a lot of distortion.  The surface isn't perfectly curved, it's pretty badly scuffed, and it's a back surface mirror, so the image is distorted, fuzzy and there are ghosts and smears of the star points.

One thing I did notice though was that when I used more of the mirror to reflect the projector's image, the final image looked better.  I dug out the 0.7 wide angle screw on lens for my old Canon Optura DV video camera, and shoved it onto the front of the DLP with rubber bands.  This both maximized the image onto the mirror, and increased the size of the final image on the ceiling. It's still far from perfect, but not bad considering that I put this together with some rubber bands and a cheap mirror...

For the star field generation, I used Stellarium, running on my MacBook.  That side of it works pretty well. ;)

Anamatronic Avian: Skeleton Experiments

I'm about to start making the skeleton for my animatronic Tiki-Room Macaw.  Rather than futzing with drawing up detailed plans in some cad program, Iv'e decided to instead get the basic shape made, and then just build one out of foam core.  My thought was that once I have the shape worked out, I'll disassemble it and come up with plans for 3d printable parts that can be attached together, and eventually some vacuum formed parts as well for the head and beak, which need to be lightweight... although I'm starting to think that they could all be 3D printed, with a skin stretched over them for feathers and fur, after seeing the posts on Hack-A-Day about using acetone vapor to smooth out parts... anyway..

One of the things I was unsure of was the control linkages, and how the articulation points can be made.  It needs to have a few points of articulation to match the birds in the Enchanted Tiki Room:

• Perch rotation - 270 degrees, spins the bird around (not shown)
• Lean - +20, -20 degrees, to lean forward and backward at the point where the legs connect
• Head yaw - +45, -45 degrees back and forth
• Head tilt - +15, -15 degrees up and down
• Beak - 30 degrees, could be all open or all closed (shown in the diagram as 15 degrees)

I was thinking that after I constructed the foam version, I could figure things out from there, but after seeing this post on Hack-A-Day with a "HOG Drive", I realized I could leverage off of this design for the head linkages.

I chatted with Skip at Interlock, and by the end of this past Tuesday evening, I had two 3-D printed versions of this, using ABS, rather than the PLA material I am more familiar with. (Here's the Thingiverse link for the design.) Since I wasn't going to be mounting a motor, we (and by "we" I mean "he") replaced the motor space with a flat plate with a mounting screw hole.  He also replaced the back control arm with just a peg, since the bridge-like shape wouldn't hold up properly on his printer.

The first print (on the left) has a failed control peg on the center disk.  It was adding material onto printed material that didn't cool yet, so it just kinda globbed up.  This was improved by Skip by adding a second post, seen in the second version on the right.  He also added some material around the screw holes in the frame, to improve durability.

After printing and having this in my hand, I'm realizing that it won't quite work for me, although it does give me an excellent starting point.  The center disk is too small to mount the head on.  It's only about 1 1/2 inches in diameter. I think I'd want something about 2-3" in diameter, with plenty of mounting points and space for securing the head ,as well as space for wiring for the beak servo (or linear motor, or solenoid, or whatever).  It really showed me the design considerations for actually constructing something, not to mention it really emphasized that whatever design I can think of, I can print... which is pretty futuristically awesome.

But the important thing is that I know have ideas to build on for the final version.  I'll still be constructing a foam core model, and I'll be using this above design as a kick-off point.

(This post is cross-posted to the Interlock blog as well.)

Daisy Chaining Serial Connections

As part of the Animatronic Avian project, I need to have a way for the controller software/computer to send synchronized data out through all of the performers on the stage.  Being that I may be using my reflashed stepper motor controllers in this, rather than full-blown Arduino boards (or custom ATmega boards), I need to have a way to network these without using any precious IO pins.

On top of this, it needs to be very lightweight so that I can send data down through all of the performers without using too many resources of the device.

I also want it to be cheap, both with cost of parts for implementation, as well as for system resources in the chip firmware.


The solution I came up with is to use the builtin UART, which usually is set for a standard RS232 connection, but in a cascading daisy chain fashion.  This means that the hardware-assisted UART in each chip, plus one data line down to the next chip is all that's needed to implement this.  The networking stack running on the device is light enough that it should not impact performance of the main usage of the Arduino.

The above diagram shows how four Arduino boards are wired for this.  Basically instead of the TX and RX of a board connected to its host, instead its TX goes to the next device in the chain, and the RX comes from the previous device on the chain.   The actual implementation of this uses my D15-based ATmega widgets, and thus I followed this diagram:

Four wires are needed to hook up each node: power, ground, serial in, serial out.  In the above configuration, the final node does not output to anything.  I had the above working quite well with a simple firmware program.

Before I constructed this, I had no idea if it would even work.  But I spun up five of these, networked together, and it all seems to work perfectly.  Here's a video where I demonstrate it:

The program reads in a character from serial input, if it's a "b", it sends the "b" to the next device immediately, then turns off the LED for 1/4 second.  If it is a number, it will turn off the LED for that many seconds, then subtracts one from that number and sends that new number down to the next node.

So if it got a "6", it will turn off its LED for 6 seconds, then sends a "5" to the next one.  This was the simplest program I could think of to check if this concept would even work.  Turns out, it does!

This diagram shows an updated version which adds a few features which will be helpful for getting the software design debugged.   The reset line is connected to the FTDI header, as well as a jumper to feed the output of the first device or the last device back to the host.  This will enable me to reprogram the first node quickly, without needing to plug the micro into an FTDI interface cable.  This also will let me experiment with adding a "return".  The "return" line takes the output of the final node in the daisy chain, and sends it back to the host.  I may use this as a trigger for a mechanism to continuously send data states to all nodes.  (Once the computer host receives something from the final node, it can send down the next data envelope.)


So the basic idea of how this will be used is as follows.

The host will be playing back an audio track, and looking at a few data tracks.  At any particular timeslice, it will prepare a data envelope of bytes, containing all of the synchronization events for the animatronics.  This includes digital bits to turn LEDs, motors, and solenoids on and off.  There are also analog bytes that will be for controlling servos.  Let's try out a use case to better understand how this will work in practice...

First, the host looks at the data for the current timeslice.  For our example, we will have three animatronic objects on the serial bus, each of which has 5 data bytes associated with it.  The data is prepared and would look something like this:

• 15, 1, 1, 1, 1, 1, 200, 200, 200, 200, 200, 30, 30, 30, 30, 30

The first number is the count of the numbers that follows.  In this case, 15 digits will be included.  This is sent out from the computer host via RS232, 9600 baud.  The first animatronic microcontroller receives this, and will remove the numbers that it needs from the end.  In this case, it will pull off the five "30"s from the end.  It will also reduce the count from 15 to 10.  This will look like this:

• 10, 1, 1, 1, 1, 1, 200, 200, 200, 200, 200

It now sends this modified data envelope to the next device on the bus.  That device will pull off the  five "200"s from the end, and then send down the new envelope.

• 5, 1, 1, 1, 1, 1

The final micro on the list will pull off the five "1"s, the count reduces to 0, and it refrains from sending anything further.

The specifics of the protocol are yet to be worked out.

Also, the specifics of the interconnect are yet to be worked out too.  It'll probably be four pin header for input, four pin socket for output. (+5v, Ground, data, return)

The latency of this will be imperceptible for the use cases I plan to use this for, and it will enable me to have oodles of devices on the serial bus, all controlled by one host computer.  And best of all, no additional hardware (MIDI, DMX, I2C, SPI) is required, and no additional IO pins will be used for it.

Here's the Arduino program if you want to try it out yourself and you have a couple of Arduinos lying around...

/* Cascading Blinker
**
**  2012-December-01  Scott Lawrence  yorgle@gmail.com
**
** A number character when received will turn on the LED for that number of seconds
** It is then decremented then sent out.
**
**  Boring on its own, but it's a test to see if I can cascade RS232 devices.
**
**  Host--->RX(device 0)TX--->RX(device 1)TX--->RX(device 2)TX--->  Etc
*/
const int ledPin = 8; // 13 for standard arduino
void setup() {
  // initialize serial:
  Serial.begin(9600);
 
  // make the pins outputs:
  pinMode(ledPin, OUTPUT);
  digitalWrite( ledPin, LOW );
}
void blinkFor( long ms )
{
  digitalWrite( ledPin, HIGH );
  delay( ms );
  digitalWrite( ledPin, LOW );
}
void loop()
{
  int ch, digit;
  long d = 0;
 
  // wait for something to come in
  if( Serial.available() == 0 ) return;
  // read in a character.
  // If it's within '1' .. '9', set the timer for that number of seconds.
  ch = Serial.read();
  if( ch >='0' && ch <= '9' ) {
    digit = ch - '0';
   
    if( digit > 0 ) {
      d = digit * 1000;
    }
  }
 
  if( ch == 'b' ) {
    // turn off for 1/4 second, send down echo immediately
    Serial.write( 'b' );
    blinkFor( 250 );
  }
 
  if( d > 0 ) {
    // turn on the LED for the requested number of seconds
    blinkFor( d );
    // cascade out our digit, one less than ourselves
    Serial.write( (digit - 1) + '0' );
  }
}