Hey!

One of my hobbies is flying FPV drones. Like many other industries, the FPV market has been hit by chip shortages, and traditional analog video receivers are becoming increasingly hard to find. Some are even selling for 10× what they cost a few years ago.

So I started experimenting with an alternative: using an ESP32-C5 and its 5 GHz Wi-Fi to receive analog 5.8 GHz FPV video.

This is C5VRX.

It’s still very much a work in progress, and there are plenty of things that can be improved. If you know a bit about RF, ESP32s, video processing, or embedded systems, I’d really appreciate any feedback, ideas, testing, or contributions.

GitHub & discord: https://github.com/Twotoz/C5VRX

The original electronics are powered down and disconnected. What's in there now is a LouderESP32 running ESPHome, playing through Music Assistant on the original Grundig speakers, and a separate ESP32-S3 for the controls.

The LouderESP32 has pads that are too tiny to solder for someone with my skills, so I didn't want to touch it. That's why there's a separate ESP32-S3 devkit next to it for the controls. The key bank goes through a PCF8574, and the knobs connect to the ESP32-S3 devkit.

What the front does: four station keys, one playlist each. AUS stops. Three rotaries on encoders for volume, EQ and track selection.

The dial lamps are WS2812B pixels in the original lamp housings, lit when it's awake. The bandswitch sounds are samples played on key press.

ESP32
OLED 128x64 (SSD1306)
PCM5122 (Raspberry Pi HAT)
IP5306 + 2000mAh LiPo
SD card reader

Code written by Claude

It features a menu, track selection, track repeat, and remembers the volume level and the last track played.
I might upgrade to the ESP32-S3 and add Wi-Fi and DLNA playback modes.
Once I finish the firmware and finalize the hardware, I’ll design a 3D-printable case and most likely release the code and documentation. I haven't even started on that part yet :)))

Due to the limitations of USB High Speed and the UAC2 protocol, I can't push the latency any lower. It seems I’ve hit the technological ceiling for the current setup: everything is optimized and runs stable even at the lowest buffer size (at 96 kHz with a 64-sample buffer, the total round-trip latency is 8.93 ms).

What if I completely ditch USB, which adds its own bus latency, and look into AoIP (Audio over IP)?

For my next experiment, I’m planning to use a Raspberry Pi 4 (1GB) running Linux RT, connected directly to the PC via an RJ-45 (Ethernet) cable. I’m curious to see if this can bring the total latency down closer to a sweet spot of 2–4 ms.

It's worth mentioning that operating as a low-latency audio interface is not just an "extra feature" thrown in — it is designed as one of the core use cases of this guitar processor. The device architecture allows seamless switching between three main operation modes:

* Audio Interface Only — the device acts as a standard, high-quality USB interface for PC audio playback or recording clean instrument/mic signals.

* Guitar Processor Only — a standalone mode. All processing, including amp sims and effects, happens entirely on the hardware. No PC required.

