Design of remote monitoring system based on ARM embedded system

1 Introduction

The monitoring system has become an indispensable part of modern production and life. At present, there are many types of monitoring products, most of which are widely used in security fields such as transportation, hospitals, banks, homes, and schools.

With the emergence of embedded systems, especially embedded systems based on ARM core chips, the application fields of monitoring systems have become more extensive. In addition to security functions, the remote monitoring alarm system designed in this article can also be applied to the following fields: Communication field: remote communication, video conferencing and video on demand, securities, distance education, etc. Medical field: ward monitoring, remote diagnosis, etc. Industrial field: remote equipment diagnosis, maintenance, repair, remote production monitoring, etc. Household field: remote maintenance of household appliances; automatic alarm for major accidents such as electricity, gas, and fire, etc.

2 System Design

2.1 System composition

The remote monitoring system designed in this paper is mainly composed of central controller, data terminal, sensor module, communication module, interface module, etc. System composition diagram (as shown in Figure 1).

2.2 Central Controller

The system core is responsible for data collection, judgment and processing. In order to improve the system efficiency, Samsung's S3C2410 chip is used as the processor. The S3C2410 chip is a cost-effective ARM chip, which is very suitable for mobile phones, PDAs and other handheld devices. The main features include: arm920T core, the highest operating frequency is 203MHz, LCD controller: can directly drive the true color LCD screen, and supports up to 2048×1024 true color LCD screen, 2 USB Host ports, 1 USB Device port, support Nand flash boot mode, SD card interface, UART, IIC, SPI, IIS and other types of serial interfaces, 4-channel DMA.

The CPU core of the monitoring system in this article uses a standard SO-DIMM200 gold finger interface, which is convenient for later maintenance and upgrades. If the use environment of the monitoring system is more demanding, the CPU can be replaced with an S3C2440 chip. The S3C2440 is fully compatible with all the features of the S3C2410 (note: the chip pins are not fully compatible). Compared with the S3C2410 chip, the performance of the S3C2440 is superior: the maximum operating frequency can reach 500MHz, and the internal integrated CMOS camera interface, but the price is more expensive.

2.3 Data Terminal

The main function of the data terminal is to analyze and process the monitoring data and report the data to the monitoring personnel in a timely manner. At the same time, the monitoring personnel can use the data terminal to remotely control the monitored equipment according to the on-site situation. The biggest advantage of the data terminal is that it is safe, reliable and easy to carry. In general, in order to save costs, mobile communication devices such as mobile phones and PDAs can be used as data terminals. However, if it is used as a monitoring system for high-risk environments or precision instruments, the data terminal needs to be professionally customized. The central controller is used here as the data terminal, that is, the central controller is used as both a data collection and transmission center and a data receiving and processing center.

2.4 Communication Module

The communication module is mainly responsible for remote data communication. It has one or more communication methods such as RS232/485, GPRS, CDMA, etc. It needs to be customized according to the site environment and user needs. The communication module is connected to the controller through an interface bus, and the connection method is TTL/RS232/RS485, etc.

2.5 Sensor Module

The main function of the sensor module is to sense the external environment and monitor it in real time. It is composed of one or more sensors such as human infrared sensor, vibration sensor, ultrasonic sensor, combustible gas sensor, temperature sensor, humidity sensor, etc. It can be customized according to different on-site monitoring environments.

2.6 Interface Module

The interface module is mainly used as a system expansion function to expand the controller's A/D conversion, I2C, SPI and other interfaces externally. The interface module has no specific function, but can be connected to other devices as needed, for example, it can be connected to industrial instruments or equipment to monitor the instruments or equipment in real time.

Although the interface module is not the main part of the monitoring system, it is indispensable for the entire system. This is because the monitoring system in this article mainly considers the scalability of the system and seamless connection with other systems. The interface module can be used to easily upgrade the monitoring system and achieve seamless connection with other systems or devices. This is also the main function of this system that is superior to other monitoring systems.

3 Software Design

3.1 Working Software

The software design of the system is relatively complex, and only the entire working software process is given here (as shown in Figure 2).

3.2 Operating System Porting

S3C2410 chip supports a variety of embedded operating systems, such as WINCE, uCLinux, etc. However, considering the real-time requirements of the monitoring system, the μC/OS-II embedded real-time operating system is used here. μC/OS-II is a real-time multi-tasking operating system with open source, portable, curable, customizable, and preemptive. Most of its source code is written in ANSI C. The entire embedded system is divided into two layers: hardware layer and software layer. Here we mainly study the architecture of the software layer. The software layer is mainly divided into four parts: real-time operating system kernel, processor-related parts, application-related parts, and user applications. The files that need to be modified when porting the μC/OS-II system are: application-related files: OS_CFG.HINCLUDE.H; processor-related files: OS_CPU.H, OS_CPU_A.ASM, OS_CPU_C.C.

3.2.1 Processor-related code

