Hi
The first thing to remember is that the uNetwork operation uses Ethernet II protocol but not IP. That means that the IP address is not important for the uNetwork operation. However usually one would like the nodes to also work with TCP/IP as well as uNetwork.
The MAC address of each node in the system must be known. In a network not connected to a LAN the MAC addresses could really be 00-00-00-00-00-01, 00-00-00-00-00-02, but often the real, unique MAC address of each node will be required. This could be made configurable or a node could even be given 2 MAC addresses (the standard one for IP operation and a second one of uNetwork operation - some devices - like the SAM7X - allow more than one uni-cast MAC address to be configured, otherwise the Ethernet interface may have to work in promiscuous mode).
If these addresses can not be fixed it can also be made configurable.
OurConfigNr is not used by uNetwork - this concerns the task configuration (which can be different for each node).
OurNetworkNumber must be individual for each node - eg. set by reading in a DIP switch. The number must then match the MAC address entry in the ucNodeMac table. The simple example uses two nodes with OurNetworkNumber = 1 and OurNetworkNumber = 2, and each with a MAC address the same as its network number.
To send data from a task on node 1 to a task on node 2 it is essentially the same as when ending data between two tasks on the same node. The only difference is in the node address.
Eg. Consider an existing routine which sends some data:
// Send data read from the LCD to the application
//
static void fnSendAppRead(unsigned char ucData)
{
unsigned char ucMessage[ HEADER_LENGTH + 2];
ucMessage[ MSG_DESTINATION_NODE ] = INTERNAL_ROUTE; // destination node
ucMessage[ MSG_SOURCE_NODE ] = INTERNAL_ROUTE; // own node
ucMessage[ MSG_DESTINATION_TASK ] = LCD_PARTNER_TASK; // destination task
ucMessage[ MSG_SOURCE_TASK ] = OWN_TASK; // own task
ucMessage[ MSG_CONTENT_LENGTH ] = 2;
ucMessage[ MSG_CONTENT_COMMAND ] = E_LCD_READ;
ucMessage[ MSG_CONTENT_DATA_START ] = ucData;
fnWrite( 0, ucMessage, (HEADER_LENGTH + 2)); // send message to defined task
}
The destination and source nodes are given as INTERNAL_ROUTE, which ensures that the message is delivered locally.
If you have two nodes (1, and 2) and each has been named as follows
#define NODE_MOTOR 1
#define NODE_LCD 2
the motor node could send a message to the LCD node as follows:
// Send data read from the LCD to the application
//
static void fnSendAppRead(unsigned char ucData)
{
unsigned char ucMessage[ HEADER_LENGTH + 2];
ucMessage[ MSG_DESTINATION_NODE ] = NODE_LCD; // destination node
ucMessage[ MSG_SOURCE_NODE ] = NODE_MOTOR; // own node
ucMessage[ MSG_DESTINATION_TASK ] = LCD_PARTNER_TASK; // destination task
ucMessage[ MSG_SOURCE_TASK ] = OWN_TASK; // own task
ucMessage[ MSG_CONTENT_LENGTH ] = 2;
ucMessage[ MSG_CONTENT_COMMAND ] = E_LCD_READ;
ucMessage[ MSG_CONTENT_DATA_START ] = ucData;
fnWrite( 0, ucMessage, (HEADER_LENGTH + 2)); // send message to defined task
}
Since the two nodes are different, the uNetwork protocol (instead of local queues) will be used to deliver the data.
If the LCD were to be moved to the local node, simply changing the LCD node define to
#define NODE_LCD 1
will automatically cause the data to be delivered locally instead. The rest should be fully compatible.
All reception data arrives at the input queue at the destination task. The destination task doesn't have to know whether the data was sent from a local task or a remote task on a remote node (although the information is in the header of the received message). Therefore standard fnRead() of the tasks input queue is used, which is compatible with locally delivered message data.
Data delivery is normally guaranteed by the uNetwork protocol. It will automatically repeat data as necessary in case or errors.
If there is a serious error, such as the cable has been disconnected and so the remote node can not answer, the local task defined to be responsible (UNETWORK_MASTER) will receive error events (UNETWORK_FRAME_LOSS or UNETWORK_SYNC_LOSS). In case of recoverable errors there are counters kept that can be monitored to check that the network is reliable (uNetwork_stats). A serious error will mean that the network has in fact failed; if such an error occurs it may mean that further operation must either be restricted to the local node or the system is no longer operational - often it is interpreted as a watchdog timeout so that a reset can be attempted.
When a remote device receives a message it can of course send an answer back to the source (the reverse routing involved swapping the node source and destination as well as task source and destination addresses). Acknowledges at the application layer are generally avoided since the protocol will ensure delivered when the network has not catastrophically failed.
Regards
Mark
