Category: Embedded

my first encounter with the sparkfun pro micro – rp2040

whbeebe

I’m starting an informal series about all the little microcontroller experimenter boards I’ve been picking up, especially the inexpensive ones that cost US$10 or less. This post is about the SparkFun Pro Micro — RP2040, which can currently be purchased for US$10.95 from SparkFun ( https://www.sparkfun.com/products/18288 ).

Figure 1: Sparkfun Pro Micro — RP2040 (image via SparkFun)

The Pro Micro is the same width and almost twice the length of the Adafruit QT Py ESP32-C3, another $10 microcontroller experimenter’s board. The board comes with castellated edges, providing the experimenter or designer with the ability to solder the board directly onto the surface of a larger circuit board. While there are far fewer I/O pins brought out to the edges as there is in a stock RP2040 Pico board, it does have four times as much storage flash (16MB), a NeoPixel LED in place of the standard red LED on the Pico, and a QWIIC connector on the other end. It also has USB-C in place of micro USB on the other end. For for an extra six dollars over the cost of a bare Pico you get a device that’s a lot more civilized. I think the inclusion of the QWIIC connector alone is worth the extra six dollars.

Figure 2: Pro Micro RP2040 general pinout (image via SparkFun)

This is the most complete pinout diagram for a microcontroller I think I’ve ever seen. Not just the pins, but key functionality around the board is documented as well. You can do just about anything with only this diagram to refer to. But that’s just me.

I want to call your attention to the boot and reset buttons at the bottom edge next to the QWIIC connector in conjunction with putting the Pro Micro in bootloader mode. Let’s say you want to put the latest Circuit Python firmware on this board. Plug a USB cable into your computer and then into the board. Press and hold the boot button. Press and release the reset button, then release the boot button. The RPI-RP2 flash drive will show up on your computer, at which point you can drag-and-drop (or copy in a console) the Circuit Python UF2 firmware to RPI-RP2. Once the UF2 firmware has finished copying, the board will reboot itself and the regular CIRCUITPY storage device for that board will appear on your computer.

Figure 3: How the Pro Micro’s built-in flash appears on Fedora 36

And here’s my version of blinky Python code to blink the on-board WS2812 addressable LED.

"""NeoPixel blink example for RP2040-based boards such as the Sparkfun Pro Micro RP2040.The example requires two libraries from the Adafruit CircuitPython Library Bundle.Download the bundle from circuitpython.org/libraries and copy the following files to yourCIRCUITPY/lib folder:- neopixel.mpy- adafruit_pixelbuf.mpyOnce the libraries are copied, save this file as code.py to your CIRCUITPY drive to run it."""import boardimport neopixelimport timenp = neopixel.NeoPixel(board.GP25, 1)neopixel_colors = [(64, 0, 0),  # red(0, 64, 0),  # green(0, 0, 64),  # blue(0, 64, 64), # cyan(64, 0, 64), # magenta(64, 32, 0), # yellow(0, 0, 0)# black]while(True):for color in neopixel_colors:np.fill(color)time.sleep(0.5)np.fill(neopixel_colors[-1])time.sleep(0.5)

These little boards are powerful, easy and cheap. And they’re a lot of fun to work with!

FIgure 4: Thonny editing the code and communicating with the Pro Micro

And for the sticklers, I’m using Circuit Python 7.3.0-rc.2, or release candidate two of the very latest version of Circuit Python (see https://circuitpython.org/board/raspberry_pi_pico/ ).

a serious issue with pop!_os 22.04 and esp32 dev boards — FIXED

whbeebe

Remember when I spoke glowingly of the latest version of Pop!_OS, 22.04? Well the bloom is now definitely off the rose. I’ve been working with the ProS3 on my MBP which means I haven’t been working with any of the ESP IDF development boards on my updated Pop!_OS Linux system. Last night I decided to fire everything back up on that system and install the Rust crates and tools for ESP embedded development via Rust. The updated Python 3.10.4 tripped me up when I tried to enable the ESP-IDF environment. That forced me to re-run the ESP-IDF installation script to rebuild the Python virtual environment it uses. I’d expected that that would happen. The biggest issue is critical: I can’t see any of the ESP development boards as tty devices. Here’s what happens when I plug one of the ESP32 development boards in via USB.

[  872.282830] usb 1-4.3: new full-speed USB device number 9 using xhci_hcd[  872.405203] usb 1-4.3: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00[  872.405220] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3[  872.405224] usb 1-4.3: Product: CP2102N USB to UART Bridge Controller[  872.405227] usb 1-4.3: Manufacturer: Silicon Labs[  872.405229] usb 1-4.3: SerialNumber: 448454f7dffaeb11aa2038a4c6d924ec[  872.407305] cp210x 1-4.3:1.0: cp210x converter detected[  872.417691] usb 1-4.3: cp210x converter now attached to ttyUSB1[  876.147068] usb 1-4.3: usbfs: interface 0 claimed by cp210x while 'brltty' sets config #1[  876.150583] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1[  876.150819] cp210x 1-4.3:1.0: device disconnected

I checked with lsusb and sure enough the developer boards as USB devices are all there. It’s whatever the kernel driver usbsf is doing that’s seemingly forcing the device ttyUSB1 to immediately be dropped. It looks like an off-by-one bug but I can’t say that with certainty. The fact it’s happening right now is really annoying me. I have both Fedora 35 in a VM with kernel 5.17 and Ubuntu 22.04 in another VM with kernel 5.15. I’ll use them to see if they exhibit the same problem. If either Ubuntu or Fedora doesn’t exhibit this issue then Pop!_OS is off this machine to be replaced by one or the other. This is a one strike and you’re outa here issue. You don’t mess with my development environment. I’ve considered buying a System76 Linux machine in the past, but if I ever do in the future then I’ll buy it with Ubuntu installed. I’ll never recommend Pop!_OS again.

Update and Near Solution

Turns out it wasn’t completely Pop!_OS’ fault. The primary culprit is an application called brltty ( https://brltty.app ), a “background process (daemon) which provides access to the Linux/Unix console (when in text mode) for a blind person using a refreshable braille display.” It was automatically installed when Pop!_OS was upgraded, and is also part of the bog standard Ubuntu 22.04 installation, which is why it wound up in Pop!_OS.

Figure 1: Output portion of dmesg

I fired up my Ubuntu 22.04 VM and allowed it to access one of the ESP32-C3 developer boards. As Figure 1 shows it failed just like it had under Pop!_OS.

I ran dmesg to look at the tail of the log, and sure enough I saw the same failure mode. That’s when I went looking for brltty and why it was running on Linux. Folks, unless you’re a blind developer, you don’t need to have this running at all.

I also tried this on my Fedora 35 VM. Because Fedora didn’t have brltty running it mapped the developer board’s USB port to a tty port just fine. I checked to see if it was installed, and it wasn’t. I hope and pray that brltty doesn’t show up in Fedora 36 or any future Fedora release.

To remove brltty from Ubuntu execute in a shell sudo apt remove brltty. This worked for Ubuntu and allowed the USB port mapping to function properly.

Update for Pop!_OS

What works for Ubuntu won’t work for Pop!_OS. Try to remove brltty and you will remove all the many bits that support the desktop, thus disabling graphical login. Instead, I had to use systemctl to shut down and full disable the service. I found these instructions on a Reddit forum:

$ sudo systemctl stop brltty-udev.service$ sudo systemctl mask brltty-udev.serviceCreated symlink /etc/systemd/system/brltty-udev.service → /dev/null.$ sudo systemctl stop brltty.service$ sudo systemctl disable brltty.serviceUnit /etc/systemd/system/brltty.service is masked, ignoring.

This disabled both parts of the brltty service (!) and allowed my ESP32 development boards to properly connect. What I’m afraid of is that any future Pop!_OS updates will re-enable the service and I’m going to have to go through this process all over again.

I’ve made up my mind. I’m waiting for Fedora 36 to be released so I can install it in one of my VMs. If it looks solid then I’m switching over to Fedora from that point forward. As I wrote about above, this isn’t a part of Fedora. One other fact that makes my blood boil is that this is a known problem that goes back to at least 2011. Over ten years of this cropping up intermittently.