Hacker News Reader

Comment by hlandau | Hacker News Reader

A bit surprised to see a common MCU used here rather than one designed for safety applications (e.g. TMS570). Is there any rationale to this?

View on HN

I don't see a super explicit one, but: https://activities.esa.int/4000140241

> The proposed activity is to evaluate the usage of Rust programming language in space applications,

> The design of the system will be guided to support potential future qualification activities.

> This application will showcase the viability of the developed RTOS and provide input to a Lessons Learned report, describing the encountered issues, potential problem and improvement areas, usage recommendations and proposed way forward.

Looks like it's not intended for real applications, but instead to gain some experience. What better way to ensure that you don't ship the prototype than by doing it on hardware that is similar but different enough to ensure that it won't be used in production.

Just a guess though!

I hope they also publish the Lessons Learned report mentioned above, would be an interesting read.

Hello, one of the devs of Aerugo here.

The rationale is rather simple - SAMV71 is used in critical applications (it has some functional safety certificates), and I have past experience of writing critical software for it at N7.

> Is there any rationale to this?

It's all ARM Cortex? The RTOS doesn't care.

The choice of microcontroller matters. Functional safety qualified MCUs might have the same CPU core but is built in a way that minimizes interference or common cause of failures between peripherals. The software needs to be written closely following the safety manual of such a MCU to make maximum use of those safety guarantees.

There are several safety critical Cortex implementations around, with features like multi-core lock-step operation that is largely transparent to the RTOS (or whatever) beyond fault handling. There isn't some vast gulf between the ATSAMV71Q21 they've piloted this on and whatever space rated device and requirements you imagine.

While our RTOS in fact doesn't care about it, because it's up to the user to implement the abstraction for the platform, the bigger issue is Rust support for more exotic architectures used in space - for example, SPARC (LEON3), which we'd like to consider for a Rust project, but it's compiler support seems relatively bad.

That seems like an insoluble problem: for every fault tolerant SPARC device someone slices off a wafer the ARM crowd ships a truck load of chips. SPARC will never have the mindshare necessary to polish the LLVM/Rust stack to parity.

Reply on news.ycombinator.com