2023-11-26 04:06 AM - edited 2023-11-26 04:07 AM
(STM32F103C8)
My program continuously sends UART messages with regular blocking calls like this:
HAL_UART_Transmit(&huart1, buf, size, timeout);
The result on my logic analyzer normally looks like:
I also handle interrupts coming from HAL_SPI_TxRxCpltCallback at 1kHz. When this coincides with a UART transmission, the result looks like this:
The SPI interrupt causes a slight delay in UART transmission, but it never seems to corrupt the transmitted data by getting "in between" the bits of each byte and messing up the timing. I ran a test for many hours and everything was fine.
Is this behavior something I can depend on to always be true? If so, I would imagine that to accomplish this the UART is disabling interrupts during the time it is transferring each byte? I have a bunch of other timer interrupt driven code that is quite time-sensitive, just trying to understand if the UART will affect that.
Solved! Go to Solution.
2023-11-26 08:00 AM
The data is shifted out in hardware, the HAL_UART_Transmit() will block in whatever thread it is running, waiting on TXE, filling the pending transmit buffer. Other interrupts, call-back, will similarly block execution of the loop waiting on the USART.
These things can happen more concurrently if you use interrupts to just manage the transactions, but then don't waste time doing other processing.
2023-11-26 08:00 AM
The data is shifted out in hardware, the HAL_UART_Transmit() will block in whatever thread it is running, waiting on TXE, filling the pending transmit buffer. Other interrupts, call-back, will similarly block execution of the loop waiting on the USART.
These things can happen more concurrently if you use interrupts to just manage the transactions, but then don't waste time doing other processing.
2023-11-26 05:00 PM
Yes, both the transmission and reception is atomic per byte, because, as Tesla noted, bits are shifted in/out by hardware.