diff options
| -rw-r--r-- | docs/Code_Overview.md | 28 |
1 files changed, 14 insertions, 14 deletions
diff --git a/docs/Code_Overview.md b/docs/Code_Overview.md index 6ee53fa4..c47d783c 100644 --- a/docs/Code_Overview.md +++ b/docs/Code_Overview.md @@ -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 |