Part 2 is to implement M23: select file. That's more than just a
few lines, as we also have to teach the gcode-parser to collect
strings.
For now the file is simply tested for successful opening, no
actual printing, yet.
About build size: during development there was another
implementation, which didn't abstract SD card functions into
sd.c/.h, but put them into gcode_process.c directly. At the
feature completeness of this commit, the other implementation
used 70 bytes flash less, but also 23 bytes more RAM. So I decided
for the more abstracted/encapsulated version. --Traumflug
Also, this adds 14 bytes binary size even without SD card support.
A lot more #ifdefs around each use of next_target.read_string
would remove this, but after all we do care a bit about
readability of the source code, so let's sacrify these 14 bytes
to it. --Traumflug
Some M-codes apparently need this. Perhaps it could be avoided,
but it costs just 8 bytes binary size and 2 bytes RAM, so not
really a reason to make a headache.
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.
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.
Michael Moon
Markus Hitter
Stephan Walter