experimenting with micropython 1.18 on adafruit’s qt py esp32-c3

I’ve been dealing with some unique issues trying to run Micropython version 1.18 (  https://micropython.org/download/esp32c3-usb/ ) on various microcontroller boards, especially any made with the latest Espressif ESP32 MCUs, which include the ESP32-S3 and ESP32-C3 MCUs. These particular MCUs are being sold as part of Espressif-built developer boards as well as this particular board sold by Adafruit, the QT PY ESP32-C3 ( https://www.adafruit.com/product/5405 ). This post documents my initial work with the QT PY.

FIG 1 — QT PY ESP32-C3 (via Adafruit)
FIG 2 — QT PY ESP32-C3 Pinout (via Adafruit)

This little board is built around the Espressif ESP32-C3, which in turn is powered by a single core RISC-V processor. Figure 1 is a photo of the board. It’s no bigger than an American postage stamp, yet it has a USB-C connector on one edge and a STEMMA QT/Qwiic connector on the opposite edge for wiring I2C devices into the board. There aren’t that many pinouts, but that’s not the point of this very small but powerful board. It has 4MB of flash and 400K of SRAM, which is more than enough for complex embedded work. And that 32-bit RISC-V processor is running at 160MHz (import machine; machine.freq(); 160000000), a speed I can certainly make use of with Micropython. And all for US$10. What an incredible bargain!

I flashed the QT PY with the Micropython official release, version 1.18. Everything seemed to work until I tried to work with the build-in RGB pixel. The test code in Figure 1 would not work.

import machine  as mafrom machine import Pinimport neopixel as neoimport time as tiimport osprint(', '.join(os.uname()))np = neo.NeoPixel(Pin(2, Pin.OUT), 1, 3)neopixel_colors = [(128, 0, 0, 0), # red(0, 128, 0, 0), # green(0, 0, 128, 0), # blue(128, 32, 0, 0), # orange(0, 64, 64, 0), # cyan(0, 0, 0, 0)# black]while(True):for color in neopixel_colors:np[0] = colornp.write()ti.sleep_ms(500)

It produced the following error on the REPL:

esp32, esp32, 1.18.0, v1.18 on 2022-01-17, ESP32C3 module with ESP32C3Traceback (most recent call last):  File "<stdin>", line 23, in <module>  File "neopixel.py", line 1, in writeOSError: (-258, 'ESP_ERR_INVALID_ARG')

I went googling around and found the problem and solution on a forum: https://github.com/micropython/micropython/issues/8346

The suggested solution was to use a nightly build of micropython 1.18. I installed the nightly for 24 April. Sure enough the code worked and the NeoPixel ran through its color sequence just like on the earlier ESP32-S3 board I’ve been working with. The original code was then uploaded to the Qt Py board, and it also worked as before. The only change to the ESP32-S3 code was to line 8 highlighted below, to use GPIO #2.

import machine  as maimport neopixel as neoimport time as tiimport osprint(', '.join(os.uname()))np = neo.NeoPixel(ma.Pin(2), 1)neopixel_colors = [(128, 0, 0, 0), # red(0, 128, 0, 0), # green(0, 0, 128, 0), # blue(128, 32, 0, 0), # orange(0, 64, 64, 0), # cyan(0, 0, 0, 0)# black]while(True):for color in neopixel_colors:np[0] = colornp.write()ti.sleep_ms(500)

All of this was performed using Thonny 3.3.13. It would appear from my experience that Thonny is the only development tool that can work with Micropython on the ESP32-S3 and -C3 based boards. I’ve even had problems with the mpremote tool that’s supplied with Micropython.

running micropython 1.18 on an esp32-s3-devkitc-1-n8r8

Programming with the Mu Editor v 1.1.1

I’ve been experimenting with some of Espressif’s latest components via their developer kits. I’ve been working with both the ESP32-S3-DevKitC-1-N8R8 (8Mb RAM, 8Mb FLASH) and the ESP32-C3-DevKitC-02. The fundamental difference between the S3 and the C3 is that the S3 is a dual core Tensilica LX7 32-bit processor while the C3 is a single core RISCV 32-bit processor. I bought the C3s because at $10/board, they are the cheapest way to get into studying RISCV that I know of.

All of this is hosted on an M1 MacBook Pro M1 running macOS 12.3.1.

The screen capture above is the Mu Editor ( https://codewith.mu ) working with the ESP32-S3.

The ESP32-S3 was programmed with MicroPython downloaded from the MicroPython site here: https://micropython.org/download/GENERIC_S3/

Do not try to use the official release, it will not work. Success came by using one of the nightly builds: GENERIC_S3-20220414-unstable-v1.18-338-g988827b85.bin. I’m assuming that any nightly build from this point will work with these boards, but I’ve not tried this yet. I followed the directions on the MicroPython download page to flash the ESP32-S3 board.

Final Thoughts

I got everything to work on my MBP and macOS, especially programming the complete ESP32-S3. These MCUs are still advertised as experimental, with minimal support. And believe me they aren’t kidding. I’ve been programming these boards using Espressif’s ESP IoT Development Framework (IDF) v4.4. I’m comfortable working with the ESP-IDF command line tools in C/C++. And yet I wanted to flash at least one of my ESP32-S3 boards with either MicroPython or Adafruit’s Circuit Python. I’ve been sticking to MicroPython because of my extensive experience using it with Pycom boards (primarily the FiPy board) as well as using MicroPython on the RP2040-based boards.

As far as a decent IDE/editor is concerned, the only option for me has been the Mu Editor on macOS. I tried to install it via Python’s PIP on my Linux work box, but it fails all over the place; Mu Editor via PIP on Linux (and even on macOS) is a hot mess. I downloaded the macOS installation package from the Mu editor website and installed from that.

Mu with this version of MicroPython still isn’t perfect. For whatever reason if I try to trigger a read of the files on the ESP32-S3, the Mu editor fails and the windows at the bottom of the editor become unresponsive. I have to exit the application and restart it. Everything else seems to work, especially the REPL window, for which I’m thankful.

There appears to be a Circuit Python build (v 7.2.5) for the ESP32-S3-DevKitC-1-N8R8, but I haven’t tried it yet because there is conflicting information on the download page that there is no Circuit Python support for this board, right next to the download link. Right now things seem to be fine with MicroPython, and MicroPython has some key features missing from CircuitPython.

Update 15 April

I downloaded and flashed today’s MicroPython build and it worked as well as the build from 14 April. It would appear that consistent forward progress is being made.