Dropping bytes with 3 mb/s UART

[charlesrwest]

Hello!

I'm working on a project with a stm32f0-discovery board talking to a BNO080 IMU over UART.

The IMU has it's own framing/serialization scheme and appears to be hard coded to talk at a 3000000 baud rate. After looking at the chatter with a logic analyzer, it's clear that it is properly responding to the requests that are sent from UART1. However, when I do a sdReadTimeout it is equally clear that I am losing bytes.

For instance, the response from the IMU is suppose to have 2 bytes for framing, 4 bytes for the header and then a message beginning with 0xF8. And this is what I see with my logic analyzer. However, the data returned from sdReadTimeout shears off the byte before the message start 0xF8 every single time. Looking at it further seems to indicate that it is losing random bytes from the data as well.

If I may ask, is 3 mb/s just too high to be expected for UART reads with this chip? Is there something I should be doing that I haven't been to try to avoid data loss?

Uart config:
static const SerialConfig uart2_config =
{
3000000, //"3 Mb/s" baud rate
0,
USART_CR2_STOP1_BITS,
0
};

[Giovanni]

Hi,

The serial driver is interrupt-driven, it has limits because the STM32 UART is not deeply buffered (especially on M0 devices.

You need to use the UART driver which uses DMA and is much better at handling high baud rates. Note that it is unbuffered and is meant to work with known-size messages.

Giovanni

[rew]

You could also... just turn on the peripheral yourself and when the first "data available" interrupt happens, you busy-wait for all the data.

Now you might say that's inefficient, because interrupt driven you might still be able to do other stuff, but the fact that you are dropping bytes means that the "interrupt load" is currently above 100%. Reducing that to 100% during the reception of a packet is better than what you have now.....