MUX interface of VxWorks network protocol stack

Abstract:The flexibility of the network protocol stack of embedded systems is an important indicator in applications. This article introduces the MUX (mutiplexer) interface of the VxWorks network protocol stack of the embedded operating system and its usage.

Keywords:VxWorks network protocol stack MUX

VxWorks is a high-performance and cutting-down embedded real-time operating system launched by Wind River System (Wind River) in the United States. It is widely used in fields with high real-time requirements, such as communications, military affairs, aviation, and aerospace, with its excellent reliability and excellent real-time performance, such as satellite communication, military drills, ballistic guidance, and aircraft navigation. The VxWorks operating system includes process management, storage management, backup management, file system management, network protocols, and system applications. VxWorks only occupies a small amount of storage space and can be greatly reduced to ensure high system efficiency. It can be combined according to user requirements. Its open structure supports industrial standards so that developers only need to do the least work to design effective and suitable for different user requirements.

1. network protocol stack and MUX interface of VxWorks

The network protocol stack in VxWorks is called the Scalable enhanced network stack. SENS is developed based on the 4.4bsd TCP/IP protocol stack, including many protocols not available in the 4.4bsd TCP/IP protocol stack. In addition, sens adds many new features when implementing some protocol functions, for example, the multicast function is added when the IP protocol is implemented. SENS protocol stack level 1 is shown.

 

The basic features of sens are similar to those of the traditional TCP/IP network protocol stack. However, as shown in figure 1, the biggest feature of sens is that the MUX layer is added between the data link layer and the network protocol layer. In Sens, the network interface driver is called end (enhanced network driver), which is in the data link layer. The IP layer and the TCP/UDP layer are collectively referred to as the network protocol layer. There is an application interface (API) between the data link layer and the network protocol layer. This interface is called the MUX (Multiplexer) interface in sens. MUX interface 2.

 

On the network protocol layer, VxWorks typically uses the TCP/IP protocol (other protocols are also supported); on the data link layer, it typically uses Ethernet and also supports physical media for other data transmission, for example, the serial line access method used for long-distance connection, such as PPP. However, no matter what physical media is used, the network interface driver must use MUX to communicate with the network protocol layer (the data link layer is an abstract concept, the network interface driver is the code for implementing the functions described by this abstract concept ).

In 4.3bsd, the network interface drivers and protocols of VxWorks are closely integrated. they communicate with each other by transmitting specific data structures. On the basis of MUX, they only interact with each other through MUX. For example, after receiving a packet, the network interface driver is not directly connected to the protocol layer. Similarly, when the network interface driver is ready to send data to the protocol layer, the driver calls a function provided by MUX ). This function is responsible for transmitting data to the action details of the protocol layer. The main purpose of MUX is to separate the network interface driver from the protocol layer, so that the network interface driver and the protocol layer are basically independent of each other. This independence enables loading of a new protocol or network interface driver. All existing MUX-based protocols can use this new network interface driver. Similarly, to add a new MUX-based protocol, the existing network interface driver can also use MUX to communicate with the new protocol.

2. MUX interface workflow analysis

The MUX layer, as an independent network layer, has its own function functions. However, these function functions are only interfaces for communication between the upper and lower layers. The call relationship between the network protocol layer and the network driver and the MUX interface is shown in 3.

 

The Network Protocol provides the following interface functions:

① Stackshutdownrtn ()

② Stackerror ()

③ Stackrcvrtn ()

④ Stacktxrestartrtn ()

When the MUX interface layer needs to communicate with the protocol layer, the above functions are called. To enable the network protocol layer to use MUX, you must implement at least four functions.

MUX implements muxbind (), muxunbind (), muxdevload (), and so on. Both the network protocol layer and the Network Driver Interface must use the MUX access point as needed. Since MUX is provided by the system, you do not need to perform additional coding during the application; you only need to enter the correct parameters when using it.

For example, in VxWorks, muxdevload is defined as follows:

End_obj * muxdevload

(

Int unit,

End_obj * (* endload) (char *, void *),

Char * pinitstring,

Bool loaning,

Void * pbsp

)

Other functions are defined in the muxlib. h file.

The network interface driver must complete functions such as endload (), endunload (), and endsend. MUX uses these functions to communicate with network drivers. When writing or loading a network driver Using MUX, you must implement all the end functions in figure 3. These functions are all for specific network interfaces, that is, each network driver must have these functions.

3. MUX applications

3.1 how the system starts and uses the network interface driver-end through MUX

When the system starts, the following functions must be performed through tasks (similar to the process concept, which is an execution unit in the embedded operating system:

① Load from memory and start end;

② Registration is used to handle end interruptions;

③ Use end to process the package.

When the system starts, VxWorks generates a tusrroot task to perform the following functions: first initialize the work queue of the network task, and then generate a tnettask to process the tasks in the work queue of the network task.

The tnettask calls muxdevload () to load the network interface driver. In tnettask, The endload () Access Point of the Network Driver device has been defined, and muxdevload () also executes endload (). Endload () executes device initialization and returns a structure named end_obj. By adding a pointer to end_obj, MUX points to the function that can send data to the upper layer of MUX ). Then MUX adds the returned end_obj to the end_obj Structure linked list. This chain table includes all available network devices in the current system. After returning from muxdevload (), the network device is ready for use.

We must call sysintconnect () to register the interrupt handling of network interface devices. The most typical call to sysintconnect () is in the endstart () of the network interface device. When a network interface device is loaded using muxdevload (), muxdevstart () is called to start the device, and muxdevstart () calls endstar () to register the interrupt processing.

After the system is started, you must use the device through interruption. When a network device is interrupted, VxWorks activates the interrupt service registered by the device driver. The service interruption workload should be minimal. You only need to get the package from the local hardware. To minimize the suspension lock time, the interrupt service should only process tasks that require the minimum execution time, such as errors and status changes. In order to process all the time-consuming work at the task level, the interrupted service should be queued. For example, netjobadd () must be called to queue jobs accepted by the processing package at the task level (). At the time of input, this example routine receives a pointer to a function and waits until it receives five additional parameters (the pointer refers to the function parameter ).

Status netjobadd

(

Funcptr routine,

Int param1,

Int param2,

Int param3,

Int param4,

Int param5,

)

If netjobadd () is called, the network driver must define the access point for processing packets at the task level. The netjobadd routine puts function calls (including their parameters) into the task queue of tnettask. VxWorks uses tnettask to Process Task-level network processing.

Here is an example to illustrate the situation of receiving packets. In other cases, netjobadd () can also execute the corresponding column entry function.

3.2 MUX-based network protocol layer and network interface driver

MUX-based features: provides an interface to write programs at different layers connected to it. It can be said that both the network protocol layer and the network interface driver can regard MUX as an application procedure interface (API ). Adding a network interface device driver to the VxWorks target system is as simple as writing an application. The procedure is as follows:

① Compile the source code of the driver and load it in the VxWorks image;

② Edit target/src/config/bsp/confignet. h;

③ Edit the cfonfig. h file of BSP.

Note: If you do not re-compile the new boot Roms (boot ROM), you cannot use the new end. This means that only one target system without end can be started. Therefore, you must edit the configuration file to use the new end.

Figure 3 shows that the MUX-based network protocol is bound up with MUX, while the network interface driver is bound down with MUX. The main function of the protocol layer is to provide interfaces for the transport layer and applications. The protocol layer code is also programmed through the interface provided by the MUX interface, which is very similar to that of general-purpose computers and will not be discussed here.