AVR is shackled by the fixed ( and unsuitably high ) priority of the serial interface. This means that USB has precedence over the motor pulses and anything but the most trivial serial I/O has to be disabled while motion is occurring.
In moving to less limited h/w lots of these necessary defects can be dealt with.
In experimenting with GRBL on STM32, I have increased the Gcode line length to the official NIST 256 chars and increased the txbuff to 1024. The latter is enough to buffer the output of $$, for example.
Most newer platforms will also allow freely assigned priority levels, so I have set the USB interrupts below the stepper timing pulses.
The aim is to enable commands like $$ during motion and use if to test whether the priorities are working and GRBL is producing stable pulses even with some continuous serial output running. This should be possible on fast h/w like STM32 even with a fairly fast step rate.
It seems like the pulse train should be the highest priority on the system not the serial I/O.
One $$ command works fine ( it’s buffered ) but if I send two such command lines immediately by pasting them into my sender ( minicom ) it causes the motor to stall. I’m assuming that this is because there is a delay in one of the pulses resulting in a rapid change of speed which is tripping the motor up. It’s running at about 10% down on it max. stable pulse rate on this mechanical hardware.
This maybe just something which I need to debug on the new platform but I was wondering whether I may be causing a glitch in GRBL’s functioning in doing this in an untested context.
Any advice on that?
Thx