Track when tasks are pending and spin in irq_wait() when no tasks are
pending. This improves the mechanism for sleeping the processor -
it's simpler for the board specific code and it reduces the
possibility of the processor sleeping when tasks are busy.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add function to indicate when tasks need to be run. This will allow
the scheduler code to know if there are any tasks that need to be
processed.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Don't rely on the generic scheduler code to always have a timer no
more than 1ms in the future. Instead, create an avr specific timer
that will be called every 0x8000 ticks. This simplifies the generic
code and it reduces the amount of code that needs to be run every
millisecond.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If sched_add_timer() is called on a timer that would make it the new
head of the list, then add it and signal the board code that the timer
should be rescheduled.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's not necessary to keep a millisecond counter. Replace the two
users of sched_check_periodic() with explicit task wakeup flags.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The simulavr simulator will warn when writing to the watchdog
registers, but running code closer to what real hardware runs is worth
a few extra warnings.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Keep the homing code separate from the main stepper class. This makes
it easier to verify the correct config parameters are provided.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Instead of limiting the amount of non-acked messages to 50ms, limit
the amount to one round-trip-time. This should make it less likely
that the mcu will be overloaded and it should make retransmits faster.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The first message always has a sync byte with it, so its size should
be one larger. Also, the idle_time should always be the minimum time
that the message could be received, so it should always be reset to
eventtime on a retransmit.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If a nak message causes a retransmission then also accept a second nak
message as long as it is for a sequence greater than the first nak.
This should allow faster retransmits when there are multiple
transmission errors in a small time period.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Track the sequence number of the message last retransmitted (not the
sequence number of the next message to be transmitted). This fixes a
small possibility of a valid nak not being honored.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
If a retransmit is triggered by a nak, then it is not necessary to
increase the rto. The next retransmit time should be based on the
expected reception of the first retransmitted message, not the last.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Wait for any pending moves to be fully handled before exiting. Make
sure the wait is done inside the "self.is_processing_data" check to
avoid infinite recursion. Don't keep reading from the file while
waiting to exit.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Allow the micro-controller code to be built without support for
regular gpio pins. In this case, the code for endstops, steppers, and
gpiocmds will be disabled.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Implement new dynmem_start() and dynmem_end() functions instead of
alloc_chunk() and alloc_chunks() in the board code. This simplifies
the board code.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It is not necessary to limit stepper acceleration - only the limiting
of stepper torque is important.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The existing clock synchronization code has two flaws: intermittent
transmission latency during get_status requests can cause the
estimated clock to be too low, and the estimated clock calculation did
not take into account possible clock drift between samples. The
former could potentially lead to "Timer too close" errors and the
latter could potentially lead to "Move queue empty" errors.
Rework the code to avoid the above problems. It's not necessary to
estimate the micro-controller clock as an excellent estimate is
reported by the micro-controller (via the CLOCK_FREQ constant).
Account for a small drift from the reported value, and check on each
sample if the drift exceeds the expected limits. With a good starting
estimated clock, only the offset needs to be calculated. Use previous
offsets (and the estimated clock) in calculation of new offsets to
avoid intermittent latency from badly skewing the results. Finally,
add an additional time offset of one millisecond to account for any
minor inaccuracies.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Change the command dispatch and response generation so that most of
the work is done on pru0 instead of pru1. This allows more code to
fit into the limited space on pru1.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Kevin O'Connor