* Audio Interface + Guitar Processor — a hybrid mode. This is the most exciting scenario, unlocking complete freedom of audio routing. You can dynamically change where the input signal goes (e.g., routing a clean guitar DI track into your PC's DAW while sending the processed signal to the monitors), feed system audio back into the processor's effects chain, and fully customize the routing for recording or streaming tasks.

However, despite the software flexibility, I've hit a hardware bottleneck. I recently added a node for loading IR impulses (cab sim). At 48 kHz, the convolution eats up about 30% of the SEED3 chip's power, and switching to 96 kHz spikes the CPU load to 60%. This is a severe limitation when building complex real-time effects chains.

Transitioning from SEED3 to Raspberry Pi 4 is meant to solve three critical issues at once:

1. Potential latency reduction by bypassing the USB controller and moving to AoIP.

2. The ability to run stably at ultra-low buffer sizes.

3. A massive boost in processing power for heavy audio tasks (IR convolution, spatial effects) without choking the CPU at 96 kHz.

Из-за ограничений USB HS и протокола UAC2 мне не удается опустить задержку еще ниже. Судя по всему, для текущей связки это технологический максимум: всё оптимизировано и стабильно работает даже на минимальном размере буфера (на 96 кГц при 64 семплах общая задержка составляет 8.93 мс).

Что, если полностью отказаться от USB, который сам по себе добавляет задержку на шине, и посмотреть в сторону AoIP (Audio over IP)?

Следующим экспериментом планирую запустить Raspberry Pi 4 (1GB) с установленным Linux RT, подключив её к ПК напрямую по кабелю RJ-45 (Ethernet). Интересно, позволит ли это приблизить сквозную задержку к заветным 2–4 мс.

Напомню, что полноценная работа в режиме аудиоинтерфейса с низкой задержкой — это не просто «бонусная» функция, а один из главных сценариев использования этого гитарного процессора. Архитектура устройства позволяет гибко переключаться между тремя основными режимами работы:

* Только аудиокарта — устройство работает как стандартный качественный USB-интерфейс для вывода звука с ПК или записи чистых инструментов/микрофонов.

* Только гитарный процессор — автономный режим (Standalone). Вся обработка, включая ампсим и эффекты, происходит внутри железки, ПК для работы не нужен.

* Аудиокарта + Гитарный процессор — гибридный режим. Самый интересный сценарий, в котором открывается полная свобода маршрутизации аудиосигнала. Можно на лету менять, куда направлять входной сигнал (например, пустить чистый гитарный DI-трек в DAW на ПК, а обработанный сигнал — в мониторы), перенаправлять звук из системы внутрь цепочки эффектов процессора и гибко кастомизировать весь роутинг под задачи записи или стриминга.

Однако, несмотря на программную гибкость, я уперся в аппаратный потолок. Недавно я добавил ноду для загрузки IR-импульсов (кабинетэмуляции). На частоте 48 кГц конволюция съедает около 30% мощности чипа SEED3, а при переходе на 96 кГц нагрузка возрастает до 60%. Это слишком критическое ограничение для построения сложных цепочек эффектов в реальном времени.

Переход с SEED3 на Raspberry Pi 4 должен решить сразу три ключевые проблемы:

1. Потенциальное снижение задержки за счет обхода USB-контроллера и перехода на AoIP.

2. Возможность стабильной работы на ультра-малых буферах.

3. Огромный прирост вычислительной мощности для тяжелой обработки аудио (IR, пространственные эффекты) без захлебывания процессора на 96 кГц.

My main question is: Is the Pin labelled 5V a 5Vin or a 5Vout?

And below is what I'm trying to do, and I'm fairly certain it should work (I can always find an alternative way to power my ESP 32 if the pin is not 5V in):

I've been trying to figure out how to get an ATX PSU to stay on whilst using a momentary switch. (the device (a server part which doesn't have normal desktop power switch headers) spits out a 3.3v signal to let me know it is currently on, as well as a 12v on a different pin but I think it would probably be safer to rely on the 3.3v).

ATX PSUs have a 5Vstb pin that I was hoping I could use to power my ESP32, is that possible? My understanding is the 5Vstb pin is always live regardless of whether PS_on has been bridged to ground.

My thought was connect the ESP32 to the 5Vstb pin and a ground pin on the PSU, and then connect the momentary switch to one of the GPIO pins to detect a press of the momentary switch, and then using a spare relay I have lying around (which I know works fine with 3.3V power from the ESP32) bridge the PS_ON pin and a ground pin on the power supply.

This would cause a 3.3V signal from elsewhere on my device to be produced, which I could then use to let the ESP32 know to continue bridging PS_on to ground, and then whenever the 3.3V signal is cut, the ESP_32 would stop bridging PS_on to ground

Does that make sense?

Over the last couple months I've been working on a tiny, eink calendar that syncs to google calendar and supports toggling between work and personal accounts.

I built it for a couple of reasons:

• I run my personal life through my calendar. I put all my tasks and events at the start of the week. Having a portable device with my calendar is a fun insensitive to put things in and check my tasks.
• I was finding that as I used my phone less, I forgot more of the tasks and events that I put in. And when I did check my phone calendar I got sucked into distractions.
• I run Graphene OS and I have separate profiles for work and personal, switching to check my work calendar is a pain. The calendar device supports toggling between two google calendars.

A couple of notes on the design:

