search

Severson-Group / AMDC-Firmware

Embedded system code (C and Verilog) which runs the AMDC Hardware
http://docs.amdc.dev/firmware
BSD 3-Clause "New" or "Revised" License
31 stars 5 forks source link

Create distinct entities for tasks vs controllers #170

Closed npetersen2 closed 4 months ago

npetersen2 commented 3 years ago

After thinking about this for a while, I have converged on the following ideas for how to structure repetitive code blocks on the AMDC platform. This effectively will extend the current architecture by exposing a new entity that people ought to use for real-time control tasks.

Overview

  1. Remove the sys/scheduler.c module. This functionality will be merged into another module! This will be an API breaking change, but this is the right move for a more structured, robust code base.

  2. Create two new entities: sys/task.c and sys/controller.c

All previous task-related stuff (i.e. scheduler, task_control_block_t, co-operative operation, etc) will be moved into the sys/task.c module. Do not worry, it still exists!

sys/task.c sys/controller.c
New name for present task architecture NEW MODULE
Runs via cooperative scheduler Runs in ISR context (highest priority in system)
Supports priorities within group of other registered tasks (MAX, MID, MIN) Supports priorities within group of other registered controllers (MAX, MID, MIN)
Scheduling based on time (i.e. "run every X Hz") Scheduling based on PWM ISR harmonic, tied to Fsw
-- User can configure ISR events from PWM carrier on peak, valley, or both
-- User configures controller to run at some subharmonic of PWM ISR. For example, every possible update rate, every 10, etc.

Adoption Plan

After this is implemented, all current tasks, controllers, etc will be migrated to use the sys/task.c module. This will only involve calling a new function which does the same thing as before; the system will behave exactly the same!!

Once everyone is using the sys/task.c module, users can start migrating their motor control code to use the sys/controller.c module. This will be done on a per-user basis.

Forced Usage?

People do not HAVE to use the new sys/controller.c module to build controller code! The old task system will continue to work. However, strict timing simply cannot be guaranteed with a cooperative approach. For some applications where moderate jitter is okay, there is no need to update to the ISR-based controller approach. However, for applications that need very accurate timing (no jitter) and control executed relative to PWM updates, the new sys/controller.c module will be the solution.

npetersen2 commented 4 months ago

@annikaolson some ideas from long back about implementing a system architecture with both the ISR/PWM-synced code callback and the current scheduler time-based callback.

Might be useful for implementing #377.

This also might be more complicated than we need... and just wait for v2 for the full support of time-based and PWM-synced code to run in the same system

npetersen2 commented 4 months ago

We'll close this since we have implemented this in a different way, see latest v1.3-staging