Hacker News new | ask | show | jobs
by rckoepke 1884 days ago
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.
1 comments
dragontamer 1884 days ago
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.

link
flyingcircus3 1883 days ago
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.
link