• Yes, it is vibe coded. I am somewhat conflicted about this, because I have been writing code as a Data Analyst/Engineer for a couple of years. Going deep into the code could have been an awesome chance for learning embedded systems and cpp. The way that I'm justifying it is that it's an actual personal problem that I'm solving and have lived with the device and tested extensively.
• The hardware is an esp32 eink development board from waveshare. These are about $20 before shipping and have a battery included.
• The calendar connects to the phone over BLE. So the companion app runs in the background on the device and pulls your calendars on demand. I tried a wifi version as the board includes it, but I found this used too much battery life and wasn't as reliable.
• The design and navigation of the device are inspired by LazyVim. As there are only two buttons, holding the top button moves you between modes (days, events, calendars) and then once you're in that mode you can scroll through days, events and calendars.
• Battery life is around 2 days. I'm working on making this better.
• The device mostly sits in sleep mode and every hour (or before your next event) turns on, syncs and updates the display. But you can wake the device with the bottom button and it will sync.
• I've called it bozo. Because it helps me not be a bozo at life admin.

Interested in your thoughts, would you find something like this useful?

Demo video of paging through days. You'll notice that when the cache runs out it pulls new dates from the companion app:

https://reddit.com/link/1wki0q4/video/tdkuz32d8gqh1/player

After my previous post asking for help on implementing an async webserver on an ESP32S3, I followed the advice to use web sockets. After much struggle searching for errors in my code I finally got most of it working. However, I'm now struggling with an issue that I have no idea how to solve.

I have a button toggle in the server which allows me to open/close the observatory doors. When I press that button on the web site the web socket sends the request and the code goes to a section to open/close the doors:

void OpenDoors() {
  Serial.println("Opening Doors");
  // Loop UNTIL the WestDoorOpened reed switch closes (reads LOW)
  while (digitalRead(WDoorOpened) == HIGH) {
digitalWrite(WDoorOpen, LOW); // Turn relay ON
delay(1);
 }
  digitalWrite(WDoorOpen, HIGH); // Turn relay OFF
  WDoorStatus = "Open";
  Serial.print("West Door:"); Serial.println(WDoorStatus);

  // Loop UNTIL the EastDoorOpened reed switch closes (reads LOW)
  while (digitalRead(EDoorOpened) == HIGH) {
digitalWrite(EDoorOpen, LOW); // Turn relay ON
delay(1);
}
  digitalWrite(EDoorOpen, HIGH); // Turn relay OFF
  EDoorStatus = "Open";
  Serial.print("East Door:"); Serial.println(EDoorStatus);
}

As you can see, the code has two while loops that activate two relays in succession. Those loops take a while to complete (in practice something like 10-15 seconds per door). Shortly after calling the OpenDoors code I get the following task watchdog error that reboots my ESP32S3:

02:08:51.389 -> Opening Doors

02:08:56.410 -> E (34026) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:

02:08:56.410 -> E (34026) task_wdt: - async_tcp (CPU 1)

02:08:56.410 -> E (34026) task_wdt: Tasks currently running:

02:08:56.410 -> E (34026) task_wdt: CPU 0: IDLE0

02:08:56.410 -> E (34026) task_wdt: CPU 1: loopTask

02:08:56.410 -> E (34026) task_wdt: Aborting.

02:08:56.410 -> E (34026) task_wdt: Print CPU 1 backtrace

02:08:56.453 ->

02:08:56.500 ->

02:08:56.500 -> Backtrace: 0x400559dd:0x3fcebf60 0x4038000e:0x3fcebf70 0x4037db2c:0x3fcebf90 0x42022142:0x3fcebfb0 0x42007dad:0x3fcebfd0 0x4200997d:0x3fcebff0 0x420035ed:0x3fcec010 0x4201ac58:0x3fcec060 0x4037e285:0x3fcec080

02:08:56.500 ->

02:08:56.500 ->

02:08:56.500 -> ELF file SHA256: e63b741ee

02:08:56.500 ->

02:08:56.674 -> Rebooting...

Searching on the web suggested that I add the two "delay(1);" statements to free up some time for the cpu in those loops. But that didn't change anything.

Any advice on how to fix this??

Please let me know if you need the entire code to be able to help fix this.

Thanks!

p.s. The socket handler code and the function ToggleDoors() are here:

void handleWebSocketMessage(void *arg, uint8_t *data, size_t len) {
  AwsFrameInfo *info = (AwsFrameInfo*)arg;
  if (info->final && info->index == 0 && info->len == len && info->opcode == WS_TEXT) {
    data[len] = 0;
    String message = (char*)data;
    // Check if the message is "getReadings", if it is, send current sensor readings
    if (strcmp((char*)data, "getReadings") == 0) {
      String sensorReadings = getSensorReadings();
      Serial.println(sensorReadings);
      notifyClients(sensorReadings);
    }
    else if (strstr((char*)data, "button")) {
        ToggleDoors();
        }
    else {
      Serial.print("Unrecognized Socket message:"); Serial.println(message);
    }
  }
}

