Application scope of ARM7 embedded system in vehicle dispatching

1. Overall design of vehicle dispatching system:

The whole system consists of four parts: (1) communication master station; (2) vehicle-mounted slave station; (3) communication link; and (4) system monitoring part. The following is a brief introduction to the functions of each part.

(1) Communication master station: It completes information forwarding and is the link between the system monitoring part and the vehicle-mounted slave station. It forwards information from the system monitoring part to the vehicle-mounted slave station. It also receives information from the vehicle-mounted slave station and uploads the information to the system monitoring part.

(2) Vehicle-mounted slave station: The monitored object receives monitoring dispatch commands and can return its own status information. The acquisition of status information relies on the GPS receiver in the vehicle-mounted slave station to complete the collection of vehicle position and speed information.

(3) Communication link: complete the information transmission between the communication master station and the vehicle-mounted slave station and the information interaction between the communication master station and the system monitoring part. The former uses the GSM mobile phone module as the communication tool in this design, while the latter is realized by RS232 or USB.

(4) System monitoring part: The location information of the monitored vehicle is displayed on an electronic map in a graphical form (GIS, the use of geographic information system), and its status and other text information can be displayed. And the input of information such as dispatching commands can be completed through the human-computer interface of the system monitoring part. Since the basic components of these vehicle monitoring systems are included in many papers, they are briefly introduced here. For related content, please refer to the relevant paper materials. The following focuses on the kernel scheduling mechanism of UC/OS-II, the transplantation of the operating system, the development of embedded system programs based on the state machine, and the hardware design issues.

2. Kernel scheduling mechanism of the operating system:

Since the system does not have a strong requirement for timeliness, UC/OS-II, a simple source code developed operating system, is used. Since UC/OS-II is scheduled based on tasks. Therefore, the intermediate results to be processed in the system or the response to external input and output should be completed in the task. Task scheduling is based on priority (UC/OS does not support the time slice rotation method). After the multi-task scheduling starts, the clock beat starts working, and the clock beat generates periodic interrupts, and the clock beat provides the basis for delay or timeout. Before starting the multi-task, initialization work should be performed first, including the initialization of the CPU, TCB (task control block), ECB (event control block) and the operating system itself. After the initialization is completed, the multi-task is started, and the system always runs the task with the highest priority in the ready state. Since the task itself is an infinite loop, the task must contain functions that cause task switching, such as OSTimeDly(), OSSemPend(), etc. When these functions are executed, the task switching will be caused, that is, the scheduling of the task. The scene should be protected before the task switching. Tasks need to communicate with each other. There are many ways to communicate, such as global variables, shared storage areas, and other common methods. However, in systems using UC/OS-II, communication between tasks is more often carried out using semaphores, message mailboxes, and the like.

3. Operating system transplantation:

When porting the UC/OS-II operating system to Samsung's ARM7TDMI S3C44B0X, attention should be paid to the task switching function OSCtxSW(), where the core of task switching is to use the pop instruction to restore the work site of each task. The interrupt return instruction is used to change the PC pointer to achieve the purpose of task switching. It actually restores all the processor registers from the task stack and executes the interrupt return instruction. The actual porting is to use software to simulate the occurrence of interrupts. The key issue in the porting is how to construct the task stack and the order of popping the task when switching. The task area stack initialization is mainly to simulate the content of the stack after the task is interrupted. It is also worth noting the functions of the switch interrupt OS_ENTERCRITICAL() and OS_EXIT_CRITICAL(). These two functions implement the protection of the critical area content.

4. Programming based on state machine:

The software design of the whole system adopts the design method of task plus state machine. Since the system adopts the UC/OS-II operating system, all event processing in the system adopts the task scheduling method, and the task runs under the scheduling of the operating system. For each task, the design method based on the state machine is adopted. The event that causes a certain state in the system to transfer may be a semaphore or other events. The relevant content of the state machine is introduced below.

A state machine can be thought of as a graph of states and transitions that describes the application's response to received events.

Execution of the state machine: The state machine processes an event at a certain moment and must complete the processing of this event and obtain the result before processing another event.

The execution process of a program based on a state machine is as follows: at any time, there are one or more states in which the state machine is active. If a state is active, then a transition away from this state may be triggered, causing an event to be executed, and making another state or the state located at the initial state position active (the next state is in the initial state).

A state machine is a description of the sequence of states that an object of a state machine experiences during its own life cycle and its response to those events. A state machine can be understood as an object whose state is transferred from one state to another under the action of an event.

Several basic concepts in state machine:

1. State: refers to a condition or situation in the life cycle of an object, during which the object will meet certain conditions, perform certain activities, or wait for certain events.

2. An event is a description of a meaningful thing that occupies a certain position in time and space. In a state machine, the generation of an event can cause a state transition.

3. Transition is a relationship between two states, which indicates that the object performs certain actions in the first state and enters the second state when specific events or specific conditions are met.

Another issue that should be paid attention to in the programming of embedded systems is the reentrancy of functions. Reentrant functions can be called recursively and can be called by two or more processes at the same time. This requires a simulated stack area to be provided for the reentrant function during compilation.

Figure 2 shows the LCD display part of the system program designed using the state machine design method. The following is an explanation of Figure 2.

Among them, menu 1 is to display the welcome interface (the state mentioned above); menu 2 is to send short messages; menu 3 is to record the content of sent short messages; menu 4 is used to read received short messages. The specific state transfer process is as follows: when the display is in the welcome interface, in this state, if the down button is pressed (this is an event) or the key to send a short message is pressed, the system state is transferred to menu 2 (a state transfer occurs, and the following is similar to this, so the corresponding analysis is omitted.); in this state, when the down button is pressed or the system needs to enter the content of the short message to be sent, the system state enters menu 3 from menu 2; in this state, when the down button is pressed, the system state is transferred to menu 4; when the short message is finished reading, the system state returns to the welcome interface. The actual system also has a return button, etc. Here, this figure is just used to simply illustrate the programming method using a state machine.

5. Hardware design:

In order to make full use of the high clock frequency of S3C44B0X and reduce the delay of S3C44B0X in fetching instructions and accessing data, the system uses the method of solidifying the code in FLASH, and copying the code from FLASH to SDRAM for operation after the system starts. In addition, the system uses PDIUSBD12 as the communication master station to communicate with the system monitoring part on the PC. Compared with the RS232 serial communication method, the speed is greatly improved. Especially when the number of dispatched vehicles is relatively large, its speed advantage is more obvious.

VI. Summary:

After the system was run, the system met the design requirements.