Avoid blocking main loop while sending data via UART

[robomechs]

Avoid blocking main loop while sending data via UART

[robomechs]

Ok. We can use dma for this purpose.

[mstrens]

Is it possible to use DMA when you do not yet know the number of char to be sent?
I presume, the logic is currently to call "serial_write()" byte per byte from many place in the code.
Is it not easier to fill a buffer and use an interrupt to sent the data in the buffer?

[robomechs]

Maybe. We have to think.

[mstrens]

I changed the code in order to toggle a pin each time the program goes into the main loop (in protocol.c). I put a digital scope on the serial RX and TX signal and on this pin.
I can confirm that when GRBL is sending the status (in reply to a "?"), the STM32 does not enter anymore the main loop for about 3.2 ms.
This delay would not exist if sending via UART would use a buffer and an interrupt

[mstrens]

I made changes in order to use interrupts when sending data via UART (in order to avoid locking the main loop).
Code concerns main.c, serial.c and serial.h
I tested the code with UART and it seems OK.
Code is available on my site (in branch master)
https://github.com/mstrens/grbl_6axis_on_stm32
In this code there are also some changes in order to check the timing of the protocol_main_loop (in protocol.c) and the timing of handling the set/dir in interrupts (in stepper). The principe is to change the pin flood and mist (just for debug). It is activated in protocol.c with parameter
#define DEBUG_TIMING_WITH_FLOOD_AND_MIST

[mstrens]

I made a new change in order to put #define DEBUG_TIMING_WITH_FLOOD_AND_MIST in grbl.h (instead of protocol.c; it was wrong).
I also now change the flood pin when I change the X step pin (it is for my current testing).
it could even change for future test. So look at the code if you want to use such a debug function