* STM32F1 HAL
Adding files for STM32F1 HAL based on libmaple/stm32duino core.
Current persistent_store uses cardreader changes to be sent in separate
commit, but could be changed to use i2c eeprom.
There is another persistent_store implementation that uses the MCU flash memory
to emulate eeprom
Adding readme with some information about the stm32 HAL.
* Switch to Timer4 to avoid a hard reset on STM32F103C6 boards
On bluepill STM32F103C6 boards, using Timer5 results in a error() vector call. Switch to 4 since these are both general purpose, 16 bit timers.
* Add support for EEPROM emulation using Flash
Some low end machines doe not have EEPROM support. Simulate it using the last two pages of flash. Flash does not allow rewrite between erases, so skip writing the working version if that's enabled.
* Basic Pins for a malyan M200
This is a work in progress to go hand in hand with the STM32 work.
* Add support for ADC with DMA. This work has exposed a problem with the pin enumerations in STM boards vs what marlin expects (i.e, try defining PA0 as a temp pin). The hack can be removed with we go to fastio completely. To see this work, set something in adc_pins to a value like PA0 and connect your pullup resistor'd thermistor.
* Missing file - change HAL_adc_init to actually do something
We have an actual ADC init function now.
* Remove pinmode hack
Remove the pin mode hack that I was using to init PA0.
Updated Readme.md
* Several changes to timers and GPIO
Faster GPIO, and faster timer functions by accesing registers and
libmaple.
Still more changes pending for the Timer's code to skip using the
HardwareTimer class altogether.
Switch all enums to be within #defines
This change allows a user to have, for instance, TEMP_4 and TEMP_BED definied but nothing else. The enums which are not defined move "out", allowing the first ones to take the slots in the enum, and since the array is sized on ADC_PIN_COUNT, we always have the right size data and in order.
* Update Malyan M200 pins
Update Malyan M200 pins with correct fan values.
* Test all pins on actual hardware, update definitions
Some of the pin definitions were from knowlege base/pdfs. Now they've been tested against actual hardware. This should be very close to final.
* Update HAL_timers_Stm32f1.cpp
* Add sample configurations for Malyan M200
Add sample configuration for Malyan M200 without bed leveling, and move fan to auto cool E0 since this printer by default has only one fan.
Choose the timer based on MCU defintion. Timer5 is not valid on C8/CB class boards, so use Timer4 for the step timer.
readme.md update
* Updates to timers, and some stm32 boards definitiions
* Correct pin toggle macro.
* Remove duplicated Malyan M200 entry from pins.h
* Update configuration_store.cpp
* Formatting, indentation
* Formatting in HAL_Stm32f1.cpp
* repair reverse_pass()
And make it readeble.
This was broken a long time ago.
Not competely unfunctional but far from optimal.
* Minor speedup when calling calculate_trapezoid_for_block
2 float / to 1 foat / and 2 float *
* Various style changes
User could enable SERIAL_XON_XOFF on USB-native devices and it would not be enabled without warning, but M115 would report the capability as available.
[2.0.x][LPC1768][FIX] NUM_DIGITAL_PINS was negative, fixes PWM, arduino io functions, M42, M43, M226, probably also Servo, some LCD, soft spi, SoftwareSerial, ... may be others
G26 uses logic that looks like:
```
ex = _GET_MESH_X(i + 1) - (SIZE_OF_INTERSECTION_CIRCLES - (SIZE_OF_CROSSHAIRS));
```
The Bi-Linear macros need parenthesis to work correctly.
During long lasting moves of a delta machine neither the temperatures are maintained nor buttons checked nor ... .
The fix is to call 'manage_heater()' and 'idle()' every now and then in the loop where the move is segmented.
The code is abot the same as in G2_G3 wher we had the same problem with too large circles lasting too long.
Fixing #7510
Travis is having problems at: https://github.com/MarlinFirmware/Marlin/pull/8560
So... doing a direct commit to get things correct. Bugfix_v1.1.x does not have this bug. Nothing needs to be done to that branch.
These changes may need to be warmed over. I tried to fix things with
the least amount of disruption. I just wanted to get the bugfix_v2.0.0
branch working for people again.
This will solve 2 issues on tool change.
1) when no home is done ("no_move" is set) tool change should never move X & Y because... I don't know where I am...only Z should be adjusted to avoid bed collision if other nozzle is lower than current.
Since no move no bed level matrix should be applied
2) When SWITCHING_NOZZLE is enabled and system is homed there are two movements to go to destination, but first can move Z to older position and then crash on the bed
include LPC1768 syntax for M42
couple more pin_t changes
consistency
change M42 to R, P format
Revert "change M42 to R, P format"
This reverts commit 01f12f579ec9ccc1bb9126e68d2c86449e9b7edf.
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.
This is a non-intuitive change. @oldmcg says in this post https://github.com/MarlinFirmware/Marlin/issues/7572#issuecomment-340641207 that using DELTA_PRINTABLE_RADIUS is better than DELTA_PROBABLE_RADIUS for setting the probe limits. This is because the automatic probe code checks all locations for being reachable by the probe prior to doing the probe.
Scott Lahteine