I suspect there will be issues with pacing (no flow control between two streams), and there's inconsistency in data size, ie 16-bit data, vs 8-bit data.
So you'll want to think about the disparity between the data rates, consider using HT/TC for the ADC, and then lighting off a Normal DMA transfer to the USART from the alternating halves of the ADC buffer.I think I've posted a couple USART TX DMA examples, including ones that cycle through multiple strings (aka buffers).
Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
> It is not in your post but do you have your USART2_IRQHandler() ? You need it even if you are using the DMA.
Certainly not. > This is with HAL library but you still need to manage your UART Flags in the IRQ. Certainly not; contrary, you need DMA to handle them. JW
I appeared to be missing a line in my GPIO config for the TX pin.
/* Connect USART pins to AF */
GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_USART2);
After using this I got it working at the 115200 baudrate, after upping this to 2625000 I had to use the oversampling command. Using no flow control seems to work when using a terminal program but I guess it could be added for more stability.
I guess I don't need any of the USART IRQ handlers since, I configured DMA1 to handle the USART Tx requests with the following line:
Since both DMA streams are not running parallel but one after another this seems to check out. The mismatch of 16-bit ADC values being transferred over an 8-bit USART line is currently being handled on the receiving end where I perform an fread which expects uint16 values. It's not flawless yet but I'm on my way :)
Thank you already for all of your responses!