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.
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.
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.