Design of Embedded WEB Server Based on ARM and eCos

With the rapid development of modern communication technology and network technology, Ethernet technology has become more and more mature, especially Web technology based on TCP/IP communication protocol has been widely used. We can use microcontrollers and Ethernet interface chips to replace PCs for field control and form embedded Web Server systems. Field sensors automatically track the information of each monitoring point, store the detected data in non-volatile memory, and publish it to the Internet in a timely manner; relevant staff can remotely control, manage and maintain the equipment through Web technology, and directly monitor the operation of field equipment from the browser, which greatly improves production efficiency and management level.

In order to realize the function of WEB server, an embedded operating system and an implementable TCP/IP protocol stack are necessary, so higher requirements are put forward for embedded processors. Compared with traditional 8/16-bit microcontrollers, ARM core processors have great advantages in computing speed, power consumption and storage capacity, and ARM core processors can easily implement embedded TCP/IP protocol stacks, so ARM core processors have become the preferred processors for embedded Web server devices. The design model of the system is shown in Figure 1.

1 System Hardware Design

The ARM core processor LPC2210 is based on a 32/16-bit ARM7TDMI-S CPU that supports real-time simulation and embedded tracing. There are 16 KBSRAM on the chip, which is configured into 4 groups through the external memory interface, with a capacity of 16 MB per group. LPC2210 uses a 144-pin package with extremely low power consumption. It has multiple 32-bit timers, 8-way 10-bit ADC, PWM output, and can provide up to 76 GPIOs and up to 9 external interrupt pins; it uses a 3-level pipeline technology to greatly improve the efficiency of instruction execution, and can achieve a maximum CPU operating frequency of 60 MHz through a programmable on-chip phase-locked loop (PLL).

The EMC combination of LPC2210 complies with ARM's PL090 standard, and the bus width can be set to 8 bits, 16 bits, or 32 bits. Generally, memories with a 16-bit bus width have a higher cost-performance ratio.

The embedded Web server is implemented with Philips' ARM core processor LPC2210 as the core; the network interface chip uses Realtek's NE2000 compatible chip RTL8019AS, which has a built-in 10BASE-T transceiver and is connected to Ethernet through the HR901170A device. The hardware structure is shown in Figure 2.

In Figure 1, LPC2210 is expanded with 2 MB NOR Flash (chip model SST39VF160) and 8. MB PSRAM (chip model MT45W4Mwl6). In order to facilitate debugging and final code curing application, the address space of LPC2210 external memory interface BankO and Bank1 is used, and the address space Bank0 and Bank1 are allocated to PSRAM and Flash respectively by selecting nCE_F and nCE_R through chip select signals. Usually, the code is cured to Flash, and Flash is allocated to Bank0 and PSRAM to Bank1, because Bank0 can be used to guide the operation of the program. [page]

The large-capacity on-chip memory of LPC2210 provides sufficient storage space for the implementation of TCP/IP protocol stack and data processing; using LPC2210SPI interface to expand MMC/SD card as external non-volatile memory, the data collected by ADC on-site, IP address, network card physical address and updated web page can be saved in it, and the MMC/SD card can be replaced at any time when needed. LPC2210 has ARM and Thumb instruction sets, and adopts pipeline processing technology, which can pre-process the next instruction during instruction execution, greatly improving the efficiency of instruction execution and providing effective support for network applications that require fast data transmission.

2 System Software Design

eCos (embedded Configurable operating system) is a portable embedded real-time operating system for 16-bit, 32-bit and 64-bit processors. As its source code is open, more and more designers are paying attention to the eCos operating system. The biggest features of eCos are modularity and kernel configurability. The smallest version of eCos is only a few hundred bytes, which is very suitable for the development of small embedded systems. Compared with embedded Linux, eCos has the advantages of flexible configuration and resource saving. Its other advantages are the use of multi-task preemption mechanism, minimal interrupt delay, support for all synchronization primitives required by embedded systems, and flexible scheduling strategies and interrupt handling mechanisms. Therefore, eCos has good real-time performance. Compared with operating systems such as μClinux and μC/OS, it is more suitable for the development of devices that process real-time signals, such as mobile communications, WLAN and other communication equipment.

3 eCos Porting

Figure 3 shows the migration process of eCos. The migration of eCos is completed through three sub-modules, namely the architecture abstraction layer (Architeeture Hal), the variant abstraction layer (Variant Hal) and the platform abstraction layer (Platform. Hal). For a new architecture, it is relatively difficult to establish the system structure abstraction layer. At present, eCos already supports various mainstream CPUs, that is, the eCos source code contains the CPU architecture layer and variant abstraction layer, so the migration work is mainly concentrated on the platform abstraction layer.

RedBoot porting is the best start for platform abstraction layer porting. RedBoot is a command line interface located above the hardware abstraction layer and includes the GDB debugging tool and its debugging stub. Once the hardware abstraction layer is ported to the target board, RedBoot can load the program into the target board and debug the code on the target board.

4 TCP/IP protocol stack - implementation of LwIP

