Hacker News Reader

Comment by arwhatever | Hacker News Reader

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

I have at least managed to get some literal blinkenlights doing what I want on various Adafruit boards with very little effort.

View on HN

Code 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.

I 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.

I 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).

Interesting! For me ESP8266/32 felt trivial to reach successful prototypes. With no prior experience it took me less than a week to create PoE temp/humidity monitors for a datacenter with Grafana and Prometheus.

In contrast I have stumbled quite a lot trying to learn the STM ecosystem. I find myself really wishing for someone to work with to help me get past the initial startup hurdles so I can be more productive.

I'm having trouble finding the actual code for the demos included in the STM3210C-EVAL or STM3220G-EVAL, or tutorials for making use of the myriad peripherals included on the boards.

Heh, I guess a lot of it is up to personal tastes.

STM's documents seem very through, and when I use STM boards they seem to follow the docs without much issue. I usually use classic Arduino, or maybe the ATMega328pb directly, because I prefer 5V compatibility. But I don't recall any issues with STM last time I used them.

Rasp. Pi doesn't have much low-level stuff, but the board is so overpowered that you can manage to bit-bang stuff at lol Python levels and still get many things done. Its not my go-to tool because again: 5V preference, as well as timers / ADC aren't as capable as other chips.

But ATMega328pb / Arduino is a really nice starting point. You got the Arduino high level library, and a very short ATMega328pb document (well... short for chip level documents anyway. Still hundreds of pages, but its not like 1000s of pages like ARM stuffs)

-------

I'll admit to using the simplest STM F0 (ARM M0+) boards, which are trying to be ATMega328pb level in terms of complexity. STM has many, many boards of many capabilities and levels of complexity. Its a very big family. So my experiences with STM F0 stuff probably don't apply to everybody.

In my experience, ESP8266 development doesn't rely very much on the datasheet. Thats because there is a large community around one or two chips, and therefore a single driver implementation is good enough for everybody to write high level code on top of. There's little to no register interaction, and no need to look up how the peripherals work. There's no ARM Cortex I can think of that has this development style.

I've got the complete opposite experience. Maybe the kind of stuff I work on is just different but that sounds like a lot of work that could have been avoided by cobbling together some reference designs and carefully reading PCB layout documentation.

With all the different reference designs, parts libraries, and open source projects available these days, spinning up a PCB design has never been faster and easier (I use Altium). My record for a nontrivial design is less than 12 hours from idea to fab+assembly order with an FPGA + Wifi referenced design grafted onto a gutted STM32F4discovery followed by ~30 hours troubleshooting the bringup and sending out a second revision. I don't think I've ever written and tested nontrivial firmware in that time frame.

Even in complex microprocessor boards where routing high speed signals (DDR3/4, MIPI2/3, etc) takes up 90% of the design time, the time spent faffing with BSPs and device drivers far outweighs design time.

If you are interested in writing Rust for embedded systems then this is a great collection of resources: 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/

Excellent 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.

Thanks, the list looks awesome

How 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?

Reply on news.ycombinator.com