This is the most critical part of the transplant. The kernel organically combines the application system and the underlying hardware into a real-time system. To make the same kernel applicable to different hardware systems, there needs to be an intermediate layer between the kernel and the hardware. This is the code related to the processor. Different processors have different codes. We need to transplant this part of the code ourselves during transplantation.

a）OS_CPU.H

It includes processor-related constants, macros and type definitions defined with #define, system data type definitions, stack growth direction definitions, interrupt disabling and interrupt enabling definitions, system soft interrupt definitions, etc.

b)OS_CPU_A.ASM

This part needs to operate the processor registers, so it must be written in assembly language. It includes four sub-functions: OSStartHighRdy(), OSCtxSw(), OSIntCtxSw(), and OSTickISR(). OSStartHighRdy() is called in the multi-task system startup function OSStart(). The functions completed are: setting the system running flag OSRunning = TRUE; loading the stack pointer of the highest priority task in the ready list into SP, and forcing the interrupt to return. In this way, the ready highest priority task is like returning to the running state from an interrupt, allowing the entire system to operate. OSCtxSw() is called in the task-level task switching function. Task-level switching is achieved through interrupts artificially created by SWI or TRAP. The vector address of ISR must point to OSCtxSw(). The functions completed by this interrupt are: saving the task environment variables (mainly the register values, which are achieved by pushing into the stack), storing the current SP in the task TCB, loading the SP of the ready highest priority task, restoring the environment variables of the ready highest priority task, and returning from the interrupt. This completes the task-level switching.

OSIntCtxSw() is called in the exit interrupt service function OSIntExit() to implement interrupt-level task switching. Since it is called in the interrupt, the processor's register stacking work has been completed, so this part of the work is not needed. Specific tasks completed: adjust the stack pointer (because calling the function will make the task stack structure inconsistent with the standard stack structure when the system task switches), save the current task SP, load the SP of the ready highest priority task, restore the environment variables of the ready highest priority task, and return from the interrupt. In this way, the interrupt-level task switching is completed. OSTickISR() system clock beat interrupt service function, which is a periodic interrupt that provides clock beats for the kernel. The higher the frequency, the heavier the system load. The size of its cycle determines the minimum time interval service that the kernel can provide to the application system. It is generally limited to the ms level (related to the MCU). For more demanding tasks, users need to create interrupts to solve them. The specific content of this function: save registers (if the hardware completes it automatically, it can be omitted), call OSIntEnter(), call OSTimeTick(), call OSIntExit(), restore registers, and return from the interrupt.

c) OS_CPU_C.C

There are 6 functions defined in this file, but the most important one is OSTaskStkInit(). The others are used to expand the system kernel. OSTaskStkInit() is called by the system itself when the user creates a task, and initializes the stack of the user task. The stack of the established task that enters the ready state is consistent with the stack structure when the system is interrupted and the environment variables are saved. In this way, the interrupt return instruction can be used to make the ready task run.

3.2.2 Application-related code

This part includes two files: OS_CFG.H, INCLUDES.H. Users customize the appropriate kernel service functions according to their own application systems. OS_CFG.H is used to configure the kernel. Users customize the kernel according to their needs, keep the necessary parts, remove the unnecessary parts, and set the basic conditions of the system. For example, the maximum number of tasks that the system can provide, whether to customize the mailbox service, whether the system needs to provide a task suspension function, whether to provide a task priority dynamic change function, etc. INCLUDES.H system header file, the file required by the entire real-time system program, including the kernel and user header files.

3.3 Graphical User Interface

Although the μC/OS-II operating system has high real-time performance, it does not have good graphical interface support like WINCE, uCLinux and other operating systems. Therefore, when using LCD and touch screen, it is necessary to transplant the user graphical interface program. Here we use μC/GUI. μC/GUI is a collection of software modules, through which we can add a user graphical interface (GUI) to our embedded products. μC/GUI has high execution efficiency and is independent of the processor and LCD controller. This module can work in a single-task or multi-task environment and can support display modes of different sizes.

Through μC/GUI, we can easily draw graphics and interfaces on the LCD screen. If you need to support multiple fonts, you must add the corresponding font library to μC/GUI. In order to avoid garbled characters, try to use the GB2312 national standard font library.

3.4 About the compatibility of fonts

The Chinese character library commonly used in our country is GB code, but UNICODE code is used internationally. Therefore, if the data terminal uses mobile communication devices such as mobile phones and PDAs, character code conversion must be performed before data is sent, that is, GB code is converted to UNICODE code or UNICODE code is converted to GB code. Since there is no regularity in the arrangement and combination of GB code and UNICODE code, the usual method of character code conversion is table lookup method.

4 Conclusion

The remote monitoring system based on the arm9 embedded system is different from the previous monitoring systems. The high-performance processor chip greatly improves the performance of the system. It enables the monitoring system to work in a relatively harsh environment. In addition, the design fully considers the scalability and compatibility of the system, and realizes the seamless connection between this system and other systems to meet the needs of different working environments.