Trimming the Fat from Internet0
Looking 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..
Looking 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..
posted by Ed at 10:48 AM
1 Comments:
I'm not crazy about trimming IP addresses for smaller devices
So the initial thought was to default the ip address to 1 byte (but allow this to be configured at flash time).. But once we break compatibility with i0 (assuming a standard emerges), I figured why not trim even more..
But to clarify things.. there is a clear distinction between a device and a module.. Multiple modules are linked to create a single device.. This device may or may not need to communicate with other devices.. If in fact the device is meant to communicate with i0 ready electronics, then an i0 module can be used..
I think that before long we'll have lots of i0 connection media (ultrasound, fiberoptic, etc.) that you wouldn't want to miss out on
I don't have a crystal ball, so I can't judge the validity of this statement.. What I can say is that there are currently thousands of chips that talk I2C and it would be great to be able to use this as our internal bus (one of my main inspirations, the Tower does this).. But because I2C doesn't meet any of the 3 requirements for our internal bus (I2C = 2 pins, 2 wires, master/slave), we've chosen to deal with it as an external bus (ie: an I2C module)..
But assuming the "connection media" you talk about is implemented on a general purpose micro with the networking done in software, we could always make them conform to our protocol (they already do a click based putChar and getChar)..
Conversely, my thought is that the hardware modules could also be configured to do straight internet0 as well.. This way a module could also be a device.. But I think this will be the exception rather than the rule..
Post a Comment
<< Home