- Clean up the API to use a `static` class instance to adhere to Marlin convention
- Add `const` position data access for read/write
- Add Storage capacity to the interface
The current Marlin implementation relies on a timer interrupt to start the ADC conversion and read it. However in some circumstances the interrupt can be delayed resulting in insufficient time being available for the ADC conversion. This results in a bad reading and false temperature fluctuations. These changes make sure that the conversion is complete (by checking the ADC hardware via the HAL) before reading a value.
See: https://github.com/MarlinFirmware/Marlin/issues/11323
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.
