Design of monitoring terminal of suspension controller based on CAN bus

CAN bus is a serial bus developed by Bosch of Germany to solve the data exchange between multiple sensors and controllers in modern cars. Due to its high communication rate, long communication distance and strong anti-interference ability, it is suitable for high-interference environments. At present, CAN bus has been widely used in real-time communication between control systems with strong background interference.

For multi-point suspension control, the number of controllers is likely to be more than one, and the electromagnetic environment in which the controllers are located is generally relatively bad. Therefore, the communication method and communication reliability between controllers is an issue that must be considered. The network composed of CAN bus has the characteristics of simple structure and high reliability, and can realize point-to-point, point-to-multipoint and global broadcast. Therefore, for suspension control, using CAN network as a communication network is an ideal choice. On the other hand, digital controllers in complex working environments are likely to enter the "flying car" state under electromagnetic interference or power fluctuations, causing one or more points of suspension to fail. This requires the design of an upper-level supervisory node in the CAN network to effectively supervise and adjust the nodes in these networks in real time.

The CAN network monitor/debugger designed with the computer's parallel interface and a dedicated CAN driver chip is easy to implement and has a user-friendly interface. However, in the actual control site, this computer-based monitoring system has problems such as inconvenience in carrying and high cost. Therefore, designing a portable CAN network monitor/debugger has great practical significance. This article introduces a portable CAN network monitoring terminal based on TMS320LF2407A DSP. It is simple to use, has a user-friendly interface, and is small in size. It is suitable for on-site monitoring and debugging of the maglev train suspension controller.

1 System Introduction

For multi-point suspension control, in order to reduce risks and improve control flexibility, one suspension point is generally controlled by a separate controller. The relationship between each suspension point and the monitoring node is shown in Figure 1. The CAN monitoring terminal is also a common node in the CAN network and is connected to the entire network through a twisted pair cable.

For each suspension point, the parameters that need to be monitored generally include current, gap, acceleration and some other intermediate parameters. Depending on the different control algorithms, the number of monitored parameters is also different. The task of the monitoring node is to send a send permission command to one of the suspension nodes. After receiving this command, the suspension node will regularly package the current parameters of the sensor and controller and send them to the CAN bus. The monitoring node then listens to the data sent by this node and displays the received parameters on the display. Long-term reception can also depict certain parameters, such as current and gap, in the form of curves for the evaluation of the suspension control algorithm. If it is necessary to modify certain parameters of the currently monitored controller, the modification command can also be sent to the target node through the human-machine interface of the CAN monitoring terminal.

In terms of implementation, the main control chip of the CAN monitoring terminal uses TI's TMS320LF2407A DSP. In addition to the characteristics of rich on-chip resources, fast computing speed, low cost, and low power consumption, this DSP also has an on-chip CAN module, which is easy to use. Data output is realized by a 240×128 LCD screen, which can depict the trend of each parameter change with a curve, with good flexibility. User input uses a row and column scanning keyboard, which makes hardware implementation and software programming more convenient.

2 Hardware Design

The hardware block diagram of the system is shown in Figure 2. As can be seen from the figure, the TMS320LF2407A DSP is the core component of the entire circuit. It is a high-performance 16-bit fixed-point DSP for real-time control, with 32K words of on-chip Flash program memory and 2.5K words of on-chip RAM, a computing speed of up to 40MIPS, and an on-chip serial communication interface and CAN communication interface. These features have greatly facilitated the design and implementation of the CAN monitoring terminal. In terms of hardware implementation, considering the system's requirements for volume and power consumption, all DSP programs and LCD fonts are directly burned into the DSP's on-chip Flash through the JTAG port, and the program can run directly in the on-chip Flash after power is turned on. The DSP's crystal oscillator frequency is selected to be 6MHz, and the DSP's operating main frequency reaches 24MHz after the DSP's on-chip PLL phase-locked loop is quadrupled.

Since the DSP chip has a CAN controller module, the design of the CAN module of the monitoring terminal is very simple. It only needs to connect a CAN driver chip to the CANTX and CANRX pins of the DSP. The CAN driver chip selected here is PCA82C250.

The power supply voltage of DSP is 3.3V, while the peripheral chips are basically 5V. If they are directly connected, it will inevitably lead to level conflicts. The solution is to use an LVC4245 as a bidirectional buffer between the DSP data bus and the peripheral interface bus. When exchanging data, the R/W signal of DSP controls the data flow direction of LVC4245.

The LCD uses a 240×128 dot matrix SMG240128A monochrome LCD screen. It has a relatively large effective display area, suitable for displaying information such as curves, and the programming of the underlying driver is relatively easy. The interface between the LCD and the DSP uses an analog port line method, that is, two 74HC573s are used to latch the data bus and the control bus data respectively, simulating the driving timing of the LCD. Several status bits of the LCD are directly read in by the I/O pins of the DSP.

The keyboard consists of 18 keys, 0 to 9, A to F, SHIFT and ENTER, so the hardware design uses a 5×4 row and column scanning method: 74HC573 provides 5 output row lines, 74HC244 provides 4 column inputs, and DSP provides row and column scanning timing. Considering the level matching problem, the connection between 74HC573 and 74HC244 and the DSP data bus is also buffered by LVC4245.

The 74HC573 and 74HC244 chips of LCD and keyboard interface are both selected by a GAL through decoding the address bus of DSP. The circuit is simple and flexible.

