openinverter forum

I noticed something strange after building stm32-test code. When built with "custom" printf.c Johannes provided the UART all of a sudden became "choppy" like it would split the line and send parts.

This causes problems with Mac particularly with PHP.
If fgets does not receive full line it is difficult to know when it ends ...at least in Mac there is no wait until available ...the serial just freezes.

Why are we using outdated method for "printf" if libopencm3 has a simple solution https://github.com/libopencm3/libopencm ... art_printf

After trying libopencm3 example all is good. No freezing with Mac. fgets receives complete line.

I suspect same this is the same issue I've been having with main firmware as well.

The reason back then was the lacking support for fixed point numbers and (less importantly) the dependency on libc and libnosys. The binary size increases by 40k or by 30k with the --gc-sections flag. So the main firmware would swell from 35 to 65kb.

It would also be possible to try and see if the firmware is still performant enough when running on floats. Would certainly look better to write a*b instead of FP_MUL(a, b)

Just checked on the main firmware. I basically hard coded usart3 as output to skip various function calls.
The output is always choppy because of various interrupts. I think this will be the same with the libc printf.

A clean solution would be to supply the USART via DMA. That said, the USART3 TX DMA shares a channel with TIM3_CH3 that is used for the single channel encoder - using DMA. So it would only work for REV2+ hardware which uses TIM3_CH1.

Thanks for detailed explanation, it doesn't explain "choppy" behavior in stm32-test program ...there is not much interruption going on to output uart.

I could see speed difference with old printf.c it takes about 1-2 seconds for output to display but with new almost instant.

Speed justifies increased size.

Yes, I think we should use the new printf in the test program. In the main firmware feel free to test it, especially during inverter operation.
Would you mind modifying the pull request again?

Just merged the pull request but it doesn't compile. Like "make" has no effect.
make V=1 displays
Using ./libopencm3/ path to library
make: Für das Ziel „all“ ist nichts zu tun.

oh, never mind, it's just very silent. Weird.
Will add the -O2 -g3 flags again and remove --gc-sections. Otherwise I can't debug properly

I've modified the custom printf.c to use DMA for outputting data. Should create a better flow especially on a loaded CPU.
That said e.g. the Json output is generated by multiple printf calls per line, so you might still see some jitter.

EDIT: does not work on REV1 hardware, as USART3 shares the DMA channel with TIM3_CH3 formerly used as encoder input.

Now I tested double buffered DMA writes. Basically a buffer is filled up until a "\n" is hit or the buffer is full. Then it is dispatched to DMA for sending. Meanwhile the application can fill up the other buffer.
It makes sending more continuous as you can see on a screen shot which seems to help Dimas frontend on the MAC (see above). If breaks to occur, they will be at the end of line. It also speeds up total transfer time. I didn't look into it closely, I guess it's between 30-50% faster on a system loaded with 17.6kHz PWM.

It will not work on REV1 hardware.

I put it on an extra branch (fconst_dmatx), since the commit also contains another sort of breaking change.
https://github.com/jsphuebner/stm32-sin ... onst_dmatx

Dima, can you test if that improves things?

EDIT: now tested performance. Command "stream 20 cpuload". Takes 2.5ms w/o DMA, 1.8ms w/ DMA. So 28% faster.

Wow thanks for doing this ...the science of uart.

I will test and get back to you. Maybe keep printf.c universal for future code, because HWREV1 is still good learning for beginners

Tested, works ... feels faster

Web interface issues, echo comes in with data on first line. I normally expect first line as echo, rest is data. Can you keep /n after echo?

Oh totally missed your reply!
Yes I just ran into the same problem. I thought the delay between command and reply was too long but actually is the missing echo. Thanks!

I've made the change in the fconst_dmatx branch