Design of UCOS-II embedded serial communication module

In embedded applications, the main reason for using RTOs is to improve the reliability of the system, and secondly, to improve the development efficiency and shorten the development cycle. Ucos-ii is a preemptive real-time multitasking kernel that uses embedded systems to properly cut the source code and easily be ported to microprocessors with different 8~32-bit frames. But Ucos-ii is just a real-time kernel that does not provide some API function interfaces to users like other real-time operating systems such as embedded Linux. In the UCOS-II real-time kernel, the access interface of peripherals is not unified, there is a lot of work needs the user to complete. Serial communication is an important part of SCM measurement and control system, asynchronous serial port is a relatively simple and representative interrupt driving peripheral. Taking the serial port of MCU as an example, this paper introduces the general idea of writing interrupt service program and peripheral driver program under UCOS-II.

1 ucos-ii interrupt processing and 51 series single chip microcomputer interrupt system analysis
UCOS-II Interrupt Service Program (ISR) is generally written in assembly language. The following are the steps for interrupting a service program.

1. Save all CPU registers, call Osintenter () or osintnesting (global variable) directly plus 1;
2. Execute user code to do interrupt service;
3. Call Osintexit ();
4. Recover all CPU registers;
5. Executes an interrupt return instruction.

The UCOS-II provides two ISR and kernel interface functions, Osintenter () and Osintexit (). Osintenter () Notifies the UCOS-II kernel that the interrupt service program has started. In fact, the work of this function is to add a global variable osintnesting 1, this interrupt nesting counter can ensure that all interrupt processing is completed before the task scheduling. Another interface function Osintexit () notifies the kernel that the interrupt service has ended. Depending on the situation, the breakpoint is returned (either a task or a nested interrupt service program) or the kernel is scheduled for a task.
The user-written ISR must be installed in a location so that when the interrupt occurs, the CPU runs an accurate service program based on the corresponding interrupt number. Many real-time operating systems provide API interface functions for installing and uninstalling interrupt service programs, but the UCOS-II kernel does not provide similar interface functions, which require the user to implement themselves in a migration to the CPU. These interface functions are related to the specific hardware environment, which is explained in detail in the following 51 MCU interrupt processing.
51 MCU interrupt basic process is as follows: The CPU at each machine cycle S5P2 time sampling interrupt flag, and the next instruction cycle will be the sampling interrupt query. If there is an interrupt request, it is processed according to the principle of priority. When the response is interrupted, the corresponding priority activates the trigger at the corresponding bit, blocks the sibling or low-level interrupt, and then, under the hardware control, presses the interrupt address into the stack according to the interrupt source category and shifts to the corresponding interrupt vector entry unit. Typically, a jump instruction is placed at the entry unit to the execution of the interrupt service program. When the interrupt return instruction Reti is executed, the priority of the position when the response is interrupted is activated after the trigger is cleared 0, the protected breakpoint address is popped from the stack, and the loader counter PC,CPU returns to the original interrupted place to continue executing the program.
During the porting process, Keil C51 is used as the compilation environment. Keil C5L integrates C-compile and assembler. The interrupt subroutine is written in assembly language and placed in the Os_cpu_a.asm assembly file after the transplant ucos-ii. The following is a porting interrupt service subroutine code that takes a serial port break as an example.

csegat0023h; Serial port Interrupt Response entry Address
LJMPSERIALISR; transfer to serial port interrupt subroutine entry address
Rseg? PR? SERIALLSR? Os_cpu_a
SERIALISR:
Usingo
CLR EA; First off interrupt to prevent nesting
Pushall; a defined stack macro that is used to
; The value of the CPU register is pressed into the stack
Lcall_? Osintenter; monitoring interrupt nesting
Lcall_? Serial; Serial Interrupt Service Program
Lcall_? Osintexlt
Setbea
Popall; a defined out-of-stack macro that stacks the value of the CPU register
RETI

2 serial Port driver
The author has successfully transplanted the UCOS-II kernel on the 5l single-chip microcomputer, and the porting process is not discussed here. Here the key analysis Uc0s-ii kernel under the serial driver programming.
A buffer is required because the serial device has problems with peripheral processing speed and CPU speed mismatch. Send data to the serial port, as long as the data written into the buffer, and then by the serial port removed outward. When receiving data from the serial port, it is often necessary for the CPU to be processed after receiving several bytes, so these pre-received data can be stored in the buffer. In fact, the single-chip microcomputer's asynchronous string port only has two mutually independent, the address same receive, the transmit buffer register SBUF. In real-world applications, you need to open two buffers from memory, the receive buffer and the send buffer, respectively. This defines the buffer as the data structure of the ring queue.
The UCOS-II core provides the signal volume as the mechanism of communication and synchronization, and introduces the data receiving semaphore and the data sending signal to synchronize the operation on both sides of the buffer respectively. The operating mode of the serial port is as follows: The user task wants to write, but when the buffer is full, sleep on the semaphore, let the CPU run another task, wait for the ISR to wake up the task after reading the data from the buffer; Similarly, the user task wants to read, but the buffer space, can also sleep on the semaphore, waiting for the external device Due to the UCOS-II signal volume provides a timeout waiting mechanism, the serial port of course also has a time-out reading and writing ability.
Figure 1 is a serial reception with buffers and semaphores. The data receive semaphore is initialized to 0, indicating that there is no data in the ring buffer.