Due to the requirement of portability, the system is powered by batteries. Five rechargeable No. 5 batteries are used as the power supply here, and the normal power supply voltage is 5~7V, which just meets the power supply requirements of the power chip TPS7350. Since the system requires two power supplies of 3.3V and 5V, a low-voltage difference chip TPS7350 is selected as the power supply chip for the 5V power supply, and another low-voltage difference chip TPS7333 is used as the power supply chip for the 3.3V power supply. In order to prevent unexpected shutdown accidents caused by insufficient battery power, a battery power alarm circuit is also constructed here using an LM311 to light up the LED alarm prompt when the battery voltage is lower than the safe voltage. For easy operation, all hardware circuits and batteries are installed in a portable plastic shell.

3 Software Design

In the CAN network structure diagram shown in Figure 1, the data flow can be roughly divided into two categories: communication between each suspended node and communication between the suspended node and the monitoring node. Since the communication between the suspended nodes has no direct relationship with the monitoring terminal, it can be ignored. What needs to be considered is the communication between each suspended node and the monitoring terminal, which requires that a communication protocol between the suspended node and the monitoring terminal must be formulated when forming the CAN network. When implementing, the specific protocol is as follows:

(1) The receiving identifier of the CAN monitoring terminal is 0, and the identifiers of other floating control nodes must not conflict with it; all nodes use a unified baud rate (50Kbps or 500Kbps); the length of the data packet is unified to 8B.

(2) Data transmission from the CAN monitoring terminal to the suspended node The identifier of the data packet is specified by the DIP switch of the monitoring terminal. Each suspended node compares the identifier of the data packet with its own local identifier to determine whether to receive the data packet.

(3) The monitoring of the CAN monitoring terminal is open, and it does not require the identifier of the received data packet to be consistent with its own identifier. However, the first byte in the data packet indicates the label of the suspension controller that sent the data packet. If the label is consistent with the label specified by the dip switch, the content of other bytes will continue to be processed; otherwise, the packet will be discarded. The second byte in the data packet indicates the type of parameter, and the remaining bytes are parameter data in floating point form.

(4) When the system starts running, each suspended node does not send data to the CAN monitoring terminal. Only after the CAN monitoring terminal sends a "send permission" command to a node, the node will periodically send upload data to the CAN monitoring terminal. If the CAN monitoring terminal wants to monitor the data of other nodes, it must first prohibit the current node from sending data, and then send a "send permission" command to other nodes. This can effectively reduce the data flow on the CAN bus.

The above protocol can effectively maintain the data communication order in the CAN network.

From a practical point of view, the software is required to be as simple as possible, with a friendly interface and easy operation. In order to make full use of the display capacity of the LCD, a menu is used to prompt the user to operate. The completed software interface is shown in Figure 3.

The program adopts a layered program structure. The bottom layer is some hardware drivers, such as keyboard scanning, LCD status reading and LCD data writing. On the basis of these bottom-level drivers, some upper-level subroutines are organized for the main program to call. In terms of the choice of programming language, considering that the structure of the program is relatively complex, the main body of the program is programmed in C language, and only a small part involving some low-level operations of DSP is programmed in assembly language. The main flow chart of the software is shown in Figure 4.

Initialization includes initialization of CAN control registers and screen initialization, and then reads the status of the DIP switch, determines the baud rate and communication object, and sends a "send allow" command to the monitored node.

The main body of the program is a large loop. After initialization, the keyboard is continuously scanned. First, it is determined whether a key is pressed. If the user does not operate, it is checked whether the CAN module receives data. If no data is received, the keyboard is scanned again. If data is received (that is, the corresponding CAN receive interrupt flag is set), the received data packet is analyzed and integrated according to the above protocol, and then the received value is displayed on the screen; at the same time, points are drawn at the corresponding position of the curve to complete the drawing of the curve. If a key is found to be pressed during the keyboard scanning process, the key type is analyzed and then transferred to the corresponding subroutine for processing. After processing, it returns to the main program.

The data reception here does not adopt the interrupt drive mode because the response speed of LCD is slow. When the response speed of LCD is lower than the speed of CAN receiving data, interrupt nesting will be formed, and stack overflow will occur over time. In addition, when the interrupt mode is used, the DSP will not have time to take care of the user's keyboard input when the amount of data is large. Practice shows that the query mode can give full play to the inherent capabilities of DSP and LCD, and the overall response speed is faster than the interrupt mode.

LCD display involves many subroutines and layers. When writing a program, first define a segment in the DSP's Flash ROM, make a library of dot matrix data such as characters and Chinese characters that may be involved in the LCD display process, put it in the segment, and then read it through ROM access instructions when using it.

The process of drawing a curve is as follows: first determine the origin of the coordinates, the maximum coordinates in the X and Y directions, and the range of the input values, then open a buffer BUFF of the same size as the number of X coordinate points in the memory to memorize the coordinates of the points that have been drawn; at the same time, set an X pointer to store the current X coordinate. When new data is received and the Y coordinate is determined, first search the BUFF to obtain the Y coordinate of the point originally displayed at the X position, clear the point at this position, then draw the point at the new Y coordinate, and finally record the Y coordinate value of the new point at the corresponding X position of the BUFF. At this time, the drawing of a point is completed. Later, the pointer on the screen must be adjusted to indicate the currently displayed X coordinate. When drawing to the maximum position in the X direction, return to the position of X=0 to continue drawing.

The menu operations at the bottom of the screen are also implemented using a tree structure, which will not be described in detail here.

The process of CAN monitoring terminal sending data to floating node is generally carried out after the corresponding menu operation and pressing ENTER key to take effect. Before each data transmission, the program needs to read the state of the dip switch to determine the baud rate of communication and the identifier of the communication object. In implementation, the highest bit of the dip switch controls the baud rate, and the following 7 bits determine the sending identifier of the communication.

4 Conclusion

The use shows that this CAN bus monitoring terminal based on TMS320LF2407A DSP can play a good monitoring and debugging role in the network composed of multiple suspension controllers. It has a compact structure, a friendly interface and is very convenient to use.