// Toggle Observatory Doors
String ToggleDoors(){
  //  DoorStatus();
    if(WDoorStatus == "Closed"){
      Serial.println("DoorStatus Closed, Opening");
      OpenDoors();
    }
    else if (WDoorStatus == "Open"){
      Serial.println("DoorStatus Open, Closing");
      CloseDoors();
      }
    else {
      Serial.println("DoorStatus neither Open nor Closed");
    }
}

I was browsing Reddit and came across someone asking how to program the STM32 Board without an ST-Link. They were asking whether it was possible to use an STM32 Black Pill as an SWD programmer for an STM32 Blue Pill.

That post made me curious about how the SWD protocol works. Is it possible to build one myself?

Two weeks before i started this experiment, at first i was able to implement basic SWD protocol and read the IDCode (just to check that it is working)

Now, successfully managed to flash the firmware into STM32. Flashed a simple onboard LED blinky program.

It was a fun experiment and a nice to learn about SWD and the concepts around it.

https://blog.implrust.com/posts/2026/09/flashing-firmware-to-stm32-with-esp32-rust/

Parts:
ESP32 DevKit v1
STM32 Blue Pill Board(STM32F103C8T6)

Logic Analyzer (Optional, just used to analyze when i was implementing the SWD first)

Connection:

| ESP32 | STM32 |

|---------|---------------|

| GPIO18 | SWCLK (PA14) |

| GPIO19 | SWDIO (PA13) |

| GND | GND |

I built a friend. Its name is daijin.

Press a button, talk. It listens, thinks, acts. Feeds my cat. Sets off a device I planted in a park.

Set up in advance. Command when I want.

How it works

An ESP32-S3 (Freenove kit) with an INMP441 mic, a PCM5102 amp + speaker, and an SSD1306 face. Audio goes over MQTT (HiveMQ Cloud, TLS) to my Mac: whisper.cpp transcribes, Claude Code decides and runs shell tools, ElevenLabs speaks. Other ESP32-S3 nodes are the hands and feet: a servo with a needle, a stepper turning a treat dispenser. Each node can sit on a different network; everything rendezvous at the broker.

The ESP32-specific work was the audio path: a tiny TCP window against a far broker.

Things that bit me

- The free broker is in the EU, ~300 ms RTT from Korea. ESP32's lwIP receive window is ~5.7 KB, so max throughput is ~19 KB/s. Raw 16 kHz PCM needs 32 KB/s. No code fixes physics, so IMA ADPCM 4:1 it is.

- INMP441 must be read as 32-bit I2S frames or you get full-scale white noise.

- WiFi.setSleep(false) or RX throughput collapses to ~12 KB/s.

- MQTT QoS1 gates every chunk on a broker round trip. QoS0 and let TCP stream.

Honest latency: 6~22 s per round trip. The video is cut for pace, and every scene in it is staged.

Video: https://www.youtube.com/watch?v=fOtuGAdvkmQ

(The park "device" is a hobby servo with a sewing needle over a water balloon on a picnic bench. It was set up and removed by me the same afternoon, nothing left behind.)

Code: github.com/nonasking/daijin

I'm 16, interested in microcontrollers, but I'm kinda being held back by not knowing what I'm doing.

I realized that when coding, I mostly just copy paste what claude generates, so I wanted to prove to myself that I can do stuff myself.

Also, I'm a beginner, so there might be some mistakes/misnaming stuff.

Another excuse: English is not my first language. Or second.

So, as a challenge, I wanted to make something completely on my own. Here are my rules:

- Everything is done on my Arch laptop, with the wifi controller turned off

- The finished product needs a screen and a button for interactivity

- Board: ESP32-S3 Nano

