Your own application code spinning cannot directly be stopping interrupts triggering - whatever you're doing will be interrupted. But again, looking at your code, I don't see why that should be losing characters. Rather than writing your own interrupt handler, I suggest you use UARTSerial. The UART is the first thing to start visibly suffering with bad interrupt latency, but it will affect other devices too like radios.
#NUCLEO F401RE ARM PROGRAMMING SERIAL#
That's why you need an interrupt handler, and the interrupt latency in the system should be targeted at around the 100us mark which means you shouldn't lose non-flow-control UART characters.Īn awful lot of boards do have no control on certain serial ports - particularly the debug terminal line to the USB, so as a quality-of-implementation aim we want it to be possible to reasonably reliably receive non-flow-controlled data via a buffered serial device like UARTSerial.Īnd it's kind of the canary in the coal-mine. So I assume you'd want to use HW flow control. but anyway when your application will start doing something else, you'd lose characters anyway. Here is seems like it takes time reading the timer.
(I believe the lptimer calls are made with IRQs fully masked, so serial IRQs get starved as much as the foreground thread).Īnd I think there will always be cases where the test will fail because receiver CPU is busy doing something else. Certainly you should be using UARTSerial normally to make reception reliable, but this specific test case was devoting 100% of foreground CPU time to reading the serial port - that should get the data out of the hardware as fast as an interrupt handler could. Now, I'm not confident that if this test app fails (with no other threads running) that UARTSerial will work any better. (It is derived from BufferedSerial, but the name got changed just to avoid name conflicts).
UARTSerial is the in-tree class that provides buffering.
0 kommentar(er)
