Trimming the Fat from Internet0Looking for a bus for inter-module (read: inter-object) communication, we had a few concrete requirements:
1) 1-wire: One data wire allows us to easily pass the three necessary wires (v+, v-, data) through the module's core, exposing the three connections on each side (top and bottom) of any module, even on single sided boards, allowing easy physical linking..
2) 1-pin: One microprocessor pin allows us to free up to 5 (4 when doing "in circuit programming") pins on an 8pin micro for the module's actual functions (read: methods)..
3) P2P: Peer to peer communication turns out to be essential for inter-module (object) communication.. Any module must be able to communicate with any other module directly to follow the object oriented programming paradigm. In other words, any object must be able to instantiate and call the methods of any arbitrary object.. A master slave system will not provide this level of flexibility without additional overhead (forwarding messages between slaves)..
These three requirements automatically ruled out many popular protocols such as I2C, LIN, CANN, USB, etc.. Rather than attempt to reinvent the wheel, we decided to look at the
Internet0 (i0) protocol. This protocol seems to have everything we needed (except for a TCP like delivery guarantee implementation - which would sit on top of i0), but comes with a lot of overhead.. Because it is based on IP, there is a 20 byte minimum overhead. So to send 1 byte of data, you must send a 21 byte packet.. A big contributor to this is 4 byte source and destination addresses. This may be necessary for "building scale" networks, but seems like overkill for our "circuit board scale".. One approach would be to learn from internet0 in terms of the physical layer and data link layer implementation.. Their
CSMA implementation seems pretty solid even without any collision detection, and what they're doing in terms of "clicks" makes it easy to detect collisions (based on a pin change interrupt in between sending clicks).
One argument for keeping the protocol in tact is to 1) allow for connection with other internet0 ready electronics, or 2) connection with the internet.. Since there are currently no commercially available internet0 electronics, #1 is not really a concern.. As for #2, connection to the internet is a concern but should be done at the level of the "whole circuit" rather than at the level of the individual parts (modules).. For example, the whole circiut will act as one unit, and may communicate with a remote server, exposing its current state (as a whole) or gathering data from the remote server (and acting on it as a cohesive unit).. This does come at a cost (in terms of additional electronics to communicate with the remote server) but I believe this cost is far outweighed by the savings in terms of communication overhead.
Because the goals and requirements of the Hardware Library project are not one-to-one with those of the "building scale" networks for which Internet0 seems to thrive, and because we can learn from (and contribute to) the development of internet0's physical and data link layers, we'll probably go for a best-of-both-worlds approach, and trim the fat from internet0..
I just updated the code.. It no longer polls for button presses.. It is now 99% interrupt driven.. (I now need a timer driven delay scheme to make it 100%)