Maintaining the periodicity of tasks (from GSOC on Discord)

@Saksham asks:
Hi everyone :wave:, I’m building a small RTEMS-based satellite telemetry simulation where multiple tasks handle sensors, telemetry, and command decoding.
I’d like to ensure deterministic behavior between the Sensor Task (running every 1s) and the Telemetry Task (running every 5s).
What’s the best way in RTEMS to maintain this fixed periodicity — should I use rtems_rate_monotonic_period() or Clock Manager timers for tighter control?”

@Saksham I’m not authoritative but, it depends.

How long does your code run in the sensor task and the telemetry task? The typical granularity of ticks in RTEMS is 1/1000 of a second, how much time creep can you afford?

One approach is to just rtems_task_wake_after(1000), but that will give you a time slip of the task run time.

Another approach is to take note of the time before you start your processing (rtems_clock_get_ticks_since_boot()), do your processing, then rtems_task_wake_after(1000 - (nowTime-startTime)). Now you’re dealing with single tick time slip.

{new content}

A third approach is to use software timers to schedule your code to run each time the timer fires. This would give you time consistency to the single tick (I think) without the time slip error of the second approach. Now you’re just dealing with task switching arbitration and priorities.

Rate monotonic periods, as you mentioned, would be the logical choice to avoid needing to worry about time slip. It (along with most RTEMS-provided timing directives) does limit you to the granularity of the RTEMS ticks (default is 10ms, but can be configured).