Design of CAN repeater based on LPC2119 and μC/OSII

introduction

The direct communication distance of the CAN bus is only about 10 km, and due to the limitation of the transceiver driving capability, only 110 nodes can be connected to the bus at most, which brings certain difficulties to the system networking. The CAN repeater is designed to solve this problem. Since the repeater has the function of data forwarding, it can not only expand the communication distance, but also increase the maximum number of nodes. By setting the initialization parameters of the CAN repeater, different communication rates can be used in different network segments, and messages can be filtered to reduce the burden on the bus.

1 Hardware Design of CAN Repeater

1.1 Introduction to the LPC2119 microcontroller

The CAN repeater is a hardware and software system with the ARM microcontroller LPC2119 as the core. LPC2119 is a 16/32-bit ARM7TDMISMCU produced by Philips that supports real-time simulation and tracing, with 128 KB embedded high-speed Flash memory. The unique acceleration structure enables 32-bit code to run at the maximum clock rate. Applications with strict control over code size can use 16-bit Thumb mode to reduce code size by more than 30%, while performance loss is small. LPC2119 integrates two CAN controllers. Its main features are: data transmission rate up to 1 Mb/s on a single bus; 32-bit register and RAM access; compatible with CAN 2.0B, ISO 118981 specifications; global acceptance filter can recognize all 11-bit and 29-bit Rx identifiers; acceptance filter provides Full CANstyle automatic reception for selected standard identifiers.

1.2 Comparison between LPC2119 internal CAN controller and SJA1000

The CAN controller integrated in LPC2119 is roughly the same as the SJA1000 CAN controller of Philips, except that it is slightly different in the acceptance filter. This makes it convenient for developers who are used to SJA1000 to use LPC2119. The SJA1000 acceptance filter is defined by the acceptance code register and the acceptance mask register. The bit pattern of the message to be received is defined in the acceptance code register. The corresponding acceptance mask register allows certain bits to be defined as "irrelevant". Different filtering modes can be selected through the mode register: single filtering mode and dual filtering mode. For the CAN controller integrated in LPC2119, the global acceptance filter contains a 512×32 (2 KB) RAM. Through software processing, 1 to 5 identifier tables can be stored in the RAM. The entire RAM can accommodate 1024 standard identifiers or 512 extended identifiers or two types of mixed identifiers. At the same time, there are 5 address registers pointing to the table of the acceptance filter RAM: Full CAN standard address, standard single address, standard address range, extended single address or extended address range. When the receiving end of the CAN controller has received a complete identifier, it will notify the acceptance filter. The acceptance filter responds to this signal and reads the controller number, identifier size, and identifier from the controller itself. The acceptance filter then searches the table in RAM to decide whether to receive or discard the frame information.

1.3 CAN repeater hardware structure

The hardware structure diagram of the repeater is shown in Figure 1. LPC2119 is connected to the two buses through the CAN bus transceiver respectively; the bus driver is powered separately by an isolated DC/DC module, which not only realizes the electrical isolation between the two CAN interfaces, but also realizes the electrical isolation between the repeater and the CAN bus. In addition, there are LED display and keyboard interface. The LED is used to display the working status of the repeater, and the keyboard is used to correct the baud rate of the bus. The final program debugging and tracking is completed through the JTAG debug port.

Figure 1 Hardware structure diagram

2 System Software Design

2.1 Introduction of μC/OSII real-time operating system

As applications become more complex, the traditional front-end and back-end design methods will become too complex, real-time performance cannot be guaranteed, and deadlock is prone to occur. The best way to solve these problems is to use a real-time operating system.

μC/OSII is a completely preemptive real-time kernel, which is based on priority, that is, the task with the highest priority in the ready state is always run first, so the real-time performance is better than that of non-preemptive kernels. It includes real-time kernel, task management, time management, inter-task communication synchronization (semaphore, mailbox, message queue) and memory management functions; most of its code is written in C language, which is highly portable and can run on most 8-bit, 16-bit, 32-bit and even 64-bit microprocessors, microcontrollers, and digital signal processors (DSPs). [page]

CAN repeaters have high requirements for the real-time and reliability of the system. Using μC/OSII real-time operating system can effectively schedule tasks; assigning different priorities to each task can ensure timely response of tasks, and using real-time operating system reduces the complexity of the program and facilitates program development.

2.2 Issues to consider in software design

(1) Capacity of the used code

In the design of foreground/background systems, the memory capacity requirement depends only on the application code, but the situation with RTOS is very different. The RTOS kernel itself requires additional code space.

Total code size = application code + kernel code

Each task runs independently, and each task must be provided with a separate stack space (RAM). When deciding how much stack space to allocate to each task, it should be as close to the actual demand as possible. The size of the stack space must not only calculate the needs of the task itself (local variables, function calls, etc.), but also the maximum number of interrupt nesting levels (saving registers, local variables in interrupt service routines, etc.). Another feature that the kernel should have is that the size of the stack space required for each task can be defined separately. All kernels require additional stack space to ensure internal variables, data structures, queues, etc. If the kernel supports interrupt stack separation, the total RAM requirement is expressed as: Total RAM requirement = application RAM requirement + kernel data area RAM requirement + sum of each task stack requirement + maximum interrupt nesting stack requirement.