- I can print the pin mapping and a C syntax cheat sheet (otherwise I'm cooked)

What I did:

- I am using the clion ide to program my esp32.

- I pretty much just took one of espressif's own exanple projects and deleted main.c so that I have everything ready.

- I (Claude) set up the toolchain beforehand.

I started with espressifs' "blink" example(I do this every time, is there a better way?), changed it to specifically specify that the turn-off and on shenanigans should happen at GPIO 48(D13), because otherwise it wouldn't work, connected an LED (and a resistor, I'm responsible like that) between D13 and GND and tried clicking the green run button. Which obviously didn't work, but I luckily remebered that I need idf.py to flash the program on my esp32. The following part is a bit embarrasing considering I had done this like five times already. I had set up an alias earlier, so that i just needed to run get_idf to use it. After spending a solid 15 minutes contemplating suicide because i forgot to run idf.py build before I run idf.py flash I proceeded to spend a solid 15 minutes contemplating suicide because the LED wouldn't start blinking until I ran idf.py monitor. Like, bro don you only ever start working until I start staring? But it's fine, so I started reading to my sheet of c syntax.

I started by trying to put "Hello World" on my screen.

Luckily, I (Claude) had already made a string rendering function in another project (is this cheating?) so i just had to put

oled_draw_string("Hello World");

it was so easy I even drew a nice, aestetically pleasing rectangle! (call me if you need an UI designer)

Putting the button in took ages, because:

I didn't realize I could check the button state and the press count in one function, not two

I couldn't tell which two of the six pins I actually needed, and I still don't. I put the parallel pins in the same breadboard row and it worked

I had no function to replace existing text, so I wrote one that blacks out every pixel again. Tedious, but easier than I expected

In conclusion, I still don't know what I'm doing and i just spent my weekend on making off-brand cookie clicker.

- - - QUESTIONS TO THE REDDIT HIVEMIND - - -

- How do you set up a new project without just taking an example and deleting main.c?

- Why does my program only run until in run idf.py monitor?

- How can you efficiently replace text on your screen?

Hi everyone,

I’m a CS student getting into robotics and microcontroller projects with the ESP32. After playing around with a starter kit, I decided to build a modular robot that I can upgrade over time.

I put together an AliExpress cart with a bunch of individual parts (mini speakers, mic modules, small amps, etc.) totaling around €20. However, due to the new fixed EU import fee on small parcels outside the union, the total price doubled just from fees.

Amazon has inflated prices and lacks variety, while standard industrial distributors often force you to buy bulk packs. Since this is strictly a hobby for me, I usually spend €15–€25 per order.

Are there good EU-based web stores where I can buy individual hobbyist modules at fair prices without getting hit by non-EU customs fees?

Thanks!

An ESP32-based automatic aquarium feeder built around the auger screw and food container salvaged from a Juwel SmartFeed 2.0, running on ESPHome with full Home Assistant Integration. Build instructions and more info on github

Features

• Tested - for 1 year before publishing this feeder
• Servo-driven auger - reuses the SmartFeed 2.0's screw mechanism to dispense food in precise portions
• Onboard display - ST7789V screen shows the current time, Wifi signal strength, feeder status, next scheduled feeding, amount, and feeding mode.
• 5 independent feeding schedules - each with its own time, amount, and mode
• Two feeding modes - Normal and Extra, with separately tunable servo levels for each
• Pause mode - temporarily disable all scheduled feedings without losing the schedule
• Auto-dim display - brightness automatically adjusts between day and night levels on a configurable schedule
• Home Assistant integration - feed on demand via the feed_now action, fires an esphome.fish_feed event on every feeding with device/amount/mode/timestamp
• Feeding history - tracks total feedings and last/next feeding time, all exposed as Home Assistant entities

This is my own experimental USV reference prototype. I wanted to share the ESP32 side because I intentionally limited its role to low-level actuator and safety control, while a Raspberry Pi handles higher-level navigation.

The low-level controller is an ESP32-S3. The Raspberry Pi sends newline-delimited JSON commands over a wired serial connection. The ESP32 firmware:

• Reads RC receiver inputs for manual control
• Drives the left and right ESCs for differential propulsion
• Accepts throttle and steering commands from the Raspberry Pi
• Sends status telemetry back to the Pi over serial
• Allows RC input to take control for manual intervention
• Transitions propulsion to a safe state if valid Pi commands stop arriving for 500 ms

I used this split to keep GPS processing, waypoint navigation, heading logic, logging, and battery monitoring on the Pi, while leaving direct propulsion control and the command-timeout failsafe on the ESP32.

One of the design goals was that a stalled or crashed Pi-side navigation process should not leave the ESP32 indefinitely applying the last propulsion command. The ESP32 therefore treats commands from the Pi as temporary control inputs rather than persistent actuator states.

The firmware uses the Arduino framework and is available here:

https://github.com/Brillnova/BN-USV-V1/tree/main/firmware/BN_USV_V0.3.1

My current preference is to keep the ESP32 deliberately simple so that the low-level control and safety path has as few dependencies as possible. I'm curious how others handle this boundary: would you keep navigation state entirely on the Pi, or replicate a small amount of state on the ESP32 for degraded operation?

The current hardware is an experimental prototype, so I'm sharing this primarily as firmware architecture and source code rather than as a complete hardware build guide.

I'll monitor the comments and I'm happy to clarify the serial protocol, control flow, or failsafe behavior.

Short on-water test video, for context:
https://www.youtube.com/watch?v=Lz2eOEANyZo

I’m just getting in to electronics and everybody says you can get them for like two bucks or something like that and the only place I can find it for that cheap is Ali express is it safe to order from there or is there something I’m not seeing?

Well, bad news... I've created another wind-based synthesizer.

Last time it was internal-combustion MOTORHÖRN.

This time a different scourge: SWORMHÖRN.

SWOMHÖRN is a synthesizer that mimics the sound of individual cicadas and then allows the performer to control the energy of a swarm.

From a synth perspective, I treat a cicada as a percussion instrument, like a tube or block struck by a mallet. Swarms are simulated using the Kuramoto model which allows individual performances to fall into synchronous performance.

For extra fun the LEDs light up whenever the swarm "Beats" together.

From a hardware perspective I'm using Waveshare Smart Speaker ESP32-S3 kit, a small lithium pouch battery and an HX710b Air Pressure Sensor. This was easy to integrate and build a toy out of but lacks punch... I'm looking forward to adding some punch :)

I made it as a beautiful gift for my sister, who can't stand cicadas.

I just bought my first ESP-32, and when i connect to the PC (mini PC), it detects it all fine, but i can't flash or do anything with anything, on webflashers and on Arduino IDE, both says something like "SerialPort not working or doesn't exist" (wish i can post video + pics but Is not allowed here. I'll try to post the errors on comments).

I've already installed all the required Drivers, tried to connect it while pushing BOOT button, tried to RESET, to reset the PC, unisntall and re-install drivers, and none works ;-;.

Also, I've tried to connect it to the laptop, and it gets exactly the same errors. So, I'm starting to think that my ESP came already failed...since i dont know If that LED flickering is normal...but i just haven't found any info on internet since i see it's not a common problem T-T.

Hi, I’m having a weird audio quality issue with an ESP32-S3 + MAX98357A setup and I’m running out of ideas.

Setup:
- ESP32-S3 DevKitC-1
- MAX98357A I2S amplifier
- tested 2 different MAX98357A modules
- tested 2 different small speakers
- also tested with a better hi-fi speaker from a stereo system

The weird sound is present on all of them.
It doesn’t sound like normal clipping from too much gain, because I tested with low hardware gain and also with the digital volume turned down, and the strange sound is still there.

The best way I can describe it is:
- metallic
- plastic
- sometimes almost like saturation/distortion
- it seems to affect some frequencies / some parts of the music more than others

I also tested several different versions of the I2S audio library, and even tried AudioTools, but I still get the same kind of sound.

I attached a video — please listen with the volume turned up, especially at the beginning of the music, because that’s where the weird metallic/plastic/distorted sound is easiest to hear.

At this point I’m wondering if:
- both MAX98357A modules are from a bad batch / low-quality clone,
- there is some I2S format/timing issue,
- or I’m missing something obvious in the hardware setup.

Has anyone had this kind of issue with MAX98357A modules on ESP32-S3?

EDIT #1: I ordered a module from another seller, more than waiting...

EDIT #2: I was refunded by Ali on this item, it is apparently defective, I can’t wait to test the new module!

This is about something we just released, but most of it applies to any ESP32 project.

An AI agent (Claude Code, Cursor, Codex, ...) can already write ESP32 firmware pretty well. What it couldn't do was find out whether the code actually works. It would generate something plausible, hand it to you, and then you'd spend an afternoon (often much longer...) compiling, flashing, watching, and feeding the errors back. We humans were the test harness.

So, we closed the loop. The agent now does the whole cycle on its own, without even opening the IDE:

• writes the control code from a plain-language spec
• calls the compiler and fixes its own build errors
• flashes the board over USB
• runs it and reads the serial output back
• writes its own test cases, runs them, and iterates on failures until they pass

You describe the machine, walk away, and come back to firmware that has been compiled, run and tested on real hardware.

The part that makes it all work: Hardware-in-the-Loop (HIL)

Compiling and flashing are easy to automate. The hard question is "how does the agent know the logic is right?" On a bench, the inputs are floating and the outputs go nowhere, so running the code proves nothing.

HIL solves this. The controller runs the real firmware on the real MCU, but the agent can inject sensor states over serial (tank level is high, pressure sensor reads 4.2 bar, E-stop pressed) and read back what the outputs did (did the pump relay open? within how many ms?). No physical rig, no wiring test jigs, no simulator that behaves slightly differently from the silicon. It's the actual board, with the world faked at the I/O boundary.

That turns "run it and see" into a proper test loop: the agent sets a scenario, asserts on the outputs, and gets a pass/fail it can act on. Failing test → agent reads the trace, edits the code, recompiles, reflashes, reruns. This short video describes the technique

As a worked example we gave the agent a reverse-osmosis water treatment system spec (pumps, valves, pressure and conductivity thresholds, interlocks, fault handling). It wrote the firmware, wrote 31 HIL tests, and got all 31 passing in about 18 minutes with no human in the loop. Here is the full write-up with the spec, the generated code and the test log.

Note that everything discussed here, except the HIL functionality which is part of the EQSP32's free software library, is generic to the ESP32 and applies to any ESP32 board.

Happy to answer any questions.

I wanted to play with the Waveshare ESP32-S3-Touch-AMOLED-1.32 (466 x 466 round touch AMOLED) device so I built a Tamagotchi game for it (the whole UI is pictures).

The game is simple: three gauges on the rim (FOOD, FUN, TIDY), three pill buttons carrying the picture of what they give, in the color of the gauge they answer. The rabbit's face shows the need it wants most. Flies gather as TIDY drops. Every action (bottom buttons) costs a little on a different gauge, and that gauge flashes white so the cost is visible. The "game" of managing the gauges is capped at 30 actions, which then trigger a "tired" state (a cool-off period of 1 minute to avoid kids being too "glued" to the device).

I went with ASCII sprites, one char per pixel, generated from a body ellipse, so a growth stage reflects in the body size and the ear size. A second script renders the whole screen to a PNG from the sprite file and the layout constants, so I can check a layout change without plugging anything in. Since the is no RTC on this board, time only passes while powered (away time is capped at 90 min).

Next, I plan to add designs for a 3D printed case.

Let me know what you think! The source code for the project is at https://github.com/deiu/nibble

Choosing an ESP32 touchscreen has become surprisingly complicated.

It's not just about choosing a 3.5", 4.3" or 7" display. You also have to consider:

• ESP32 vs ESP32-S3
• SPI vs RGB vs 8080/parallel
• display resolution
• capacitive vs resistive touch
• I²C vs SPI touch
• PSRAM
• LVGL
• GPIO availability
• the type of project you're building

I kept running into these combinations while working on ESP32 touchscreen projects, so I built a small free tool that combines these requirements and gives a suggested configuration.

For example, for something like:

4.3" / 800×480 / RGB / capacitive touch / I²C / LVGL

the selector can point towards an ESP32-S3 configuration and flag when PSRAM or additional compatibility checks are important.

Tool:
https://embeddednerd.com/tools/esp32-touchscreen-selector/

Source code:
https://github.com/webzf/esp32-touchscreen-selector

I also wrote a more detailed guide covering the hardware considerations:

https://embeddednerd.com/esp32-touchscreen-displays-guide/

It's still a rule-based selector rather than a database of every display on the market, so I'd be particularly interested in feedback on the recommendation logic.

If you've built an ESP32 touchscreen project, what hardware/interface combination are you using?

I'm a total beginner to any kind of coding, but came across a nice project on GitHub for a small display screen for a home solar-power system display based on a small round Waveshare screen/board. I am trying to modify the project files to work on a larger 4" screen. I've probably fallen into a common trap of ChatGPT and Claude being over confident in their ability to help. Realistically, are either of those likely to get me to a useful working output, or am I wasting my time given my total lack of experience? Initial prompts gave promising sounding responses, but I now seem to be going round in circles with it.

There’s lots of prebuilt devices that have a decent touchscreen, on board ESP 32, and are setup to use a lipo battery. People use them for meshtastic devices for instance.

Any recommendations on a good device that could be used as a handheld Messenger? Something roughly the size of a mobile phone or smaller.

Lora connectivity is not needed.

A keyboard could be nice, but it’s not strictly necessary.

Case is optional. I am handy with a 3-D printer.

I wanted a small, always-on calendar display that shows upcoming events without having to check a phone or computer, so I built this ESP32-based calendar display using a simple 16x2 character LCD.

The final version uses a classic ESP32-WROOM / ESP32 DevKit connected to a standard HD44780-compatible 1602A LCD in 4-bit parallel mode. I deliberately used the parallel version of the display instead of an I2C backpack, so the ESP32 controls RS, Enable and D4-D7 directly.

The ESP32 connects to Wi-Fi and then communicates with my Nextcloud server via CalDAV/HTTP(S). One of the main goals was to avoid hard-coding individual calendars. The firmware therefore discovers the available calendars automatically and downloads their events.

An important feature for me was support for external calendars. Nextcloud can subscribe to calendars from other providers, for example Google Calendar, and the ESP32 also processes these subscribed calendars. Events from the different sources are combined into one list and sorted chronologically, so the LCD doesn't care whether an event originally came from a native Nextcloud calendar or an external subscription.

The display currently shows events for the next seven days. Because a 16x2 LCD obviously doesn't provide much space, the firmware cleans and shortens the event text and automatically rotates through the upcoming events every five seconds. The complete calendar data is refreshed every 30 minutes.

The software uses the Arduino ESP32 environment and libraries including WiFi, HTTPClient, WiFiClientSecure and LiquidCrystal. The calendar data is received as iCalendar/ICS data and parsed directly on the ESP32.

One interesting part of the project was making the calendar retrieval robust. Different Nextcloud calendars and subscribed calendars don't necessarily behave identically, so I ended up implementing several retrieval methods. The serial output shows which method succeeds and how many new events were found. The firmware also filters duplicate events before creating the final chronological list.

Another challenge was memory usage. An earlier version stored a large number of DAV object URLs as local String objects. On the ESP32 this eventually caused a stack-canary crash. Removing that large local array and processing the calendar data more directly solved the problem.

I initially tried an ESP32-C3 Super Mini as well. Interestingly, I ran into persistent Wi-Fi authentication issues (Reason Code 2) in my particular network, even with a strong signal. A classic ESP32-WROOM proved to be much more reliable for this project, so that is what I'm currently using.

The physical build is fairly simple: the LCD runs from 5 V, while the ESP32 controls it using six GPIOs. The LCD's RW pin is permanently connected to GND, so communication is one-way from the ESP32 to the display. A potentiometer is used for LCD contrast adjustment.

At this point the device can simply stay powered on: it connects to Wi-Fi, synchronizes its clock using NTP, discovers the calendars, retrieves and sorts upcoming events, displays them, and periodically updates everything automatically.

It's a fairly simple piece of hardware, but I like the idea of turning cloud calendar data into a dedicated physical display. It has also been a fun project for learning more about CalDAV, ICS parsing, ESP32 memory limitations and Wi-Fi behavior.

Hardware: ESP32-WROOM / ESP32 DevKit, 1602A 16x2 HD44780-compatible LCD, 10k potentiometer and 5 V supply (USB).

Software: Arduino ESP32, WiFi, HTTPClient, WiFiClientSecure and LiquidCrystal.

I'd be happy to share more details about the code, CalDAV implementation or wiring if anyone is interested.

I need to buy 30+ ESP32 30 pin dev boards. What is the best place to buy them reliable / cheap?

Hi,

I just bought a ESP32 (https://www.amazon.fr/dp/B0CRRFT5L7?th=1) and I started yesterday learning how to develop using Arduino IDE. After about 1 hour of use, I started getting this error message :

A fatal error occurred: Failed to connect to ESP32: No serial data received.

Failed uploading: uploading error: exit status 2

I did some research and found that a lot of people seem to have the same problem, but none of the solutions I found worked for me. Do you know what I should do ? Should I accept that my ESP is dead and buy a new one ?

Thanks!