The idea was to clear all flags with one variable, but actually,
this raises the binary size instead of lowering it. So, the code
in gcode_parse.c, line 354, is probably as fast as it can get.
Remove the assumption there's always an extruder temperature
sensor and make reading on single sensors (e.g. M105 P2) more usable.
Apparently works very well, but *sigh* yet another 100 bytes of binary size.
There were a whole bunch of cases where P and/or S were used without
checking for the validity of the value. This led to all sorts of
confusion, for obvious reasons.
This is a version of muldiv() with qn and rn precalculated,
so it can be avoided to re-calclulate it on every instance.
Yet another 116 bytes, unfortunately.
This gets rid of overflows at micrometer to step conversion as
much as possible within 31 bits. It also opens the door to get
STEPS_PER_M configurable at runtime.
This also costs 290 bytes, unfortunately.
Programming fuses doesn't belong to the firmware or to firmware
uploading. Fuses have to match the hardware and the bootloader,
so they should be set when setting up these.
We have multiplies followed by divides all over the place and
most of them are difficult to handle regarding overflows. This
new algorithm handles this fine in all cases, as long as all
three operators and the overall result fits into 32 bits.
The previous code was actually misbehaving and sent this string:
TYPE:Mendel EXTRUDER_COUNT:%d TEMP_SENSOR_COUNT:%d HEATER_COUNT:%d
(part of a string in gcode_process.c) instead of "0x". Ouch! Memory
landscape messed up?
This means:
- Max endstops are gone.
- Min endstops are now PB0 / PB1 / PB2.
- Order of the steppers is inverted (X Y Z E instead of E Z Y X).
- All pins on port A one to the left (pin number - 1).
These were commits 9dbfa7217e0de8b140846ab480d6b4a7fc9b6791 and
2b596cb05e621ed822071486f812eb334328267a.
There are several reasons why this new approach didn't work out well:
- The machine coordinate system is lost on relative movements.
OK, we could keep tracking it, but this would mean even more
code, so even more chances for bugs.
- With the lost coordinate system, no software endstops are possible.
- Neither of X, Y, Z will ever overflow.
- If a movement planner would appear one day, he'd have to handle
relative movements as well. Even more code duplication.
Instead of converting them to absolute first, then back to
relative and having all the fuzz with working on the queue's
start vs. working at the queue's end, mark a movement as relative
and use this directly.
Now we don't have tables for default or gen7 electronics, but
two default tables for a single vs. two different thermistors.
This seems to be more logical.
Markus Hitter
Ben Gamari