BlinkieBits

BlinkieBits will be a series of small boards with microcontrollers on some (Processor Boards), LEDs on others (Display Boards), and I/O capabilities on others (Interface Boards). The boards will interconnect to make blinkies, and will talk to each other to make larger blinkie displays.

Project Status

Work on the BlinkieNICBoard is ongoing. Project dormant as of June 2010 while I work on other things.

Topology

Current idea is to have a 2-dimensional 'base layer' of interface board(s) and processor board(s), and then a layer on top of display boards. Each display board would plug into one (or more?) processor board using standard connections so that any display board could plug into any processor board (channel requirements notwithstanding).

Interface Board Ideas

Interface boards will contain a processor of some sort, BlinkieNet I/O, and an external type of I/O (which would be different for each kind of interface board). No displays would plug directly into these, they just convert external I/O to blinkie-compatible I/O.

• USB
• RS232
• Ethernet
• SPI/I2C/TWI/1Wire

Processor Board Ideas

Processor boards will just contain a processor itself, a display connection, and BlinkieNet I/O pins. Processor boards talk to each other through the BlinkieNet, and light the display boards connected to them.

• Umm... processors and stuff. See the Blinkie MCUs page for notes on what CPUs might work best.

Display Board Ideas

Display boards will contain the actual display elements, likely just LEDs (at least to start). The boards may also contain a small EEPROM identification chip and/or mux, but beyond that no intelligence of their own. All ideas based on 12 channels per display board, as a random example.

• 1x16 Single-Color
• 1x5 RGB
• 4x4 Single-Color

Other Boards

Other boards will be debug and prototype boards, created to prove/work out concepts that will later be used in the 'real' boards.

• BlinkieNICBoard

Architecture/Project Ideas

• Standard number of channels per display/processor board, or variable?
  • Variable likely makes more sense, as no one processor board is going to cover the space from a big 2D RGB array to a small contact sphere, and having to connect 50 tiny processor boards together isn't a good solution.
  • If variable, could two 12-channel processor boards (for example) connect to one 24-channel-requiring display board, or one 24-channel processor board connect to two 12-channel-requiring display boards?
    • Connectors to connect the base layer and the display layer together are going to be a mechanical design issue in this case, but it would greatly increase the flexibility (and complexity, and therefore design fun) of the system.
    • Figuring out how to do the 'identification ROM' and power pins in this case would be complex (and fun).
• Would boards interconnect in 1d space only, or also in 2d space?
  • Definitely 2d space. Makes things way more complicated and fun.
• Could boards program each other like the IXM boards can?
  • No reason not, if the MCUs supported self-programming and a standard bootloader was used. Very small MCUs likely won't support the former though, so a hack would need to be done with extra pins to program each other.
  • No small PICs support self-writing to program space, some tinyAVRs do support it. All large PICs and ATmega/ATxmega AVRs also support it.
• Display boards could have a tiny EEPROM (think SPD on DIMMs) to identify to the processor board what model of display board/what LEDs are on it.
  • Very tiny SOT23-3 EEPROMs that communicate over one wire are very cheap (like Microchip 11AA02E48T-I/TT which has 2kb of EEPROM and a pre-programmed MAC address at ~$0.32 in qty. 10!).
• Interface protocol can hopefully be single-wire, to maximize I/O pin usage on small MCUs.
  • Could get complex with a single I/O pin communicating in a 2d matrix of modules.
• Some display boards could include latching muxes, which would mean they were non-PWMable but could have a large number of LEDs on them.
• Interconnect connectors should be symmetrical if at all possible, that way there's no 'backwards' and modules could be connected together such that displays were on both sides of the system, and any cables between modules can be plugged in without concern.
• It may take too much CPU time/code (especially on small CPUs) to keep up with the BlinkieNet (on a large matrix there would be a lot of 'packet!...not for me. packet!...not for me. packet!...not for me.). A separate dedicated NIC (network interface chip) may be a good idea, if it wouldn't add cost/size too much. That chip could handle all BlinkieNet (I think that's the new name for the interconnect fabric) I/O and communicate with the main CPU over a simple serial protocol, only when a packet is addressed to the specific module in question.
  • An ATtiny12 or PIC12F508 would give us 6 I/O pins to work with and are under a dollar each in qty. 1.
• Will forwarding BlinkieNet packets through every node in the matrix be too time-consuming for decent frame rates? If so, do we need to connect the whole matrix together so we can talk directly node-to-node (termination would be a huge issue then, it seems like) or do a kind of switched topology where you would set up a connection between nodes, transmit the data, then tear it down?
• Systems shouldn't require an interface board for some critical feature like inter-node routing, only for doing the interfacing to an external system. Large systems should be able to be self-contained, if desired.