After the receive interrupt arrives, the ISR reads the received bytes (②) from the receiving buffer sbuf of the UART, puts it into the receive buffer (③), and then wakes the read operation (④, ①) of the user's task side by receiving the semaphore. Throughout the process, you can query the value of the variable for the current number of bytes in the record buffer, which indicates whether the receive buffer is full. The UART receives the data and triggers a receive interrupt, but if the buffer is full at this time, the received character is discarded. Buffer size should be set reasonably, reduce the possibility of data loss, but also avoid the waste of storage space.

Figure 2 is a serial port with a ring buffer and a timeout semaphore. The send semaphore initial value is set to the size of the send buffer, which indicates that the buffer is empty and the send interrupt is turned off. When the data is sent, the user task waits on the semaphore (①). If the send buffer is not full, the user task writes data to the send buffer (②). If the first byte in the send buffer is written, send interrupts (②) are allowed. The sending ISR then extracts the first written byte output from the send buffer to the UART (④), which in turn triggers the next send interrupt, so it loops until the last byte in the send buffer is taken away and the send interrupt is closed again. At the same time as the ISR outputs to the UART, the signal is signaled (⑤), and the task is sent to see if there is space in the send buffer based on the semaphore value.

Design of 3 serial communication module
Each serial port has two ring queue buffers and two semaphores: one to indicate the receive byte and the other to indicate the sending byte. Each ring buffer has the following four elements:

• store data (int8u array);
• The counter containing the number of bytes in the ring buffer;
• A pointer to the next byte being fetched in the ring buffer.

Figure 3 is a flowchart for receiving data software modules. Serialgetehar () is used to get the received data, if the buffer is empty when the task is suspended, when a byte is received, the task is awakened, and bytes are received from the serial port. Serialputrxchar () is used to put the received bytes into the buffer, and if the receive buffer is full, the byte is discarded. When a byte is inserted into the buffer, the Serialputrxchar () notifies the data to receive the semaphore so that it communicates the message to all waiting tasks. To prevent suspending an application task, you can find out if there are bytes in the ring queue by calling Sceiallsempty ().

Figure 4 is a flowchart for sending a data module. When data needs to be sent to the serial port, the Serialpurchar () Wait semaphore should initially be the buffer size when initializing the sending semaphore. Therefore, when there is no more space in the buffer, Serialputchar () suspends the task, and as long as the UART sends the bytes again, the pending task resumes. Serialgctchar () is called by the Interrupt service program, and if the send buffer has at least one byte, Seri-a1getchar () returns a byte sent from the buffer. If the buffer is empty, Serialgetchar () returns NULL, which causes the call to stop further send interrupts until the data is sent.

4 interface functions for asynchronous serial communication
Application tasks can be controlled and accessed by several functions such as Uart:serialcfgport (), Serialgetchar (), Serialinit (), Serialisempty (), Serialisfull () and Serialputchar ().
Serialcfgport () is used to establish the characteristics of a serial port, which must be called before other services are invoked for the specified port, including determining the baud rate, number of bits, parity and stop bits, and so on.
Serialgetchar () causes the application to fetch data from the ring buffer that receives the data.
Serialinit () is used to initialize the entire serial port software module and must be called before any other services provided by the module. Seriallinit () Zeros the number of bytes in the ring buffer counter and initializes the in and out pointers for each ring buffer, pointing to the beginning of the data store. The data receive semaphore is initialized to 0, indicating no data in the ring buffer. Initializes the data transfer semaphore with the transmit buffer size, indicating that the buffer is empty.
Serialisempty () allows the application to determine whether a byte is received from the serial port. This function allows you to avoid suspending tasks when you have no data.
Serialisfull () allows the application to determine the state of the transmit ring buffer, and this function avoids suspending the task when the buffer is full.
Serialputchar () allows an application to send data to a serial port.

Conclusion
The serial communication module takes full advantage of real-time kernel task scheduling function and semaphore mechanism, the system software modularization, readability enhancement, easy to modify and transplant, its design ideas and methods can be very good application in a variety of situations in the measurement and control system, the expansion of the system is convenient, has a certain reference role. The serial communication module has been used as a part of the remote control terminal of a railway water supply, which is running stably and improving the operation efficiency and real-time of the whole system.

Design of UCOS-II embedded serial communication module