Directories and Files
The code for µC/Modbus is found in the following directories.
Target Independent Source Code
\Micrium\Software\uC-Modbus\Source
This directory contains the UART, OS and CPU independent source files. This directory contains the following files:
mb.c Master/Slave independent code mb.h mb_def.h Modbus Definitions mb_util.c ASCII convertions utilities mbs_core.c Slave specific code mbm_core.c Master specific code
RTOS Interface
\Micrium\Software\uC-Modbus\OS\uCOS-II
\Micrium\Software\uC-Modbus\OS\uCOS-III
These directories contains the code to interface to the µC/OS-II and µC/OS-III RTOSs and contains the following file:
mb_os.c
(See RTOS Interface)
If you interface µC/Modbus to different RTOSs, you would place an mb_os.c
file in a separate directory. In other words, all RTOS interface files should be called mb_os.c
but the specifics of the actual RTOS you use would be placed in a different directory. When you build your product, you obviously need to select only one RTOS interface – the one specific to your RTOS.
\Micrium\Software\uC-Modbus\OS\None
This directory contains the code to use µC/Modbus-S in a single threaded environment without the need of an RTOS.
mb_os.c
(See No-OS Interface)
mb_os.h
(See No-OS Interface)
Product Specific Files
???\Product
This directory contains your application code. You need to provide the following files:
mb_cfg.h
(See Configuring µC/Modbus)
mb_data.c
(See µC/Modbus-S, Accessing Application Data)
mb_bsp.c
(See Board Support Package (BSP))
CPU and Compiler Specific Files
\Micrium\Software\uC-CPU\<CPU-type>\<compiler>
This directory contains information about your CPU and the compiler you are using. There are three files that you need to specify:
cpu.h
cpu_a.asm
It’s preferable to ‘modify’ existing files than create new ones from scratch so that you don’t forget anything. An example of these files is provided with µC/Modbus.
cpu.h
This file defines CPU/compiler specific data types. The code below shows an example of the data types needed by µC/Modbus for an ARM CPU and the IAR Embedded Workbench compiler.
typedef void CPU_VOID; typedef unsigned char CPU_CHAR; typedef unsigned char CPU_BOOLEAN; typedef unsigned char CPU_INT08U; typedef signed char CPU_INT08S; typedef unsigned short CPU_INT16U; typedef signed short CPU_INT16S; typedef unsigned int CPU_INT32U; typedef signed int CPU_INT32S; typedef float CPU_FP32; typedef double CPU_FP64; typedef void (*CPU_FNCT_PTR)(void *);
You also need to specify the type of ‘alignment’ to use as well as the ‘endianness’ of the processor:
#define CPU_CFG_ALIGN_TYPE CPU_ALIGN_TYPE_32
#define CPU_CFG_ENDIAN_TYPE CPU_ENDIAN_TYPE_LITTLE
You also need to define code to disable and enable interrupts. In fact, the code to disable interrupts should ‘save’ the state of the interrupt enable setting and then disable interrupts. This is done by an assembly language function called CPU_SR_Save()
. The code to re-enable interrupts should simply restore the state saved by CPU_SR_Save()
. This would be done by a function called CPU_SR_Restore()
. The state of the interrupt enable setting is stored in a local variable of type CPU_SR
as shown below.
typedef CPU_INT32U CPU_SR; #define CPU_CRITICAL_ENTER() {cpu_sr = CPU_SR_Save();} #define CPU_CRITICAL_EXIT() {CPU_SR_Restore(cpu_sr);}
You should note that µC/Modbus actually uses CPU_CRITICAL_ENTER()
and CPU_CRITICAL_EXIT()
to disable and re-enable interrupts, respectively.
cpu_a.asm
This file contains the code for CPU_SR_Save()
and CPU_SR_Restore()
. This code is typically written in assembly language since it generally accesses CPU registers which are not typically accessible from C. However, if your compiler allows you to manipulate CPU registers in C, you would implement CPU_SR_Save()
and CPU_SR_Restore()
directly in C and call this file cpu.c
instead of cpu_a.asm
.