The full name of UDP protocol is User Packet Protocol, which, like TCP protocol, is used to process packets in networks. In the OSI model, in the fourth layer – the transport layer, it is on top of the IP protocol. UDP has the disadvantage of not providing packet grouping, assembly, and not being able to sort packets, which means that after a message is sent, it cannot be determined whether it has arrived safely and completely. UDP is used to support network applications that require data transfer between computers. Many client/server mode network applications, including online video conferencing systems, require the use of UDP protocol. The UDP protocol has been in use for many years since its inception. Although its initial glory has been overshadowed by some similar protocols, even today, UDP is still a very practical and feasible network transport layer protocol.

Due to the limited software and hardware resources of embedded systems, most of the TCP/IP protocol stacks running in REX521BBHGLB01C embedded systems have been tailored according to the characteristics of the embedded system. Currently, the widely used embedded TCP/IP protocol stacks include ucTCP IP, LWIP, uIP, Linux TCP/IP, etc. UIP is a micro TCP/IP protocol stack designed specifically for embedded microcontrollers with 8 and 16 bits, which requires very little memory during runtime and implements commonly used TCP/IP protocols; The code comments are detailed and can be used for commercial or non-commercial purposes. Due to the above characteristics, uIP is widely used in the network interconnection of embedded systems.

The architecture of the uIP protocol stack

The uIP protocol stack has removed uncommon features from the complete TCP/IP protocol. REX521BBHGLB01C simplifies the communication process, but preserves the protocols that must be used for network communication. The design focus is on IP/TCP/ICMP/UDP/ARP network layer and transport layer protocols, ensuring the universality of its code and the stability of its structure.

Due to the fact that the uIP protocol stack is specifically designed for embedded systems, it also has the following superior features:

(1) The code is very limited, and its protocol stack code is less than 6K, making it easy to read and port.

(2) The amount of memory occupied is very small, with only a few hundred bytes of RAM.

(3) The hardware processing layer, protocol stack layer, and application layer share a global cache area, without data copying, and both sending and receiving rely on this cache area, greatly saving space and time.

(4) Supports concurrent active and passive connections.

(5) The source code provides a set of instance programs: web server, web client, email sender (SMTP client), Telnet server, DNS host name resolution program, etc. It has strong universality and can be ported without modification.

(6) The processing of data adopts a round robin mechanism, without the support of manipulating the system.

Due to the low resource requirements and easy portability of uIP, most 8-bit microcontrollers have used the uIP protocol stack, and many well-known embedded products and projects (such as satellites, Cisco routers, wireless sensor networks) are using the uIP protocol stack.

In the software architecture of embedded systems using uIP, the uIP protocol stack acts as a code library that communicates with underlying hardware and upper level applications through a series of functions. The relationship between the uIP protocol stack and the underlying and upper layer applications of the system is shown in Figure 1.

 

From Figure 1, it can be seen that the uIP protocol stack mainly provides two functions, uip_input() and uip_periodic(), for the system’s underlying calling. The main interfaces between the uIP protocol stack and application programs are UIP_APPCALL() and UIP_UDP APPCALL().

When initializing uIP, the uip_init() function is called, whose main function is to initialize the listening port of the protocol stack and set all connections to the closed state. Then the main control part of uIP calls the uiP_input() function, which will process the packet based on the protocol identifier of the packet header and call the upper layer application when needed. When uip_input() returns, an output packet is placed in the same global buffer uip_buf, and its size is assigned to uip_len. If uiP_len is 0, it indicates that there are no packets to be sent. Otherwise, the main control part calls the underlying system’s sending function to send the packet to the network [3].

UIP cycle timing is used to drive all uIP internal clock events. After the cycle 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 should be placed in the uip’buf for the underlying system to query the size of the uip_len to determine whether to send it.

Due to the many applications using TCP/IP, the application program is implemented as a separate module by the user. Users need to provide the processing function for network packets as an interface to uIP, and define this function as the macro UIP_APPCALL() or UIP_UDP_APPCALL(). UIP_APPCall() is the user’s processing of TCP packets, while UIP_UDP_APPCall() is the user’s processing of UDP packets [4]. In this way, after receiving data packets from the bottom layer, uIP can directly call UIP_APPCall() or UIP_UDP_APPCall() at the location where it needs to be sent to the upper layer application for processing, without the need to modify uIP.