McNet Main Page: Unterschied zwischen den Versionen
Aus ProjectWiki
Mat (Diskussion | Beiträge) (Created page with "== Description == On my robot platform, I have one single board PC communicating with 5 µCs. To ensure a stable operation, I needed some sort of protocol, which is able to be us...") |
Mat (Diskussion | Beiträge) (→Description) |
||
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
== Description == | == Description == | ||
| − | On my robot platform, I have one single board PC communicating with 5 µCs. To ensure a stable operation, I needed some sort of protocol, which is able to be used on several hardware interfaces. In my application, it's a serial connection between the PC and the µC-Master/Router, which is connected to the other controllers via I²C. | + | On my robot platform, I have one single board PC communicating with 5 µCs. To ensure a stable operation, I needed some sort of protocol, which is able to be used on several hardware interfaces (called subnets). In my application, it's a serial connection between the PC and the µC-Master/Router, which is connected to the other controllers via I²C. There are also some non-McNet devices (called static nodes) on the Bus, like a CMPS03 compass module, which I want to include in the protocol. |
| + | |||
The data I want to transfer are high-level commands, like for the motor controller, "drive 1m forward with half speed", instead of transferring the raw sensor data to the PC and raw output data back. So i dont need a really fast communication, but it should be reliable, it would be good if no packets get lost. | The data I want to transfer are high-level commands, like for the motor controller, "drive 1m forward with half speed", instead of transferring the raw sensor data to the PC and raw output data back. So i dont need a really fast communication, but it should be reliable, it would be good if no packets get lost. | ||
| − | It was also important for me that the network topology is not hard programmed into the nodes, there should be a self-detection for that, because | + | |
| + | It was also important for me that the network topology is not hard programmed into the nodes, there should be a self-detection for that, because later I dont want to mess with such unimportant details :) | ||
Last but not least, the whole thing should be easy to use, with just a few lines of code in the main program. | Last but not least, the whole thing should be easy to use, with just a few lines of code in the main program. | ||
| Zeile 8: | Zeile 10: | ||
McNet consists of layers: | McNet consists of layers: | ||
* The first layer (L0, Hardware) abstracts the hardware interface and has some mechanisms to ensure that the binary data is transferred correctly. Depending on the hardware, it uses a CRC8 checksum, ACK/NACK feedback, timeouts etc. | * The first layer (L0, Hardware) abstracts the hardware interface and has some mechanisms to ensure that the binary data is transferred correctly. Depending on the hardware, it uses a CRC8 checksum, ACK/NACK feedback, timeouts etc. | ||
| − | * The second layer (L1, Routing) is the core of McNet. Each node has its own global address, independent from the HW interface(s). When the system powers up, the nodes first determine the network topology and build up | + | * The second layer (L1, Routing) is the core of McNet. Each node has its own global address, independent from the HW interface(s). When the system powers up, the nodes first determine the network topology and build up their routing tables choosing the shortest (count of hops) routing path (this also happens when a node is "hot-plugged" into a running network). Static nodes are hard-programmed in one node's routing table, which then acts as a router between the static device and the rest of the network. After this exchange process has finished, the network is ready to transmit binary data packets. |
* The third and last layer (L2, Application) just acts as an interface between the main application and L1. It transfers a command byte and corresponding user data with different data types (byte, word, single, string, etc) | * The third and last layer (L2, Application) just acts as an interface between the main application and L1. It transfers a command byte and corresponding user data with different data types (byte, word, single, string, etc) | ||
| − | Each layer has its own send and receive buffers, so you get a 3-staged packet buffer. | + | Each layer has its own send and receive buffers, so you get a 3-staged packet buffer. This way you can process received data or send data while you are receiving the next packet. |
| + | |||
| + | == Future Developments == | ||
| + | * Rewriting of the TWI layer | ||
| + | * planned subnet layers: SPI, RFM12 radio modules on the µC side, TCP/IP on the PC side | ||
| + | * Dynamic McNet and subnet addresses (using one node as fixed address server), like DHCP in TCP/IP networks. | ||
Aktuelle Version vom 3. Mai 2011, 23:47 Uhr
Description
On my robot platform, I have one single board PC communicating with 5 µCs. To ensure a stable operation, I needed some sort of protocol, which is able to be used on several hardware interfaces (called subnets). In my application, it's a serial connection between the PC and the µC-Master/Router, which is connected to the other controllers via I²C. There are also some non-McNet devices (called static nodes) on the Bus, like a CMPS03 compass module, which I want to include in the protocol.
The data I want to transfer are high-level commands, like for the motor controller, "drive 1m forward with half speed", instead of transferring the raw sensor data to the PC and raw output data back. So i dont need a really fast communication, but it should be reliable, it would be good if no packets get lost.
It was also important for me that the network topology is not hard programmed into the nodes, there should be a self-detection for that, because later I dont want to mess with such unimportant details :) Last but not least, the whole thing should be easy to use, with just a few lines of code in the main program.
Structure
McNet consists of layers:
- The first layer (L0, Hardware) abstracts the hardware interface and has some mechanisms to ensure that the binary data is transferred correctly. Depending on the hardware, it uses a CRC8 checksum, ACK/NACK feedback, timeouts etc.
- The second layer (L1, Routing) is the core of McNet. Each node has its own global address, independent from the HW interface(s). When the system powers up, the nodes first determine the network topology and build up their routing tables choosing the shortest (count of hops) routing path (this also happens when a node is "hot-plugged" into a running network). Static nodes are hard-programmed in one node's routing table, which then acts as a router between the static device and the rest of the network. After this exchange process has finished, the network is ready to transmit binary data packets.
- The third and last layer (L2, Application) just acts as an interface between the main application and L1. It transfers a command byte and corresponding user data with different data types (byte, word, single, string, etc)
Each layer has its own send and receive buffers, so you get a 3-staged packet buffer. This way you can process received data or send data while you are receiving the next packet.
Future Developments
- Rewriting of the TWI layer
- planned subnet layers: SPI, RFM12 radio modules on the µC side, TCP/IP on the PC side
- Dynamic McNet and subnet addresses (using one node as fixed address server), like DHCP in TCP/IP networks.
