Issue
159 October 2003
Embedded
Networking with MicroMessaging
STATUS
CHANNEL
Each
node generates one status message that’s sent after
the boot-up message and implements the heartbeat, which
is a message sent periodically with information about
the current state (e.g., running or stopped). The message’s
content is compliant to the NMT control message of CANopen
(CiA DS301).
Photo
1 shows MicroMessaging messages produced by nodes 3
and 5. Each node has data channel 1 (message IDs 23h
and 25h) transmitting a 6-byte value and data channel
3 transmitting (message IDs 63h and 65h) a 2-byte value.
The heartbeats produced are messages E3h and E5h. As
you can see, I used PEAK-System’s PCANVIEW, which is
a simple CAN monitor. The Period column displays the
cycle time of each message in milliseconds. In the MicroMessaging
nodes, the heartbeats were set to 1 s.
|
(Click
here to enlarge)
|
Photo
1—The messages include the heartbeats of the nodes
(0E3h and 0E5h), which are sent within a period
of 1000 ms (every second). The first four messages
in the Receive window are process data messages. |
NETWORK
STRUCTURE
Although
MicroMessaging can be used in stand-alone embedded networks
(i.e., all nodes connected via the same physical network
technology), its true strength lies in mixing different
technologies. A CANopen network can be used as a backbone.
Several subnetworks based on other network technologies
can be connected to that backbone via simple gateway
tasks running on some of the connected nodes.
A
single MicroMessaging network, which could be a subnetwork
to a CANopen network, may consist of up to 31 nodes.
Each node has a unique node ID ranging from 1 to 31.
Each node can have up to four process data channels,
each capable of transporting up to 8 bytes of process
data. Each process data channel supports all of the
common connection types offered by CANopen: point-to-point
(from one node to one other node) or multicast (from
one node to multiple others) connections. The transmission
type (i.e., how the transmission is triggered) for process
data messages is time-driven on a fixed time basis (e.g.,
every 50 ms).
SHARING
NETWORK MEDIA
When
it comes to sharing a single network media, a network
technology needs to provide an arbitration mechanism.
In other words, a method is needed that assigns the
network media to a specific node so that it can transmit
messages without being interrupted by others.
The
transmission types (i.e., what triggers the transmission
of a message) supported by MicroMessaging depend on
the type of network media used. On a network media supporting
multimaster access (any node can write to the bus at
any time, collisions get resolved automatically, and
it’s available with CAN and I2C), nodes may write their
messages at any time (collisions get resolved automatically).
If
the network media does not support multimaster-access
(e.g., a UART interface shared by multiple nodes), all
transmissions only happen by polling: One node in the
network becomes responsible to poll all of the nodes
connected to the network cyclically. After being polled,
a node transmits all of the messages that are due for
transmission (e.g., those where the event timer expired).
The default poll message is the one with the ID 20h;
it has a length of 1 byte, and the data byte contains
the node ID of the node that is currently polled.
GATEWAY
TASKS TO CANopen
The
best method to interconnect multiple MicroMessaging
networks is to use CANopen as a backbone. Simple gateway
tasks running on nodes that have access to both a MicroMessaging
network and a CANopen network can provide such an interconnection.
CANopen
can handle up to 127 nodes, and multiple MicroMessaging
networks can share the same CANopen backbone if the
gateway task is smart enough to use an offset for the
node ID used on CANopen. For instance, it could have
nodes 1 through 31 (01h–1Fh) on the MicroMessaging network,
but translate that to nodes 33 through 63 (21h–3Fh)
on the CANopen network.
A
gateway task that runs on a microcontroller with access
to both CANopen and a MicroMessaging network is kept
simple if both networks use the predefined connection
set, which is the default usage scheme for the message
identifiers (11 bits on CANopen, 8 bits on MicroMessaging).
The schemes divide the message identifiers into a function
code (most significant bits) and the node ID (least
significant bits). This allows you to put the node ID
directly in the message ID and assign each node a number
of messages using the function code (see Table 1). Exchanging
messages between MicroMessaging and CANopen only requires
a translation of the message identifier used on both
systems (see Table 3).
| Table
3—The 3-bit function code used in MicroMessaging
messages corresponds to the 4-bit function code
used by CANopen. |
