ModBus: Inter-module Communication

Modkit Electronics Modules are electronic circuits which contain a micro-controller, perform a specific function or group of functions, and connect to other modules through common V+, Data, and GND lines..

As explained in a previous post:

"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).."

For these reasons, I decided to implement a subset of Neil Gershenfeld's Internet0 protocol.. Even though I rewrote the polling based micro-code to implement an interrupt based system, the software overhead for shifting out the bits was still significant enough to keep looking for a hardware based solution..

I've decided to explore the possibility of using the hardware based USART on larger micros or the USI (Universal Serial Interface) shift register on smaller 8pin devices.. On the USART, this will require coupling the Rx and Tx lines which will mean that we will not meet our requirement of 1 data pin but this is fine because the AVRs with a USART generally have enough pins to spare.. On the USART enabled micros, we should be able to get "free" collision detection as we can read the Rx line when Transmitting and check against the transmitted data to check for a collision.. On the smaller micros we will use the USI to shift out the bytes in hardware and it is yet to be seen if we can accomplish this with just one pin..

In both cases, we will have to implement CSMA in software before acquiring the bus and will use the SLIP encoding scheme to encapsulate packets..

The challenge now is to figure out how to couple the Rx and Tx lines on the USART based micros in such a way that a collision on the bus will be detectable by checking the RxByte against the TxByte.. Also, Dhananjay talked about the need to use an "open collector driver." Is this possible without external components while enabling Rx and Tx?

On the USI based micros, the challenge is figuring out whether you can configure the USI in such a way to use the same pin for both Rx and Tx while leaving all other pins available for general purpose i/o and other functions..

Interrupt Based Click Transceiver

I just merged my rx and tx code into a single interrupt based click transceiver.. When I started the networking code, the biggest problem was lack of documentation..

Thanks to Thomas, Benn, and Kerry, I was able to get some up to date information on the current internet0 and click implementations.. It turns out that things have changed since this document was put together. the following is the scheme that I used to encode a byte in clicks:

The test modules have a red and green led and send a test byte to a second board which flashes the green led on success and red led on a read error.. I'll try to add some more documentation in the next few days.. But for now you can download the board, schematic, and code for the test modules.. I'm releasing them under the GPL which allows you to modify and redistribute them, free of charge..

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..