µC/Modbus Architecture

Figure 1-5 shows how the µC/Modbus communications stack fits in your product and also shows which source files are associated with each layer.

MB stands for ModBus, MBS stands for ModBus Slave and MBM stands for ModBus Master. A file that starts with mb_ indicates that the code in the file is independent of Modbus Slave or Master. A file that starts with mbs_ contains Modbus Slave specific code and, of course, a file that will start with mbm_ will contain MODBUS Master specific code.

Figure 1-5 - Relationship between modules.

(1) Your product needs to configure µC/Modbus (at compile time) to establish the maximum number of channels your product will support, whether some channels will support Modbus ASCII and/or RTU, whether the ‘Daniels Extensions’ will be supported to provide floating-point, which Modbus function codes will be supported, whether a product will be a Master, a Slave or both, etc. Configuration is done by changing a C header file (mb_cfg.h). This is code that YOU need to provide and mb_cfg.h typically resides in your product’s directory since it can be different for each product.

(2) A Modbus master, connected to your product (that is running µC/Modbus-S) can read or change just about ANY data in your application. Access to your data (read or write) is done via a C file that you provide (mb_data.c). mb_data.c can read integers, coils, discrete inputs, floating-point values, etc. mb_data.c also allows you to execute ANY code when data is read or written. For example, if you change the diameter of a circle and need to compute the surface, you can simply include the code to compute the surface in mb_data.c. More on this later. This is code that YOU need to provide and mb_data.c typically resides in your product’s directory since it can be different for each product.

(3) This is the application independent slave code and it knows how to process Modbus ASCII and/or Modbus RTU packets. You should NOT have to modify this code.

(4) The interface to the UARTs in your product is placed in the Board Support Package (BSP) file called mb_bsp.C. This is a file that you provide in order to interface to µC/Modbus. Note that each channel can either communicate via RS-232C or RS-485 (at the interface level). This is code that YOU need to provide and mb_bsp.c is either placed in your product’s directory or provided by Micrium in the

\Micrium\Software\uC-Modbus\Ports\<CPU>\<compiler>

directory. This is the adaptation layer for the CPU or board you are using.

(5) µC/Modbus-S can be used with or without a RTOS (Real Time Operating System) environment. µC/Modbus-M assumes the presence of an RTOS. However, you can use just about any RTOS and the RTOS specifics are actually isolated in a file called mb_os.c. The code for µC/OS-II, µC/OS-III and Non-OS environment are provided so you don’t have to change this code if you use µC/OS-II or µC/OS-III in your product or you use µC/Modbus-S without any RTOS. The file mb_os.h. is only needed when µC/Modbus-S is used without any RTOS this is explained in Section 8.

(6) µC/Modbus is independent of the CPU and the compiler you use. However, you need to provide information about the data types specific to your CPU and compiler. For example, you need to define the following data types:

CPU_BOOLEAN Boolean (True or False, Yes or No, etc.)
CPU_INT08U  8 bit unsigned integer
CPU_INT16U  32 bit unsigned integer
CPU_INT32U  8 bit unsigned integer
CPU_FP32    32 bit IEEE754 floating-point
Etc.

These data types are needed because µC/Modbus never uses the standard C data types (i.e. char, short, int, long, etc.) because they are non-portable.

These data types need to be placed in a file called cpu.h (more on this later).