(2024-12-02) Looks like I've found the most optimal MCU board so far -------------------------------------------------------------------- As my journey into the world of MCUs began, I knew for sure that it wouldn't stop on AVRs. In particular, if you remember my previous post, I mentioned some other chips at the end of it, namely ESP8266 and RP2040. Well, since then, I've had a chance to obtain some boards based on both of those (all clones, of course): ESP-01 (01S), WeMos D1 Mini and RP2040-Zero. I've yet to get much more familiar with the latter (I already like how easy it is to flash and how small it is in size for what it can do) but I can already say which one of these three became my absolute favorite, especially considering its price comparable to clone Arduino Nanos. Yes, I'm talking about the D1 Mini. Why? Well, the ESP-01S is definitely the cheapest option if you want pure processing power with wireless capabilities, but is stripped to the bare bones: no USB (you need to use a USB-TTL converter to interact with it), pure 3.3V dependency, no guarantee of how much flash memory you're gonna get (typically 1 MiB but it can vary from 512 KiB to 4 MiB), no ADC or other advanced pins that the ESP8266EX chip does have, not even a reset button, only two free GPIO pins (one of which also controls the internal LED) if you still need UART, and a totally not breadboard-friendly pinout. Not sure I'll have a lot of situations where such an amount of compromises would justify about half the price. And the RP2040-Zero is still cool in almost every aspect and has a lot of ADC pins but is priced about the same as the WeMos while having no wireless module whatsoever and, again, not being compatible with standard Arduino-style breadboards (if you do solder the five pins on the side opposite to the USB port, that is). The D1 Mini, on the other hand, has none of those issues. It is totally breadboard-friendly, has enough pins for everyday hobby needs (even though there's only one ADC pin but that's what the ESP8266EX itself gives you), has an internal USB-TTL adapter and a way to power it not only via USB but with external 5V or 3.3V sources, has the guaranteed 4 MiB of on-board flash memory and even fixes some drawbacks of the original chip, for instance by having a dedicated reset button or a built-in voltage divider to bring the 3.3V ADC pin input to the allowed range of 0..1V. Also, unlike e.g. NodeMCU clones, the clone D1 Mini boards usually don't have a lot of (or any) QC issues because they are basically manufactured by soldering a ready-made ESP-12S (or 12F?) module on top of their custom PCB. Hence, the WeMos serves both as a breakout board for the ESP-12 (and ESP8266EX itself) and as a quality-of-life enhancer for it by adding all those features for a small fraction of the price you'd pay if you had to take a bare ESP-12 and do all this by yourself. Well, how easy is it to work with? I was interested in operating it with a higher-level language, and among JS, Python and Lua, I obviously chose Python. That's why all I needed was a corresponding MicroPython firmware binary and the esptool to flash it via USB. Definitely much more straightforward process than what needed to be done to interact with ATmega MCUs. Well, flashing an RP2040 is even easier, but I'll compare the MicroPython experience on both in my later posts. For now though, once I have MicroPython up and running on a D1 Mini, the only thing I need is the ampy tool to move files there. I have some understanding how this tool actually works, so I might end up writing my own if I dislike something there. As of this moment, I just call ampy as a part of my makefiles. I find it quite astonishing that the Alpine Linux repos already have both ampy and esptool directly available via the system's apk package manager. And the MicroPython distribution is... well, a full-featured Python. Of course, it somewhat limits you with the set of libraries you can call (and the 1MB build for the ESP-01S limits you even more), but other than that, it's a "normal" Python 3.4 with some features backported from the newer language versions and some differences from the "big" CPython thoroughly documented in the official documentation ([1]) which I highly recommend to fully read anyway. On top of that, it offers several levels of optimization (turned on with decorators) and an mpy-cross tool to pre-compile Python modules before loading them onto the device, so it definitely can be made not as slow as you probably might imagine. Also, there even is a possibility to leverage micropython-lib to install third-party libraries ([2]), similar to the way pip works on the "normal" CPython. You can find many useful things there, like USB HID/CDC/MIDI drivers or an aiohttp port. Some of those libraries even extend the standard MicroPython library to the CPython level of features, just in case you really need those in your MCU. Now, my first plan for the nearest future using these D1 Minis is to build something like a pocket assistant device that would eliminate the need of carrying pretty much any phone around the house. Kinda like a programmable pager or something. I've already soldered the first prototype contraption (that doesn't even have a piezo buzzer) and, of course, am going to refine it a lot, but for now I'm more focused on the software side of things, which presents enough of a challenge of its own, given that the device is only going to have four buttons in the original design. I'm also keeping tabs on the projects like ESPboy although I'm not quite at that level yet. Let me also remind you that I do have a couple of SIM800C GSM modules lying around... and they are waiting for their time to shine as well. --- Luxferre --- [1]: https://docs.micropython.org/en/latest/reference/index.html [2]: https://docs.micropython.org/en/latest/reference/packages.html