Tags: Cardinality
Scheduling
RTOS scheduler manages which task should be in Running State.
Note: the scheduler configuration can be changed in the FreeRTOSConfig.h file.
By default, FreeRTOS uses a fixed-priority preemptive scheduling policy, with round-robin time-slicing of equal-priority tasks.
Priority
- Each task given an integer priority upon creation, priority usually based on time-sensitivity
- Task performing detumbling algorithm (flight path and velocity) very time-sensitive
- Task collecting telemetry data in background is not time-sensitive
- Idle task gets the lowest priority
- Fixed priority means scheduler won’t permanently change task’s priority once set; scheduler may still temporarily boost its priority due to priority inheritance
Pre-emption
- Preemptive means scheduler always runs highest priority task in the Ready or Running State; even if there’s a lower-priority task already Running, scheduler will change the Running task at the next tick interrupt
- “Handling an urgent situation”, the urgent task pre-empted original task
Interrupts
- High-priority situation which suddenly came up, forces system to pause and deal with it
- To make LED turn on when button has been pressed, we can use interrupt. This is a hardware interrupt which is triggered when the state of a pin (connected to button) changes
- Our Interrupt Service Routine, or ISR, defines how to deal with the interrupt. This is the function which is called whenever the interrupt is triggered. Our ISR would turn on the LED
- TLDR: Whenever button press happens, CPU switches focus to executing ISR, which turns on the LED
Task Starvation
- Scenario: If a high-priority task is always available to run, then a lower-priority task will never be able to run, starving those tasks of processor time
- To reduce the severity of this issue, we can use ==event-driven tasks==, which only execute when triggered by an external event
- Does not consume any CPU time when in Blocked State. By only executing when an event occurs, we minimalise task starvation and wasted CPU time
- To implement an event-driven task, we need a method to send an event from one task to another. The receiving task is in Blocked State while waiting for the event
Round-robin Time Slicing