chelper: Move the host C code to a new klippy/chelper/ directory
Move the C code out of the main klippy/ directory and into its own directory. This reduces the clutter in the main klippy directory. Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
This commit is contained in:
parent
8e1b516eb6
commit
15248706ae
|
@ -17,8 +17,10 @@ arranges for includes of "board/somefile.h" to first look in the
|
||||||
current architecture directory (eg, src/avr/somefile.h) and then in
|
current architecture directory (eg, src/avr/somefile.h) and then in
|
||||||
the generic directory (eg, src/generic/somefile.h).
|
the generic directory (eg, src/generic/somefile.h).
|
||||||
|
|
||||||
The **klippy/** directory contains the C and Python source for the
|
The **klippy/** directory contains the host software. Most of the host
|
||||||
host part of the software.
|
software is written in Python, however the **klippy/chelper/**
|
||||||
|
directory contains some C code helpers. The **klippy/extras/**
|
||||||
|
directory contains the host code extensible "modules".
|
||||||
|
|
||||||
The **lib/** directory contains external 3rd-party library code that
|
The **lib/** directory contains external 3rd-party library code that
|
||||||
is necessary to build some targets.
|
is necessary to build some targets.
|
||||||
|
@ -105,9 +107,9 @@ DECL_COMMAND macro in the micro-controller code).
|
||||||
|
|
||||||
There are four threads in the Klippy host code. The main thread
|
There are four threads in the Klippy host code. The main thread
|
||||||
handles incoming gcode commands. A second thread (which resides
|
handles incoming gcode commands. A second thread (which resides
|
||||||
entirely in the **klippy/serialqueue.c** C code) handles low-level IO
|
entirely in the **klippy/chelper/serialqueue.c** C code) handles
|
||||||
with the serial port. The third thread is used to process response
|
low-level IO with the serial port. The third thread is used to process
|
||||||
messages from the micro-controller in the Python code (see
|
response messages from the micro-controller in the Python code (see
|
||||||
**klippy/serialhdl.py**). The fourth thread writes debug messages to
|
**klippy/serialhdl.py**). The fourth thread writes debug messages to
|
||||||
the log (see **klippy/queuelogger.py**) so that the other threads
|
the log (see **klippy/queuelogger.py**) so that the other threads
|
||||||
never block on log writes.
|
never block on log writes.
|
||||||
|
@ -185,28 +187,28 @@ provides further information on the mechanics of moves.
|
||||||
relative to when the micro-controller was last powered up.
|
relative to when the micro-controller was last powered up.
|
||||||
|
|
||||||
* The next major step is to compress the steps: `stepcompress_flush()
|
* The next major step is to compress the steps: `stepcompress_flush()
|
||||||
-> compress_bisect_add()` (in stepcompress.c). This code generates
|
-> compress_bisect_add()` (in klippy/chelper/stepcompress.c). This
|
||||||
and encodes a series of micro-controller "queue_step" commands that
|
code generates and encodes a series of micro-controller "queue_step"
|
||||||
correspond to the list of stepper step times built in the previous
|
commands that correspond to the list of stepper step times built in
|
||||||
stage. These "queue_step" commands are then queued, prioritized, and
|
the previous stage. These "queue_step" commands are then queued,
|
||||||
sent to the micro-controller (via stepcompress.c:steppersync and
|
prioritized, and sent to the micro-controller (via
|
||||||
serialqueue.c:serialqueue).
|
stepcompress.c:steppersync and serialqueue.c:serialqueue).
|
||||||
|
|
||||||
* Processing of the queue_step commands on the micro-controller starts
|
* Processing of the queue_step commands on the micro-controller starts
|
||||||
in command.c which parses the command and calls
|
in src/command.c which parses the command and calls
|
||||||
`command_queue_step()`. The command_queue_step() code (in stepper.c)
|
`command_queue_step()`. The command_queue_step() code (in
|
||||||
just appends the parameters of each queue_step command to a per
|
src/stepper.c) just appends the parameters of each queue_step
|
||||||
stepper queue. Under normal operation the queue_step command is
|
command to a per stepper queue. Under normal operation the
|
||||||
parsed and queued at least 100ms before the time of its first
|
queue_step command is parsed and queued at least 100ms before the
|
||||||
step. Finally, the generation of stepper events is done in
|
time of its first step. Finally, the generation of stepper events is
|
||||||
`stepper_event()`. It's called from the hardware timer interrupt at
|
done in `stepper_event()`. It's called from the hardware timer
|
||||||
the scheduled time of the first step. The stepper_event() code
|
interrupt at the scheduled time of the first step. The
|
||||||
generates a step pulse and then reschedules itself to run at the
|
stepper_event() code generates a step pulse and then reschedules
|
||||||
time of the next step pulse for the given queue_step parameters. The
|
itself to run at the time of the next step pulse for the given
|
||||||
parameters for each queue_step command are "interval", "count", and
|
queue_step parameters. The parameters for each queue_step command
|
||||||
"add". At a high-level, stepper_event() runs the following, 'count'
|
are "interval", "count", and "add". At a high-level, stepper_event()
|
||||||
times: `do_step(); next_wake_time = last_wake_time + interval;
|
runs the following, 'count' times: `do_step(); next_wake_time =
|
||||||
interval += add;`
|
last_wake_time + interval; interval += add;`
|
||||||
|
|
||||||
The above may seem like a lot of complexity to execute a
|
The above may seem like a lot of complexity to execute a
|
||||||
movement. However, the only really interesting parts are in the
|
movement. However, the only really interesting parts are in the
|
||||||
|
@ -425,8 +427,8 @@ Some things to be aware of when reviewing the code:
|
||||||
conversion is never ambiguous. The host converts from 64bit clocks
|
conversion is never ambiguous. The host converts from 64bit clocks
|
||||||
to 32bit clocks by simply truncating the high-order bits. To ensure
|
to 32bit clocks by simply truncating the high-order bits. To ensure
|
||||||
there is no ambiguity in this conversion, the
|
there is no ambiguity in this conversion, the
|
||||||
**klippy/serialqueue.c** code will buffer messages until they are
|
**klippy/chelper/serialqueue.c** code will buffer messages until
|
||||||
within 2^31 clock ticks of their target time.
|
they are within 2^31 clock ticks of their target time.
|
||||||
* Multiple micro-controllers: The host software supports using
|
* Multiple micro-controllers: The host software supports using
|
||||||
multiple micro-controllers on a single printer. In this case, the
|
multiple micro-controllers on a single printer. In this case, the
|
||||||
"MCU clock" of each micro-controller is tracked separately. The
|
"MCU clock" of each micro-controller is tracked separately. The
|
||||||
|
|
Loading…
Reference in New Issue