We have tasks that process events one at a time to completion. They can place tasks/events on each other queues synchronously.

→ One type of task is a queue processor that subscribes to a queue

→ A soft timer task

How to deal with SPI or I2C:

Option 1: We have a mutex for SPI and I2C, when a task wants an exchange it acquires a lock and does its thing. It may get interrupted by a high-priority task. (could be useful for simplicity with a priority complex risk)
- FreeRTOS could handle this!
Option 2: Have an SPI task and I2C task with separate queues for each one. The blob of data can have a pointer to a mutex and a var address (essentially writing back data to memory) which could be synchronous. We can put this in a wrapper to make it alike to a synchronous I2C call. Can also do asynchronous tasks with extra caution.

Another design principle is to keep in mind that we have a lot of newbies! Make it easy and clear to write software.

Mitchell:

peripherals can all get their own tasks with shared memory to control tasks
Control tasks are acting like FSMs and each has their own event queue
- They can write back to their event queue
- Other tasks can also write tasks to other event queues

NOTE: All critical processing happens in a “critical task” with a high priority that will prempt everything else

° CAN will happen at regular intervals with acceptable latency

Jarvis:

Inforce scheduling on every task for limited runtime
for SPI and I2C same thing as RX and TX, the information can be sent and received but the actual task can send and receive
More OOP for task design such that there are
- constructors (i.e. init)
- destructors for a cleanup
- Abstraction for inheritance from a common parent class
Shared Memory: One struct with every info/pointer in it.
- Abstraction and inheritance for tasks accessing the shared memory
- self clean up for each task

MAKE THOSE DESIGN DECISIONS OR NO CAR!

Firmware