To guarantee that the 5mS pulse from a BLTouch is recognized you need to
have the endstops.update() routine run twice in that 5mS period.
At 200 steps per mm, my system has problems below a feedrate of 120 mm
per minute.
Two things were done to guarantee the two updates within 5mS:
1) In interrupt mode, a check was added to the temperature ISR. If the
endstop interrupt flag/counter is active then it'll kick off the endstop
update routine every 1mS until the flag/counter is zero. This
flag/counter is decremented by the temperature ISR AND by the stepper
ISR.
2) In poling mode, code was added to the stepper ISR that will make sure
the ISR runs about every 1.5mS. The "extra" ISR runs only check the
endstops. This was done by grabbing the intended ISR delay and, if it's
over 2.0mS, splitting the intended delay into multiple smaller delays.
The first delay can be up to 2.0mS, the next ones 1.5mS (as needed) and
the last no less than 0.5mS.
=========================================
BLTouch error state recovery
If BLTouch already active when deploying the probe then try to reset it
& clear the probe.
If that doesn't fix it then declare an error.
Also added BLTouch init routine to startup section
The target here is to update the screens of graphical and char base
displays as fast as possible, without draining the planner buffer too much.
For that measure the time it takes to draw and transfer one
(partial) screen to the display. Build a max. value from that.
Because ther can be large differences, depending on how much the display
updates are interrupted, the max value is decreased by one ms/s. This way
it can shrink again.
On the other side we keep track on how much time it takes to empty the
planner buffer.
Now we draw the next (partial) display update only then, when we do not
drain the planner buffer to much. We draw only when the time in the
buffer is two times larger than a update takes, or the buffer is empty anyway.
When we have begun to draw a screen we do not wait until the next 100ms
time slot comes. We draw the next partial screen as fast as possible, but
give the system a chance to refill the buffers a bit.
When we see, during drawing a screen, the screen contend has changed,
we stop the current draw and begin to draw the new content from the top.
If the stepper ISR takes too long, chars are lost which leads to serial
communication errors like "Line number not +1" or "Wrong checksum". In
worst case, the printer can even do crazy moves.
With this changes, UART interrupts are handled inside the stepper ISR.
This way, no chars should be lost.
If ENDSTOP_INTERRUPTS_FEATURE is enabled this tries to set up interrupt routines
for all used endstop pins. If this worked without errors, `endstops.update()` is called
only if one of the endstops changed its state.
The new interrupt routines do not really check the endstops and react upon them. All what they
do, is to set a flag if it makes sense to call the endstop test we are used to.
This can be used on:
* ARM (DUE) based boards - all pins can raise interrupts,
* RAMPS - all 6 endstop pins plus some other on EXT-2 can raise interrupts,
* RAMPS based boards - as long the designers did not change the pins for the endstops or at least left enough,
* all boards, if there are enough pins that can raise interrupts, and you are willing/able to swap with pins dedicated to other purpose.
Ross Allan