Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using the Rust standard library with the NuttX RTOS

lupyuen.org

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Using the Rust standard library with the NuttX RTOS

#11

Post by MarkSweep »

loeg wrote: post #10

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?

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.

Re: Using the Rust standard library with the NuttX RTOS

#12

Post by the__alchemist »

fellowmartian wrote: post #8
the__alchemist wrote: post #2

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.

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.

Embedded ecosystem != RTOS

Re: Using the Rust standard library with the NuttX RTOS

#13

Post by the__alchemist »

vdjskshi wrote: post #5
the__alchemist wrote: post #2

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.

There's Hubris, https://github.com/oxidecomputer/hubris

That looks great!

Re: Using the Rust standard library with the NuttX RTOS

#14

Post by the__alchemist »

ost-ing wrote: post #9
the__alchemist wrote: post #2

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.

There is embassy and rtic, albeit they are quite lightweight

I use RTIC - I suppose this is a matter of categorization; I consider it an interrupt-wrapper that manages locks.

Re: Using the Rust standard library with the NuttX RTOS

#15

Post by the__alchemist »

AlotOfReading wrote: post #7
the__alchemist wrote: post #2

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.

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.

Those look great!

Re: Using the Rust standard library with the NuttX RTOS

#16

Post by dralley »

the__alchemist wrote: post #12
fellowmartian wrote: post #8

Earlier quoted context omitted.

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.

Embedded ecosystem != RTOS

There are plenty of options that are realtime-capable.

Re: Using the Rust standard library with the NuttX RTOS

#18

Post by the__alchemist »

sshine wrote: post #17

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 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.

Re: Using the Rust standard library with the NuttX RTOS

#19

Post by vdjskshi »

vollbrecht wrote: post #6
the__alchemist wrote: post #2

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.

The espressif ESP-IDF sdk that is using FreeRTOS underneath has rust + std support for quite some time now.

[dead]

Re: Using the Rust standard library with the NuttX RTOS

#20

Post by MarkSweep »

MarkSweep wrote: post #11
loeg wrote: post #10

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?

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 micr…

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.
Post reply on HN