Issue
159 October 2003
Embedded
Networking with MicroMessaging
LAYER
7 API
Some
networking standards, including CANopen, do not provide
an API, which hinders portability between different
implementations. This also results in additional software
overhead if different implementations are merged into
or exchanged with other network systems. The MicroMessaging
Layer 7 API provides a simple standardized interface
focusing on the process data exchanged.
MicroMessaging
uses process data channels for transporting process
data. On Layer 2, a data channel corresponds to a single
message. As a result, a single data channel can have
up to 8 bytes. Each individual node can have multiple
process data channels.
An
application may place multiple variables into each process
data channel. There are only three limiting rules: a
single variable must consist of 1, 2, 3, or 4 bytes;
the total number of bytes in a process data channel
is limited to eight; and the numeric multiple-byte variables
must be transferred in Little Endian format (lowest
significant byte comes first).
MESSAGE
FORMAT
A
single MicroMessaging message consists of a message
identifier (default is 1 byte), a data length counter
(values zero through eight stored in the lower 4 bits
of a byte, and the upper 4 bits used for an optional
checksum), and up to 8 data bytes. The bits in the identifier
are divided into a 3-bit function code and the 5-bit
node ID (see Table 1).
| Table
1—The message identifier used in CANopen (11
bits) and MicroMessaging (e.g., 8 bits) is divided
into a node ID field, which allows addressing a
specific node, and a function code field, which
specifies the contents of the message (e.g., one
code is used for service requests sent to the node). |
A
total of eight (function code) messages are assigned
to each of the 31 possible nodes (node ID 0 is reserved)
of a MicroMessaging network. The eight messages assigned
to each node are listed in Table 2.
| Table
2—Eight function codes are available for MicroMessaging
message IDs. The direction column specifies whether
this is a message coming from or going to the addressed
node. |
All
nodes must be able to receive the master control message.
A master sends this message to control the operation
state of the nodes (e.g., start or stop). The content
of the message is compliant to the network management
(NMT) master message in CANopen (CiA Draft Standard
301, or CiA DS301).
Using
emergencies is optional. If a node implements the support
of emergency messages, the message ID it may use for
the emergency message is its own node ID. The message
IDs used by the 31 nodes are 01h through 1Fh. The contents
of an emergency must be compliant with CANopen (CiA
DS301).
Nodes
only need to be able to receive and act upon the poll
message if the physical network used does not support
multimaster access. Shortly, I’ll describe how the poll
message is used.
The
message identifiers used for process data messages are
configurable to allow a receive data channel to directly
listen to the transmit data channel of another node.
The message IDs used for data channels must be in the
range of 21h to 9Fh.
Service
data channels are used for access to service and configuration
data, such as the identification record or the heartbeat
time. These channels are used in the same way as the
service data objects (SDO) channels used in CANopen
(CiA DS301).
