10 ms·
The Embedded Rust Book
- yitchelle 7y agoThis book focuses on the ARM Cortex-M archtectured microcontrollers.. Is there a comprehensive list which other microcontroller is supported by Rust? I really like the direction that Rust is heading in regards to embedded but I wish that when folks mentioned embedded, they should also indicate which microcontrollers are relevant. There are so many varieties around.
- Ericson2314 7y agoThere's no point in having a list. Anything LLVM supports can work. The rest it just a surmountable library problem, but which libraries are good enough is a matter of some opinion.
- aey 7y agoNot quite. Not all ISAs are equivalent and not all llvm backends are equivalent. Rust depends on a few features that are typically not found in embedded systems, like multiple return registers. I wouldn’t even call ARM an embedded ISA anymore.
- ajross 7y agoUh... multiple registers dedicated to return values is a feature of an ABI, not an architecture. The hardware doesn't care what you put in those registers, obviously. Rust defines its own ABI for internally-generated code, it doesn't need to care. And in fact I'm not aware of any such systems. Existing 32+ bit embedded architectures like MIPS, RISC-V, Xtensa, and ARC all have robust instruction sets with large register files and a fully-defined SysV-style C ABI. No, the reason is as stated elsewhere. Rust doesn't run on these systems because no one bothered to tool up LLVM for them.
- analognoise 7y agoWhere is the SysV style C ABI defined if we wanted to go read more about it? Or, do you have a favorite reference for a work explaining it's design choices? I'm interested in soft processors on FPGAs and their tools, and that sounds like it might make for good reading.
- thristian 7y agoNobody actually uses System V anymore, but because it's the thing other Unixy systems are based on, people keep extending the SysV ABI standard to processors ridiculously more powerful than System V itself could ever hope to run on. As best I can make out, the only relevant portions of the original SysV ABI document are chapters 4 and 5, still available and maintained on the SCO website: http://www.sco.com/developers/gabi/ http://www.sco.com/developers/gabi/ There are also separate documents defining the details of the SysV ABI for each processor family. This StackOverflow answer links to some: https://stackoverflow.com/a/40348010 https://stackoverflow.com/a/40348010 ... and the OSDev Wiki links to many more: https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI
- 0815test 7y ago> No, the reason is as stated elsewhere. Rust doesn't run on these systems because no one bothered to tool up LLVM for them. Part of the problem is that LLVM developers themselves are apparently unwilling to release support for architectures that they see as liable to go unmaintained and bitrot in the future, even if someone shows up and does the work. There is a notion of "experimental arch's" but it doesn't seem to be actively used, or to suffice in addressing the issue.
- wyldfire 7y agoBackend support is pruned for architectures that go dark. But if you showed up with support for a new one I'd be really surprised if it weren't included. Experimental archs were just used recently for wasm and riscv to find maturity. Are you referring to a specific discussion on the llvm-dev list? Last one that had a discussion in this area that I recall was Nios2.
- mhh__ 7y agoCompiler exists in theory != supported
- Ericson2314 7y agoI'm sorry but that sounds like a distinction only to freeloaders. Know your dependencies, use something like Nix+Nixpkgs to put yourself in charge of the upgrade schedule, and there will be no nasty surprises.
- nouveaux 7y agoThe last I checked, it is only ARM chips now because it's what LLVM supports.
- steveklabnik 7y agohttps://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html is mostly accurate.
- robocat 7y agoWow: tier 1 contains no ARM or other CPU arch. Tier 1 is only 32bit i686 and 64bit x86_64. Tier 2 platforms can be thought of as “guaranteed to build”. Automated tests are not run so it’s not guaranteed to produce a working build.
- dagmx 7y agoIt's pretty par for the course to have tier 1 be the most common consumer systems since they're the ones with the most bang for buck, and easiest available CI infrastructure.
- steveklabnik 7y agoWe’ve been thinking about re-doing the tier system, as it misses some important points. For example, Firefox has ARM as a tier 1 platform, so if we find bugs, they tend to get fixed up pretty quick. We’re not sure the current way of defining stuff really maps to the reality.
- wyldfire 7y agoThis is AFAICT a rust developer consideration more than anything else? I think/hope that releases are gated by one or more tier 2's successful target tests?
- rcxdude 7y agoAFAIK this is mostly waiting on someone to step up and provide the relevant CI infrastructure.
- hsivonen 7y agoNotably for the topic at hand, RISC-V target list is unmerged: https://github.com/rust-lang/rust-forge/pull/202/files https://github.com/rust-lang/rust-forge/pull/202/files (Also two other unmerged PRs to the list.)
- deleted 7y ago[deleted]
- wyldfire 7y agoThanks much to japaric (Jorge Aparicio IIRC), he's contributed heavily to projects which support embedded use cases.
- gaze 7y agoIs there a good STM32 USB library for Rust? I've seen some preliminary work on some stuff in the past but I'm not sure where it's at. If it's not particularly developed, has anyone had success calling into the ST provided libraries from rust to get USB up and running? Rust for embedded stuff seems like an absolute dream. I'd love to make use of all the excellent work that's gone into it. Most of my work just needs USB.
- wezm 7y agoThere is this one, https://github.com/mvirkkunen/usb-device/blob/master/README.md https://github.com/mvirkkunen/usb-device/blob/master/README.... which apparently works well enough to power a keyboard: https://github.com/TeXitoi/keyberon https://github.com/TeXitoi/keyberon
- contingencies 7y agoI would absolutely love to throw my lot down behind something other than C/C++ for embedded development, but after investigating Lua and Rust I could only come to the conclusion that they're currently inappropriate for resource constrained commercial development... particularly if you use a broad range of sensors, have higher-level protocol communication requirements, etc. Re-implementing this stuff isn't just a minor drag, it's commercial insanity. 1. Example hardware in this book costs around 98RMB and has a huge form factor. AVR / ATmega328P based platforms like Arduino Nano are currently ~10RMB, which can be beefed up to full ethernet connectivity with prebuilt hardware modules for another 20RMB. So in short it is possible to procure over three(!!!) embedded, ethernet capable AVR platforms for the same price as this hardware, no soldering required. Why not use something cheaper and more broadly available? It would help more people get on board (no pun intended). Oh wait, there's no AVR support. I see... 2. The nominal target hardware in the book seems overpowered/overpriced/out of date. For example, the target used in the early book is LM3S6965, which is NRND (Not Recommended for New Designs). Probably as a result of NRND status (I guess people buying up stock to keep old designs in manufacturing) it costs over 125RMB for the chip alone. The manufacturer's recommendation for replacement is TM4C12x, the cheapest development board for which is MINI-M4FORTIVA @ 22RMB (which features JTAG). ICs in this series begin at 22RMB or so, still many times AVR chip price, and with IMHO far too much hardware for novices (64KB flash, 12KB RAM, 12x12bit ADC channels, 49+ GPIO channels...). A direct quote from later in the book is In this example, let's assume we have an Texas Instruments TM4C123 - a middling 80MHz Cortex-M4 with 256 KiB of Flash. That's not middling, that's ridiculously overpowered for almost anything embedded. 3. See example code at https://rust-embedded.github.io/book/start/registers.html https://rust-embedded.github.io/book/start/registers.html and compare C and Rust Volatile Access examples at https://rust-embedded.github.io/book/c-tips/index.html https://rust-embedded.github.io/book/c-tips/index.html and see which syntax you prefer...
- Matumio 7y agoIs there seriously still a commercial reason to use the ATmega328 (an 8-bit microcontroller with 2000 bytes of RAM) for new projects? I've been working on 3D printing firmware, and it's so easy and silly to reach the limit of this CPU. Been shaving bytes of RAM by reducing queue sizes, running into performance limits even with a few 32bit additions in the stepper loop. That was 6 years ago. The only semi-valid reason to use this chip IMO is because people want to keep using existing firmware as-is.
- burfog 7y ago20 years ago, I did embedded computing with systems that would scale to about 360 processors (PowerPC "G4" MPC7410 @ 500 MHz) and about 70 gigabytes of RAM. Yes, it really was embedded. It fit in 9U (15.75 inches) and was rugged enough to fly in a military aircraft. The OS would let users turn off interrupts in order to squeeze out every bit of performance. We could also run the OS on the SHARC DSP, which is a word-addressed Harvard-architecture chip without an MMU. Running on that would allow 3x the CPU density. One system got up over 1000 cores. IO would typically come in via DMA, over a 32-bit link running at 40 MHz. There could be many of these. The end result was generally something like a radar. The end-user sees a radar, buys a radar, and uses a radar. They don't see a computer. The computer is just a component embedded in the radar.
- contingencies 7y agoThat's an interesting story but you have to admit high bandwidth real time signal processing is a pretty specialist embedded workload. I guess these days there'd be FPGAs and/or existing IC packages for the job.
- burfog 7y agoThere were several companies competing in this space. The main three were CSPI, Mercury Computing (now Mercury Systems), and SKY Computing. Matrox briefly tried to join the party. Even back then, FPGAs and custom ASICs would be part of the compute fabric. I left that out. For example, there was an FFT accelerator chip. These days the companies add in a mix of FPGAs and GPUs, but the CPUs are still there. It's all the same stuff today, but faster. To the end user, it was never a computer. It was a radar, a video processor, an MRI scanner, a sonar, an ultrasound, a chip wafer inspection device, a laser with real-time mirror warping, or some other tool.
- contingencies 7y agoYou have a good point that people who set out to implement high end military/medical/high end industrial metrology hardware greenfield projects today may see value in using Rust and won't have a problem with more expensive hardware. However, I do think that's a vanishingly small percentage of embedded development.
- jwr 7y agoSo, Nordic Semiconductor, when do we get Rust support in your SDKs? Please?
- childintime 7y agoAt least the soon to be released ESP32 successor seems to get this, by virtue of adopting a RISC-V core. Kind of a big deal really.
- jrrrr 7y ago[citation needed]
- childintime 7y agoMy info is mainly from: https://www.esp32.com/viewtopic.php?f=2&t=9768 https://www.esp32.com/viewtopic.php?f=2&t=9768 I was incorrect, citation: d) it is a Tensilica / RISC V are in the pipelines. So not "big deal" RISC-V yet, probably later.
- awestroke 7y agoWhat's it called?
- neilv 7y agoMaybe using an ARM dev board boosts acceptance of this book among its target audience, at the moment. But, for open source hardware goals, a RISC-V board, such as the HiFive1, would be good cross-promotion/support.
- neilv 7y agoImagine Rust being considered the way to develop for embedded RISC-V, from almost the start. Similarly, as long as Rust is already shaking up C/C++ a bit, they could nudge some hobby/education and professional development towards RISC-V. (Especially on embedded, right now, as I've heard the open ISA is attractive to some projects.)
- johnisgood 7y agoI feel the same way about Ada and RISC-V, to be honest. https://blog.adacore.com/ada-on-the-first-risc-v-microcontroller https://blog.adacore.com/ada-on-the-first-risc-v-microcontro... https://hackaday.com/2018/10/08/programming-a-risc-v-softcore-with-ada/ https://hackaday.com/2018/10/08/programming-a-risc-v-softcor... https://riscv.org/2019/01/adacore-joins-the-risc-v-foundation-to-provide-c-and-ada-compilation-support/ https://riscv.org/2019/01/adacore-joins-the-risc-v-foundatio...
- truebosko 7y agoWould love to learn Rust and currently debating on a few home applications. Any ideas from the HN crowd? I'm currently looking at a Pi-based weather station where I would use Rust as the processing server for all the data each day. Nothing fancy, but perhaps a fun way to learn.
- funkythingsss 7y agoProgramming rust on the Pi is a whole lot easier than "pure" embedded. There are libraries for linux PWM, GPIO, SPI etc in Rust, so it shouldn't be a problem to hook up some sensors. I in fact just wrote a little driver for the MPU6050 that I'm using with my Pi, it was a breeze. Nevertheless, get used to Rust first! Start with the book, it's great
- bsder 7y agoOkay, can we please get a primer that an intern can follow that starts from an empty Windows 10 install, installs everything including VSCode, flashes the boards with a Segger J-Link, blinks the LED, and single steps the debugger? I'm serious. I will go buy any board in order to check that tutorial out. I'll go further. I would buy the Rust folks a couple boards and Seggers to get that.
- abledon 7y agogofundme/indiegogo that idea, if its popular, it should get some traction
- bacon_waffle 7y agoThis may not be exactly what you're asking for, but: https://github.com/atsamd-rs/atsamd https://github.com/atsamd-rs/atsamd
- jamesmunns 7y agoHey, my company has this. We do consulting and training for embedded rust, and our material is open source. Check out https://github.com/ferrous-systems/embedded-trainings/blob/master/INSTALL.md https://github.com/ferrous-systems/embedded-trainings/blob/m...
- 2wrist 7y agoThats ace! BTW It is really cool that your company does this. It has a cracking name too!
- k__ 7y agoI know some embedded devs who say Rust is still too slow compared to C. What do they mean?
- jononor 7y agoThat they are happy with C and are sick of others trying to convince them to use something else. Only halfway joking... But if you really want to know what those people mean, then you should ask _them_.
- steveklabnik 7y agoHard to say. It’s possible they made a mistake, it’s possible they hit a compiler bug, it’s not really possible to know without hearing more about what they mean.
- sitzkrieg 7y agoThis is great, but unfortunately embedded doesnt always = ARM. Does anyone know if it would be possible to target mips32 since LLVM supports it? Is there any effort in rust for other arches? The mplabx + xc32 +harmony toolchain has got pretty darn awful so that would be amazing for the MIPS community