Abstract: This paper analyzes a major problem in embedded Internet, introduces two typical design schemes for embedded gateways, and designs a new type of embedded gateway that integrates internal and external network communication. Based on the introduction of the gateway hardware structure, the paper discusses the implementation methods of each software module of the embedded gateway, focusing on the gateway's software architecture.
Keywords: Embedded gateway; Multi-channel communication interface; Embedded Internet; μC Linux
The emergence of embedded Internet technology enables embedded systems to share resources, communicate information, and perform status monitoring and control with the Internet. Currently, one of the main problems with this technology is that the various communication protocols on the Internet place high demands on computer memory and processing speed, which the numerous 8-bit and 16-bit MCU systems in the monitoring and control field cannot handle. To solve this problem, a feasible method is to utilize buses commonly used in the embedded field, such as RS485, RS232, and CAN buses, to connect these embedded devices with lower processing capabilities to the communication interface provided by a gateway. The gateway then handles the protocol stack and protocol conversion, thereby connecting the 8-bit/16-bit embedded devices to the Internet.
1. Typical Design Scheme of Embedded Gateway
Gateways, also known as inter-network protocol converters, are used to connect networks using different communication protocols and realize data transmission between networks. When a message needs to be sent from one network segment to another, the gateway needs to complete the reception, translation and forwarding of the message [1]. As for the gateways currently used in embedded systems, there are mainly the following two types:
1.1 Gateway implemented using a PC
Leveraging the abundant resources and powerful processing capabilities of a PC, a web server is built on it to communicate with Internet clients. An 8-bit/16-bit MCU device connects to the PC's bus expansion interface or a specific board, communicating with the PC via a communication program, thus using the PC as a gateway to access the Internet. This method is relatively easy to implement and offers good flexibility, but it is costly, and the equipment reliability and environmental adaptability are relatively poor.
1.2 Gateway implemented using a 32-bit embedded system
Based on a 32-bit embedded system, it is small in size, low in cost, and has good reliability and environmental adaptability. Depending on the method of implementing the TCP/IP protocol stack, this type of embedded gateway can be divided into the following two design schemes.
(1) Implement the TCP/IP protocol stack in software [2]
There are usually two ways to implement this scheme. The first is to use an embedded operating system with a TCP/IP protocol stack. The gateway runs on the embedded operating system and can take advantage of the powerful functions of the embedded operating system to implement many complex functions according to user needs. The second method is to use the TCP/IP protocol stack software module alone without using the embedded operating system. The system built only occupies a small amount of storage space, but if complex functions are to be implemented, the programming complexity is large. (2) Directly use the TCP/IP protocol stack chip [2]
In this approach, the chip with the integrated TCP/IP protocol stack is directly used in the embedded gateway, which simplifies the design. However, adding an extra chip increases manufacturing costs, and developers need to be familiar with the interface of the TCP/IP protocol stack chip.
2. Hardware Structure of Embedded Gateway
The gateway's hardware architecture is shown in Figure 1. The processor is a SAMSUNG S3C44B0X based on the ARM7TDMI, a 16/32-bit RISC processor operating at 66MHz. It has rich built-in peripherals and peripherals and is commonly used in handheld and network devices. The system memory uses 4M×16bit HY57V65160b SDRAM, and the storage uses 1M×16bit SST39VF160 Flash. The gateway's Ethernet controller uses an RTL8019AS, which supports IEEE 802.3, 8/16-bit data bus, has 16KB of built-in SRAM, supports full-duplex mode, and can simultaneously transmit and receive at 10Mbps. The gateway provides multiple local communication interfaces, with the RS232 interface implemented using the S3C44B0X's UART0 port, and level isolation and conversion using a MAX3221E. The RS485 interface is implemented using the UART1 port of the S3C44B0X, with an external MAX485 connector handling TTL-to-RS485 level conversion and data transmission/reception. The CAN bus interface uses a bus connection and a PHILIPS SJA1000T CAN controller, which is compatible with both BasicCAN and PeliCAN modes, conforms to the CAN 2.0B protocol, and possesses all the features required for CAN communication. An external TJA1040T is used as the transceiver for the CAN bus interface. In addition, the system reserves other communication interfaces for future expansion.
Figure 1 Embedded gateway hardware structure
Figure 2 Software architecture of the embedded gateway
3. Software Design of Embedded Gateway
3.1 Software Architecture
The embedded gateway designed in this paper runs on the embedded operating system μCLinux. Externally, it interacts with Internet clients via a web server; internally, it connects to multiple distributed subnets of different types through multiple communication interfaces, according to different bus standards, as shown in Figure 2. The gateway treats all communication subnets within the internal network and the external Internet as equivalent networks. When forwarding data, it masks the differences between networks, converting data from different networks into a unified format for forwarding data packets, and employs a priority-based scheduling mechanism to complete the forwarding. This integrates the communication between the internal and external networks, enabling the conversion between various subnet communication protocols and the TCP/IP protocol, as well as the conversion between various subnet communication protocols.
When the web server receives a request from an Internet client, if it requests a static webpage, it sends the webpage to the client (corresponding to ① in Figure 2, the same below); if it requests communication with a terminal device on the local subnet, the server sends the communication data to the Internet interface module (②), which parses the data and encapsulates it into a forwarding data packet, which is then sent to the receiving submodule (③); conversely, when the Internet interface module receives a data packet from the sending submodule (④), it parses the data packet, generates a dynamic webpage, and sends it to the web server (②), which then sends it to the client (①).
When a terminal device on the local subnet needs to communicate with other devices or send a response data packet to an Internet client, the data is sent from the terminal device to the intranet communication module (⑤) according to a certain scheduling mechanism. The module then converts the data into a forwarding data packet for the gateway and sends it to the receiving submodule (⑥). Conversely, if the intranet communication module receives a data packet (⑦) from the sending submodule, it selects the appropriate subnet based on the destination address of the data packet, converts the data packet into data conforming to the communication protocol of that subnet, and then sends it to the destination device (⑤).
After receiving data packets from the Internet (③) or the local subnet (⑥), the receiving submodule inserts these uniformly formatted data packets into the data queue according to their priority (⑧). When there are data packets in the priority-based queue, the sending submodule retrieves the data packets (⑨) and sends them to the destination subnet (④⑦).
3.2 Porting the embedded operating system μCLinux and configuring the Boa server
μClinux is a project fully compliant with the GNU/GPL (General Public License). Its code is completely open and specifically designed for MPUs without an MMU. Through modifications to the standard Linux kernel, it is miniaturized for embedded systems, resulting in a highly optimized and compact embedded Linux distribution. Applying μClinux to a gateway leverages its comprehensive network capabilities, reducing development difficulty and shortening development time. The first step in using μClinux is to port it to the gateway's hardware platform. This involves installing a Linux operating system on a PC, downloading and extracting the uClinux source code package, downloading and installing cross-compilation tools, and establishing a cross-compilation environment. Next, the source code is modified according to the specific hardware system, and drivers for any special hardware are written or modified. Then, the kernel is configured to generate a kernel file that can run in RAM. Finally, the kernel is burned into the hardware system's Flash memory and powered on.
The commonly used WEB servers in μClinux are Boa, thttpd, and httpd. The gateway can be selected as Boa WEB server, which supports authentication, supports CGI, and is very suitable for embedded systems [3]. Boa is a single-task HTTP server. It does not start a separate process for each accessed connection, nor does it start multiple copies of itself for multiple connections. All active HTTP connections are processed internally, and only a new process is started for each CGI connection. Therefore, Boa is faster under the same hardware conditions. To use Boa WEB server, you need to set its operating environment, parameters, etc., such as setting the listening port to 80, setting the server's file root directory DocumentRoot, and setting the storage directory of CGI files.
3.3 Design of Internet Interface Module
The Internet interface module is essentially a CGI[3] (Common Gateway Interface) program. CGI is a supplement to the HTTP protocol and is a standard used to define the communication method between a WEB server and an external program. It defines the set of rules that both parties must follow in establishing interoperability. CGI technology is relatively mature and there is a lot of relevant literature, so this paper will not discuss it in detail, but will focus on introducing the implementation algorithm of the Internet module. Its flowchart is shown in Figure 3.
Figure 3 Flowchart of Internet Interface Module
The Internet client can submit data to the web server using either "GET" or "POST" methods. The web server saves the submission method used in the environment variable `REQUEST_METHOD`. For "GET" methods, the server saves the valid data in the environment variable `QUERY_STRING`, which the Internet module can directly read to obtain the valid data. For "POST" methods, the server saves the length of the valid data in the environment variable `CONTENT_LENGTH`, allowing the Internet module to read valid data from standard input under the control of this data length. After obtaining the valid data, the Internet module parses it, generates forwarding data packets, and sends them to the forwarding module. Once data reception is complete, the process suspends itself, waiting for the semaphore `InternetRec` to become valid. When `InternetRec` becomes valid, it indicates the arrival of a feedback data packet from the internal network. The process is then awakened, receives the feedback data packet, verifies the destination address, generates a dynamic webpage based on the data packet, and submits it to the web server for transmission to the client.
3.4 Design of Forwarding Data Packets
The forwarding module performs packet forwarding within the gateway. It maintains a priority-based data queue (see Figure 2), which is a critical resource and is used exclusively by the receiving and sending submodules. The structure of the forwarded packets should have a certain degree of versatility, capable of being compatible with various communication subnets or Internet data. It can be defined using the following data structure:
struct DataProtocol{
int CommType;
struct Addr_t DstAddr;
struct Addr_t SrcAddr;
int Prio;
struct DataStruct *DataHead;
int DataLengh;
struct DataProtocol ＊pDProtc; };
(1) int CommType; Defines the communication type. It is used to indicate the type of data packet being transmitted, namely DATATYPE (valid data packet) and ERRORTYPE (error message packet). DATATYPE means that the data field of this data packet contains valid data; while ERRORTYPE means that the data field carries error information. When processing data packets, the gateway can first determine the type of the data packet and then adopt the corresponding processing procedure, thus improving the processing efficiency.
(2) struct Addr_t DstAddr; Destination address for communication. Used to specify the destination address to which data is sent. Its data type is defined as follows:
struct Addr_t{
unsigned char SubNet; // Specifies the type of network (local subnet or Internet).
unsigned char DevAddr; }; // Specifies the address of the terminal device within the subnet
Note: Since the Boa WEB server used by the gateway is single-task and only handles one Internet connection at a time, DevAddr should be zero when SubNet is Internet.
(3) struct Addr_t SrcAddr; The source address for communication, used to specify the source address of the data.
(4) int Prio; Data packet priority. Different data packet priorities are defined for data packets from different communication subnets and different devices, depending on the real-time requirements of the communication. In the forwarding module, high-priority data packets are inserted at the head of the queue and are forwarded to the destination network first. When specifying specific data packet priorities, the method of the smaller the Prio value, the higher the priority is adopted, and it is stipulated that data packets related to the Internet have a higher priority than data packets transmitted between intranets.
(5) struct DataStruct *DataHead; The head pointer of the linked list queue storing valid data. This linked list is the data field of the data packet, and its data type is defined as follows:
struct DataStruct{
char *Name;
char *Value;
struct DataStruct ＊pDStruct; };
*Name stores the type of data or operation, which can be "INFO" (description information), "READ" (read data), "WRITE" (write data), or "CONTROL" (send control command);
* The format of Value is: Operation Name or Object [Parameter 1] [Parameter 2] ... [Parameter n]
There should be no spaces in the operation name or object and in the parameters. Parameters should be separated by spaces. The number of parameters can be zero.
For example, to start a device, simply send the following data: Name->CONTROL, Value->START; to read the device temperature value, simply send: Name->READ, Value->TEMPERATURE. The data packets only store the ASCII codes of the valid data. The embedded gateway only handles the transmission of these ASCII codes from the sender to the receiver, implementing routing and intermediate protocol conversion functions. The specific meaning of these ASCII codes is defined by the application layer of the sender and receiver, thus achieving a universal data transmission channel independent of the specific meaning of the data.
(6) int DataLengh; specifies the number of “Name” and “Value” pairs in the valid data.
(7) struct DataProtocol *pDProtc; A pointer to the next data packet. In a priority-based data queue, each data packet is organized in a linked list using this pointer, which facilitates data insertion and deletion.
3.5 Design of Intranet Communication Module and Device Communication Module
The intranet communication module consists of a scheduling submodule and several subnet interface submodules. The former is relatively simple, mainly responsible for the distribution and collection of data packets between the forwarding module and each subnet interface submodule. The latter is more complex, involving various network communication protocols and data formats. It forms a communication system based on the subnet communication protocol with the communication module of the terminal device. Due to space limitations, this article cannot describe it in detail, but will only give a brief introduction using RS232 as an example.
The RS232 standard only defines the physical layer specifications and data link layer hardware interface specifications in the ISO/OSI basic reference model. To achieve distributed RS232 subnet communication, a network layer is needed for address routing of terminal devices. Furthermore, a data frame format needs to be designed at the data link layer software level to encapsulate the transmitted data. In practical implementation, this is reflected in the parsing, conversion, and encapsulation between forwarded data packets and the RS232 data frame format.
For a terminal device to connect to an embedded gateway, it must provide a communication interface in hardware, such as an RS232 interface, RS485 interface, or CAN interface. In software, it must have a communication module, which primarily performs the following tasks: receiving data from the gateway, parsing it, and submitting it to the upper-layer application; receiving data to be sent from the upper-layer application, encapsulating it, and then sending it to the gateway. The application analyzes the received valid data according to the application layer's protocol rules and performs corresponding operations or responses.
4. Conclusion
Based on the analysis of typical embedded gateway design schemes, this paper proposes an embedded gateway with multiple communication interfaces that integrates internal and external network communication. This gateway is suitable for applications that connect 8/16-bit embedded devices to the Internet. The solution allows for the expansion and tailoring of application modules at each interface according to application requirements. In practical applications, it is also necessary to enhance and improve the gateway's security, and further research is needed to incorporate more local communication subnets into the gateway to improve its applicability.
The author's innovation lies in designing an embedded gateway that integrates internal and external network communication and provides multiple communication interfaces for 8/16-bit MCU systems to access the Internet. The implementation of the gateway software module and the format of forwarded data packets are discussed in detail.
References:
[1] Meng Junying, Liu Jiaomin, Wang Zhenzhou. CAN/Ethernet Embedded Gateway Based on ARM Microprocessor [J]. Journal of Hebei University of Technology. August 2005. Vol. 34 Supplement. 115-117.
[2] Zhao Guoan, Gao Hang, Zhang Youcheng. Home intelligent system with W3100A embedded gateway [J]. Microcontroller & Embedded System Applications. 2003, No.4: 51-53.
[3] Wang Xi, Ren Qimei. Research on the implementation method of uC-Linux Web server based on 44B0 platform [J]. Microcomputer Information, 2005, 3-1:76-77