Unless you have a lot of RAM available, be careful with the allocation and use of the stack. Real-time multitasking systems require more code (ROM) and data space (RAM) than foreground and background systems. The extra code space depends on the size of the kernel, and the amount of RAM depends on the number of tasks in the system.

(2) Real-time and security

CAN repeater is one of the key devices for system networking, and is often used in slightly larger CAN bus systems. While it brings convenience to system networking, it also adds some storage and forwarding delays to the system. Therefore, the real-time performance of the system must be considered in software design, and the storage and forwarding time of data must be shortened as much as possible. In addition to requiring a higher priority to be assigned to the system data forwarding task, a communication mechanism should also be established to ensure that when data on one bus is received, it can be sent to another bus immediately. In addition, the repeater is a bridge for communication between the two buses. In order to ensure normal communication between the two buses, situations such as deadlock and bus failure should be avoided as much as possible. Therefore, the system must design a monitoring task that can respond immediately to such situations. At the same time, in order not to lose data that has not been forwarded, a ring buffer must be set up for each bus to store newly received data and maintain the security of the system.

2.3 System Design and Implementation

The embedded CAN repeater mainly realizes the mutual forwarding of data between two CAN buses, and can change the baud rate of a CAN controller according to actual needs. The μC/OSII real-time operating system is adopted, and the entire design consists of an operating system and a series of user applications.

The main function is the first function executed by the program. This function will never return, and it mainly implements the initialization of the system hardware and operating system. The hardware includes the initialization of interrupts, keyboards, displays, etc. The operating system includes the initialization of task control blocks and event control blocks, and at least one task must be created before starting multi-task scheduling. In this system, a startup task is created, which is mainly responsible for the initialization and startup of the clock, the startup of interrupts, the initialization and startup of the CAN controller, and the division of tasks. After handing over the right to use the CPU, only some idle processing is done.

(1) Division of tasks

To complete the various functions of real-time multitasking, tasks must be divided. This program is divided into six tasks with different priorities according to the importance and real-time nature of each task, including system monitoring, data forwarding, keyboard input, LED display, receiving queue monitoring and baud rate setting. Table 1 is a task division table.

In addition to the six main application tasks, there are two interrupt service routines: a clock beat interrupt to provide a periodic signal source; and a CAN receive interrupt to write the received data into a ring buffer.

(2) Task synchronization and scheduling

Usually, a task in a multitasking operating system is different from a general function. It is an infinite loop and has no return value. If no higher priority task enters the ready state, the current task will not give up the right to use the CPU. In order to achieve the normal operation of the operating system and the synchronization of related events, the communication between tasks and the setting of event flags must be handled correctly. The functional structure of the entire system is shown in Figure 2.

Figure 2 System functional structure

Each task has a different priority. By calling the system suspend function or delay function, a task with a higher priority that enters the ready state can be started. In the design of the embedded CAN repeater, by setting the delay parameters, the system starts the receive queue monitoring task every certain clock beats and regularly scans the ring buffer. Once it is found that the read pointer is not equal to the write pointer, the newly received data in the ring buffer is stored in TEMPBUF, and the semaphore SendSem is sent at the same time. The data forwarding task receives the semaphore, starts running, and completes the data forwarding function. [page]

The data forwarding task is as follows: void CANDATA_ExchangeTask(void *pdata)

{

#if OS_CRITICAL_METHOD == 3 /* Allocate memory to CPU status register */

OS_CPU_SRcpu_sr;

#endif

INT8U err;

pdata=pdata;/*Avoid compiler warning*/

for(;;) {

OSSemPend (SendSem,0,&err);/*Wait for sending semaphore. If there is no signal, suspend this function and start other tasks, such as system monitoring, keyboard input, LED display, etc.*/

if (CANNUM == CAN1) {/*Judge which bus receives the data. If it is CAN1, send the data to CAN2*/

ToSendData (TEMPBUF, FORTXBUF);/*Convert the data stored in TEMPBUF into a data format that can be used for sending and store it in FORTXBUF*/

CanSendData (CAN2, 0x00, FORTXBUF); /*Send data to another bus*/

}

else {

ToSendData(TEMPBUF,FORTXBUF);

CanSendData (CAN1,0x00,TXBUF);

}

}

}Similarly, other module functions - baud rate setting, system monitoring, information display, etc., are also achieved through communication between tasks - the transmission of semaphores, so as to ensure the synchronization of time and tasks.

Conclusion

Based on the embedded hardware platform, the μC/OSII real-time operating system has its own unique features in developing applications. Users can directly use the system's interface functions to write their own applications without separate development, which greatly facilitates user programming, shortens the software development cycle, and improves development efficiency. The CAN repeater based on μC/OSII and LPC2119 runs well and works stably during the experimental debugging process.

References
1 Labrosses Jean J. Embedded real-time operating system μC/OSII. Translated by Shao Beibei et al. Beijing: Beijing University of Aeronautics and
Astronautics Press, 2003 2 Zhou Ligong et al. Fundamentals and Practice of ARM Microcontrollers. Beijing: Beijing University of Aeronautics and Astronautics Press, 2003
3 Rao Yuntao et al. Fieldbus CAN principles and application technology. Beijing: Beijing University of Aeronautics and Astronautics Press, 2003
4 Labrosses Jean J. Embedded System Components. Translated by Yuan Qinyong et al. Beijing: Machinery Industry Press, 2002
Shen Yue: Postgraduate student, research direction is computer network control and embedded systems.