An undocumented hw bug makes the UART lose chars when RX ISR is disabled, even for a very small amount of time. This happens when RX_BUFFER > 256, and the result is corrupted received commands. Solved by implementing pseudo-atomic operations on 16bit indices.
* Misc fixes and improvements
- Get rid of most critical sections on the Serial port drivers for AVR and DUE. Proper usage of FIFOs should allow interrupts to stay enabled without harm to queuing and dequeuing.
Also, with 8-bit indices (for AVR) and up to 32-bit indices (for ARM), there is no need to protect reads and writes to those indices.
- Simplify the XON/XOFF logic quite a bit. Much cleaner now (both for AVR and ARM)
- Prevent a race condition (edge case) that could happen when estimating the proper value for the stepper timer (by reading it) and writing the calculated value for the time to the next ISR by disabling interrupts in those critical and small sections of the code - The problem could lead to lost steps.
- Fix dual endstops not properly homing bug (maybe).
* Set position immediately when possible
Also simplify logic on all ARM-based interrupts. Now, it is REQUIRED to properly configure interrupt priority. USART should have highest priority, followed by Stepper, and then all others.
This is an initial cut for feedback, updated for 2.0.x.
Chamber temperature is currently reported along with hot end and bed
temperatures to serial. The format is just like that used for hot end
and bed temperatures, but using 'C' prefix. As there is no heater,
target is always 0. Is this appropriate, is there a better way to report
chamber temperatures?
Chamber temperatures are not reported on the LCD in any way.
When auto chamber fan is enabled, it currently just uses the same
temperature threshold as the other auto controlled fans.
As the chamber temperature is not connected to any heater, it doesn't
undergo mintemp/maxtemp monitoring. This would need to change in the
future if chamber heating became a feature.
* Work around for serial buffer over run
PronterFace sends a lot of M105 commands. During long operations such
as UBL's G29 P1, G29 P2, G29 P4 and G26 this can over run the serial
buffer. This results (very often) in a M1 (actually a M1M105) ending
up in the command queue.
Until we figure out a better way to resolve this issue, this will keep
the UBL commands from experiencing bogus commands at thier completion.
