Overview

Physical controls for a more enjoyable media playback experience.

Features

• Responsive volume knob & mute button.
• Transport controls (play/pause, stop, FF/REW, skip tracks).
• Pair up with your favourite Bluetooth® speakers.
• Quick, physical connection (don't have to go through menu system to pair with keypad & speakers).
• Customizable controls/scheme.

This project tries to improve over the original "Media hub" presented here.

• More compact design
• Bigger volume knob - not interfering with macropad keys.

🛒️List of main material/hardware

(See section "More tools/materials/hardware" near the end of this note for extras)

Let's start with the Debug Header, the little 3 pin interface lets you peek into the Pons of the Raspberry Pi brain. You can find this header on the Raspberry Pi 5, the Raspberry Pi Pico (H, and WH), and now happily the Adafruit RP23XX boards thus far. By connecting a Pico Probe to this interface, you can get a lot of debug information back on your big main computer. ARM refers to this type of interfacing / debugging as Semihosting.

With the 3-Pin JST cable, cable plugged into the D header on the Pico Probe and the other end of that cable onto the Debug Header on your Feather (Shown above); With the Pico Probe connected to your computer, and you can connect the Feather to any USB power source, or back to your computer as well. Once you've done that, you're ready to issue the cargo run command, so long as you have the required software installed below.

Back to the code we cloned all of the way at the top of this article. With all of the software above installed, and your computer connected to the debug probe, the probe connected to the feather, and the feather connected to power or your computer you now have a system that is ready to go. We really can run that cargo run command and have Rust code on our feather. But what are all of these files and what do they do?

.cargo/config.toml and cargo run

The .cargo/config.toml file configures cargo run to use probe-rs to flash to the boards ROM. You will need a Raspberry Pi Debug Probe in order to use this, but it makes development MUCH easier, faster, and more fun! You connect the Debug Probe's D (for debug, D for defmt 😉) side to the board's Debug Port. Once done connect the Adafruit board, and Debug Probe to your computer. You can flash at will with cargo run and see any debug messages in your computer's terminal thanks to defmt.

memory.x

If you've never seen a memory.x file before, and have no clue what it is; I don't blame you for being curious. It's an odd file, filled with things that aren't Rust or C, or anything else that fits the norm. This file actually tells the linker where to put sections of the binary. It makes sure everything is in order so that when the microcontroller jumps to flash memory, the expected data is there ready for it. It also tells the the linker how much RAM the target board or chip has.

build.rs

This build script copies the memory.x file from the crate root into a directory where the linker can always find it at build time. For many projects this is optional, as the linker always searches the project root directory -- wherever Cargo.toml is. However, if you are using a workspace or have a more complicated build setup, this build script becomes required. Additionally, by requesting that Cargo re-run the build script whenever memory.x is changed, updating memory.x ensures a rebuild of the application with the new memory settings.

This guide shows how to make an IoT toggle switch with an Adafruit Feather TFT ESP32-S3, Zephyr, and Adafruit IO. Key features include: GPIO input for Boot button, LVGL graphics, MQTT over WiFi with TLSv1.2, and USB serial shell commands for saving WiFi and MQTT configuration settings to NVM flash. This guide is intended for people who want to learn how to write applications in C using Zephyr APIs.

Demo video: IoT toggle switch: Zephyr + Feather TFT + Adafruit IO

Previously in this series of guides about using Zephyr on Adafruit hardware, I focused on setting up developer tools and writing Devicetree board definitions. This time, I'm moving up the stack to show how to build an application tying together several Zephyr APIs along with a custom board definition.

Building an IoT app with WiFi, TLS, and graphics is unavoidably a bit complicated. It took me about three weeks to write the code, which totals a bit over 2100 lines. Listing all of that here would be awkward. If you want the details, you can browse the code in my zphqst-03 GitHub repo. The code has lots of comments, including citations for the references I used while learning to use the Zephyr APIs.

This guide will focus on:

1. How to build, run, and configure the IoT toggle switch app
2. High level tour of the source code with GitHub links: which files do what?
3. Understanding C language features that you'll need to use Zephyr APIs effectively: structs, function pointers, etc.
4. Zephyr troubleshooting tips: diagnose and fix memory allocation issues, enable various types of debug logging, etc.
5. MQTT testing with openssl and the mosquitto MQTT broker with its companion command line tools, mosquitto_pub and mosquitto_sub

Overview

With all the newest features of Adafruit IO, WipperSnapper firmware, and the new Blockly Actions, you can create really complex projects without writing a single line of code. I've been working on a couple versions of smart lights to notify me of different things using NeoPixels. This project will focus on a super easy smart ambient lighting system that you can stick to the back of your computer monitor.

Components

Using just a few Adafruit components is all you need to create a really simple, but pretty powerful little notification system. We are gonna use a QT Py ESP32-S2 WiFi Dev Board to talk to Adafruit IO, a NeoPixel BFF for the QT Py, and finally a short NeoPixel strip with a JST connector pre-attached (so you can connect right up to the BFF board.

The only soldering you will need to do is to attach the boards together. You can solder the boards together with the included pins, or pick up some female headers so you can detach the boards and use them on any future projects.

If you're working an office job, you're...in an office. Whether that's in your home or not, I'm going to hazard a guess that it's also indoors - and being indoors for an extended period of time without well-ventilated spaces can legitimately lead to low air quality (and in theory health issues).

Now, I'm not hear to spread fear and make you all think you're dying a slow death by breathing in your co-worker's exhalations. However, I am here to show off an easy way to build a cloud-connected indoor air quality system with:

1. A variety of Adafruit air quality sensors.
2. A Blues Notecard to cloud-connect the project with LTE connectivity.
3. Adafruit IO to visualize air quality data and integrate with other services.
4. A Philips Hue LED strip to provide real-time visuals for low air quality alerts.

Gradient is a node-based editor designed for use with Autodesk Fusion 360. 

I started working on Gradient after playing with the node based geometry in Blender. The nodes in Blender are fantastic (frankly they work much better than mine do right now) but I wanted  to create algorithmically defined geometry right in Fusion 360 using solids and surfaces which are better suited to making 3D models for technical and engineering parts. I wanted to be able to make algorithemic structures that are user defined but and can be finely controlled and tuned to the design needs.

Models like this would be very time consuming to model by hand. However they can be quickly generated and re-generated with different parameters or random seeds.

If you are interested in trying Gradient for yourself you can download it from the github repository below. Please be aware currently Gradient is in an early development stage, meaning only a small fraction of its functionality has been implemented, and there are likely a few bugs to sort through.

Gradient github

I had an Adafruit Huzzah and an OLED FeatherWing 128 x 64 in my box of goodies and decided to make a smart digital clock for my study.

The clock is connected to internet via WiFi, synchronises the time and via an api displays the temperature in my area. It is set to update every 5 minutes. Also displays an icon of the current weather. 

These are parsed from the api response:

{"coord":{"lon":yyyyyy,"lat":xxxxx},"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"base":"stations","main":{"temp":1.03,"feels_like":-1.33,"temp_min":0.57,"temp_max":2.64,"pressure":1039,"humidity":76,"sea_level":1039,"grnd_level":1034},"visibility":10000,"wind":{"speed":2.06,"deg":170},"clouds":{"all":0},"dt":1738790391,"sys":{"type":1,"id":1440,"country":"GB","sunrise":1738742403,"sunset":1738773892},"timezone":0,"id":3333224,"name":"xxxxxx City","cod":200}

Next I created a 3D printed bezel that allowed me to fit the stacked boards in my workbench pannel.

As part of a series on Zephyr with Adafruit hardware, this guide shows how to configure Zephyr to use an ST7789 TFT display with a Feather RP2350. By connecting the display with a breadboard, we can use a logic analyzer to verify that the Zephyr display driver pin configuration agrees with the CircuitPython display driver. This guide is meant for people interested in adding support for Adafruit displays to Zephyr.

Parts

Overview

Physical controls for a more enjoyable media playback experience.

Features

• Responsive volume knob & mute button.
• Transport controls (play/pause, stop, FF/REW, skip tracks).
• Pair up with your favourite Bluetooth® speakers.
• Quick, physical connection (don't have to go through menu system to pair with keypad & speakers).
• Customizable controls/scheme.
• Customizable setup: Optionally connect USB hub/dock for added features, for example:
  • mirror phone to TV w/HDMI out: Watch videos on a bigger screen
  • add keyboard: Better typing experience for texts/emails.
• Solderless project.

Main hardware

Program your device

To get your RP2040 macropad to act as a media controller, it needs to:

1. detect keypresses and changes in the knob position
2. send out corresponding keyboard messages to the attached USB host device (ex: a phone).

My own implementation for this "media hub" is written for Adafruit's CircuitPython, and can be found here:

• 💾 MediaController project README (see MediaHub_AFMacropad). 🚀 Installation instructions.

As part of a series on Zephyr with Adafruit hardware, this guide shows how I made a pogo pin SWD debug probe adapter for the CLUE board so I can conveniently program it with Zephyr firmware. My other SWD option was soldering wires to the test points, but I like how pogo pins are neater and less fragile. This guide is meant for people interested in adding support for Adafruit boards to Zephyr. It might also be useful for folks who want to fix a bricked bootloader.

Overview

As part of a series on Zephyr with Adafruit hardware, this guide shows how to write a Zephyr board definition for the Adafruit Feather RP2350 with an I2C SHT41 temperature and humidity sensor. Future guides will look more at using sensors and displays. This is intended for developers who want to know about adding support for Adafruit boards to Zephyr. If you just want to write CircuitPython code, you can safely ignore this stuff.

Overview

The OM Weather Display periodically updates and displays the following local weather conditions:

• Day, date, and time (AM/PM)
• Tomorrow's sunrise and sunset times
• Temperature
• Relative Humidity
• Wind speed and direction
• Wind gust speed
• Condition description and graphic icon

Location, time zone, and measurement units settings are stored in the settings.toml file. Either "METRIC" or "IMPERIAL" measurement units can be specified.

Weather condition query and internet clock refresh interval rates are set by parameters in the code.py module. The default interval for updating weather conditions is 5 minutes. The local time is updated from the Adafruit Network Time Protocol (NTP) server hourly.

The CircuitPython code runs on an ESP32-S3 4MB/2MB Feather attached to a 2.4-inch TFT FeatherWing. An optional ALS-PT19 ambient light sensor can be used to automatically adjust display brightness.

CircuitPython Code

The Weather Display's CIRCUITPY root directory contains the following files and folders.

• files:
  • settings.toml -- Wi-Fi and location parameters
  • om_query.py -- OM API URL query string builder
  • who_to_map_icon.py -- parses the WMO weather code for descriptions and icons
  • code.py -- the primary code module
• folders:
  • fonts -- contains the font files
  • icons_160x160 -- the weather icon bitmap graphics files
  • lib -- the CircuitPython library modules
  • sd -- a placeholder for the unused SD storage drive

A downloadable bundle of code files and folders can be found in the OM Weather Display GitHub repository.

Materials

The following parts are used to build the MiniMarquee:

• QT Py ESP32-S2
• IS31FL3741 13x9 PWM RGB LED Matrix
• 50mm Stemma QT cable
• Black LED acrylic, 2-3 mm thick, cut to 41mm x 29mm
• 4 M2x12 nylon screws and nuts
• Little rubber feet
• Nitto double-sided adhesive tape (or other tape with similar adhesive strength)
• 2 1-ounce wheel weights (optional)

Installing Firmware

The MiniMarquee's firmware is written for Arduino in PlatformIO. There are two ways to install the firmware onto the QT Py ESP32-S2:

1. Drag-and-drop UF2 installation
2. Build source code and install onto device

The UF2 method is recommended, as it is very simple and does not require downloading any additional software or dealing with any code at all. However, if you wish to customize your MiniMarquee's firmware, you'll need to go for option 2 and build it from source.

I was working with one of Adafruit's CNC Rotary Encoders and made a mistake wiring. Well, long story short, I killed it. I am not sure exactly what I did, but I suspect I accidentally drove its outputs with an improper voltage.

To prevent the experience from being a total loss, I took the time to partially disassemble it.

The plastic cover around the screw terminals can easily be removed, exposing a PCB. 3 pins hold this PCB onto the rest of the assembly. After desoldering them, the component side of the board can be seen.

The board features a "7550" voltage regulator. The incoming supply is regulated down from whatever it is to 5V for the internal circuitry. C2 is the input smoothing capacitor, and C1 is the output smoothing capacitor.

D1 and D2 are light emitting diodes in series (likely IR) which are positioned under matching sensors in the upper part of the assembly. A "331" (330Ω) resistor limits the current through the LEDs.

The 3 soldered positions are a supply and 2 returns from the sensor package in the upper part of the assembly. Resistors R2 & R3 are pull ups, while caps C3 and C4 smooth out any spurious transitions of the signals. It seems most likely that the sensor assembly consists of two phototransistors, which can pull the pins of the "HC14", a schmitt-trigger inverter. This creates the signals A and B at a dependable logic level, and also the inverted A/ and B/ signals.

Diode D3 is a reverse current protection diode; in case VCC and GND are swapped, no current can flow. Interestingly it's on the GND side, while I thought it was more common to see on the VCC side.

If I cared to determine which component(s) I damaged, this is totally a board that could be reworked by hand. However, I don't plan to spend the time and instead will just pick up a fresh encoder from the store—and double check my wiring next time.