An Implementation of uIP TCP/IP Protocol Stack on 51 Series MCU

1. Introduction

With the continuous development of information technology and the improvement of people's requirements for comfort and convenience in daily life, information appliances, smart meters and other products appear more and more frequently in our lives; people are also more and more keen to connect home appliances, meters and other equipment to the Internet, so that they can be remotely viewed and controlled conveniently and timely. To connect these devices to the Internet, it is necessary to consider the implementation of TCP/IP network protocol.

51 single-chip microcomputer is a general term for all single-chip microcomputers compatible with Intel 8031 ​​instruction system. The ancestor of this series of single-chip microcomputers is Intel's 8031 ​​single-chip microcomputer. Later, with the development of Flash rom technology, 8031 ​​single-chip microcomputers have made great progress and become one of the most widely used 8-bit single-chip microcomputers. Its representative model is ATMEL's AT89 series, which is widely used in industrial measurement and control systems. At present, many companies have launched 51 series compatible models, which will occupy a large market at present and for a long time to come. 51 single-chip microcomputer is a basic entry-level single-chip microcomputer and the most widely used one. It should be noted that 52 series single-chip microcomputers generally do not have self-programming capabilities. This article will briefly describe the implementation method of uIP, analyze the application interface of the uIP protocol stack, and discuss how to apply it to 51 series single-chip microcomputers.

2. Brief description of the implementation method of uIP protocol stack

The uIP protocol stack mainly provides three functions for the system bottom layer to call. They are uip_init(), uip_input() and uip_periodic(). Its main interface with the application is UIP_APPCALL(). ip_init() is called when the system is initialized. It mainly initializes the listening port of the protocol stack and defaults all connections to be closed. When the network card driver receives an input packet, it will be placed in the global buffer uip_buf. The size of the packet is constrained by the global variable uip_len. At the same time, the uip_input() function will be called. This function will process the packet according to the protocol in the packet header and call the application when necessary. When uip_input() returns, an output packet is also placed in the global buffer uip_buf, and the size is assigned to uip_len. If uip_len is 0, it means that there is no packet to be sent. Otherwise, the packet sending function of the underlying system is called to send the packet to the network. The uIP periodic timing is used to drive all uIP internal clock events. When the periodic timing is triggered, each TCP connection will call the uIP function uip_periodic(). Similar to the uip_input() function. When the uip_periodic() function returns, the output IP packet is placed in uip_buf for the underlying system to query the size of uip_len and send.

uIP implements the four basic protocols of the TCP/IP protocol suite: ARP address resolution protocol, IP Internet protocol, ICMP network control message protocol and TCP transmission control protocol. In order to be applied on 8-bit and 16-bit processors, the uIP protocol stack adopts a targeted approach when implementing each layer of the protocol to keep the code size and memory usage to a minimum.

1 In order to save memory when implementing the ARP address resolution protocol, the ARP reply packet directly overwrites the ARP request packet.

2 The original IP network protocol was greatly simplified when it was implemented, and it did not implement fragmentation and reassembly.

3 When implementing the ICMP network control message protocol, only the echo service is implemented. uIP does not reallocate memory space when generating an echo message, but directly modifies the echo request message to generate the echo message. Change the ICMP type field from "echo" to "echo reply", recalculate the checksum and modify the checksum field.

4 TCP in uIP does not implement a sliding window for sending and receiving data. The state of each TCP connection is saved by the uip_conn structure, which includes information such as the local and remote TCP port numbers, the IP address of the remote host, the retransmission time value, the number of the last retransmission, and the maximum size of the connected segment. An array of uip_conn structures is used to save all connections, and the size of the array is the maximum number of simultaneous connections supported. In order to reduce the use of storage, uIP does not cache the sent data packets when processing retransmissions, but the application regenerates the sent data when retransmission is required.

Three uIP protocol stack interfaces

In order to achieve maximum versatility, the uIP protocol stack "packages" all protocol sets other than the underlying hardware driver and the top application layer into a "library" during implementation. The protocol stack "communicates" with the underlying hardware and top application through interfaces. In this way, uIP has extremely high versatility and independence, and is very convenient to port to different systems and implement different applications, which well reflects the platform-independent characteristics of the TCP/IP protocol. The interface relationship between the uIP protocol stack and the underlying system and application is shown in Figure (I):

1 uIP protocol stack and the underlying system interface

The interface between uIP and the underlying system includes two types: the interface with the device driver and the interface with the system timer.

1.1 uIP and device driver interface

