Industrial Modbus Communication with the LPC55S06 Baseline MCU
Last year I wrote quite a bit about the new LPC5500 series MCUs focusing on the LPC55S69 and its ample processing capabilities. The LPC5500 series has a wide range of offerings and with the recent release of the baseline LPC550x/S0x family of parts, there are plenty of device options all sharing the Cortex® M33 technology on a 40nm platform. One aspect of the baseline family of parts is having options that deliver a good balance of simplicity and flexibility. The simplicity/flexibility balance is important in many industrial applications. Combining standard industrial communication peripherals such as RS-485 capable UARTs and CAN-FD with a solid microcontroller foundation means that designers can implement a wide range of products in the industrial space.
Figure 1: The LPC55(S)0x Baseline Family
Speaking to the industrial use case in the context of the simplicity/flexibility balance, I will demonstrate how the LPC55S06 can be used implement the ubiquitous Modbus-RTU protocol. The LPC55 baseline family has fully a featured UART peripheral (QTY 8!) that is well suited to RS485 communications. Combining the UART with an extremely flexible timer subsystem, interfacing with a Modbus network is a straightforward process. There are literally millions of industrial processes and controllers which use Modbus to implement IO operations. I always like to refer to the “Cookie Factory” as the model use case for industrial applications. We all understand the implications when the “Cookie factory” is down so high-reliability controllers, sensors and actuators are essential! Modbus is an essential component of these industrial processes and it would be difficult to find a process that does not use Modbus in some capacity.
Modbus Basics
Modbus is an open, de facto standard protocol in the industrial sensing and control markets. What makes Modbus so ubiquitous is its simplicity in message framing and data model. Modbus uses a client-server approach with half-duplex communications. A client can address up to 247 servers on the bus. In this article, we will focus on Modbus-RTU which uses binary data on a half-duplex RS-485 link. The utility of Modbus comes in a very simple data model. Each device implements an array of 1-bit (Coils/Discrete Inputs) and 16-bit entities (Holding Registers/Input Registers). Coils (1-bit) and Holding Registers (16-bit) have read/write access while Discrete Inputs (1-bit) and Input Registers (16-bit) are read-only.
The server can map the Discrete Inputs and Coils to actual physical IO (for example a relay) or a “virtual operation” (an internal configuration setting). Analog input data from sensors can be placed in the input registers. The designer is free to use the 1-bit and 16-bit entities as they please. When you purchase a Modbus sensor/device, it comes with documentation of which registers and discrete IO are exposed to a client. This model is extremely simple and effective for the industrial use case and Modbus is an integral part of all the industrial programming paradigms.
The Modbus specification is freely available and open. There are an extremely large number of Modbus devices available on the market ranging for simple sensors to complicate actuators and motor controls. A simple web search can return a large of number of product. There are even Cellular Connected Industrial IOT available such as the TZero “MachineMailbox”.
Figure 2: An example of an Industrial IOT Modbus Device.
Modbus with the LPC55S06
There is one detail when implementing Modbus-RTU with RS485 that requires some special consideration. Modbus data packets, or PDUs, are simple binary packets transmitted via RS-485 signaling. This means a UART is needed to send and receive data. What makes Modbus different from other serial protocols is that data packets do not have explicit “end of frame” or “start of frame” bytes. Frames must be sent as back-to-back characters. The end of a packet is delineated by *idle time*. This means that in addition to a UART, we need a timer to properly implement Modbus-RTU. The Modbus specification indicates that there should be a minimum of 3.5 character times (<= 19200 baud) or 750uS (>19200 Baud) to delineate packets.
Figure 3: Modbus Message Framing
Modbus generally assumes 1- bit characters: 1 start-bit, 8 data-bits, 1 parity and 1 stop-bit. In the case of no parity, 2 stop bits are specified. It is common for modern devices to not require 2 stop bits. As an example, a 19200 baud device should use an idle time of 2mS at the end of a packet. Modbus also specifies that there should never be more that 1.5 characters of idle time in bytes in a packet This however is rarely an issue as most MCU can easily ensure that UART characters are sent back-to-back.
Figure 4: Modbus Inter-character Timing
As packets are delineated by idle time, a timer is required to detect the end of a packet. One of my favorite features of all NXP MCUs is the plethora of timers. A good option for precision timeout applications is the “Multi-Rate Timer” or MRT.
Figure 5: Timers in an NXP LPC MCU
The MRT is a 4-channel 24-bit timer with 3 modes: Repeated Interrupt, One Short and One Short Stall.
Figure 6: The NXP Multi-Rate Timer (MRT)
The MRT is a simple down counter than can fire an interrupt when the counter reaches zero. It is the perfect option when all you need to implement a precision “timeout”. For detecting Modbus packets, we can use the MRT interrupt in conjunction with the UART receive interrupt.
Figure 7: Decoding Modbus Packets with an UART IRQ and an MRT IRQ
In the diagram above, the green arrow indicates when we receive a character and get an interrupt. This is where we can start/reset the MRT for our 3.5-character timeout. Every time a character is received, reset/restart the timer. When the packet is complete, the MRT interrupt will fire and then we can consider the packet complete. The data packet can then be processed, and the response can be transmitted to the client. If you want your firmware to enforce the inter-character idle requirement, simply use another MRT channel to detect if there has be 1.5-character times between incoming bytes.
LPC55S06 Modbus Demonstration
To demonstrate Modbus on the LPC55S06, I used the LPC55S06-EVK as a quick prototyping platform. Instead of RS-485, I elected to use the UART attached to the built in USB-UART interface to simplify the demonstration an initial firmware development. Once the underlying UART/timing is functioning, one could connect an RS-485 transceiver to the UART to create a fully compliant Modbus device. In conjunction with the LPC55S06-EVK, I used two software components : Modbus Poll and liblightmodbus. Modbus Poll is PC based test software that can be used as a Modbus Client or Server for testing and development. liblightmodbus is an open-source C library for implementing a Modbus client or server on a microcontroller. I found liblightmodbus as a simple way of bringing Modbus functions into a C based MCU project. A particular feature of liblightmodbus that I find valuable is its clear separation between the physical Modbus transport and application logic. This makes integration into new projects fast and straightforward.
For the demonstration, a desktop PC will be the Modbus client and the LPC55S06-EVK will be the server. The server will implement 3 “coils” (digital outputs) which can control the RGB LED on the LPC55S06-EVK. In the video, I send commands to enable disable the LEDs via coils at address 0, 1 and 2.
Figure 8: Modbus Demonstration with LPC55S05-EVK
And to show you the timing from real world signals on the LPC55S06-EVK:
Figure 9: Modbus Transmit/Receive Timing on the LPC55S06-EVK
I used a combination of interrupts on the UART and the MRT to detect the idle time at the end of a packet. The setup was straightforward with the MCUXpresso SDK functions.
You can see from the demonstration that the LPC55S06-EVK is successfully implementing Modbus functions. The sky is the limit in terms of how one uses the Modbus IO. You could place ADC data in the registers, connect the “coils” to physical relays, read physical inputs, etc. With Modbus, the designer gets to map the 1-bit and 16-bit IO as they see fit. In this example, the LPC55S06 was the “server” receiving commands from the client. There is no reason why the role could not be reversed as it is a function of the firmware The liblightmodbus library can just as easily enable applications where the MCU is the client requesting information from other Modbus servers.
I hope this gets you thinking about the NXP LPC55S0x baseline MCUs and industrial applications. With the MCUXpresso SDK and the LPC55S06-EVK, you can be on your way to a prototype in short order. Please visit the LPC55(S)0x baseline family page for more information so you can get started today.