New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explicit masking and unmasking of hardware tasks? #621
Comments
We could e.g. have a primitive that disables a task/interrupt for a monotonic duration. In general, it is hard to ensure that a disabled task/interrupt will later be enabled, but monotonic gives you that guarantee. |
If you want the Something like: #[task(binds = EXTI)]
fn task1(cx: task1::Context) {
// ...
}
#[task]
fn task2(cx: task2::Context) {
// Disable task 1
let handle = task1::disable().unwrap();
// Keep it disabled for 1 second
task3::spawn_after(1.secs(), handle);
}
#[task]
fn task3(cx: task3::Context, handle: task1::TaskMaskHandle) {
// Re-enbable task1
drop(handle);
} |
Yea that approach would work as an /Per |
What @korken89 suggests is also viable assuming the |
For all practical matters the approach by @korken89 is going to cut it. So its all just a matter on where to draw the line of guarantees provided by RTIC. It can be seen as a programming error (on par with all other programming errors) to call |
If a user calls I think the bigger issue here is that this needs to be connected to the clearing of the associated interrupt somehow, else you'd only get the interrupt firing as soon as the masking is cleared. |
Aha, I was just thinking of the masking here, not how the underlying hw would trigger the interrupt, I don't see a generic way of handling that. Perhaps some embedded-hal trait would be required. |
A an aside, enabling and disabling task could be seen as affecting the RTIC model, essentially going from one task-set to another is a "mode-change", more on that at #23. |
This can be useful for delaying handling of edge-triggered interrupts gracefully in cases where lowering the interrupt line from within the handler can become cumbersome. You would mask the task from within itself and then unmask it once whatever handles it is done. Is it possible to do this with current RTIC? I guess that RTIC has enough knowledge to expose a safe interface for unmasking, but I'm not sure about how this might interact with locks.
The text was updated successfully, but these errors were encountered: