5 ms·

Using the Rust standard library with the NuttX RTOS

62 points by fork-bomber 2y ago

the__alchemist 2y ago
Interesting. RTOS is a major embedded ecosystem component that rust currently lacks. For anyone not familiar: NuttX is notable as the RTOS used on the open-source PX4 flight controller firmware, which is ubiquitous in commercial UASs.
- kbaker 2y ago
  https://arewertosyet.com/ https://arewertosyet.com/ has a big list. The definition of what is an RTOS and how much is in software vs hardware is a blurry area. https://rtic.rs/2/book/en/#is-rtic-an-rtos https://rtic.rs/2/book/en/#is-rtic-an-rtos
- vdjskshi 2y ago
  There's Hubris, https://github.com/oxidecomputer/hubris https://github.com/oxidecomputer/hubris
  - the__alchemist 2y ago
    That looks great!
- vollbrecht 2y ago
  The espressif ESP-IDF sdk that is using FreeRTOS underneath has rust + std support for quite some time now.
  - vdjskshi 2y ago
    [dead]
- AlotOfReading 2y ago
  Rust has some very competent RTOSes already like Tock / OxidOS and PikeOS. It's great to see support for NuttX, but it's Rust isn't completely lacking for options here.
  - the__alchemist 2y ago
    Those look great!
- fellowmartian 2y ago
  Actually, Rust embedded ecosystem exists and is amazing. It’s a breath of fresh air after having to use vendor SDKs from ST, Nordic, and even Raspberry Pi.
  - the__alchemist 2y ago
    Embedded ecosystem != RTOS
    - dralley 2y ago
      There are plenty of options that are realtime-capable.
- ost-ing 2y ago
  There is embassy and rtic, albeit they are quite lightweight
  - the__alchemist 2y ago
    I use RTIC - I suppose this is a matter of categorization; I consider it an interrupt-wrapper that manages locks.
junon 2y ago
Not sure if the author is the one who added support but it'd be great to get a somewhat in depth explanation as to how a target was added to Rust! The docs surrounding this kind of... leave a lot to the imagination.
loeg 2y ago
So like, taking a step back, is NuttX POSIX or POSIX-like (if there's a file namespace with /dev in it / you can use the Nix package)? And... does it have a global memory allocator (using stdlib packages that use alloc)? I can't really tell if this is an RTOS for microcontrollers or like, 32-bit ARM and don't have any background on it. And how does that interact with RTOS guarantees?
- MarkSweep 2y ago
  Yes, it’s POSIX-like, its system calls can even be implemented using interrupts like a normal OS (though that is optional). It has its own hardware abstractions and IOCTL interfaces around devices. Yes, it has a global memory allocator you obviously can use when processing interrupts. You can register your own interrupt handlers through the operating system, so you can still get real time guarantees. It does run microcontrollers. In the project I worked on we ran it on a STM32 device. The networking stack, threads, POSIX-like message queue, memory allocator, and synchronization primitives were fine. It has a little shell than runs on serial that can be useful debugging tool. It had a little file system that was easy to corrupt. Most of the other hardware abstractions we avoided and just talked directly to hardware. Personally if I were doing a project from scratch I would use a different RTOS that does not add extra layers of abstraction. But I understand the appeal of porting existing software to a POSIX-like target.
  - MarkSweep 2y ago
    Can’t edit and this should be obvious, but: I meant to say you CANNOT use the memory allocator in an interrupt handlers through. It takes a lock.
sshine 2y ago
Some years into Rust firmware with no classic RTOS experience: I get the feeling that embedded async Rust is a little like an RTOS library toolkit. Why do you need an OS abstraction when you can handcraft an embedded async runtime? Component reuse?
- the__alchemist 2y ago
  The boundaries are fuzzy, but I look at an RTOS as something you reach for when dealing with non-cooperative processes existing on the same device. I recognize that in C embedded code bases, RTOS is often used by default, regardless of this. Soemtimes it's to get a collection of higher level features, like an allocator, file system etc.
  - sshine 2y ago
    > non-cooperative processes existing on the same device That sounds like a real-world problem you could avoid by design. Is that because of 3rd-party vendoring? > Soemtimes it's to get a collection of higher level features, like an allocator, file system etc. I can relate to those needs, but I’m still unsure why not expose those in your runtime? Is embassy-rs with enough interaction between tasks an RTOS? Do you need an external API to be an OS? Do you need specific scheduling rules, or is it enough to know that certain tasks will never be blocked arbitrary long time?
    - the__alchemist 2y ago
      It's fuzzy. Re non-cooperative: Example: your browser and text editor both running at the same time on your PC etc. Re embassy: Not an RTOS in the way Nuttx, Free RTOS are etc, but if someone wants to apply the label, sure. The way most people use "RTOS", RTIC and Embassy are not it.
- bruckie 2y ago
  The classic role of an RTOS (realtime operating system) is to run applications that are, well, realtime. Like the anti-lock brake controller in your car, or the fly-by-wire system in the F-117A that compensates for its natural aerodynamic instability, or the motor controller for a 2-ton industrial robot that's whizzing around at many meters per second, or a pacemaker that's adjusting your heart rhythm, or the controller for some piece of a bazillion-dollar ASML EUV lithography system. These are applications where a failure to finish your computations on time has Majorly Bad Consequences. In these kinds of applications, you need hard realtime guarantees, which usually means things like: - everything is preemptive - lock order is very explicitly defined - memory is statically allocated - every computation (including interrupts) has a bounded (and guaranteed, and often formally proven) processing time Embedded async Rust (AFAIK) isn't suitable for building applications like these. Having said that, the meaning of "RTOS" has shifted over time to something like what you're implying: a collection of primitives that's slimmer than a "real" operating system that allows running an application on embedded hardware. And in that sense, embedded async Rust is a viable option. [1] https://en.wikipedia.org/wiki/Lockheed_F-117_Nighthawk#:~:text=Early%20stealth%20aircraft%20were%20designed,flight%20system%20to%20maintain%20controlled https://en.wikipedia.org/wiki/Lockheed_F-117_Nighthawk#:~:te...
cantrelate 2y ago
As a side note, Zephyr RTOS (hosted at the Linux Foundation) already supports writing applications in Rust https://github.com/zephyrproject-rtos/zephyr-lang-rust https://github.com/zephyrproject-rtos/zephyr-lang-rust

62 points by fork-bomber 2y ago

Interesting. RTOS is a major embedded ecosystem component that rust currently lacks. For anyone not familiar: NuttX is notable as the RTOS used on the open-source PX4 flight controller firmware, which is ubiquitous in commercial UASs.

kbaker 2y ago
https://arewertosyet.com/ https://arewertosyet.com/ has a big list. The definition of what is an RTOS and how much is in software vs hardware is a blurry area. https://rtic.rs/2/book/en/#is-rtic-an-rtos https://rtic.rs/2/book/en/#is-rtic-an-rtos
vdjskshi 2y ago
There's Hubris, https://github.com/oxidecomputer/hubris https://github.com/oxidecomputer/hubris
- the__alchemist 2y ago
  That looks great!
vollbrecht 2y ago
The espressif ESP-IDF sdk that is using FreeRTOS underneath has rust + std support for quite some time now.
- vdjskshi 2y ago
  [dead]
AlotOfReading 2y ago
Rust has some very competent RTOSes already like Tock / OxidOS and PikeOS. It's great to see support for NuttX, but it's Rust isn't completely lacking for options here.
- the__alchemist 2y ago
  Those look great!
fellowmartian 2y ago
Actually, Rust embedded ecosystem exists and is amazing. It’s a breath of fresh air after having to use vendor SDKs from ST, Nordic, and even Raspberry Pi.
- the__alchemist 2y ago
  Embedded ecosystem != RTOS
  - dralley 2y ago
    There are plenty of options that are realtime-capable.
ost-ing 2y ago
There is embassy and rtic, albeit they are quite lightweight
- the__alchemist 2y ago
  I use RTIC - I suppose this is a matter of categorization; I consider it an interrupt-wrapper that manages locks.

junon 2y ago

Not sure if the author is the one who added support but it'd be great to get a somewhat in depth explanation as to how a target was added to Rust! The docs surrounding this kind of... leave a lot to the imagination.

loeg 2y ago

So like, taking a step back, is NuttX POSIX or POSIX-like (if there's a file namespace with /dev in it / you can use the Nix package)? And... does it have a global memory allocator (using stdlib packages that use alloc)? I can't really tell if this is an RTOS for microcontrollers or like, 32-bit ARM and don't have any background on it. And how does that interact with RTOS guarantees?

MarkSweep 2y ago
Yes, it’s POSIX-like, its system calls can even be implemented using interrupts like a normal OS (though that is optional). It has its own hardware abstractions and IOCTL interfaces around devices. Yes, it has a global memory allocator you obviously can use when processing interrupts. You can register your own interrupt handlers through the operating system, so you can still get real time guarantees. It does run microcontrollers. In the project I worked on we ran it on a STM32 device. The networking stack, threads, POSIX-like message queue, memory allocator, and synchronization primitives were fine. It has a little shell than runs on serial that can be useful debugging tool. It had a little file system that was easy to corrupt. Most of the other hardware abstractions we avoided and just talked directly to hardware. Personally if I were doing a project from scratch I would use a different RTOS that does not add extra layers of abstraction. But I understand the appeal of porting existing software to a POSIX-like target.
- MarkSweep 2y ago
  Can’t edit and this should be obvious, but: I meant to say you CANNOT use the memory allocator in an interrupt handlers through. It takes a lock.

sshine 2y ago

Some years into Rust firmware with no classic RTOS experience: I get the feeling that embedded async Rust is a little like an RTOS library toolkit. Why do you need an OS abstraction when you can handcraft an embedded async runtime? Component reuse?

the__alchemist 2y ago
The boundaries are fuzzy, but I look at an RTOS as something you reach for when dealing with non-cooperative processes existing on the same device. I recognize that in C embedded code bases, RTOS is often used by default, regardless of this. Soemtimes it's to get a collection of higher level features, like an allocator, file system etc.
- sshine 2y ago
  > non-cooperative processes existing on the same device That sounds like a real-world problem you could avoid by design. Is that because of 3rd-party vendoring? > Soemtimes it's to get a collection of higher level features, like an allocator, file system etc. I can relate to those needs, but I’m still unsure why not expose those in your runtime? Is embassy-rs with enough interaction between tasks an RTOS? Do you need an external API to be an OS? Do you need specific scheduling rules, or is it enough to know that certain tasks will never be blocked arbitrary long time?
  - the__alchemist 2y ago
    It's fuzzy. Re non-cooperative: Example: your browser and text editor both running at the same time on your PC etc. Re embassy: Not an RTOS in the way Nuttx, Free RTOS are etc, but if someone wants to apply the label, sure. The way most people use "RTOS", RTIC and Embassy are not it.
bruckie 2y ago
The classic role of an RTOS (realtime operating system) is to run applications that are, well, realtime. Like the anti-lock brake controller in your car, or the fly-by-wire system in the F-117A that compensates for its natural aerodynamic instability, or the motor controller for a 2-ton industrial robot that's whizzing around at many meters per second, or a pacemaker that's adjusting your heart rhythm, or the controller for some piece of a bazillion-dollar ASML EUV lithography system. These are applications where a failure to finish your computations on time has Majorly Bad Consequences. In these kinds of applications, you need hard realtime guarantees, which usually means things like: - everything is preemptive - lock order is very explicitly defined - memory is statically allocated - every computation (including interrupts) has a bounded (and guaranteed, and often formally proven) processing time Embedded async Rust (AFAIK) isn't suitable for building applications like these. Having said that, the meaning of "RTOS" has shifted over time to something like what you're implying: a collection of primitives that's slimmer than a "real" operating system that allows running an application on embedded hardware. And in that sense, embedded async Rust is a viable option. [1] https://en.wikipedia.org/wiki/Lockheed_F-117_Nighthawk#:~:text=Early%20stealth%20aircraft%20were%20designed,flight%20system%20to%20maintain%20controlled https://en.wikipedia.org/wiki/Lockheed_F-117_Nighthawk#:~:te...

cantrelate 2y ago

As a side note, Zephyr RTOS (hosted at the Linux Foundation) already supports writing applications in Rust https://github.com/zephyrproject-rtos/zephyr-lang-rust https://github.com/zephyrproject-rtos/zephyr-lang-rust