I think that there is an issue on the latest example. Assumed that the last chunk is 250 bytes (DMA Size is 250) and the next one chunk is 32bytes (DMA Size is 282), the condition about Size == RX_SIZE(256) will not be executed.
You can't. You should just define the buffer large enough. Or first send the data containing the size of RX buffer. Then use the data to define a new RX buffer and call dma function to receive the data. But this can't be done in a continuous data stream. After sending the buffer size, the sender must wait for some time so that the mcu gets enough time to create the buffer and call the dma receive function.
@@ControllersTech Thank you, I think my question was not clear enough. I was worried about a buffer overflow when too much data is sent. But I realized later that the dma will automatically loop in circular mode, and the size of the buffer is passed when calling ReceiveToIdle_DMA. Now I have been experimenting with this and it all works well, I am trying to optimize the delay between the Idle callback and the actual end of the message, which for some reason I can't get under 2us at 6MBaud. I suppose this is a hardware limitation. (Using the G431)
Initialize the DMA reception in normal mode and clear or reset unused data after each transfer : void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { // Check if the received size is less than the buffer size if (Size < MAX_SIZE) { // Clear the unused portion of the buffer memset(&rxData[Size], 0, MAX_SIZE - Size); } // Re-enable the DMA reception for the next transfer HAL_UARTEx_ReceiveToIdle_DMA(huart, rxData, MAX_SIZE); }
Ive been messing around with an F401 Black pill, st-link to program it, and usb to ttl adapter to send data. I cannot for the life of me get it to do anything at all. Nothing happens. The program uploads fine. I have tried swapping the tx/rx pins around.
@@ControllersTech Yes that worked perfectly, provided the board was not in debug mode. Turns out I had just missed pressing "resume" and the code was waiting on HAL_init... Ive only just a few days ago received my first F4 board, no experience at all with CubeIDE, ive always had arduinos. Doh moment 🤣
@@ControllersTech Its all working now, next is trying to figure out how to setup an RxEventCallback from a specific uart. Can I change in // void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) the *huart to &huart1/&huart2 or something, trying to make it listen on both uarts and whatever comes in forward over the opposite uart.
Best channel with cool tutorials!
It is perfect and simple as always.... Good job...
Thank You for your tutorials
Thanks for the new video. Is there a resource you would recommend to learn more ?
You are just an amazing man!! Thank you
Great thank you so much for sharing
Can you make the Video on how to configure the UART in DMA so that another UART Rx via Intrupt can trigger the UART DMA to transfer.
Great
Thank you
It's time for Lin bus dude
I think that there is an issue on the latest example.
Assumed that the last chunk is 250 bytes (DMA Size is 250) and the next one chunk is 32bytes (DMA Size is 282), the condition about Size == RX_SIZE(256) will not be executed.
Is it possible to configure the timeout at which the controller considers an Idle event occurred?
How do we tell the DMA the size of the Rx buffer, in order to avoid overflow when sending a large file?
You can't. You should just define the buffer large enough.
Or first send the data containing the size of RX buffer. Then use the data to define a new RX buffer and call dma function to receive the data.
But this can't be done in a continuous data stream. After sending the buffer size, the sender must wait for some time so that the mcu gets enough time to create the buffer and call the dma receive function.
@@ControllersTech Thank you, I think my question was not clear enough. I was worried about a buffer overflow when too much data is sent. But I realized later that the dma will automatically loop in circular mode, and the size of the buffer is passed when calling ReceiveToIdle_DMA. Now I have been experimenting with this and it all works well, I am trying to optimize the delay between the Idle callback and the actual end of the message, which for some reason I can't get under 2us at 6MBaud. I suppose this is a hardware limitation. (Using the G431)
super video, tks
How do you reset the index in the DMA buffer so that after each occurred Idle event the next received bytes are stored at the beginning of the buffer?
Why not use the interrupt for such case ?
I would like to use as little processing power as possible. Is it possible to store at the beginning of the buffer after each Idle event?
Initialize the DMA reception in normal mode and clear or reset unused data after each transfer :
void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size)
{
// Check if the received size is less than the buffer size
if (Size < MAX_SIZE) {
// Clear the unused portion of the buffer
memset(&rxData[Size], 0, MAX_SIZE - Size);
}
// Re-enable the DMA reception for the next transfer
HAL_UARTEx_ReceiveToIdle_DMA(huart, rxData, MAX_SIZE);
}
i can't found this function
Ive been messing around with an F401 Black pill, st-link to program it, and usb to ttl adapter to send data. I cannot for the life of me get it to do anything at all. Nothing happens. The program uploads fine. I have tried swapping the tx/rx pins around.
Did you try running a simple program to blink LED ?
Maybe the clock configuration itself is wrong.
@@ControllersTech Yes that worked perfectly, provided the board was not in debug mode. Turns out I had just missed pressing "resume" and the code was waiting on HAL_init...
Ive only just a few days ago received my first F4 board, no experience at all with CubeIDE, ive always had arduinos. Doh moment 🤣
@@ControllersTech Its all working now, next is trying to figure out how to setup an RxEventCallback from a specific uart.
Can I change in
// void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size)
the *huart to &huart1/&huart2 or something, trying to make it listen on both uarts and whatever comes in forward over the opposite uart.