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:
Kevin O'Connor 2018-04-30 11:22:16 -04:00
parent 8e1b516eb6
commit 15248706ae
8 changed files with 29 additions and 27 deletions

View File

@ -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