Extended timing semantics

[perlindgren]

As of today task do not carry deadline information and inter-arrival time. These are required for response time analysis and automatic priority assignment. This was part of the original work on RTFM, and in an experimental branch of RTFMv3 I had the deadline and inter-arrival info implemented and working.

Now the syntax has changed (and the internals as well, all for the better;)

One could think of adding to the task attribute:
#[task(..., deadline = D, inter-arrival = I)]

Where D, I is given in some suitable time format matching monotonic.
Priorities could be derived ordered by deadline (shorter deadline, higher priority).

If no deadline is given, then the deadline can be computed from the inter-arrival (rate monotonic). There are cases though where the deadline will be shorted than the inter-arrival (e.g., emitting IO with low jitter), or the opposite, where we can allow buffering of events processed under relaxed timing requirements)
(This is 101 scheduling for real-time systems, nothing fancy/new and certainly not my invention.)

An open question is how automatic priority assignment could co-exist with manual assignment. (This we never settled in the original RTFM work/implementation.)

Perhaps another attribute could be used to declare the range of assignable priorities.
#[rtfm_priorities(5..)]

Allowing 5..(1<<NR_PRIO_BITS)) to be used by RTFM for automatic assignment, and the lowest priorities reserved for manual assignment (1..=4) or equally (1..5), using Rust ranging syntax. 0 is the idle priority.

#[rtfm_priorities(5..=15)]
Would allow the user to manually assign priority 16. (Amounting to an interrupt disable, assuming we have 4 priority bits).

I guess that would cover the typical use cases:
We have some real time tasks with known (minimum) inter-arrival. These are typically our IOs, like serial, ethernet, etc. where transmission speed stipulates the inter-arrival.
In addition, we have application logic, with hard real-time requirements, e.g., periodic control loop.
These will all be annotated with the corresponding timing data and assigned by RTFM to priorities 5..=15 (for the example above).

Besides real time tasks, we can have other application logic, running without explicit deadlines, here fixed priorities makes sense, as we can use that to relate their importance. E.g., it may be more important to update a control model, than to emit logging data (or vice versa).

And finally, we might have some real-high priority things going on, which must be dealt with immediately (but does not have any sensible deadline), e.g., some panic button that should immediately put the system in a fault mode.

The last case might be solved by just putting a very short deadline (shortest among all), to give it the highest priority, but that is not really robust, as at some point we might want to change some other deadline associated (or inter-arrival, with derived deadline), and then it may no longer be the shortest.

Perhaps setting a deadline of 0, could indicate that it must be hardwired to the highest priority, that is of course robust.

Such tasks are usually left out of the overall schedulability analysis as they indicate an abnormal condition, for which the inter-arrival should be infinite under normal operation. In a related post, I touched upon the problem with mode changes, this can be seen as such a mode change. (If given a deadline, we can still check the response time for the abnormal case.)

There is also another crux:
If we have tasks without inter-arrival information (like the low priority logging and application logic), we cannot do full blown schedulability analysis. That makes full sense, since these tasks are "best effort", and we have a mixed-critical system. Typically response time analysis for higher priority tasks would not be possible, but RTFM is underpinned by SRP providing a solution. SRP ensures single non-transitive blocking, so we just have to take into account (for each resource) maximum critical section. Thus, even under overload we can still ensure that our real-time tasks will meet their deadlines, ain't that a blast!

Would allow