[2.0.x] Emergency parser for multiple serial ports

[thinkyhead]

Followup to #10516

Make sure the emergency parser can track state for multiple serial inputs.

This may need to be augmented with an additional emergent_state for each serial device, attached to whichever object is most closely associated with the serial input instance, whether it's the input ring buffer, the static class, or whatever.

Build tested for AVR, DUE, and LPC1768.

[p3p]

I like this approach, that's why I chose it for my LPC1768 PR, but not doing much AVR development I was worried about adding overhead to the UART ISR if I generalised the implementation, you know better than me that it's OK.

emergent_state is an little odd for the state variable.

[thinkyhead]

I was worried about adding overhead to the UART ISR

It could all be moved to emergency_parser.h and made FORCE_INLINE, so I may do that.

emergent_state is an little odd for the state variable.

Maybe I watched too many medical dramas. I'll change it to emergency_state.

[p3p]

Would you be ok with adding a single character realtime command, such as 0x18 (Ctrl-X), to reset the mcu.. this isn't at all because I wouldn't have to cross the room to reset my Re-ARM to flash

[thinkyhead]

0x18 (Ctrl-X), to reset the MCU

• If the MCU can be reliably reset from code. There was a thread where someone couldn't get the usual methods to work at all, but maybe they did finally solve it.
• And, if we can be sure that this character won't be spuriously sent in the event of a funky serial connection. Hinging such a strong response on a single character might be brittle, and in future if Marlin gains a binary protocol we'll need to work around it.

[p3p]

If the MCU can be reliably reset from code. There was a thread where someone couldn't get the usual methods to work at all, but maybe they did finally solve it.

For the ARM MCUs its just NVIC_SystemReset();, AVR I have no idea,

Hinging such a strong response on a single character might be brittle, and in future if Marlin gains a binary protocol we'll need to work around it.

0x18 will never be purposefully sent but corruption in the connection could ofc cause it, grbl have a few single char opcodes that get stripped from the serial stream before the parser, seems to work fine, but there is always the risk I guess.

[thinkyhead]

AVR I have no idea,

An infinite loop will reset if the watchdog is on. Or, a jump to address 0x00 will do it.