- Move D23 into it's own function inside Dcodes
- Correctly include a break in the switch statement
- Show the dumper status (enabled/disabled) after toggling
- Allow to generate an immediate dump via g-code using D23 E for
symmetry with D20 E
When building with GCC 4.9.2 (bundled with PF-build-env-1.0.6.*), -Os
and LTO enabled, PID_autotune gets automatically inlined into
process_commands().
Sadly, due to the massive size of process_commands(), it results in
codegen bug doing a partial stack overwrite in process_commands()
itself, manifesting as random behavior depending on the timing of
interrupts and the codepath taken inside the merged function.
Mark the function as noinline and add a note about the affected compiler
version in order to be checked again in the future.
Instead of using a mixture of int8_t, unsigned char and (incorrectly)
int, use uint8_t consistently for indexing the current block.
This improves the performance of the wait loop in plan_buffer_line,
which currently expands all comparisons to a word for no reason.
This also extends the theoretical limit to 128 entries.
Add some static assertions to ensure BLOCK_BUFFER_SIZE is correct.
This avoids the "busy" output interleaving with regular output in very
rare scenarios.
We should focus in finding which calls are not using manage_inactivity()
properly instead of working it around.
Code running in the temperature ISR needs to be fully reentrant, which
is hard to track down.
Move autoreporting to the main processing loop. This can make the
autoreporting slower or pause at times, but removes the reentrant
restriction, which allows us to use printf_P.
This PROGMEM is currently ignored by gcc, but even if it wasn't it
wouldn't be correct since the following code is expecting to read "item"
without fetching the array itself from PROGMEM.
The longpress function is currently called within the temperature ISR,
which is bogus. Calling the longpress function at the wrong moment
can corrupt the menu buffers.
Move the call to the main loop by changing the logic slightly:
- still sample the lcd buttons inside the temperature ISR, which keeps
scrollong/pressing responsive, but...
- set a flag to indicate that longpress has been triggered instead of
calling the function directly
- call the function on the next manage_inactivity run
Combined with #3180 this removes _most_ unsafe operations out of the ISR
which can happen during a normal run (max/mintemp warnings are still an
exception).
Instead of having to guess the PC where the SP was sampled, always take
both. This allows "seamless" stack decoding for both serial and xflash
dumps, since we don't have to guess which function generated the dump.
Make the core functions (doing the sampling) be ``noinline`` as well,
so that they always have valid frame.
Save SP which is closest to the crash location, which simplifies
debugging. For serial_dump, write SP just before the dump.
For xfdump, save SP in the dump header.
This makes xfdump_dump and xfdump_full_dump_and_reset() equivalent for
stack debugging.
