logo slogan

Segger emMODbus


Modbus is an open, mature, and straight forward communications protocol. It was originally published in 1979 by Modicon (Schneider Electric) and has since evolved into a standard communications protocol for industrial electronic devices.

Modbus was specifically designed to be used in supervisory control and data acquisition systems, connecting a supervisory computer with several remote terminal units (RTU). It therefore uses a master-slave-technique in which one devkeil_kitice, the master, initiates transactions (called queries). Other devices, the slaves, respond by performing the action requested in the query and/or by supplying the requested data to the master.

See Wikipedia for further information.

emModbus, SEGGER's implementation of the Modbus protocol, supports communication via UART (ASCII, RTU) and Ethernet (Modbus/TCP and Modbus/UDP) and is capable to communicate with any Modbus compliant device.

emModbus supports building master and slave devices, which can even be combined in the same product. Also, multiple interfaces in the same product are supported. Each interface can be configured at runtime, making it possible to build a pretested library to be deployed in multiple projects.


Easy to integrate.
Low memory footprint.
ANSI-C code is completely portable and runs on any target.
Follows the SEGGER coding standards: Efficient and compact, yet easy to read, understand & debug.
Supports ASCII, RTU and Modbus/TCP (and UDP) protocol.
Sample applications for all protocols included.
Kernel abstraction layer: can be used with or without any RTOS.
Works out-of-the-box with embOS.
Modbus/TCP can be used with standard socket interface and any TCP/IP stack.
Works out-of-the-box with embOS/IP.
Project for executable on PC for Microsoft Visual Studio available.


Product information


Available shipments

SEGGER offers emModbus in two distinct shipments, both of which are optimized for use in embedded systems.


Master Slave

Master API (including samples for ASCII, RTU and Modbus/TCP)

Slave API (including samples for ASCII, RTU and Modbus/TCP)

ASCII frame encapsulation

RTU frame encapsulation

Modbus/TCP frame encapsulation (also supports Modbus/UDP)

Kernel abstraction layer for embOS and Windows

Modbus master application for Windows (binary)

Modbus master application for Windows (source)

Modbus slave application for Windows (binary)

Modbus slave application for Windows (source)


TCP/IP stack
For usage of Modbus/TCP, emModbus requires a TCP/IP capable stack. emModbus can be used with any TCP/IP stack that supports BSD Standard Sockets.

Multi tasking
Although emModbus can be used completely without an RTOS it is recommended to use emModbus in a multi tasking system, at least when implementing a Modbus master.

Memory footprint


ROM usage
emModbus requires approximately 2.5 KBytes of ROM for a master device and approximately 3 KBytes of ROM for a slave device.

RAM usage
emModus requires approximately 30 Bytes of RAM for the stack itself and approximately 300 Bytes of RAM for each channel added.


Instruction set

emModbus currently supports the following instructions:

Function code



Read Coil.


Read Discrete Input.


Read Holding Register.


Read Input Register.


Write Coil.


Write Register.


Write Coils.


Write Registers.



Technical background

Message frames

emModbus supports all three Modbus standard protocols covered by the official Modbus documentation:




Original Modbus standard. Binary data is sent via serial connections such as RS-232 or similar.


Similar to RTU. Instead of raw binary, data is encoded in ASCII.


Binary data is encapsulated in a TCP frame and sent via network connections such as Ethernet. This variant can also be used with UDP instead of TCP and is then called Modbus/UDP.

Message frame fields

Although the different message frames are each handled differently by the protocol, both RTU and ASCII frames consist of the same four specified fields. Field 2 and 3 constitute the Protocol Data Unit (PDU), which is included in the Modbus/TCP frame as well.

RTU message frame

When using RTU frames, each byte contained in a message is sent as binary data. The main advantage of this mode is its greater density, allowing better data throughput for the same baud rate compared to ASCII frames.

ASCII message frame

When using ASCII frames, each byte contained in a message is encoded and sent as two ASCII characters. This allows time intervals of up to one second to occur between characters without causing an error.

Modbus/TCP message frame

When using Modbus/TCP frames, an additional header called 'Modbus Application Header' precedes the Protocol Data Unit.

Data types

Modbus uses four primary data types:

Data type



Single bit, alterable by an application program, read-write.

Discrete Input

Single bit, provided by an I/O system, read-only.

Holding Register

16-bit, alterable by an application program, read-write.

Input Register

16-bit, provided by an I/O system, read-only.