Building a 3D safety sensor with Rust | Hacker News Reader

Building a 3D safety sensor with Rust

sonair.com

104 pointstorotime25 comments

I'm writing firmware for my espresso machine in Rust right now and I was also pretty blown away at how easy it is. I am writing code across two micro-controllers (I'm re-using existing hardware) and I am using no-std RTIC2+Embassy on an STM32 inside machine and std Embassy on a ESP32-S3 on the outside of the machine. I don't know C++ (although C++ for embedded would probably have been fine, except I don't like C++ anyway) and it would have been a lot more work to get this working in C.

Using Rust I get so many static guarantees that it makes it trivial to get things working. And things have matured a lot since the last time I checked about a year ago.

Things are still a bit rough, for example I am maintaining my own version of embassy-stm32 so I can make a few things work the way I want to, but it's not really a problem for an embedded project.

Developing rust for xtensa is also a bit painful at times, but it still beats writing C or C++.

Moreover, RTIC2 allows me to write high performance real time code the way I would have written it in C with a mountain of boilerplate removed from sight just down to the way async works in rust as well as the things RTIC handles.

Just wondering why you decided to use Embassy and RTIC? Was there any specific reasons? I’m doing an Embassy project on an esp right now so wondering if you have any issues or insights worth mentioning?

From my understanding Embassy and RTIC are two different models of concurrency so I’m not sure of any benefit of using both at the same time.

So, on the STM32 (which is the only place I am using RTIC), I don't use the Embassy executor. I just use the embassy-stm32 hal crate for all my peripherals and embassy-futures for some of the executor-agnostic no_std and non-alloc futures utilities.

A lot of embassy (except quite unsurprisingly, the executor) is executor agnostic. In fact, I think it might be _all_ of embassy that is executor agnostic. There's some information here: https://rtic.rs/dev/book/en/rtic_and_embassy.html

While my code is not public yet, here is an example (written by someone else) of STM32 code using the embassy-stm32 I2C peripheral wrapper with RTIC:

https://github.com/andresv/rtic_arbiter_demo/blob/master/src...

Interesting! Thanks for sharing, Rust always seems to have something new to learn.

I tried using async rust on my esp32 last year, and though i got some functionality working, any little victory was always followed seconds later by big, productivity halting, hard-to-overcome hurdles. Im glad people smarter than me are making it happen

No mention of Ferrocene other than a "further reading" bullet point at the end. Are they using it? Does that help with respect to getting a device safety certified?

From https://ferrocene.dev:

> ISO26262 (ASIL D), IEC 61508 (SIL 4) and IEC 62304 available targetting Linux, QNX Neutrino or your choice of RTOS.

The article also mentions one of those standards:

> Sonair is developing a safety-certified device (IEC 61508 and SIL2).

Disclaimer: I’m one of the founders of Ferrous Systems, the company behind Ferrocene.

One of the goals when certifying Ferrocene was that it serves as a drop in replacement for rustc. So while we’re happy if you start out building your product with Ferrocene (and have made our pricing model compatible with that) - going the route of “rustc first, then slot in Ferrocene” is entirely supported. There are also sometimes good reasons to pick that approach - Ferrocene is much more limited in terms of target support and while we may have a timeline to deliver the target you need in the qualification level you need, we might not ship it yet (though we usually can enable Support relatively quickly)

That said, I’m quite confident that using Ferrocene gives you a faster route to certification than trying on your own. I’d not be surprised if we hear from them.

We are already talking :)

Really glad you all are out there doing what you do. In my opinion it is the most important thing for Rusts long term success and longevity. No clue what the costs are like for running on Ferrocene but maybe one day I will have a project that'd benefit from it.

So the cost for the basic level (quality managed, one target architecture) are pretty low - about 240 EUR/human per year. CI runners are free. Certification material is billed separately to allow speculative and experimental usage. You only pay for it if and when you need it.

A lot of projects can benefit from that level of assurance since we have a different support tier policy than upstream Rust, that is: we treat different targets as Tier 1. And you get signed installers for windows etc.

Also, with the upcoming CRA legislation, using a quality managed toolchain will make your life easier - one part you don’t have to manage.

That is incredibly reasonable pricing thank you for being open to sharing. Hoping one day we talk from a business perspective. Cheers

Thank you for your work on Ferrocene! I particularly appreciate that you're open about the price, at least for a starter license.

We're using Rust for space applications, and while we don't have a need to certify our software yet, we'll keep Ferrocene in mind for the future.

EDIT: Oh, the Ferrocene compiler is fully open source. I didn't expect that!

We’d also be more open about the rest of the plans, but it’s a hard information design problem more than anything else - the website desperately needs an update. Too much to do and too little time. If I just didn’t spend so much time around here ;)

The compiler being open source is not the big thing - it’s mostly upstream rustc with very little modification. However, all of the safety manuals are open too, so you can see what you’ll get.

I see that you’re from Berlin - if you’re interested in a chat, ping us.

> Too much to do and too little time. If I just didn’t spend so much time around here ;)

Heh, very relatable :)

> I see that you’re from Berlin - if you’re interested in a chat, ping us.

I also just saw you're based in Berlin. Will definitely ping you when I'm back. Particularly interested in your "Rust Experts" offering.

One question about Rust safety certification in general:

How do you deal with dependency sprawl? For example, if you write a basic async program with Tokio and friends you may end up depending on >200 crates. Would you our your clients certify them one by one? Are they much more picky with which dependencies they "take on"?

Dependencies. Hard topic. The question is less about the numbers, but rather in the amount of code you pull in. In the end, every line needs to be certified. The team that wrote sudo-rs blogged about their approach here https://www.memorysafety.org/blog/reducing-dependencies-in-s...

Essentially, expand your use for initial development and whittle down later as much as possible.

That said, Tokio is not going to be a good certification candidate - but that’s a topic for a longer conversation. (TL;DR: The Tokio project has aims and goals that are good for their use, but problematic when it comes to writing safety certified software)

That makes a lot of sense, thanks!

I'm interested in knowing how they achieve requirements traceability to code and the requisite level of code coverage (certain SILs require MC/DC coverage, which usually requires expensive tooling). Also which hazards they identified and their mitigations.

They are aiming for SIL 2 which to the best of my knowledge requires no MC/DC coverage. MC/DC support in rustc is being worked on, but I would not expect the required features to land before end of 2025 or even mid 2026.

I love articles like this. Team of engineers try something new to them and win long term. All of the bullet points were the experience I've had in my professional and hobby projects. It's a great language and ecosystem. There is a lot of hate on here about the technology but the proof is in the pudding.

Now how to build a web site that doesn't keep 60% of the screen as whitespace is the next frontier of software.

Well, that, and writing articles that aren't mostly content-free.

this is me or the web is broken ??? (all text align to the right side)

I see the same thing (Safari, macOS 15.2). It seems to be a design choice.

> The writing has characteristics of content that might have been partially generated or assembled from multiple sources without smooth transitions between sections. While the technical information about Rust seems solid, the narrative structure and voice consistency aren't what you'd typically expect from a single-author technical blog post.

Arms race!

> Spam-filters, actually. Once they became self-modifying, spam-filters and spam-bots got into a war to see which could act more human, and since their failures invoked a human judgement about whether their material were convincingly human, it was like a trillion Turing-tests from which they could learn. From there came the first machine-intelligence algorithms, and then my kind.

https://craphound.com/overclocked/Cory_Doctorow_-_Overclocke...

"Asking an LLM what it thinks about an article" is the new "judging a book by its cover".

Except it's even dumber.

Where is that first quote from?

Reply on news.ycombinator.com