Commit f04895f5 documented that "{printer.gcode_move.gcode_position}"
may contain more than 4 components, however the code was not actually
updated to export that additional information. (Commit ac6cab91 only
made the change to "homing_origin" and "position".)
Export the information in gcode_position as intended.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Most errors, aside from amplitude, should never happen.
Output them to the log to simplify later debugging.
Count them to aggregate error metrics.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
If the sensor coil is disconnected, the frequency is equal to the reference.
If the sensor is misconfigured or damaged, the coil frequency is
greater than 1/4 of the reference frequency.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
Amplitude errors are useful but often too aggressive.
On some sensors, it is not possible to avoid them completely.
Make them non-critical for homing.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
I2C error means we don't know the sensor status.
Force data output to the host and cancel homing.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Use a different method of setting the hardware pwm registers so that
the actual cycle_time is much closer to the requested cycle_time.
Also, remove the now unused stm32_timer_output command, as the main
hardware pwm interface provides the same accuracy.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
BTT Eddy uses 12MHz clock in frequency.
Coil is oscillating at 3+MHz.
Which is out of spec for LDC1612 sensors.
Division of coil frequency seems to reduce output noise.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
The event handler is registered with an incorrect event name, causing the handler to never be called.
Signed-off-by: Maksim Bolgov maksim8024@gmail.com
Currently, there is no way to adjust the calibration curve.
The existing z_offset infrastructure is not applicable
or disabled here.
To make it possible to fine tune calibration curve.
Reload Z_OFFSET helper for probe_eddy_current.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
It's possible for a motor disable request to occur while processing a
previous motor enable. Use a reactor mutex to ensure the two events
are processed serially.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
To support the cartographer, it is required to output 24 MHz.
With current defaults max output frequency is:
48 MHz/256 = 187.5 KHz
Adjusting the PWM scale allows for ramping up the frequency.
To not mess up with existing PWM users,
define the STM32-specific command.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
A misplaced sensor or a misconfigured one
can return unreliable results.
Assist with this by refusing to use the too noisy points.
Filter noisy points by the frequency difference to noise ratio.
Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
It is possible for USB host controllers to send back-to-back IN tokens
which only gives the MCU ~3us to queue the next USB packet in the
hardware. That can be difficult to do if the MCU has to wake up the
task code. The stm32 "usbotg" hardware does not support a builtin
generic double buffering transmit capability, but it is possible to
load the next packet directly from the irq handler code. This change
adds support for queuing the next packet destined for the host so that
the USB irq handler can directly load it into the hardware.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The USB buffer size register PCKSIZE.SIZE was not being assigned
correctly. As a result, it was possible for an incoming USB
transmission to write past the allocated buffer space, which could
corrupt memory of other storage. In particular, in some cases gcc may
layout ram in such a way that the trailing bytes of an incoming
message might overlap the buffer for an outgoing message. This could
cause sporadic transmit errors and unstable connections.
Fix by correctly configuring the PCKSIZE.SIZE register.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
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>
