Hacker News Reader

Comment by TheCapeGreek | Hacker News Reader

For a layperson, is this just for older style ECUs controlling various car functions, instead of e.g. electronic dashboards?

Basically, will this be also usable for more modern vehicles (say 2015+) that have been highly digitized, or is the project scope much smaller?

My understanding is that beyond the rise of EVs, the longevity of vehicles of the last decades is in question as they use more and more computerised controls, and their parts becoming rarer on top of the proprietary software controls. So beyond replacing just the ECU, keeping modern cars alive as they age and even become classics is a valuable task.

I believe the concerns of the digital era losing historicity due to the ease of bitrot translate to vehicles as well.

View on HN

It won't be something you as a layperson can just take and run in your car, like you would Linux on an old laptop. The HW is pretty diverse and is tightly coupled with the car. It's more like something car makers can use to build on top of in order to quickly and safely bring up an ECU. People who worked with, for example, AUTOSAR stacks on modern ECU's know how much of a pain bringing up even just CAN communication can be.

I share your concern about bitrot and longevity in modern cars, and this could help, but it would still not be something someone could just do in their garage, you'd likely need more resources than that.

Yes, new cars are evolving in terms of ECU architecture, and we are targeting small chips for two use cases:

First - as "edge components" get smarter - you still have small microcontrollers all over the car (for example - you need a local MCU and a complex PCB for running a headlight with dozens of LEDs with minimum wiring to a central command unit);

Secondly - you now have multi-core, multi-arhitecture controllers - and you need small OSs for some of these cores in order to run embedded apps efficiently.

Rust is certainly an attractive option, but the support for MCUs used in automotive seems weak (because the variety of LLVM backends is less than that of gcc). What do you think about this? Will you use a GCC-based Rust compiler (e.g. gccrs or rustc_codegen_gcc) or your own LLVM backend?

I’m not in automotive, but I am interested in this too. Which MCUs are you thinking of?

Not OP, but just a set of MCU arch common in automotive that you'd have to bend a bit to compile Rust for:

- Renesas RH 850/v850 - there is a gcc but not a llvm backend

- RL78 (I think this is kind of dieing though)

- Infineon Aurix Tricore (Hightec has a compiler for it)

- PowerPC was pretty popular but I did not see it that much lately.

Thanks! Always interested in digging into details :)

There’s been a tremendous amount of interest in Rust for automotive over the past few years, but it’s a hard world to learn about unless you’re in it.

I'd like to add ST's Stellar MCU's: https://www.st.com/en/automotive-microcontrollers/stellar-32...

Looks like Oxid has a demo using these proc's: https://www.linkedin.com/feed/update/urn:li:activity:7041723...

We did have a demo using the Stellar MCU's. :)

But they weren't on my list because those have ARM cores and the support for those in Rust is quite good.

I think this is for component manufacturers, a bit like Arduino IDE for windshield wipers and left front blinker circuits.

Reflashing automotive ECU with open source firmware isn’t going to make a lot of sense, many still use OTP ROMs and even sometimes real hardwired ROMs.

Reply on news.ycombinator.com