Post

Facts

Orual@nonbinary.computer

unironically best thing about embedded rust is that you can basically write arduino (pin.set_high()) but it'll compile to something efficient in a lot of cases. the HAL crate layer is where you do unsafe mostly, and you can write drivers targeting the safe abstraction and they work crossplatform

How easy is rust for those of us who aren’t in tech? My brain is so fried from using stats software pretty much exclusively that I had to install pycharm again to debug a simple py script I wrote

It's complicated. 1) rust has lovely pycharm style interfaces to all the cool user friendly stuff rust does 2) rust is a systems programming language and is at least as hard as C but the compiler (or IDE linter) will yell at you for writing bad code.

The difficult bits in rust, IMO, are things that are difficult about programming without a memory manager full stop. You have to care about ownership of pointers, you have to care about allocation. It will help you in ways that C-like languages but the language is not the hard part.

This is really helpful, it also tells me I need to maybe stick to scripting languages for now which manage the bulk of that for me (admittedly, quite badly often) I have some time off coming up soon and was thinking of learning a new language and rust was on the “maybe” list.

For sure. Rust is only really useful where you would want to use C or C++. So embedded devices or operating system/driver programming are both great choices or high performance code. But Python is an objectively better tool for hacking out a solution that doesn't need to be small or fast.

legit I use (micro)Python a fair bit for rapid prototyping on embedded, especially if I *know* for sure i am going to throw away the prototype or perf just does not matter one bit. if I think the prototype might become production I will often try and write it in rust.

I used circuitpython for a quick-and-dirty demo once (BeBox-style CPU utilization strips for all 12 threads on my laptop!) and that convinced me I should just do all my prototyping in rust lol.

Some ARM chip, arduino-type thing, probably an atmel samd since that's what most of those used. WS2812s (aka NeoPixels) since we had strips of them laying around and you can wire a whole line of them to one pin. This was a quick and dirty demo so it was all laid out on breadboards and cardboard.

Circuitpython has a built-in library for working with neopixels (since it's an adafruit thing), which is part of why I picked it for the project. The docs didn't make clear the kinda-obvious-in-retrospect fact that you need explicit flushes in your code or the latency will be super high :-(

(I mean if it were me I'd just force the user to ALWAYS explicitly flush to the neopixels, since there's no way the library can know when the right time to do a refresh, but whatever)

The other problem was that I was feeding data in via serial, and circuitpython REALLY wants to use the primary serial port for its repl. By which I mean that you can't make it stop for love or money. The development experience was... suboptimal.

0 reposts2 likes

oof yeah. one of the reasons i've basically sworn off of atmel parts is bc they just straight up never have enough serial ports and way too inflexible pin mapping, even the ARM ones. so yeah that was a bad confluence of factors there, plus neopixels are super fucky re: timing.

Think there might have been a second serial port on the chip actually, but I didn't have an FT232R or the like on hand so it wasn't useful.

I mean once a friend showed up and told me about the explicit refresh thing the neopixels actually worked fine. But the embarassingly slow refresh made the demo pretty lame until that happened.