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:
parent
c0f72a2c38
commit
63ba7d231e
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue