4 ms·
Am admittedly too inexperienced to properly weigh the pros and cons of various platforms, but I find the Rust support for certain embedded platforms to be compe
by arwhatever 5y ago
Am admittedly too inexperienced to properly weigh the pros and cons of various platforms, but I find the Rust support for certain embedded platforms to be compelling.
https://github.com/atsamd-rs/atsamd https://github.com/atsamd-rs/atsamd
I have at least managed to get some literal blinkenlights doing what I want on various Adafruit boards with very little effort.
- davidhyde 5y agoIf you are interested in writing Rust for embedded systems then this is a great collection of resources: https://awesomeopensource.com/project/rust-embedded/awesome-embedded-rust https://awesomeopensource.com/project/rust-embedded/awesome-... Visual Studio Code with rust-analyzer and probe-run give you the same turn key experience as Arduino except on a more professional level. Flash your devices with a simple “cargo run” command and see log messages magically appear from your microcontroller in your console. The STM32 line of microcontroller or nordic’s nRF52 boards are well supported. These are 32 bit microcontrollers rather than the 8 bit microcontrollers you get for Arduino. And of course, there’s a book: https://docs.rust-embedded.org/book/ https://docs.rust-embedded.org/book/
- arwhatever 5y agoExcellent resources indeed. I feel like I should also mention that I tried some bare metal embedded Rust about 2 1/2 years ago and didn't get anywhere with it. Now I try and there's support for quite a few boards, and it's easy to get started with them. (good CLI tools, etc.) I have the impression that the Rust ecosystem and community have progressed very rapidly in the embedded direction, and in short time.
- Trex_Egg 5y agoThanks, the list looks awesome
- ajfjrbfbf 5y agoHow does the code size compare with a traditionnal C approach? The book website mentions using STM32 which usually have plenty of space (64-512kB). How well would it work for say, an ATtiny with 2-8kB of program space?
- dragontamer 5y agoCode is NOT the hard part of these projects. You'll spend an inordinate amount of time painting boxes to be the right color and design. Or drilling holes that are just the right size. Or deciding on acrylic cases vs wood cases vs altoid containers. Or the pros/cons of 1.5" standoffs vs 2" standoffs. Once you figure out those details: you need to think of power (4xAA is my favorite), with probably an efficient buck-converter to drop the 5V down to 3.3V, and then a myriad of sensors that are in the 3.3V range... probably SPI vs I2C interface, or maybe a raw voltage reading so that you can do thing from your ADC converter directly. Then the whole thing is cobbled together with maybe 500 to 1000 lines of code. Like seriously, code is the easy part. Then you realize that your ADC converter is having an aliasing issue (physical: nothing related to code), so you need to build a low-pass filter. Do you wanna go with a passive inductor+capacitor approach? Or is your ADC converter at a high enough frequency that you need to go with a quad-Op-Amp and get a 8th order Butterworth filter up in there? What's the frequency of the aliased noise? Can you measure it on your oscilloscope? ----------- I'm talking about basic "read sensor" and "blink them lights" projects. These are the things that come up in practice. Code... sure. Reading the docs for how to run the various sensors (if I2C or SPI) may be tricky at times, but they "just work" more often than not. Physical issues (voltages, frequency, filters, and making your paint actually stick on the altoid can etc. etc.) are harder to debug. And if I were to take a guess why your I2C "code" isn't working, I'd bet on a physical issue (ex: fanout, resistor choice, trace length, capacitance) over code issues, especially if you're using a plug and play library like Arduino's I2C or Rasp. Pi's I2C stuff.
- swsieber 5y agoI have had to try multiple libraries to get a basic humidity sensor working with an ESP8266. I agree that the hardware will be the dominating factor long-term; but I do think you're underselling the the complexity on the software side, and that it can make a big difference to a newbie.
- dragontamer 5y agoI wouldn't necessarily say that ESP8266 is a beginner-friendly board. Its a cheap board with WiFi capabilities, but not as beginner friendly as say Arudino (and clones), or STM-stuffs, or Rasp. Pi. But I think most hobby projects are the type you're basically talking about: 1. Insert some combination of sensors onto a microcontroller board. 2. Loop over reading those sensors. 3. Very basic math / addition / etc. etc. 4. Turn on blinky-lights based off of the sensor readings. Or maybe WiFi / Bluetooth / RS232 UART / some other I/O to "publish" the results somewhere. Maybe a motor in some cases. This general process covers the typical projects a hobbyist would do: "useless boxes", blinky, temperature sensor recorder, remote-control car/sumo bot, etc. etc. I wouldn't say Arudino "just works". There are definitely decisions where you can "hang yourself" or "shoot yourself in the foot" if you don't know what you're doing. But I guess the physical-version of that is "literally overvolt your board and maybe something catches on fire". So making sure that the physical bits (voltage levels, current levels, etc. etc.) are all set requires a bit of thought. Ex: Doing some PWM-controls on a 12V motor? Good job, if you forgot the flywheel diode, you're gonna see a fire pop up somewhere. To understand why requires understanding the underlying physics of a motor (inductance, dv/dt and di/dt), and how that interacts with pulse-width modulation. Even if things aren't catching on fire, you can damage components by having inappropriate controls thought out along the electronics (think of the voltages associated with the back-EMF when that motor turns off).