2016-04-17 09:36 AM
I'm currently hitting overrun issues using HAL library's HAL_UART_Receive_IT() function
Baud rate: 115200 The only thing the interrupt routine ( HAL_UART_RxCpltCallback() ) does is copy the incoming 10 bytes into another buffer So what I need to know is... is my clock config OK for this baud rate or this has little to do with my problem?2016-04-17 09:43 AM
And you're using what part exactly? I'll assume an F1 of some type.
36 or 72 MHz for the APB should be more than adequate, at those rates the USART should be capable of several mega-baud. I'd try to keep the interrupt loading below the 100's of KHz2016-04-17 10:49 AM
Oops, yes its a STM32F103CBT
> I'd try to keep the interrupt loading below the 100's of KHz I think this was part of the problem earlier when I was interrupting at every byte received, so I changed it to interrupt after receiving 10. It receives first 3 or 4 sets of 10 bytes just fine now but beyond that the overrun occurs, even if I send just 1 byte after the first overrun I'm sending it 10 bytes every 2 seconds Tried disabling all other interrupts (I'm using I2C 400khz with DMA,) and giving USART1 Global Interrupt preemption priority 0, didn't notice a difference I read someone else suggesting DMA if you want to store read bytes in a ring buffer (my case) Is this the only way?2016-04-17 04:15 PM
115200 baud would interrupt at 11.5 KHz, you'd want to watch what you are doing, but it's sustainable, I've used F1's and modems at this rate.
The HAL's likely to add some burden. If you have a constant stream of data, DMA may well be a good strategy, basically a double sized buffer, with HT and TC interrupts. Any strong driver for the F1? Subsequent parts have better flash caching and prefetch mechanisms so the wait states don't slow execution.2016-04-18 03:41 PM
Thanks clive1
Got it working after some edits to the HAL callback