Allow reqclock to be slightly less than the transmitted messages's
deadline. That is, delay messages with a reqclock far in the future
to slightly past (1<<31) ticks from its deadline. Use (3<<29)
instead, which gives an additional (1<<29) grace period to avoid clock
overflows.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
For correct operation the trsync system must be programmed prior to
the start of endstop checking. This means the desired "reqclock" for
the trsync configuration messages need to use the same "clock" that
the endstop start message uses - even though the actual deadline for
these messages is later.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Arriving of SW PWM out of sync
can cause pulse width distortion - make them longer
Synchronize the update clock to avoid that
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The MIN_REQTIME_DELTA parameter controls when the host will flush
incomplete message blocks to the mcu. If the message had a target
time less than 250ms it would result in a flush even if a message
block was not completely full.
In the situation where the host generates lots of queue_step commands
to the point that it fills the mcu move_queue, then it would be
possible for individual queue_step commands to become eligible for
transmit only microseconds apart. It could also lead to a situation
where the target time was less than 250ms in the future. The result
could lead to many small message blocks as each became flushed
individually.
Tune the MIN_REQTIME_DELTA to 100ms to reduce the chance of this.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change TIMER_MIN_TRY_TICKS from 2us to 90 instructions.
On newer chips 2us is a large amount of time - for example on the
520Mhz stm32h723 it would be 1040 instructions. Using a large time
can result in "busy waiting" in the irq handler when the cpu may be
better spent running tasks.
The armcm_timer.c code is used on most ARM cortex-M chips and on all
of these chips the SysTick timer should be tied directly to the
instruction counter. This change should be safe because it should not
take more than 90 instructions to reschedule the timer on any of these
chips. Also, all of these chips should be able to exit the irq
handler and reenter it in less than 90 instructions allowing more time
for tasks to run if the next timer is more than 90 timer ticks in the
future.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The TIMER_IDLE_REPEAT_TICKS was intended to reduce the number of cases
where timers would defer to tasks when tasks are mostly idle.
However, with commit ea546c78 this became less important because
timers now only defer to tasks if tasks are consistently busy for two
consecutive calls to sched_check_set_tasks_busy().
The TIMER_IDLE_REPEAT_TICKS mechanism could result in extended task
delays if timers do become busy. Timers can become busy in normal
operation if timers are scheduled to run more than 500,000 times a
second (every 2us or faster). This can occur on stepper movement when
using high microstep settings. If timers become busy, it could take
up to 1ms for tasks to next be given an opportunity to run (two calls
to sched_check_set_tasks_busy() at 500us per call). This wouldn't
typically be an issue if tasks are also busy, but in some loads tasks
may need to run periodically in such a way that the task status
alternates between idle and busy. In this case, the
TIMER_IDLE_REPEAT_TICKS mechanism could effectively limit the number
of task wakeups to only ~1000 per second.
The "USB to canbus bridge" code uses tasks to transfer data to/from
USB and canbus. If timers become busy, the limiting of task wakeups
could lead to a situation where the effective bandwidth becomes
severely constrained. In particular, this can be an issue on USB
implementations that do not support "double buffering" (such as the
stm32 usbotg code). There are reports of "Timer too close" errors on
"USB to canbus bridge" mode as a result of this issue.
Fix by removing the TIMER_IDLE_REPEAT_TICKS check. Check for busy
tasks every TIMER_REPEAT_TICKS instead (100us).
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
- Document AHT15 and AHT30 sensor support
- Update sensor_type options (AHT1X, AHT2X, AHT3X)
- Add note about some AHT20 working with AHT1X sensor type
Signed-off-by: Lev Voronov <minicx@disroot.org>
This also enables arbitrary using names for primary carriages
with generic_cartesian kinematics.
Signed-off-by: Dmitry Butyugin <dmbutyugin@google.com>
* Do not recommend ZV shaper by default if possible
* Try to find more optimal shaper out of more aggressive ones
Signed-off-by: Dmitry Butyugin <dmbutyugin@google.com>
This adds a dedicated check for that case to be able to
find the root cause of a misconfiguration earlier.
Also, replace occurrences of hardcoded max tick count.
Signed-off-by: Pascal Pieper <accounts@pascalpieper.de>
This timing is also known as T1H in various datasheets. Increasing it
should improve compatibility with various revisions and clones of the
WS2812 LED.
The short version is that 800 is the timing used by Adafruit's popular
NeoPixel Arduino library, and it has no problem driving my BTT RGBW kit
LEDs, while Klipper cannot drive them properly without this patch. The
real upper limit to this value is something like 5000ns so increasing
it should not cause new compatibility problems for LEDs that currently
work.
Signed-off-by: Alistair Buxton <a.j.buxton@gmail.com>
A "dummy extruder" that is created when no "[extruder]" config section
is defined does not have a "name". Avoid reporting that empty name in
the `{printer.toolhead.extra_axes}" status report.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Update the "position" status to include extra axes. Export a new
"extra_axes" value that describes the class associated with each
component of the coordinate.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change "homing_origin" and "position" to support more than 4
components. Export a new "axis_map" value to describe the contents at
each component index.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Instead of passing arguments as parameters, pass them as a list (or
tuple). This simplifies the callers and makes it easier to pass
additional parameters.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Keep moving messages from the pending queues to the ready queues even
if it's not currently valid to transmit messages to the mcu. This
improves the statistics when debugging.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Only hold the lock in the serialqueue thread when moving messages to
the ready queue and when setting the next need_kick_clock.
Only set the need_kick_clock just prior to sleeping.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Maintain the next needed wakeup time for entries in the pending
queues. This avoids needing to walk the upcoming queues when it is
known that nothing is ready to be released.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
There's no reason to attempt to handle multiple buffer transmissions
in a single command_event() call. Handle the transmit case outside of
the command building loop.
If data is transmitted, then get a new timestamp from the pollreactor
and retry before sleeping.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
