Design of universal network code framework based on pSoSystem operating system

pSoSystem is a high-performance, modular operating system dedicated to embedded processors. Based on open operating system standards, it provides a complex multitasking environment. At the same time, it also provides a series of integrated development tools, which can be used in Unix systems as well as Windows systems. In addition, because pSoSystem is a modular operating system, developers can choose different operating system modules according to their needs.

Authors: Chen Haihua, Hu Lin, Yang Chenhui

Introduction to pSoSystem Operating System

pSoSystem is a high-performance, modular operating system dedicated to embedded processors. Based on open operating system standards, it provides a complex multitasking environment. At the same time, it also provides a series of integrated development tools, which can be used in Unix systems as well as Windows systems. In addition, because pSoSystem is a modular operating system, developers can choose different operating system modules according to their needs. In this way, it is unnecessary for us to load a huge operating system onto the embedded system equipment. For example, if our application system does not need to support file functions, it is not necessary to load the file system. In this way, the size of the operating system can be greatly reduced. The entire system structure of pSoSystem is shown in Figure 1.

Design of universal network code framework based on pSoSystem operating system
Figure 1 pSOS system block diagram

Overview of pSoSystem network device driver

Design of universal network code framework based on pSoSystem operating system
Figure 2 Network-driven model

Design of General Network Driven Model

The overall design idea of ​​the general network-driven model is to abstract the operation independent of the specific hardware to form a general code framework. Specifically, it mainly includes the following parts:

a) Separation and hierarchical model design of bottom-level driver and upper-level application;
b) The design of the corresponding interface function obtained from the above separation level;
c) Design of abstract code framework for receiving and sending network card data packets;

Below, this article will make a more comprehensive analysis on the design of the above three aspects.

Separation and hierarchical model design of bottom-level driver and upper-level application

Obviously, this piece of design is the first part of the entire drive model design. Only by effectively separating the bottom-level driver and the upper-level application can the independence and reusability of the code be ensured, so that the developer of the driver does not need to care too much about the upper-level application, which conforms to the design philosophy of modern software. Regarding the design of this part, pSoSys2tem has helped us complete it. The network-driven model it provides is a typical software layered design example. See Figure 2 for details.

Interface function design

Generally speaking, the driver layered model designed above will provide some standard interface functions for the communication between the upper and lower layers. Obviously, the realization of these interface functions is mostly related to the underlying hardware, but the operation steps are similar. Therefore, in our general drive model framework, it is necessary to abstract general operations independent of specific hardware to form a general code framework. Here, we generally give the general interface functions in the form of pseudo-C code. accomplish.

(1) Design and analysis of NiLan interface function

NiLan is the most important interface function that connects the pNA+ layer and the network driver. In fact, as early as the pNA+ module loading process, pNA+ installed this function, the corresponding pseudo-C code is as follows:

UCHAR *SetUpNI (UCHAR *FreeMemPtr)
{InstallNi((int
()) Nilan, IPaddr,
BSP-LAN1-MTU, BSP-LAN1-HWALEN, BSP-LAN1-FLAGS, SysVars.Lan1SubnetMask, 0);
/*By calling this function, the NiLan function is installed in the pNA+ module*/
FreeMemPtr=SetupLanParams (BSP-LAN1-PKB, FreeMemPtr);
/*In the pNA+ module, allocate space for the receiving and sending buffers used by the network card*/
}

Code 1

Through this function, the pNA+ layer can complete all related network application calls. The specific method is to pass in different function numbers from the pNA+ layer to achieve the purpose of calling the corresponding specific function functions. The corresponding pseudo-C code is as follows:
longNiLan (ULONGfunction, union nientry*p)
{
if (function= =NI-INIT)
{
return ni-init();
}else
{
/*Call the corresponding function according to the function number*/
switch (function)
caseNI-SEND: call ni-send(); break;
case other function number: call other function function; break;
}
}

Code 2

(2) Design and analysis of ni-init function

This function is mainly used to configure and initialize various hardware and software resources of the network card. The specific functions are as follows:
a) Initialize buffers, mainly to link them into a linked list to facilitate operation;
b) Initialize the registers related to the network card, the most important thing is the first address RxDesc and TxDesc of the transceiver register;
c) Initialize the transceiver register, mainly to chain it into a queue to facilitate the recycling of memory;
staticlongni-init(void)
{
InitBuffers();/*Initialize the buffer, mainly to
Its chain becomes a linked list*/
InstallIsr();/*Install interrupt service program, the most important
Is the interruption of network data reception*/
InitDescps()/*chain the sending and receiving registers into a queue*/
lanInit();/*Initialize each register of the network card*/
}

