Small micro controllers don't have the resources you're used to. The smallest thing I ever wrote code for was in the PIC family and had 176 bytes of RAM and like 4 or 8K of flash (EEPROM?). Even on more common parts you may find only a few K of RAM and 10's or 100's of K flash. In that space we don't do any dynamic memory allocation, never mind garbage collection. If you did it's entirely possible you'd run out of heap space and the program would crash. It's a really different world than what web developers and app developers are used to. I highly recommend taking the dive even if it's just for fun and to see a different type of software development.
The recommended development board isn't that bad. 256Kb Flash memory, 48-Kbyte RAM. It's not as tight as a classic Arduino.
This is where Rust's safety helps. Debugging embedded code on small machines is a huge pain. The more problems caught at compile time, the better off you are. A compile time error beats JTAG debugging every time.
The article gets kind of vague once they get beyond LED-blinking and busy-waiting. They implement a brute-force CPU dispatcher and call it "async" programming. They never get to interrupts at all.
Rust on little machines makes sense, but it needs more support underneath to deal with timers, interrupts, and concurrency. There are projects working on this.[1]
> Rust on little machines makes sense, but it needs more support underneath to deal with timers, interrupts, and concurrency. There are projects working on this.[1]
NB. the OP is part of that project, from the same author.
Rust needs a CPU dispatcher underneath, so the thread and lock primitives can work. A minimal single-process multiple-thread OS, something like VxWorks, is all that's needed. This would probably be something you'd link with the program.
It's better to have one good one CPU dispatcher than making users roll their own crappy one for each application.
If you mean every Rust program requires a dispatcher to run, then no, Rust does not need a CPU dispatcher. Thread and locks are not primitives: they're implemented in the standard library (the std part, specifically). The 'thread' safety guarantees don't rely on that functionality, instead the arrows go the other way: the spawning and locking constructs build on the guarantees (driven by the Send and Sync traits, which are purely compile-time constructs) to provide expressive yet safe API. For instance, there's numerous operating systems built in Rust, for instance intermezzOS seems to be pure Rust except for the single file https://github.com/intermezzOS/kernel/blob/master/src/asm/bo... .
If you mean that it would be really nice if there was a general purpose dispatcher library available, then sure, that seems like something that would be great on crates.io.
In any case, I don't see how your comment relates to mine.
Rust with a CPU dispatcher offers the opportunity to get beyond the raw busy-wait and basic interrupt handling of Arduino-type code without going all the way to a full Linux system. That's what I'm getting at here.
The first micro I ever used (as a kid in the late '90s) was a PIC16C62A. 128 bytes of RAM, 3.5kB of EPROM. Not EEPROM, this was the UV-erasable stuff. I didn't have a UV lamp so I could only program during the day when I could take it outside & peel back the black electrical tape from the window to erase it.
And you might want to avoid multiplication operations, because the compiler will likely have to implement those in software, which will be slow, and might make your program too large to fit in the memory… :-)
As a rule, I now try to avoid anything that isn't 32 bits with hardware multiplier. Unless you need a controller for under 50 cents I don't think that's a high bar any more. Floating point - much as I'd like to make it a minimum requirement I still enjoy doing some math in fixed point.
Oh for the day when RV32IMAF can be considered low end.
For me, it's the elegance of making do with the least sophisticated components. Using a microcontroller at all can be seen as bringing out the big guns.
The AVRs, at least some of them, have reasonable Flash and RAM and EEPROM (v nice), and a single-instruction multiply. Much nicer than the 8-bit CPUs that I used to program back in days of yore...
