Open perlindgren opened 5 months ago
As a comment, in RTIC we can easily support this view, by allowing the idle
task running at the lowest priority to return. The current default behavior of omitting idle
is running an infinite loop in main, preventing main
from returning, but this could be implemented as a returning main.
Typically in embedded programming one assumes the application to be non returning. In Rust this is manifested in the signature of the entry point, and using RTIC in the signature of the Idle task.
This brings the implication that the system is conceptually live even when no work is at hand. The common mitigation is to provide some sort of WFI (wait for interrupt and/or WFE (wait for event), putting the core/system to sleep awaiting some "event" (either external or internal, e.g., timer).
It works by halting the PC (potentially the core clock), and retains the current state so that the "main" can continue.
While this works it is clearly sub-optimal, as the state needs to be retained during the sleep.
RISC-V RT could propose an alternative model where "main" is allowed to return, and on return puts the system to sleep (similar to WFI/WFE).
This approach would be backwards compatible to current non-returning "main" as you can still support WFI/WFE if a continuation is desired.
For systems leveraging this approach, we gain an interrupt priority level (0), and can tie a handler/task to that. We can also gain power, by not keeping the state live during the sleep. (State will in any case start fresh on behalf of the interrupt waking up the system.)
A potential problem is that an optimizing compiler would optimize out the complete application, so this must be ensured not to happen somehow.
Any thoughts?