2020-11-16 01:14 PM
Hi
I have to send a large amount of data as a formatted ASCII over UART. The data is read through some terminal software on a PC.
I only have 1 wire to do this so it has to be UART.
I have a F042K6 STM32 Nucleo and running it at 1500000 baud. Works fine. However I cannot get the data to send fast enough.
It is taking about 2.2ms to format the data and send via UART. My sampling rate needs to be between 1khz to 1.5khz
The problem I think is the sprintf which I have to use to get the format for the UART to send.
Is there a way I can speed this up?
Or should I just buy a different chip. I am using 32pin package because I dont have space for anything larger.
This application btw works reasonably well on an LPC1768 made using ARM mbed 2 arduino type compiler, so maybe I should just buy the beefiest 32pin STM32 available?
Am running at 48mhz, have tried lower clock speeds with same BAUD UART and the transfer just gets slower, so pretty sure it is to do with the sprintf
uart_buf_len = sprintf(uart_buf, "%.1f\t%.1f\t%.1f\t%.1f\t%.1f\t%.1f\t%.1f\t%.1f\t%i\r\n", v1, v2, v3, v4, v5, v6, v7, v8, timer_val);
HAL_UART_Transmit(&huart1, (uint8_t *)uart_buf, uart_buf_len, 100);
2020-11-16 03:36 PM
could you send the binary data instead and do floating pt conversion on the PC if possible?
2020-11-16 03:54 PM
I don't know what "processing" means in this case, but if you convert ADC (i.e. integer) results into float and then perform float arithmetics, then it's not sprintf() which is your biggest problem.
Switching to Cortex-M4 with its floating-point unit would help immensely, if you can't avoid float; but only if you don't make some of the mistakes which leads to conversion and subsequent work with double.
JW
2020-11-16 04:35 PM
I have Nucleo-STM32G474, I could probe and try your code if there is an improvement...
2020-11-16 06:05 PM
HAL_UART_Transmit is using polling to get each-character-out-one-at-a-time-waiting-for-the-done-flag-to-be-asserted-before-going-back-for-the-next-character.
Start using DMA.