Hacker News Reader

Comment by adhoc_slime | Hacker News Reader

I've been working on some rust code for the rp2040 mcu as my entry into rust and embedded programming and I think it has killed my enthusiasm for both rust, and embedded. I want to work on an esp project but I feel so burned right now that I am just thinking of dropping rust all together.

I'm actually really happy to see Espressif progress on this, I just want to throw how I'm feeling the void.

View on HN

I think you have to be careful not to stretch your learning budget too thin. Coincidentally, I recently started tinkering with embedded as well and decided against using Rust (not new to me) for it because I prefer the well trodden path when first getting started in something. There is plenty of opportunity to venture out later.

Similar to the times when boards with USB support weren't a thing, where you had to program it over serial. Now with USB it's so easy to program these boards, that you can jump right to the thing which interested you from the beginning, without having to deal with things like first flashing an Arduino which then served as a programmer.

I currently don't see any benefit of using Rust on a MCU if you're a hobbyist, but that doesn't mean that it isn't a wonderful language to use on a Raspberry Pi or anything above that.

Maybe give Toit (toitlang.org) a try.

We have been working on it for a few years now, and it gets more and more complete. Recently Espressif started contributing as well (and added Toit to their esp-idf installer).

Some selling points of Toit:

* modern language

* very fast execution for a dynamic language. (more than 10x faster than micropython)

* consistent libraries.

I'll give it a look over and see if I can get a blinky.toit going.

Just want to add I’m very impressed with Toit.

I’ve been using ESP-IDF for 2 years and have 100k lines, but I would love to consider Toit in the future.

Care to share the specifics? Embedded programming in of itself is difficult and tedious, and unless you really love it, professionally makes you less money than much easier forms of SWE. But I'm curious to understand if you are mad at embedded or mad at Rust.

In general I'm not mad, the learning curve of both combined was a lot and beat me down, and the rp-hal library is still beta and ironing out its kinks. I experienced a lot of frustration (and still do) around USB HID implementations. Simple things I thought would be given, eg sharing an rp-hal I2C bus was made tedious by rust's ownership rules.

I think the matter of embedded programming being difficult was just exacerbated by this. I'm just a hobbyist in the embedded world, and I really find it fun and interesting, but as a hobbyist I only have limited time to be working on my project and I want something to show for my time, besides rustc messages about my unsafe code.

Depending on your needs, you may be able to get away with using e.g. MicroPython on your ESP. Gets you embedded (light), but obviously not the Rust part.

It's been pretty easy to work with, compared to "normal" embedded work with C that in my experience is a lot of tedious work to learn and set up before you get some momentum and can start focusing on the actual application.

If you want to do some simple (or semi-complicated) stuff, there's no easier way than MicroPython. Just flash and run, done.

I think the issue here is being new to Rust. I moved to embedded Rust after using C and it's a breath of fresh air to have the type system catch so many things for me. But I was already proficient in Rust before I made that move.

The RP2040 in particular is pretty great though, being able to flash firmware with `cargo run--release` is amazing, and I can use tools like probe-rs and defmt to help debug my firmware.

My only "complaint" at the moment is a bit of immaturity in the USB side of things but I get it, USB is a pretty complicated stack and it'll just take time for things to mature.

For reference, here's some keyboard firmware I wrote for the RP2040. To me it feels reasonably high level and concise for something that drives a real world USB device (as simple a keyboards may be)

https://github.com/bschwind/key-ripper/tree/main/firmware

Thanks, for the repo link! The build/release process for the rp2040 and package management is actually what drew me to rust for embedded initially, super quick turn around to writing to fiddling with the hardware.

I think you're right about it being new to rust, and I recognise my folly in learning both embedded and rust in parallel. I wish I could go back and un-burn myself on it.

Ha-ha, kind of same situation here. I was burned by sheer complexity of RP2040 bootstrap code. Now I switched to some STM32F0 chinese board which seems to be much simpler. I'm not sure if I would end up using Rust because I know little about Rust, but I want to try it along the path. Although I think I would prefer bare assembly.

I've also been working on a hobbyist rust embedded project and happened to pick the esp to do it on! Shoot me an email if you'd be interested in comparing notes - I've had a few frustrations but I feel like I'm getting into the groove of productivity. Email is my username at gmail :)

Same situation here - very excited particularly about no_std but it would be a big time investment on a framework/language I probably won't use professionaly. Still wanted to move away from Arduino/C++, found the sweet spot on MicroPython.

I get it. I can't even get my rust to run on armv7, it is built against a glibc way newer than is available for the board and I can't figure out how to fix it. So I'm using the c++ compiler on the board and being annoyed.

Why are you linking against glibc in the first place? An embedded single-purpose device that's always going to run a single piece of code has no use for dynamic linking. Use a statically linked libc only, and compile in freestanding mode for bare metal stuff.

Because my target isn't bare metal? I've done embedded for decades and it has been quite a while since I used something that didn't have an rtos or linux of some flavor on it other than a uc. An armv7 is so much more powerful than the stuff I started out using it almost seems silly to worry about stripping out the os, but even if I wanted to the bsp for the hardware is integrated with the linux install.

All that said... I may not need anything out of glibc for this project so it is probably worth trying without it. I'm calling into c based bsp methods that do depend on glibc but they will be fine. So thanks!

Reply on news.ycombinator.com