LwIP is an open source TCP/IP protocol stack for embedded systems developed by Adam Dunkles and others at the Swiss Institute of Computer Science. It can be ported to an operating system or run without an operating system. The key point of LwIP implementation is to reduce the RAM usage while maintaining the main functions of the TCP protocol; generally, only a few dozen bytes of RAM and about 40 KB of ROM are needed to run, which makes LwIP suitable for application in mid- and low-end embedded systems.

LwIP can be divided into several layers as shown in Figure 4. The main functional modules are: operating system simulation layer, network interface function, various modules implementing TCP/IP protocol (IP, UDP, TCP, IC-MP, ARP), buffer and storage management subsystem, and checksum function.

LwIP API is a set of application programming interfaces, through which programmers can use all the functions of LwIP. In addition, LwIP also provides developers with a more advanced BSD Socket APl, which allows them to use general Socket functions to write network communication software. The operating system simulation layer enables LwIP to use some advanced management functions provided by the operating system, such as semaphore management, message queue management, thread creation, etc. [page]

4.1 IP Processing

LwIP can only implement most of the basic functions of the IP layer. Although it can send, receive and forward packets, it cannot receive and send IP fragment packets, nor can it process packets carrying IP parameter options. However, for most applications, this will not be a problem.

① Receive packets. For incoming IP packets, the network device driver can call the ip_input() function to start processing, and complete the initial integrity check of the IP version field and the packet header length here, and also calculate and verify the packet header checksum.

②Send the packet. The outgoing packet is processed by the ip_output() function, which uses the ip_route() function to find the appropriate network interface to transmit the packet. When the outgoing network interface is determined, the packet is passed to the ip_output_if() function with the outgoing network interface as a parameter.

③Forward the packet. If there is no network interface with the same address as the destination address of the arriving packet, the packet should be forwarded. This work is done by the ip_forward() function.

④ICMP processing. ICMP processing is quite simple. The ICMP packet received by the ip_input() function is handed over to the icmp_input() function, which decodes the ICMP packet header and then takes appropriate action.

4.2 UDP Processing

UDP is a simple protocol used to decompose packets between different processes. The state of each UDP session is stored in a PCB structure. The UDP PCB is stored in a linked list, and when a UDP data packet arrives, the linked list is matched and retrieved.

4.3 TCP Processing

TCP is a transport layer protocol that provides a reliable byte stream service for the application layer. Its description is much more complicated than that of other protocols, and its code accounts for 50% of the total LwIP code. The basic TCP processing process is divided into 6 functions to implement it. The tcp_input(), tep_process() and tcp_receive() functions are related to TCP input, and tcp_write(), tcp_enqueue() and tcp_output() are used for TCP output. The TCP processing process is shown in Figure 5.

4.4 Application Programming Interface Design

LwIP API is designed for LwIP, so it can make full use of LwIP's internal structure to achieve its design goals. LwIP API is similar to BSDAPI, but the operation is relatively low-level. API does not need to copy data between the application and the protocol stack, because the application can directly handle the internal buffer cleverly. In addition, BSD Socket API is easy to understand, and many applications are written for it, so it is useful for LwIP to retain a BSD Socket compatibility layer.

In view of the processing mode of the TCP/IP protocol stack, the API is implemented in two parts. As shown in Figure 6, one part is implemented as a connection library of the application, and the other part is implemented in the TCP/IP process. The two parts communicate with each other using the inter-process communication mechanism (IPC) provided by the operating system simulation layer. The current implementation uses the following three IPC methods: shared memory, message passing, and semaphore. Although these IPC methods are supported by the operating system, they do not require the support of the underlying operating system. In fact, the operating system simulation layer simulates them.

Conclusion

Based on the real-time kernel eCos, the LwIP protocol stack is transplanted and optimized in the embedded system. The transplanted and optimized LwIP stack runs as a network module, and the code occupies 40 KB of ROM. It realizes Ethernet/IP/TCP network functions and provides module API to achieve seamless connection with the system. The network application tasks based on LwIP and other non-network application tasks run in coordination under the management of the eGos real-time kernel. The network security and stability of the protocol stack are further enhanced, and corresponding network applications are developed. The "eCos/LwIP protocol stack" architecture is expected to be applied in information appliances and networked instruments and meters.

References:

[1]. LPC2210 datasheet http://www.dzsc.com/datasheet/LPC2210_454566.html.
[2]. ARM7TDMI datasheet http://www.dzsc.com/datasheet/ARM7TDMI_139812.html.
[3]. EMC datasheet http://www.dzsc.com/datasheet/EMC_2342312.html.
[4]. RTL8019AS datasheet http://www.dzsc.com/datasheet/RTL8019AS_1096173.html.
[5]. HR901170A datasheet http://www. dzsc.com/datasheet/HR901170A_1098413.html.
[6]. ROM datasheet http://www.dzsc.com/datasheet/ROM_1188413.html.
[7]. PCB datasheet http://www.dzsc.com/datasheet/PCB_1201640.html.