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:
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..
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).."
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..
0 Comments:
Post a Comment