13 tasks
- Battery charger logic, priority 1
- CLI, priority 1
- Front panel button reader, priority 1
- LCD controller, priority 1
- LCD backlight controller, priority 0
- I2C buffer descriptor handler, priority 2
- Power measurement task, priority 2
- LoRaWAN MAC manager, priority 2
- LoRaWAN message handler, priority 2
- RTC interrupt handler, priority 3
- Temperature sensor reader, priority 2
- User interface, priority 1
- Watchdog service, priority 3
There are also 3 queues, 2 timers, 3 mutexes, and 1 stream buffer used by these tasks.
I dont really consider execution time, or deadlines. My tasks just run until they are done and start waiting on something. If they run for too long they will be pre-empted by the scheduler. I dont think I have anything that is particularly time critical, but I treat RTC interrupts and watchdog related things with high priority because the RTC interrupts are used to time other things (via alarms that can be subscribed to), and the watchdog needs to keep the system running.
If I have anything close to a deadline I guess it is just that tasks must check in with a watchdog service at least once every 2 seconds to ensure that the system continues running and doesnt get reset. The watchdog service only clears the watchdog timer if all expected tasks have checked in.
As for assigning priorities, I dont have a particularly scientific method. I guess I figured that anything that is just doing “processing work” can run with low priority because it’ll get there eventually. Anything taking readings that the processing tasks rely on runs at a higher priority so that the processing tasks will ideally always have access to the latest values and/or will get their values in a timely manner. And the LCD backlight with no priority - who cares really.