sched_rt_runtime_us are meant to prevent freezing the system in case of runaway RT task. I wonder though, if it's possible to use a small value of
sched_rt_period_us to assure the task is running smoothly.
I have a simple job that requires no more than a millisecond or so of CPU time per call - say, driving a stepper motor over GPIO pins. I'd like to achieve no less than 100 cycles per second though, sustained. That's no more than 10% of the CPU time - discounting pre-emption and scheduler overhead.
I've read "very small values in sched_rt_period_us can result in an unstable system"1 but it wasn't said what order of magnitude counts for "a very small value". Can I reliably count on no more than 0.01s delay between calls to my program if I set
sched_rt_period_us to 10000 and return control (
sched_yield()) in timely manner?
The underlying CPU would likely be 850MHz ARM with a number of other tasks than said control, but none of them realtime or even required to "feel responsive", still, unlike with defaults of
sched_rt_runtime_us (95% out of 1s) I can't allow the RT task to sleep whole 0.05s at a time.