Issue 159 October 2003
Embedded Networking with MicroMessaging

---

---

Start • Layer 7 API • Status Channel • Standard CANopen Tools • Sources and PDF

When it comes to embedded networking, it is common practice to use an RS-485- or I²C-based network to quickly define a few messages to exchange data. This approach is sufficient for an embedded system that uses a few microcontrollers, and it’s fairly fixed: it always uses the same nodes with the same software and messages. However, as soon as the system grows or needs added flexibility and configurability, a standardized network solution becomes more desirable. Using standard network protocols allows you to use development tools (e.g., network monitors, analyzers, simulators, and loggers) and to possibly integrate off-the-shelf components in the network.

As a consultant and ESAcademy tutor with a lot of CAN and CANopen experience, I usually recommend switching to CANopen, one of the only embedded-networking standards around. To help newcomers with CANopen, ESAcademy came up with MicroCANopen, which is a minimal CANopen implementation that’s suitable for lower-performance microcontrollers.

Although “Use CANopen!” is still a valid recommendation for many applications, it may not be feasible for an upgrade or migration involving existing systems based on non-CAN networks. So, something else is needed for an easy migration to a standard, or, even better, to allow existing network technologies like RS-485 and I²C to merge with CANopen.

The idea of merging a simple serial bus into a CAN-based system is not exactly a new one. A similar approach was taken by the automotive industry with the local interconnect network (LIN). LIN is a simple network protocol that works on almost any UART. With the number of electronic nodes in a car continuously rising, the idea was to introduce several LIN subnetworks and use the CAN bus as a backbone that interconnects everything. A typical example would be to have a LIN subnetwork in each of a car’s seats (connecting all the switches and motors) and have one microcontroller in a seat act as a gateway between the local LIN subnetwork and the CAN bus.

INTRO TO MicroMessaging

To pursue the idea of building a bridge between any serial bus and CANopen, the tutors of ESAcademy contacted some industry and research partners and started the MicroMessaging Initiative. The goal was to standardize a messaging system for serial buses including UARTs, I²C, and LIN that offers enough compatibility to allow for the easy mixing and migrating of these technologies while still offering common software interfaces.

To reach the goal, two software interfaces are standardized in MicroMessaging (see Figure 1). The Layer 2 driver interface offers the same software functions to transmit and receive a message on all the different hardware platforms that are supported. The Layer 7 application-programming interface provides a set of application functions that directly allow the sharing of process data among the different network nodes.

(Click here to enlarge)

Figure 1—Several hardware and software layers are involved in a MicroMessaging implementation. The MicroMessaging standard specifies the software interfaces to the hardware driver level (Layer 2) and to the MicroMessaging protocol stack (Layer 7).

LAYER 2 DRIVER INTERFACE

What is special about the Micro-Messaging Layer 2 driver interface is that all functions and parameters are carefully selected to be usable and interchangeable with most serial buses, especially with UARTs/RS-232/485, I²C, SPI, LIN, and CAN. The communication mode supported upwards is a “push” and “poll” model, with the driver being responsible for implementing a minimal receive and transmit queue. Many CAN interfaces have such queues in hardware; however, when using other technologies, a software implementation may be required. The lengths of the queues are not specified and depend on the application requirements.

In order to be compatible with the message-oriented communication technologies LIN and CAN, a single MicroMessaging message consists of an identifier, a data length counter, and data bytes. Because both LIN and CAN allow for a maximum of 8 data bytes per message, this maximum message length is adapted for MicroMessaging, too.

The length of the message identifier varies greatly from 6 bits in LIN to 11 bits in CAN, which even allows for an extended 29-bit ID. In order not to loose too much flexibility, Micro-Messaging specifies to use message identifiers with either 6 or 8 bits. Some functionality is lost when using a 6-bit oriented identifier. Alternatively, 11 bits can be used when full CANopen compatibility is required.

The minimal services required at the Layer 2 level are functions to initialize the communication interface including setting receive filters (only receive messages with a certain ID), some timer functions, and functions reading from the receive queue and writing to the transmit queue.