docs: Minor updates to Code_Overview.md

Minor indentation change.  Update for change to stepcompress_append().

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
This commit is contained in:
Kevin O'Connor 2020-03-02 21:54:22 -05:00
parent c0f72a2c38
commit 63ba7d231e
1 changed files with 14 additions and 14 deletions

View File

@ -68,10 +68,10 @@ function to be called at the requested clock time. Timer interrupts
are initially handled in an architecture specific interrupt handler
(eg, **src/avr/timer.c**) which calls sched_timer_dispatch() located
in **src/sched.c**. The timer interrupt leads to execution of schedule
timer functions. Timer functions always run with interrupts
disabled. The timer functions should always complete within a few
micro-seconds. At completion of the timer event, the function may
choose to reschedule itself.
timer functions. Timer functions always run with interrupts disabled.
The timer functions should always complete within a few micro-seconds.
At completion of the timer event, the function may choose to
reschedule itself.
In the event an error is detected the code can invoke shutdown() (a
macro which calls sched_shutdown() located in **src/sched.c**).
@ -188,8 +188,8 @@ provides further information on the mechanics of moves.
with head movement even though the code is kept separate.
* After the iterative solver calculates the step times they are added
to an array: `itersolve_gen_steps_range() -> queue_append()` (in
klippy/chelper/stepcompress.c). The array (struct
to an array: `itersolve_gen_steps_range() -> stepcompress_append()`
(in klippy/chelper/stepcompress.c). The array (struct
stepcompress.queue) stores the corresponding micro-controller clock
counter times for every step. Here the "micro-controller clock
counter" value directly corresponds to the micro-controller's
@ -220,11 +220,11 @@ provides further information on the mechanics of moves.
runs the following, 'count' times: `do_step(); next_wake_time =
last_wake_time + interval; interval += add;`
The above may seem like a lot of complexity to execute a
movement. However, the only really interesting parts are in the
ToolHead and kinematic classes. It's this part of the code which
specifies the movements and their timings. The remaining parts of the
processing is mostly just communication and plumbing.
The above may seem like a lot of complexity to execute a movement.
However, the only really interesting parts are in the ToolHead and
kinematic classes. It's this part of the code which specifies the
movements and their timings. The remaining parts of the processing is
mostly just communication and plumbing.
Adding a host module
====================
@ -338,9 +338,9 @@ Useful steps:
operations.
5. Other methods. Implement the `check_move()`, `get_status()`,
`get_steppers()`, `home()`, and `set_position()` methods. These
functions are typically used to provide kinematic specific
checks. However, at the start of development one can use
boiler-plate code here.
functions are typically used to provide kinematic specific checks.
However, at the start of development one can use boiler-plate code
here.
6. Implement test cases. Create a g-code file with a series of moves
that can test important cases for the given kinematics. Follow the
[debugging documentation](Debugging.md) to convert this g-code file