kaspar030

I set all my Rust LLM written projects to 'unsafe=deny'. Not sure why not everyone is anticipating your comment.

"Build internal tools on Rails in hours, not sprints"

Not so hard to mention what your tool actually does.

So now they have to print the weights and sell as book in order to export them!

Gives the word "weights" a more literal meaning.

Part of the C protocol implementation is generated, and that generator chose the JSON parser. As it worked and there was plenty of memory left on the MCU, it was kept.

We're mentioning this in the paper: "The heap is entirely attributable to Parson's dynamic allocation of JSON tree nodes; as memory usage minimization was not a key goal, we kept Parson (the JSON parser used by the PNPL code generator by default), noting that there are less memory heavy options that do not require a heap at all."

In Figure 12, they simply stop optimizing the code once desired rate is reached.

Yes. The goal was to handle the maximum data rate of the used sensor, and stop there. Time was limited on both ends.

Just at the end of the project the Rust firmware gets over a third performance boost, most likely from their OS developers.

The ST intern found those boosts all by himself. They compared the exact MCU & peripheral initialization of the C and Rust firmwares, tightened I2C timings (where STM Cube has vendor tuned & qualified values), and enabled the MCU's instruction cache, which somehow is not default in Embassy's HAL. We were quite impressed actually, the last days before the deadline were quite productive, optimization wise.

Yup. Large companies have interesting rules sometimes.

The used protocol was part of the requirements, so the existing web service could be re-used.

1. So Ariel OS is based on Embassy - IIUC I2S and CAN has some support upstream. That can be used already, although not using Ariel's usually fully portable APIs.

2. Well, ST has released official Rust drivers for a bunch of their sensors. They're built on embedded-hal(-async), so can directly be used with Ariel OS. There is probably more.

"The open source code will be published on https://github.com/stm32-hotspot/ for the final version of the paper."

-> paper is not final. And IIUC ST will be releasing the code at some point.

You mean with the "two teams" that were tasked to develop the C / Rust versions?

Yeah of course. Then again - they were one person teams, where the C "team" had years of experience in stm32 / embedded C / stm32 cube development and churned out that handwritten state machine in just days. The Rust "team" was a pre-masters intern with only minimal embedded Rust experience. They ran into all the pitfalls with (async) embedded Rust, but corrected towards the end.

"Customers are asking for Rust" would probably be the reason why ST is looking into this.

One of the author's here, if there are any questions!

Also check out Ariel OS (https://ariel-os.org), which is built on top of Embassy.

Top end CPUs are about 3x faster than the comparable top end models 3 years ago

I wish that were true, but the current Ryzen 9950 is maybe 50% faster than the two generations older 5950, at compilation workloads.

I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.

Also, the Ryzen 9 3950X. It has a bit more punch than the 3900X, for ~200$ more.

I built one, a Noctua NH-D15 can cool it at 16*4ghz at 700RPM, so basically almost inaudible even at full load.

No ECC, though.

Technical differences aside:

RIOT is the only mentioned OS with a copyleft license (well, LGPLv2.1), trying to create a FOSS alternative in the embedded/IoT space.

With permissive licenses for embedded software, open source usually ends at the factory.

Original author of RIOT here.

Using RIOT you'll get at least multi-threading, power management, a choice of network stacks, a bunch of community-supported libraries and drivers with an extensive test suite, ...

Also, you'd have a clear upgrade path, as applications written for RIOT's API will compile (almost) unchanged for all of RIOT's target hardware. Arduino becomes to slow? Change some pin defines, re-compile for a fast Cortex-M. Intrigued by RISC-V's openness? Recompile for the Hivife1 to find out it's real-world performance with your application.