Hacker News Reader

Comment by Animats | Hacker News Reader

That's reasonable. There's a lack of good, free OSs for the space above Arduino and below Linux on Raspberry Pi. That's the land of VXworks and QNX, which are good, but not free. So people end up running an entire Linux environment, with all its vulnerabilities, on something that doesn't need it.

View on HN

Yocto Linux can be stripped down to the bare minimum for embedded applications. You can reduce your attack surface by a lot. The advantage of Linux on embedded is your new developers are up and running immediately. Something not possible with all the rest of os/rtos. Additionally lots of packages for diagnostic utilities like iperf etc are available even for obscure processors that run Linux. As long as battery life isn't a concern, let embedded Linux be an overkill, the advantages are just too great.

> immediately

I love yocto, but ‘immediately’ can sometimes take a while!

There's a good number of them, although most aren't widely known outside of the embedded world.

Here's a list: https://www.osrtos.com/

That space is usually filled by FreeRTOS, no?

FreeRTOS, and zephyr now

FreeRTOS isn’t an OS. It’s a nice scheduler. Which is what the vast majority of people want and need when they think embedded.

Zephyr, is an OS. And imo will be eclipsed by embedded variants of Linux quickly as chips are coming up in performance. There is just no path for co-existence I see.

Zephyr, NutXX, and others aren't GPL, and that is a big deal for those folks.

Zephyr and Linux are not competing, generally. There are literally billion devices shipped annually in Zephyr niche - microcontrollers with under 1 MB RAM. This will continue the next 10 years - as for significant of the market cost reductions will go into power and radio improvements - not spending money on RAM and FLASH to run Linux.

It would be nice if any NASA engineer could weigh in on why they used Linux for that Mars helicopter instead of an RTOS like mentioned above.

https://spectrum.ieee.org/nasa-designed-perseverance-helicop...

Because it's easy to work with. Even low end processors support it as long as they have an mmu.

But why not a real-time OS? What if Linux schedules some unimportant job just as the helicopter is about to perform an important manoeuvre?

I don't know specifics of this helicopter, but:

1. You can apply patches which turn Linux into RTOS.

2. You can offload RTOS-specific tasks into separate simpler MCUs and use ordinary OS to communicate with them in a more relaxed way.

Linux can do real-time scheduling. Most of the patches for that have been merged into mainline at this point, but they've existed out of tree (with real use) for a long time.

Doesn't GNU/linux have optional real time extensions?

It looks like Linux is doing higher-level stuff, and the real-time is done by a pair of redundant MCUs and a FPGA.[0]

It's running F´ (F Prime) flight control software,[1] which can run under Linux, as well as on MCUs with no OS. I'm not sure on which processors it's running.

"The two redundant TI Hercules safety processors serve as the low-level flight controller (FC); each has dual-core lockstep ARM Cortex-R5F and ECC protected Flash and RAM. The two processors run in sync and are provided with the same clock and data by the FPGA, which handles all the sensors and actuators interface. The lockstep mechanism does cycle by cycle error detection. If a fault is detected, it signals the error to the FPGA; the FPGA switches to the other processor and power cycles the faulty one, so the flight control software continues to run without disruption.

At the heart of the helicopter avionics is a Field-Programmable Gate Array (FPGA). The FPGA implements the custom digital functions not implemented in software due to resource limitations of the processors (e.g. I/O or bandwidth limits), timing requirements, power considerations, or fault tolerance considerations. The FPGA device is a military-grade version of MicroSemi’s ProASIC3L, which uses the same silicon as the radiation-tolerant device from the same family. The FPGA perform all critical I/O to the sensors and actuators, and fault managment functions including detecting error flags from the MCU and hot-swapping to the functioning MCU in case of an error. The FPGA performs vehicle flight control including an attitude control loop operating at 500 Hz, an outer motor control loop, waypoint guidance, sensor I/O from the IMU, altimeter and inclinometer, and analog telemetry for current and temperature sensing. It is responsible for system time management, interfaces to the IMU, altimeter and inclinometer sensors. It implements the “inner” motor control loop used for the two brushless rotor motors and the six brushed motor servos (three at each rotor swashplate), as well as power management and thermal control functions."[0]

[0] https://rotorcraft.arc.nasa.gov/Publications/files/Balaram_A...

[1] https://nasa.github.io/fprime/

Ingenuity had a relatively shoe-string budget and leaned heavily on off-the-shelf components. It was also a technology demonstration rather than anything mission-critical, so it didn't need absolute reliability.

Which isn't to say that NASA wouldn't necessarily use Linux in mission-critical applications; there exist real-time patches for Linux.

Microsoft ThreadX is open source.

I guess minix is kinda in that space too.

FreeRTOS has already been mentioned, but there's also NuttX/Vela.

Isn't contiki-ng another one?

Micrium (uC/os-ii, uC/os-iii) is open source now. Best dead-trees book for an RTOS. I haven't shipped anything on it, so I have no other opinion.

https://github.com/weston-embedded/uC-OS3

Wouldn't something like tiny core Linux be the best compromise? Its the Linux kernal + bare essentials. You could probably harden it and modify it for this scenario

Reply on news.ycombinator.com