Fix line parsing

[GMagician]

Fix #16838

[GMagician]

@thinkyhead is it expected that thermalManager.manage_heater is called every sent gcode line?
Since windows sends 'cr+lf', 'cr' handle message, 'lf' handle and empty message

[AnHardt]

thermalManager.manage_heater is called much more frequent than that, in the idle process - as long there is enough power left to idle. Don't care about that. thermalManager.manage_heater returns immediately if there is nothing to do, but we want it to be in time - if there is something to do. (If there is something to do is set in an interrupt - so can occur at any time.)

[GMagician]

@AnHardt if it is already been called elsewhere (and often), why is necessary here?

[thinkyhead]

@AnHardt if it is already been called elsewhere (and often), why is necessary here?

Please read #7449 where we fixed a watchdog reset issue. (Thanks again, GitLens!)

[AnHardt]

What we want is accepting lines with the endings: 'LF', 'CR', 'CR-LF' and 'LF-CR' calling thermalManager.manage_heater even with a empty line.
If you can find a faster or smaller way to handle the doubles without processing an additional empty line, tell us about that.

[GMagician]

I'll check out code. An idea may be, if info is available, to call it when empty line and more than 75% of watchdog time has been passed before previous call, but if execution is not so a big deal (optimized actions) maybe this check may be worst

[AnHardt]

I thought more a bout something simple - not touching every HAL, like:
Finding the right place for something like:
If the current char is LR or CR peek the next char - if CR or LF, read an drop it.
Or avoiding peek:
If reading CR or LF (check a flag if already set (drop this char) else (set the flag)) else (erase the flag).

'thermalManager.manage_heater' gets new data to process about 5 times a second. We want to process the data without much jitter. Calling after 3 seconds is not acceptable. When the watchdog barks something went really wrong.

If i remember correctly data is ready after: 1/1024 seconds * number_of__ADCs * 2_phases * OVERSAMPLES

In theory we could call the PID-calculation in a irregular rhythm. But then we had to scale the float PID-constants by the real interval, not a constant. For the AVRs that would take forever - is not acceptable.

[thinkyhead]

If i remember correctly data is ready after: 1/1024 seconds * number_of__ADCs * 2_phases * OVERSAMPLES

That's about right. The AVR version of Temperature::isr runs at "just under 1kHz" and the rest follow suit. There's a setup phase for each sensor followed by a read, followed by another setup phase…

It has occurred to me that the Setup phase for the next sensor could actually be done right after the Read phase of the previous sensor. So we could actually double the sensor read frequency with one small change.

…and if the different MCUs allow for multiple ADC conversions in parallel, or require shorter setup-to-read periods, then we should also take advantage of those features.

[thinkyhead]

If the current char is LR or CR peek the next char - if CR or LF, read an drop it.

Another way to manage this is to limit to the number of empty lines that can be skipped and just return to the main loop without processing if that number is exceeded. This also ensures that other queue processing from other sources isn't blocked.

[AnHardt]

Another way to manage this is to limit to the number of empty lines that can be skipped and just return to the main loop without processing if that number is exceeded. This also ensures that other queue processing from other sources isn't blocked.

If placed before removing comments no 'long' blocking should occur. If there are rally many consecutive empty lines those are processed really fast - until the serial input buffer is empty - and we are idling again.

However this makes only sense when done faster than calling and returning a function without parameters plus one decision. With an intermediate 'always inline' function - only one decision. That will be hard to beat.

In our thermal systems we have death-times (times between switching a heat-element on and registering an effect at the thermometer) of several seconds. Caling PID more often than 4-5 times per second does not make much sense. Maybe, as long as an uint16_t summ (or 32bit for the 32bitters) is not flowing over, more over-samples could give useful less noise and/or a better resolution.

For the STM32s the ADC can be read by DMA and stored in a buffer. In that case always the newest values could be available without any delay. Actually we do use busy waiting analogeRead() where the two steps don't make any sense.