UART0 serial port programming (IV): The crisis of UART0 serial port programming in UC/OS-II

1. Potential Crisis

1. When designing serial port programming in uc/os operating system, the situation is complicated because ISR and multiple tasks are executed concurrently. Especially when the receiving state is passive, data can only be received by serial port interrupt.

2. During serial communication, both parties follow the same communication protocol. Since the baud rate remains unchanged, the interval between two consecutive serial port interruptions is basically fixed.

3. The receiving process will be wrong in the following two situations:

(1) The first case is that the maximum time the system turns off interrupts is greater than the interval between two adjacent serial receive interrupts. This may result in missing an interrupt and causing data loss.

(2) The maximum time that the real-time operating system kernel disables interrupts is known and is usually very short, so it is not the key to the problem.

(3) The longest time the system takes to disable interrupts is often caused by user software. For example, the interrupt service function we wrote is too complicated, causing the system to take too long to disable interrupts in order to process the interrupt service function.

(4) The second situation is that when the serial port program is running, an interrupt program with a higher priority interrupts the serial port program, resulting in data loss.

(5) Here is a concept: the period of time when the serial port reception interrupt cannot be responded is called "dead zone". Therefore, the key to solving the problem is that the dead zone time cannot be longer than the interval between two consecutive serial port interrupts.

2. How to resolve the crisis

l Do not disable interrupts (use mutex semaphores instead) when a task accesses a time-consuming shared resource.

l The ISR should be as brief as possible, and any work that can be separated should be delegated to related tasks.

(The design here is similar to the principle of dividing interrupts into the upper and lower parts in Linux)

Use the above method to shorten the dead time.

Another method is:

Increase the interval between two adjacent serial port receive interruptions.

l Method 1: Reduce the baud rate. This method is simple, but it also leads to a decrease in communication efficiency. Secondly, the baud rate is usually fixed when programming the serial port. Therefore, this method is generally not applicable.

l Method 2: Reduce the number of interrupts while keeping the baud rate unchanged, so as to lengthen the interval between two adjacent serial port receive interrupts.

The serial port of the ARM chip has a 16-byte buffer, and can be set to generate an interrupt after receiving 1, 4, 8, or 14 bytes. If it is set to interrupt after receiving 8 bytes, the interrupt interval will be extended by 8 times compared to a 1-byte interrupt.

Tiger-John Description:

After using the serial port programming with data buffer function, it is easier to meet the condition that the interval between two consecutive serial port receive interrupts is greater than the dead time, but there are still potential dangers.

To reliably avoid this crisis: the following conditions must be met

(1) The interval between two consecutive serial port receive interrupts must be greater than the system dead time

(2) The idle time of the receive buffer must be sufficient to store the new data received during the "dead zone" time.

 If the interrupt is set every time 8 bytes are received, the free space is also 8 bytes. Since the dead time is shorter than the interrupt interval, the new data received must be less than 8 bytes to avoid data loss.

That is, under the premise that the interrupt interval is greater than the "dead zone" time, the interrupt condition is set to 1/2 of the receiving buffer, then the dead zone time is close to the interrupt interval time, and the receiving process is reliable.