3 ms·

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?

SteelPh0enix 3y ago
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.
steveklabnik 3y ago
I don't see a super explicit one, but: https://activities.esa.int/4000140241 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!
- sesm 3y ago
  I hope they also publish the Lessons Learned report mentioned above, would be an interesting read.
topspin 3y ago
> Is there any rationale to this? It's all ARM Cortex? The RTOS doesn't care.
- SteelPh0enix 3y ago
  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.
  - topspin 3y ago
    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.
- xyx0826 3y ago
  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.
  - topspin 3y ago
    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.

SteelPh0enix 3y ago

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.

steveklabnik 3y ago

I don't see a super explicit one, but: https://activities.esa.int/4000140241 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!

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

topspin 3y ago

> Is there any rationale to this? It's all ARM Cortex? The RTOS doesn't care.

SteelPh0enix 3y ago
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.
- topspin 3y ago
  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.
xyx0826 3y ago
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.
- topspin 3y ago
  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.