Code 3

Design and Analysis of Network Card Data Packet Transceiving Code Framework

Designing a general network card driver model. Obviously, the sending and receiving of data packets is the most important operation related to specific hardware. How to remove the correlation of specific hardware and abstract the general receiving and sending code independent of various hardware is very important. Below, will analyze the general steps of the network card receiving and sending process.

(1) The specific steps of the network card data packet sending process are as follows

a) In order to send data, the application calls the corresponding socket;

b) The call of the socket triggers the pNA+ system call, and the pNA+ layer calls the NiLan function to pass the upper layer data to the NI layer; refer to code 2 for the specific implementation of NiLan. Here, we mainly explain the parameters passed in; function: function No., NiLan will call the appropriate NI layer function according to different function numbers; p: The entry point of the NI layer, that is, the place where the upper layer and the lower layer exchange data. When sending data, this entry point will transfer the corresponding data from the pNA+ layer In the NI layer, when receiving data, this entry point also uploads the data received by the NI layer to the pNA+ layer.

c) After the NI layer receives the incoming data from the pNA+ layer, it assembles the data to be sent into a data frame for the next move

The sending register of the incoming network card is sent out, and the corresponding implementation code is as follows:
staticvoidni-send(char*hwa-ptr, char*pkbpt
r, USHORTtype)
{
tx-hdr=InitMblk();/3 Initialize the triplet, and store a data frame in a triplet*/
FillFrameHead();/*Fill the frame header*/
TxFillDesc();/*Call TxFillDesc() to fill the phase
Corresponding register to send data out*/
}

Code 4

(2) The receiving process of the network card data packet

The process of receiving data by the network card is different from the process of sending data. When sending data, there is an independent function of sending data, but in the process of receiving data from the network card, there is no such independent function. The receiving of network card data is through To complete the interrupt service program, the specific steps are as follows:

a) The network card generates an interrupt to receive data;

b) Interruption causes the call of ni-isr() interrupt service routine, and in ni-isr(), the real interrupt response routine is called
ni-poll() and ni-poll() call specific interrupt service routines according to different interrupt events;
static voidni-isr(void)
{
ienter();
AppModel-run-on-sstack ((Pointer) nipoll, Null);
ireturn();
}
static voidni-poll(void)
{
for(;;)
{
if (receive data interrupt) RxBufRcv();
if (transmit data interrupt) TxFillDesc();
if (other interrupts). … ..
}
}

Code 5

c) For the interrupt of receiving data, the interrupt response function called in the ni-poll() function is RxBufRev(). This function is really responsible for receiving data from the network card. Its working principle is to read the corresponding receiving register of the network card. , And notify the pNA+ layer to take the data away;
staticvoidRxBufRcv(void)
{
for(;;)
{
good=CheckFrame()/*Judge whether the received data packet is wrong*/
if (good==TRUE)/*If there is no error in the data packet, then hand it over to the pNA+ layer*/
{
/*Create triples and notify the pNA+ layer*/
msgBlk=NiFuncs.esballoc((void3)&pktAddr-“type, dataLen, 0, &frtn);
Announce(type, msgBlk, dataLen, IfNum);
}
}
}

Code 6

d) After receiving the data from the network card through the RxBufRec() function, it will finally call the Announce() function

Notify the pNA+ module to take the data away. At this point, the receiving process of a data packet is all completed; Note: Announce is a callback function, that is, a function defined in the pNA+ module and called by the NI layer;

Driver installation

In pSOS, the general driver installation is done by modifying InstallDriver in drv-conf.c (a system configuration file in pSoSystem operating system). The network driver is specifically processed in pSoSystem, which is implemented by calling the SetUpNi function in drvconf.c, and SetUpNi will call InstallDriver provided by pSoSystem to finally complete the installation of the network driver. Of course, we need to recompile the kernel of pSoSystem in the end to load our driver module into the pSoSystem system module. The specific implementation can refer to the previous code 1.

Concluding remarks

This article only gives the design and analysis of the most important part of the general network-driven model. As for some other detailed functions, due to space limitations, this article does not elaborate. Interested readers can refer to the references attached at the end of the article. Finally, I hope this article can be helpful to engineers and technicians who are interested in developing similar applications.

The Links:   LTBHBND57SCK BSM400GA120DN2SE3256