Critical issues with naked code

sfesdm

Critical issues with naked code [Copy link]

After searching online, I couldn't seem to find any information about the STM32 microcontroller not running the critical code of the system.

The microcontroller I am using now is STM32L010RBT6. There is a need for single-line communication. The entire communication process takes 10~20ms. The communication process cannot be interrupted. If we simply use the switch interrupt __disable_irq(); __enable_irq(); method, there may be problems. How can I achieve critical processing similar to running the system?

huo_hu

Weird communication

freebsder

__disable_irq(); __enable_irq(); is pretty good, and probably the only universal way to handle critical issues.

STM32L010RBT6 does not support other critical processing methods in armv6, and other means are available only in armv8.

Even with advanced methods, you still need to pay for scheduling (after entering the critical section, how do you schedule interrupts and normal execution flow when an interrupt comes), you need to monitor deadlocks, you need to monitor whether the critical section is reentered, etc. It is not simpler than the previous system.

In other words, it is enough to use __disable_irq(); __enable_irq(); for naked running, otherwise use rtos.

In addition, the entire communication process takes 10~20ms, and the communication process cannot be interrupted. This kind of communication system itself may be designed with problems. It cannot be interrupted because your communication is too fast, almost as fast as the speed of the microcontroller to retrieve data. In this case, data will be lost if the communication is interrupted. If the communication is much slower than the speed at which the microcontroller processes data, then the microcontroller can be interrupted and run out as soon as possible. So either change the communication rate or change a higher microcontroller.

sfesdm

freebsder posted on 2020-3-10 21:50 __disable_irq(); __enable_irq(); Very good, perhaps the only universal way to deal with critical issues...

There is a chip that uses a single line to send and receive data, and has very strict requirements on timing. If it is interrupted during the communication process, it is equivalent to lengthening the timing, causing the communication rate to be inconsistent with the original, and then communication errors.

If you use the __disable_irq(); __enable_irq(); method, during the timing operation, if there are multiple functions that perform the switch interrupt operation, for example

fun1()

{

__disable_irq();

......

__enable_irq();

}

fun2()

{

__disable_irq();

......

fun1();

......

__enable_irq();

}

In this case, it is possible that fun1 will reopen the general interrupt too early, which may cause communication errors. Of course, you can say that fun1 and fun2 can be combined into one function, so there is no problem... But generally speaking, there is a critical processing method that can meet more application needs.

freebsder

Timing is timing, interrupt is interrupt. It can be said that all communication physical layers or protocol request layers above have timing requirements, it's just a matter of length.
You seem to need to consider the timing duration and whether the microcontroller (or other) processing performance can keep up. Consider an extreme case, the sender sends byte data at a frequency of 50MHz to the receiver, and the receiver's processing frequency is also 50MHz. At this time, the receiver can't do anything except taking data out of the fifo. What do you want the microcontroller to do at this time? Change the scene, the sender is still 50MHz, and the receiver is now a 3G CPU. Your speed is only 1/60 of it. The CPU can do a lot of things besides your protocol.
Any physical layer communication cannot be transient, it cannot be without duration, it cannot be infinite frequency, and the frequency always has its reciprocal. Even the most hard real-time system has a response time indicator. If you are
sure that your system meets the hard real-time requirements, when the microcontroller has little surplus (more than 10 times), there is generally only one way to deal with it, which is to turn off the interrupt deadlock polling.
Resources determine your means. If you don’t have enough resources, don’t think too much.