Hacker News new | ask | show | jobs
by swsieber 1884 days ago
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.

1 comments

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.