uIP implements the interface with the device driver through the function uip_input() and the global variables uip_buf and uip_len. uip_buf is used to store the received and sent data packets. In order to reduce the use of memory, the same buffer is used for receiving and sending data packets. uip_len indicates the length of the data in the receive and send buffer. By judging whether the value of uip_len is 0, it is judged whether new data has been received and whether there is data to be sent. When the device driver receives an IP packet and puts it in the input packet buffer (uip_buf), it should call the uip_input() function. The uip_input() function is the bottom-level entry of the uIP protocol stack, which processes the received IP packets. When uip_input() returns, if there is data to be sent, the send data packet is placed in the packet buffer. The size of the packet is indicated by the global variable uip_len. If uip_len is 0, there is no packet to be sent; if uip_len is greater than 0, the network device driver is called to send the data packet.

1.2 uIP and system timing interface

The TCP/IP protocol has to handle many timing events, such as packet retransmission and ARP table entry updates. The system timing is used to time all uIP internal clock events. When the periodic timing is triggered, each TCP connection should call the uIP function uip_periodic(). The TCP connection number is passed as a parameter to the uip_periodic() function. The uip_periodic() function checks the status of the connection specified by the parameter. If retransmission is required, the retransmitted data is placed in the packet buffer (uip_buf) and the value of uip_len is modified. When the uip_periodic() function returns, the value of uip_len should be checked. If it is not 0, the data packet in the uip_buf buffer is sent to the network.

The ARP protocol is necessary for TCP/IP protocol built on Ethernet, but it is not necessary for TCP/IP built on other network interfaces (such as serial links). For structural purposes, uIP implements the ARP protocol as an add-on module. Therefore, the timed update of ARP table entries is handled separately. The system timer times the update of the ARP table, and when the timer expires, the uip_arp_timer() function is called to clear the expired table entries.

2 uIP protocol stack and application interface

The application is implemented by the user as a separate module, and the uIP protocol stack provides a series of interface functions for the user program to call. The user needs to provide the application layer entry program as an interface to the uIP protocol stack, which is defined as the macro UIP_APPCALL(). After receiving the data packet from the bottom layer, if uIP needs to send it to the upper layer application for processing, it calls UIP_APPCALL(). The interface functions provided by uIP to the application are described as follows:

2.1 Data receiving interface: The application uses the uip_newdata() function to detect whether new data has arrived. The global variable uip_appdata points to the actual data. The size of the data is obtained through the uip_datalen() function.

2.2 Send data interface: The application sends data by using the uIP function uip_send(). The uip_send() function takes two parameters; a pointer to the starting address of the data to be sent and the other to indicate the length of the data.

2.3 Resend data interface: The application determines whether data needs to be resent by testing the function uip_rexmit(). If resending is required, the uip_send() function is called to resend the data packet.

2.4 Close the connection interface: The application closes the current connection by calling the uip_close() function.

2.5 Reporting error interface: uIP provides error reporting functions to detect errors that occur in the connection. Applications can use two test functions uip_aborted() and uip_timedout() to test those error conditions.

2.6 Polling interface: When the connection is idle, uIP will periodically poll the application to determine whether there is data to send. The application uses the test function uip_poll() to check whether it has been polled.

2.7 Listening port interface: uIP maintains a list of listening well-known TCP ports. Through the uip_listen() function, a new listening port is opened and added to the listening list. When a new connection request is received on a listening port, uIP generates a new connection and calls the application corresponding to the port.

2.8 Open the connection interface: Open a new connection in uIP by using the uip_connect() function. This function opens a new connection to the specified IP address and port and returns a pointer to the new connection to the uip_conn structure. If there is no free connection slot, the function returns a null value.

2.9 Data flow control interface: uIP provides functions uip_stop() and uip_restart() for data flow control of TCP connections. The application can stop the remote host from sending data through the function uip_stop(). When the application is ready to receive more data, call the function uip_restart() to notify the remote terminal to send data again. The function uip_stopped() can be used to check whether the current connection is stopped.

Application of Four uIPs in 51 Series Single Chip Microcomputers

The 51 series of single-chip microcomputers have a long history and wide application. Many companies have launched 8-bit single-chip microcomputers with 51 cores with higher processing speeds, which are used in various fields. Therefore, it is representative to use uIP, a free TCP/IP protocol stack, to solve the network access problem of low-end embedded devices built with 51 core single-chip microcomputers. The following will discuss the use of uIP protocol stack to implement a simple WEB SERVER on 51 single-chip microcomputers. Remote users can access the WEB pages stored on the single-chip microcomputer system through a browser.

The hardware platform structure is shown in Figure 2: The single-chip microcomputer uses PHILIPS's P89C51RD2, and the 64K-byte serial EEPROM can be used to store WEB pages. The Ethernet interface chip RTL8019AS with ISA interface is connected to the Ethernet. The serial connection with the PC is realized through MAX232, and the debugging information can be displayed.

The uIP protocol stack is provided in the form of a function library, and does not provide underlying network drivers and upper-layer applications. Therefore, in order to complete the specified functions, developers must add the following modules: the driver of the underlying RTL8019AS network card chip, the implementation of the HTTP-based WEB SERVER at the application layer, and the system timer.

