1–10 of 64 posts
I have good understanding of Rust and soon will need to program ESP32 chip. Write a driver and and http/tcp api on it.
Currently I jave seen mixed messages about Rust in embedded. Ecosystem moves fast, but semms like old C/C++ devs stay with their lang. So I'm curious what Rust devs have to say abou it.
I love it so far. There are still some rough edges in the tooling, but overall I'm very happy. The resulting binaries are much larger than C projects, but I'm also opting into a lot of functionality you probably wouldn't always need in smaller environments.
Our company builds a wearable device using an NRF5x chip, and our firmware is written in C. We are moving to Rust for our newest device, in order to run graphical output and RT operations. It is looking pretty sweet!
Our company builds a wearable device using an NRF5x chip, and our firmware is written in C. We are moving to Rust for our newest device, in order to run graphical output and RT operations. It is looking pretty sweet!
And why not Carbon? :-)
Not exactly embedded but I'm writing an operating system kernel in Rust, having done so previously with C. I love it so far. There are still some rough edges in the tooling, but overall I'm very happy. The resulting binaries are much larger than C projects, but I'm also opting into a lot of functionality you probably wouldn't always need in smaller environments.
Our company builds a wearable device using an NRF5x chip, and our firmware is written in C. We are moving to Rust for our newest device, in order to run graphical output and RT operations. It is looking pretty sweet!
And why not Carbon? :-)
> Why not Rust? If you can use Rust, ignore Carbon.
So that's probably one reason.
[1]: https://github.com/carbon-language/carbon-lang/blob/trunk/do...
* Managing build configurations - I use CMake to build a single application for multiple hardware platforms. This is accomplished almost exclusively through linking, e.g., a single header file "ble-ncp-driver.h" with multiple "ble-ncp-driver.cpp" files for each target platform. I call this the "fat driver" approach which has proven to be easier to work with than creating a UART abstraction or ADC abstraction. Does rust's package system address this?
* Automated device testing - fluid leaks are similar to bugs in software. They are systemic in nature and cannot be easily understood through static analysis. We spent equal time maintaining a test bench as product development.
* Preemptive operating systems - more trouble than they are worth. Often, devs get bogged down writing messages queues to pass items between task contexts and timing analysis requires detailed event tracing.
Given I don't see teams struggle with memory ownership (easy to do if you never, ever malloc), what else can rust bring to embedded dev?
Tool chain wise:
ESP32 support is very recent and still based on the C tool chain and this makes it very fragile (you can break your environment easily and it is never clear how to recover except recompiling the entire tooolchain from 0)
Arm is a little better because the support is native.
The community is trying to make a generic embedded Hal platform API and implement it for specific devices. And it is pretty bad: almost no documentation, very few examples, tons of autogenerated code where you need to come back to the C world to understand the actual concepts.
Once you start to get going Rust is a blast to program in and the generated code is pretty efficient.
A small project I shared to help people starting on a raspberry pi clone (lilygo): https://github.com/gbin/rp2040-mandel-pico