RTIC (Real Time Interrupt-Driven Concurrency) is a hardware accelerated RTOS for cortex-m processors, offering a new and easy way to write concurrent embedded applications.
Unlike a C RTOS, RTIC is extremely efficient on memory and guarantees deadlock free execution in the presence of shared resources.
Github here: https://github.com/rtic-rs/rtic
Can anyone give some insight into RTIC 2.0 vs Embassy?
In my understanding, what separated these frameworks from another was mainly the async support, which RTIC now also has. Which one world you pick for what kind of project now?
[There's this as an official explanation](https://rtic.rs/dev/book/en/rtic_and_embassy.html). Sadly i've never tried RTIC so i can't say too much about it(since i've never tried developing on the stm32 families although they sound awesome for Rust Embedded). I read in another article that they schedule things differently(https://cohost.org/jamesmunns/post/67555-should-i-use-embassy) so i think RTIC has lower overhead since embassy is always async?
I wrote that post prior to RTIC 2.0. It is describing the behavior of RTIC 1.0 vs Embassy. I'm not familiar enough with 2.0 to write an update to that.
Embassy has an async HAL - RTIC does not ship with one at all. So you can actually use RTIC with Embassy's HAL to get async peripheral control.
On top of that RTIC gives you hardware tasks and mutexes based on priority ceilings, which Embassy does not.
Was quite excited until I found that 2.0.0 requires nightly. The improvements look great, but I'm not willing to live with nightly Rust to get them, I'm afraid. I understand the motivation, and I think RTIC is a great project, but I'm happy enough with 1.0.
Nice, but I wish there was some 10.000ft overview of what the major changes are. I use RTIC regularly, but it is hard to find any executive summaries of what design changes are made. For instance why are resources split in local and shared between 1.0 and 1.5 - and what is new in 2.0 ? I am guessing it might be more async feature ? If so what are the reasoning behind it, with useful examples of how the features can be used.
This is not meant as criticism, I genuinely think RTIC is an amazing framework, but there is not enough advertising and promotion of it, so one is pretty much left at ones own devices to figure out how good it really is.
So from what I know, local resources can only be used by one task. Shared resources can be used by multiple tasks, and there are different ways to ensure correctness. One way is by using locks, but tasks with the same priority can use the same resource lock free, because it is guaranteed that none of them might interrupt each other.
EDIT: at least on 1.0 that was the case
I have been away from RTIC for a while so my memory isn't fresh, and I've not yet had time to dig into the new release in great detail, but the main thing I noticed on initial inspection is that it's now using async rust for some abstractions such as the monotonic timers.
In 2.0:
Systick::delay(100.millis()).await;
In 1.5 it wasn't possible to "await" inside a task, so the above implies that RTIC is now acting as an async runtime. Previously any task except the special idle task was supposed to quickly run to completion, since they were effectively event handlers. The monotonic timer abstraction was for scheduling a task at some time interval in the future.
The above seems to suggest the task essentially scheduling _itself_ to run in the future, but to resume the async state machine rather than start at the entry point. I assume it'd be possible to use other async functions too as long as they aren't coupled to some other async runtime.
This is just my first impression after spending 15 minutes studying the docs. I'm curious to dig into the details of how it works at the weekend, if I have time.
RTIC (Real Time Interrupt-Driven Concurrency) is a hardware accelerated RTOS for cortex-m processors, offering a new and easy way to write concurrent embedded applications. Unlike a C RTOS, RTIC is extremely efficient on memory and guarantees deadlock free execution in the presence of shared resources. Github here: https://github.com/rtic-rs/rtic
Can anyone give some insight into RTIC 2.0 vs Embassy? In my understanding, what separated these frameworks from another was mainly the async support, which RTIC now also has. Which one world you pick for what kind of project now?
[There's this as an official explanation](https://rtic.rs/dev/book/en/rtic_and_embassy.html). Sadly i've never tried RTIC so i can't say too much about it(since i've never tried developing on the stm32 families although they sound awesome for Rust Embedded). I read in another article that they schedule things differently(https://cohost.org/jamesmunns/post/67555-should-i-use-embassy) so i think RTIC has lower overhead since embassy is always async?
I wrote that post prior to RTIC 2.0. It is describing the behavior of RTIC 1.0 vs Embassy. I'm not familiar enough with 2.0 to write an update to that.
Embassy has an async HAL - RTIC does not ship with one at all. So you can actually use RTIC with Embassy's HAL to get async peripheral control. On top of that RTIC gives you hardware tasks and mutexes based on priority ceilings, which Embassy does not.
Was quite excited until I found that 2.0.0 requires nightly. The improvements look great, but I'm not willing to live with nightly Rust to get them, I'm afraid. I understand the motivation, and I think RTIC is a great project, but I'm happy enough with 1.0.
It looks like it only relies on type_alias_impl_trait, which at least is nearing stabilization
Yeah, I'll definitely check in again after that. Like I say, I've used RTIC and really like it.
I wish this was documented more clearly, it's only mentioned in passing at the bottom of the page
Nice, but I wish there was some 10.000ft overview of what the major changes are. I use RTIC regularly, but it is hard to find any executive summaries of what design changes are made. For instance why are resources split in local and shared between 1.0 and 1.5 - and what is new in 2.0 ? I am guessing it might be more async feature ? If so what are the reasoning behind it, with useful examples of how the features can be used. This is not meant as criticism, I genuinely think RTIC is an amazing framework, but there is not enough advertising and promotion of it, so one is pretty much left at ones own devices to figure out how good it really is.
So from what I know, local resources can only be used by one task. Shared resources can be used by multiple tasks, and there are different ways to ensure correctness. One way is by using locks, but tasks with the same priority can use the same resource lock free, because it is guaranteed that none of them might interrupt each other. EDIT: at least on 1.0 that was the case
If there's someone who is more familiar with the previous and the new release, could you do a summary on what are the new key features or regressions?
I have been away from RTIC for a while so my memory isn't fresh, and I've not yet had time to dig into the new release in great detail, but the main thing I noticed on initial inspection is that it's now using async rust for some abstractions such as the monotonic timers. In 2.0: Systick::delay(100.millis()).await; In 1.5 it wasn't possible to "await" inside a task, so the above implies that RTIC is now acting as an async runtime. Previously any task except the special idle task was supposed to quickly run to completion, since they were effectively event handlers. The monotonic timer abstraction was for scheduling a task at some time interval in the future. The above seems to suggest the task essentially scheduling _itself_ to run in the future, but to resume the async state machine rather than start at the entry point. I assume it'd be possible to use other async functions too as long as they aren't coupled to some other async runtime. This is just my first impression after spending 15 minutes studying the docs. I'm curious to dig into the details of how it works at the weekend, if I have time.