The driver of RTL8019AS mainly consists of three parts: the init_8019as() function completes the power-on initialization of the network card chip, including setting the physical address of the network card, setting the location and size of the transceiver buffer, etc.; the eth_send() function completes the data transmission; the eth_rcve() function completes the Ethernet data reception. The underlying network device driver and the uIP protocol stack interface through two global variables: the variable uip_buf is the first address of the transceiver buffer; uip_len is the length of the transceiver data. The eth_send() function sends the uip_len length of data in uip_buf to the Ethernet. The eth_rcve() function stores the received data in the buffer specified by uip_buf and modifies the value of uip_len.

The source code provided by uIP includes a WEB SERVER example based on HTTP protocol. This WEB SERVER stores static pages in the data storage through a simple file system and has CGI function. Users can refer to this example and the interface function description provided by uIP to the application to implement their own application layer functions. In the user's application, the UIP_APPCALL macro must be defined as the service program of this layer. For example: in the example program, the WEB SERVER handler is the httpd() function, so the following macro definition should be performed: #define UIP_APPCALL httpd.

The 51 series microcontrollers have 2 to 3 timer counters, and one of them can be selected to time the time-related events in the TCP/IP protocol. The timer events that need to be handled by the user include: providing a benchmark for the execution of the uip_periodic() function and timing the update of the ARP table entry. The uip_periodic() function is executed every 0.5 seconds, and the ARP table entry is updated every 10 seconds.

The settings of uIP are contained in a header file called uipopt.h, which is defined in the form of macros for easy modification. Users should set the local physical address, IP address, gateway address, send and receive buffer size, maximum number of connections supported, ARP table size and other options in the uipopt.h file according to their own applications.

After adding the necessary modules and configuring uIP correctly, you need to write the main program function. For Ethernet-based WEB SERVER applications, the main program will keep querying after completing the initialization. If a new data packet arrives, it will be sent to the uip_input() function for processing; if no new data packet arrives, the timer event will be processed. The framework code is as follows:

The main control loop of the uIP protocol stack is illustrated through actual code.

void main(void)

{

/*Omit some code*/

/*Set TCP timeout processing time and ARP aging time*/

timer_set(&periodic_timer, CLOCK_CONF_SECOND / 2);

timer_set(&arp_timer, CLOCK_CONF_SECOND * 10);

/*Timer initialization*/

init_Timer();

/* Protocol stack initialization */

uip_init();

uip_arp_init();

/*Application layer initialization*/

example1_init();

/*Driver layer initialization*/

etherdev_init();

/*IP address, gateway, mask settings*/

uip_ipaddr(ipaddr, 192,168,1,9);

uip_sethostaddr(ipaddr);

uip_ipaddr(ipaddr, 192,168,1,16);

uip_setdraddr(ipaddr);

uip_ipaddr(ipaddr, 255,255,255,0);

uip_setnetmask(ipaddr);

/* Main loop */

while(1)

{

/*Read data from the network card*/

uip_len = etherdev_read();

/*If data exists, process it according to the protocol*/

if (uip_len > 0)

{

/* Received IP data, call uip_input() to process */

if (BUF->type == htons (UIP_ETHTYPE_IP))

{

uip_arp_ipin();

uip_input();

/*After processing is completed, if there is data in uip_buf, call etherdev_send to send it out*/

if (uip_len > 0)

{

uip_arp_out();

etherdev_send();

}

}

/*Received ARP data, call uip_arp_arpin() to process*/

else if (BUF->type == htons (UIP_ETHTYPE_ARP)) {

uip_arp_arpin();

if (uip_len > 0)

{

etherdev_send();

}

}

}

/* Check if 0.5S has expired, if so, call uip_periodic to handle TCP timeout procedure*/

else if(timer_expired(&periodic_timer))

{

timer_reset(&periodic_timer);

for(i = 0; i < UIP_CONNS; i++)

{

uip_periodic(i);

if (uip_len > 0)

{

uip_arp_out();

etherdev_send();

}

}

/* Check if 10 seconds have passed, if so, call the ARP handler*/

if(timer_expired(&arp_timer))

{

timer_reset(&arp_timer);

uip_arp_timer();

}

}

}

return;

}

The above examples are compiled in Keil C51 compiler with large mode and optimization level 6 (speed priority). No modification is required for the uIP code part, and only a few modifications are required for the type expression of the HTTP sample code to compile. It runs well on the hardware platform.

5. Conclusion

The uIP protocol stack uses effective methods and structured codes, which makes its memory usage very small and can be easily applied to different engineering projects. At the same time, it is free and can be used freely for commercial and non-commercial purposes. uIP provides a good solution for network access of low-end embedded devices and has high application value.