A number of regressions were patched also. The UBL G29 P2 and P4 Press and Hold had stopped working. It is very possible this is broken in the bugfix_v1.1.x branch also.
The main purpose of the Pull Request is to get the 3-Point mesh tilting to use the LSF algorithm just like the grid based mesh tilt. This simplifies the logic and reduces the code size some what. But the real reason to do it is the 3-Point case can be solved exactly. And by feeding these numbers into the LSF algorithm it provides a way to check all that code for 'correctness'.
* Fixing the DUE serial port assignments: Now -1 means the SAM3x USB Device emulating a serial port, and 0 means the USB to serial adapter included as a programming port
* Improving the Fast IO port access implementation on Arduino DUE
* Implemented EEPROM emulation on Due by storing data on the internal FLASH (with wear leveling)
* Implemented a Software SPI for the ST7920 graphics display for the Arduino RAMPS for DUE, as the default one in u8glib is clocking data too fast on ARM, and the display does not understand it.
* Fixing the case where the serial port selected is the USB device
* Adding configuration for the Makerparts 3D printer (www.makerparts.net)
* Tuned MakerParts acceleration on X and Y axis so it never loses steps. Also adjusted pulses per mm to match default hw configuration
* Fine tuned Maximum acceleration for MakerParts printer
* Style cleanup
* Style cleanup (2)
* Style fixes (3)
* Fixing the DUE serial port assignments: Now -1 means the SAM3x USB Device emulating a serial port, and 0 means the USB to serial adapter included as a programming port
* Improving the Fast IO port access implementation on Arduino DUE
* Implemented EEPROM emulation on Due by storing data on the internal FLASH (with wear leveling)
* Implemented a Software SPI for the ST7920 graphics display for the Arduino RAMPS for DUE, as the default one in u8glib is clocking data too fast on ARM, and the display does not understand it.
* Fixing the case where the serial port selected is the USB device
* Adding configuration for the Makerparts 3D printer (www.makerparts.net)
* Tuned MakerParts acceleration on X and Y axis so it never loses steps. Also adjusted pulses per mm to match default hw configuration
* Fine tuned Maximum acceleration for MakerParts printer
* Style cleanup
* Style changes to u8g_dev_st7920_128_64_sw_spi.cpp
* Even more improvements to the FastIO HAL for DUE. Now WRITE() is 2 ASM instructions, if value is constant, and 5 cycles if value is not constant. Previously, it was 7..8 cycles
* After some problems and debugging, seems we need to align the interrupt vector table to 256 bytes, otherwise, the program sometimes stops working
* Moved comments out of macro, otherwise, token pasting does not properly work sometimes
* Improved Software SPI implementation on DUE: Now it honors the selected speed passed to spiInit(). This allows much faster SDCARD access, improving SDCARD menus and reducing latency
* Update u8g_dev_st7920_128_64_sw_spi.cpp
* Disabling EEPROM over FLASH emulatiion if an I2C or SPI EEPROM is present
If using babystep to adjust the Z probe offset, the axis will move and the mesh will be updated at the same time, causing a doubling of the Z offset over the rest of the print.
To correct for this, the current Z position would need to be modified in the opposite direction, canceling out the additional Z offset added to the mesh. This would be confusing to users, and moreover it would not be accurate without also taking the current Z fade level and current Z height into account.
It might make sense to change the mesh in the case where no babystepping is taking place, but this could be considered an undesirable side-effect of changing the `zprobe_zoffset`.
One way to remedy this would be to return to storing the mesh with `zprobe_zoffset` included, then subtracting `zprobe_zoffset` from the returned Z value. Thus, a babystep moving the Z axis up 1mm would subtract 1 from `zprobe_zoffset` while adding 1 to all mesh Z values.
Without including the `zprobe_zoffset` in the `z_values` there is no safe way to alter the mesh in conjunction with babystepping, although it's fine without it.
