Gives the word "weights" a more literal meaning.

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

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.

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.

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

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.

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

We believe it offers a new combination of features that might be interesting:

- It supports writing applications as both async and threaded code, mix-and-match.

- It helps a lot in reducing boilerplate. Networking, threads & multi-core suppport, random numbers, flash storage are all readily available, with a sane and usually customizable default configuration.

- It helps writing portable applications. Ariel applications start out being fully ported to all supported boards, then get specialized. This might be interesting to library authors as well, for simplified testing on multiple platforms.

- It helps handling the little differences between MCUs. E.g, rustc target configuration, using `defmt` or not, `probe-rs` or `esp-flash`, are just build system flags. Ariel OS' meta build system handles the necessary Cargo and tooling configuration.

- It integrates `embedded-test` for turn-key testing on real hardware.

- It's all Embassy & smoltcp & embedded-hal(-async) & embedded-nal(-async) & ... under the hood, and it is easy to not use the abstractions if needed.

What we're working on right now or very soon:

- building on stable Rust

- BLE support

- a nice DSL for defining boards, aiming at no-code porting of applications

- low power handling

- a native "port" where Ariel can run as Linux/OSX application

We're at the beginning, but think that Ariel OS might already be useful to many of you, especially for reducing boiler plate and getting started more quickly.

Let us know what you think!

Join us on Matrix in https://matrix.to/#/#ariel-os:matrix.org.

Comments URL: https://news.ycombinator.com/item?id=43533481

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=41265163

Points: 35

# Comments: 7

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.

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.

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.