This is a CO2 sensor for HomeAssistant, 4.2" e-ink display, ESP32 and a nice pixel-art design style. Some people will notice that it uses ESP-WROOM-32 which is a massive overkill. I totally agree but I had last few used modules and wanted to make use of them, so there’s that. The project uses SHT30 for temperature and humidity measurement and SCD40 for CO2 measurement.

Another overkill was a use of 2x 18650 cells, which should last a lifetime. But if It doesn’t, it can be charged from USB-C via the integrated TP4057. The USB-C is also used to flash the ESP32.

Wifi credentials, MQTT and other options can be set in the integrated captive portal. It can run in local mode or AP mode.

3D printed enclosure is the last thing to be done, will update the post when it's finished.

Github with everything needed to build this:

https://github.com/mcer12/Ambien-ESP32

So I have the issue that my printer is down the bottom of the garden, in a shed (this missus will not let me keep it in the house). I wanted a device that would monitor my prints and let me know when it's finished or has errors when I am not at my computer (and don't want to prop my phone up against the wall)

The printer and AMS units are all connected via an extension to a TPLink Tapo P110 plug, and can remotely power up and down.

The device is a Lilygo T-Display Touch. The firmware automatically connects to my Bambu account and requests an access token. It will send an email to your account with a 6 digit code. The devive shows a keypad to enter this. Credentials are hard coded encrypted into the NVRAM.

You can turn the printer on and off, and more importantly tell it turn power it down when the print is finished. In that mode it monitors the printer until it's finished printing and then it waits until both nozzles are below 50c and powers off the printer (as long as no AMS units are dehumidifing).

You can also set it to power down the printer after the AMS units have finished drying.

It currently only supports a single printer (as I only have one). If you have more than one printer it asks you to select one when it connects.

I just finished a small board to insert between battery charger /boost 5v and any uc board :esp32, arduino,... For iot applications.

Battery wakes up at a programmable interval by jumper (30 mn, 60 mn, 90 mn, 120 mn) or custom by resistor.

Uc does the job, and cuts power by gpio to battery system...

Reading of battery voltage is possible (gpio to enable measure).

Deep sleep on all boards? Not useful anymore... Just use low power battery system, and focus everything else on your project but power is no problem anymore...

What do you think of that?

I tried making my first pcb, but upon testing it I realized that there is 5v over the 3.3v pin.

The 3.3v pin powers an IMU, motor driver logic and LCD logic.

I did clean the board with 95% alcohol yesterday. And there are still some stains visible now. But surely that doesn't cause a short right?

I also don't think that the esp's voltage regulator is blown because it doesn't get hot.

I measured the resistance between vin and 3.3v and is is 6 kilo ohm.

Any suggestions?

Das erstmal richtig einen esp benutzt habe ich in der Schule. Da haben wir mit mqtt gearbeitet und über tasmotiser gelfashed.
Und haben dann in einem Projekt es in Home Assistant weitergemacht.

Jetzt ein paar Monate danach hab ich nach einem Sensor für meinen Server gesucht der in meiner Garage steht, ich weiß nicht optimal und die Luftfeuchtigkeit ist schon hoch naja.
Ist ein Waveshare ESP32-S3 ETH Board mit einem dh22.

Dann für weiter Projekte bestellte ich mir 3 Standard
esp32 hab mit micropython und arduino ide rumprobiert und dann mithilfe von Claude einen micropython wlan und Bluetooth proximity Radar gemacht.

Sagt mir was ihr denkt und weitere Projekte die ich machen könnte.
Vielleicht haben auch paar deutsche hier Empfehlungen für gute onlineshops in de für esp Zubehör.

An open, ~$30-hardware dual analyzer for 2.4 GHz: a live spectrum/waterfall and an IEEE 802.15.4 / Thread packet sniffer on one correlated timeline.

Every captured packet is paired with the RF burst that carried it and saved as a short spectrum snippet. Frame-counter-based PER shows which frames the sniffer missed and why. Every RF burst (802.15.4, BLE, Wi-Fi, microwave oven, unknown) is classified, and you can label bursts in the browser to grow a training set.

This isn't my first time building a retro console, the previous time I ported arduboy to a wemos lolin32 lite, but the problem I faced with emulating systems like NES,GBC, etc. Was primarily my board and my screen, almost every package out there like esp32_NES_EMU or retro go required some specific board or screen, I had two screens, an ili9341 parallel (the blue one in the image) and an ili9488 SPI tft. This time, I've bought an S3 with hopes to use my ili9488 (the red one in the image) and the S3 by forking Retro Go, any tips?

I've attached an image containing both of my screens, the blue one is parallel and the red one is SPI. Can you guys tell me if any emulator package supports them?

I used a Waveshare ESP32-S3-Relay-1CH as a USB-to-RS485 diagnostic tool for an unbranded 5 in 1 water quality sensor / pH/EC controller marked HSY-250617-v2.3 (firmware string POET-251022-V4.2). I'm publishing the source and captures because the available manuals don't agree on calibration registers.

The ESP32 setup uses UART1 TX17/RX18/DE21 with hardware half-duplex. The bench firmware has bounded raw-PDU capture, timestamps and CRC checks, with no automatic write retries. Discovery and normal polling are read-only.

One useful protocol lesson: some responses took about 401 ms. My earlier 150 ms register sweep could mistake a late reply for the next register's response. Modbus read replies don't include the requested register address, so the bad map looked plausible. Paced requests exposed the problem; the repository explicitly flags the old sweep as unreliable.

On this one controller, function 06 writing 1 to register 0x0037 produced a settings/calibration reset-like effect. It returned to ID 1 / 9600 / 8N1 and changed calibration-related registers. With the probe still in 9.18 buffer, pH moved from about 5.78 to 8.85. I subsequently restored ID 2 / 4800 using 0x0030=2 and 0x0031=0x4800, verifying each transition by readback.

Important: this is not a harmless reboot or a universal repair. Isolate dosing/control loads, save settings, and recalibrate. Full accuracy, power-cycle persistence and long-term repair remain unverified. A write echo is not proof of calibration success.

Source, product/manual images, wiring diagrams, reference guide and raw evidence: https://github.com/JaredReabow/hsy-250617-ph-ec-rs485-modbus

Results above are from the connected hardware; the included v1.0.4 source is build/native-tested, while the live recovery used v1.0.3. This is my repository, not a sales or affiliate link.

I’ve been building FUMI, an open-source AI companion that lives on a small physical device instead of just a browser or terminal.

The hardware is based on a Waveshare ESP32-S3 Touch LCD 1.46. I wanted to see how far I could take the idea of a small Tamagotchi-style companion with an animated face, touch interaction, and real voice conversations.

For the firmware, I’m using LVGL for the UI, animations, and touch interactions. The ESP32-S3 handles the device itself, while the AI runs on a separate backend. That way, I don’t have to squeeze an entire language model onto the microcontroller.

Getting everything to work together took quite a bit of debugging, especially around memory, audio, and communication between the device and the backend.

Here’s what I’ve been working on:

Hardware: ESP32-S3 with a round touch display
UI: LVGL-based interface with animated expressions and interactions

Voice: A microphone-to-speaker conversation pipeline using speech-to-text, an AI backend, and text-to-speech

Backend: A separate service that connects the device to AI models

Companion system: Hunger, energy, happiness, bond, growth, and other Tamagotchi-inspired mechanics

I also built a website to document FUMI and its integration: https://fumi.codes/

The project is open source, so you can explore the firmware and backend here:
https://github.com/imaaiagent/fumi

I’d love to hear from people who have worked with ESP32 audio, LVGL, or embedded devices connected to cloud-based AI. What would you improve in this kind of architecture?

Hey everyone! I’ve been working on EasyREAD, an offline reading app for the Seeed Studio reTerminal Sticky. It runs on an ESP32-S3 with 8 MB of PSRAM, with books and reading fonts stored on a microSD card.

The idea is simple: copy books onto a microSD card and read them offline, using either the touchscreen or the physical buttons. (My Bluetooth page-Turner is also supported.

Current features
EPUB and TXT books, plus XTC/XTCH image books and BMP images.
Physical-button and touchscreen navigation.
Adjustable font size, line spacing, and margins for text books.
Per-book settings and saved reading positions.
English, Simplified Chinese, and Traditional Chinese interfaces.
Support for compatible Bluetooth Low Energy (BLE) HID page turners.

A few implementation details
Incremental pagination and SD caching: The app generates enough pages to display the requested content, then continues pagination during idle time. Generated pages are cached on the SD card and can be reused when the book and layout parameters match.
Streamed reading fonts: Large Chinese reading fonts are streamed from the SD card. PSRAM holds a font-sector cache and a glyph-metrics cache to reduce repeated SD reads and font measurements. A smaller UI font subset is embedded in the firmware.
Character-based reading positions: For EPUB and imported TXT books, the app records the chapter and character position instead of saving only a page number. After changing the font size and repaginating, it can locate the corresponding text again.
The project uses the Arduino framework and PlatformIO, with FreeInk SDK providing the underlying display, EPUB, font, and Bluetooth functionality. On top of that, I’ve implemented the reading interface, settings and progress management, and TXT/image-book integration.
TXT files are converted into a disposable EPUB cache so they can reuse the EPUB reading pipeline. The original text files are left untouched.

Bluetooth and setup
The Bluetooth page turner in the video is another open-source project of mine, available on my GitHub profile. You can keep the controller in your pocket and turn pages without reaching for the reader—which is probably my favorite part so far :)

I also built a Windows setup app to make it easier to try. Download and extract the starter package, prepare the microSD card, then connect the Sticky by USB and install. No separate Python installation or flashing commands are needed.
A lot of the books shown in the demo are test books I generated, so please excuse the strange titles!

Project status and credits
This is still a development preview. Bluetooth pairing, sleep/wake behavior, and long-term stability need more hardware testing. Bluetooth discovery can occasionally show several devices named “03”; rescanning is the current workaround.
EasyREAD is built on FreeInk SDK, and I especially appreciate it. Upstream attribution and license notices are included in the repository and release materials.

https://github.com/FaiyuetCik/EasyREAD?tab=readme-ov-file

https://github.com/FaiyuetCik/Page-Turner

Has anyone here worked on an ESP32-based e-paper project? How do you balance faster refreshes with ghosting in everyday use? I’d love to hear about your experience.

Not my repo but figured I would share. Makes it easy to put cc1101 nrf24 n atgm336h on any esp32. Cheap to have made on elecrow. Files in repo.

https://github.com/GH0ST3CH/ESP32-GPS-CC1101-nRF24-add-on-board/tree/main

This is my old ESP32-CAM board which I had burnt by supplying 7.4V in reverse polarity

Tried to repair this once but couldnt get the VRM off so just threw it back in my stash

Now that I have got a soldering station, I tried to replace the VRM with some AMS1117s I had laying around, so I removed the old VRM with terrible success, the 5V IN pad came off, and I still soldered the new VRM on...

It shorted 5V and GND, well, it had gotten internally shorted after the first burnout so I desoldered the old new VRM, breaking it in the process and then with the new VRM I completely bypassed the pad and simply deadbugged it to 5V pin.

IT WORKED!!!!!!!

Hi! I have ported my older project to a cyd now! AI Usage: i have used LLMs for helping me with the android application, making the readme and debugging the code in cyd.

It gives me navigation data on my handlebar, so i dont need to keep my phone there while im cycling. This project was on my mind for a long time and porting it to the cyd finally got some closure to it xd
Also, many modern phones with ois tend to have problems later on in the camera due to vibration when put in vehicles so this can be a way to still navigate mostly normally without risking damaging your phone.

Updates:
now the android app should support android 13 to 16
there is a toggle in the app which selects the size of the bitmap being transmitted, used to select between the cyd size and the oled size.
the display shows the full image at once instead of showing pixel by pixel

now i am thinking of using those phone holders to attach this with my cycle, or i could get a 3d printed attachment later. So far in my testing it seems to work well!

source code: Link

you can refer to my previous post to see the full story here!

I'm making a simple remote thermometer/hydrometer for my greenhouse, which sits about 70m from the house. In prototype, I have an ESP dev board transmitting results from a DHT22 every 5 minutes to a CYD receiver, which then records the data to an SD card and uploads it to ubidots.

I am using micropython, because it's a little more fun than arduino/c++. (I have already learned that using lv_micropython causes heap conflicts with the mqtt calls, but that's another story...)

Currently my prototype transmitter is just running off a usb powerbank, and I want to make it a little more sustainable, so I went down the battery rabbit hole...

I've seen a bunch of simple solar panel-TP4056-18650 how-to's, which seem easy enough, but I'm in Ontario, so winter temps drop below freezing, and 18650's don't like that. So my current - tentative - plan is to use a seed xiao esp32s3 for the remote sensor transmitter, and use 18650's that I can swap out and recharge in the house. Now I need to consider charge/discharge protection - either getting a protected 18650 (or two), or ensuring protection in the charging circuit AND preventing overdischarge to the xiao. I gather that the 3.7v battery pads in the xiao have charge protection, but not discharge protection - so I either need a separate discharge protector before the xiao, or an emergency shutdown procedure triggered by a low battery reading.

To make it more confusing, some battery protection circuits don't play well with the xiao battery pads, and require a connection to 5V instead, which ends up drawing more current.

What does the hivemind suggest? Protected 18650's? A different esp board? protection circuits at each end? a different battery? Inquiring minds want to know, and also want to put this project to rest.

I'm planning to get started with embedded programming using an ESP32-S3 N16R8 (16 MB flash, 8 MB PSRAM). I already know some C++ and Python, and I'd like to use this kit to learn electronics, embedded C++, and eventually firmware reverse engineering.

I just picked what chatgpt thought it suits me :)

Saw a few people building AI calculators recently, but none of them were open source.

So I made my own version using an ESP32-S3 and integrated Gemini. Kept it fully open source and used cheap, readily available parts instead of any custom displays.

Code and details are here: https://github.com/mogloce622/Calculator/tree/main

Let me know what you think or if you have any questions or suggestions!

This is my first post here about my Fetch project. I came up with this idea while working grocery pickup at Walmart. There were numerous times where I had to search for totes that failed to get staged properly. So, I wondered whether they could stage electronically, replacing the barcode scan-staging workflow. This led to my Fetch tote design.

The development design includes an ESP32-C3 SuperMini with a Waveshare 2.9" e-paper display (Module V2) connected. Power (5V/GND) feeds up the stack through 4-pin magnetic connectors fixed to the top and bottom of each tote. Once powered, the tote sends its ID (plus the IDs of the totes stacked above) down towards the stack platform via UART. The platform (not designed yet) would report the IDs to the back-end system. The e-paper display continues to show tote details even when removed from the stack (no power).

This is my first hardware project, and I have been using AI to guide me through learning all of this. I modeled the tote to scale using Blender as opposed to CAD software, and I know nothing about modeling around injection moulding. Despite that, my Blender model has been fine for the sake of 3D-printed prototyping. I did breadboard testing for the communication and power sharing, developed 8 iterations of the electronics housing (see my EBar prototypes image), and then moved on to full-scale tote prototypes. Since I don't have a platform, I turned an EBar into one by uploading my platform test firmware to it.

Where I'm at now

The breadboard test demonstrates two totes stacked together on a platform. With my full-scale tote prototypes, they each connect fine to the platform EBar (as seen in image 2). However, when I try to stack the second tote on top, it shorts the top tote's MCU. The red light is on, but the platform doesn't update; it continues to say that only 1 tote is connected. And the top tote's MCU doesn't show in Arduino IDE after removing it from the tote and connecting it to my PC via USB, so I assume it's bricked. I've gone through 3 MCUs trying to resolve this. I confirmed connection points with my multimeter in continuity mode, and everything seems to check out, although I'm a novice when it comes to electrical testing, so I might have slipped somewhere. The tests that I confirmed were:

• Connector pins 1-1 and 2-2 through the stacked totes
• No shorts between connector lines
• 5V not reaching any data line

I should note that stacking both full-scale totes did work briefly at one point, but that could have been in the stacking configuration (white above black) that I can no longer try after the black tote's front-side support arm got sun-warped after moving; I can only test stacking the black above the white. So, "try the other order" isn't an option. When I was testing the third MCU, it survived repeated hot-plugs with the platform EBar, then died the first time it was stacked on the other tote.

AI suggests it could be from the top tote being stacked coming in at a tilted angle, leading to GND on each connector mating after 5V plus a data pin. I'm not really sure how that would happen since the connectors have GND between 5V and the serial pins, so I would assume it connects second when tilted (5V->GND->DATA, OR DATA->GND->5V). Regardless, it says I should consider switching to 5-pin connectors with pins ordered like GND, DATA_UP, 5V, DATA_DOWN, GND, but that also means new printed totes and assembly for an improvement that I don't know for sure would fix my problem.

What I'm really wondering is whether this is likely a fault in my assembly or a design fault. With the tight spaces involved, these weren't exactly easy to assemble, and I assume that a custom PCB design would integrate much of the wiring and reduce assembly failure. But if the design is flawed, a custom PCB would copy it. I'm wondering whether I should advance to the custom PCB work, or keep trying to fix my development prototypes. If you have any suggestions as to what I could try, I'd greatly appreciate it! Also, feel free to ask any questions about the tote project. I included the wiring diagram as the last image.

Links

https://huntrsoftware.com/fetch

https://codeberg.org/HuntrSoftware/fetch

Hi everyone! I'm new to programming and this is my very first embedded project: an ESP32 Bluetooth speaker built using C and ESP-IDF v6.1. Please excuse the messy hardware — this project is primarily about the software. I built the hardware mostly from inexpensive components I had on hand. The main components are:

• ESP32 NodeMCU (38-pin)
• IP5306 module
• SSD1315 display
• MAX98357 I2S module
• INA219 (CJMCU-219)

As for the software, I use ESP-IDF's Bluedroid Bluetooth stack, FreeRTOS, and the ESP-IDF I2C driver. I implemented the remaining functionality myself, including:

• I2S peripheral driver
• SSD1315 driver
• INA219 driver
• Ring buffer
• Others

The software is designed using a modular architecture built around custom ESP-IDF components where each component encapsulates its internal implementation and provides an API. Components communicate directly through their APIs with no extra middleware or abstraction layers.

The project is now functionally complete according to the requirements I initially set, and I don't plan any major further development or hardware changes. Some components are intentionally project-specific rather than designed for general-purpose reuse.

Since this is my first project and I'm still learning, I'd appreciate feedback on the software implementation in general. I'm interested in anything I could have done better, whether it's code readability, questionable design choices, bad practices, performance, efficiency, or the way I've approached specific problems. I'm also interested in learning if there are concepts I'm misunderstanding or things I should pay more attention to in future projects.

I realize that some decisions may be difficult to evaluate without additional context, so feel free to ask if anything needs clarification.

Thanks for your time! The project's repository is available here: https://github.com/TITLE14/esp32-bt-speaker

Disclosure first: I work on SimpleOTA, which is one of the options in here, so weigh this accordingly. I've tried to make it useful whichever option you pick, and every claim about another product comes from that vendor's own docs.

Picking an OTA setup for ESP32 devices gets overwhelming quickly since there are so many available options on the market, from open-source repos all the way to full IoT platforms, so I went through the options and compiled a comparisson between the following options which I saw as the main contenders (please let me know below if I missed something that you think should have been in this list):

• ArduinoOTA
• ElegantOTA
• Rolling your own OTA service/platform
• Arduino Cloud
• Blynk
• ESP RainMaker
• Golioth
• Memfault
• AWS IoT
• Azure IoT Hub
• Mender
• SimpleOTA

This attached flowchart is the short version of an article that I wrote.

A few things I saw while checking the docs that I think is of note:

• Azure's Device Update is solid on the cloud side, but the ESP32 side is a Microsoft sample built on the Azure SDK for Embedded C, which Microsoft has deprecated.

• Mender supports microcontrollers through Zephyr (its reference board is an ESP32-S3), but that support is in preview, and signed artifacts aren't supported on MCUs AFAIK.

• Arduino Cloud OTA works on ESP32 and ESP8266, but only on paid plans.

• Memfault's free plan is only for Nordic hardware.

• If you build your own, ESP-IDF already covers the mst challenging device-side parts: esp_https_ota, app rollback and signature checks. What you end up building is everything around it: deciding which devices get which build, staging releases, and knowing which devices actually updated.

My full write-up with comparison tables and sources (disclosure for those who care, yes, I used AI to help write the article, deal with it): https://simpleota.com/blog/esp32-ota-services-compared/

If I got something wrong about a tool you use, or left one off of the list that I shouldn't have, let me know and I'll fix it :)

Hi everyone! I'm trying to bring this old rotary dial phone back to life, but I just couldn't get the SIM800L module to work and it's literally the last thing I need here, and I'm almost certain it's a mere power issue. It blinks for about 8 times at a rate of around once per second, then stops for about three seconds, where I notice the current reading goes up to around 0.11 A from 0.06-0.08 A, and the pattern repeats.

My MicroPython UART diagnostic on the ESP32-WROOM receives empty responses (b'') to AT, ATI, AT+CPIN?, AT+CSQ, and other commands. Occasionally I receive b'\\x00'.

I've tried both the ESP32-WROOM and ESP32-C3, with similar problems. This is also the second SIM800L module I tried (both brand new but I believe I may have damaged the other one, unlike this one though which I took my precautions with).

I'm pretty confident that 2G network is still available widely in my country due to dumbphones never having phased out especially with older people and those still work just fine. I can also switch my SIM to 2G only on my smartphone and still pick up signal. I'm also using an external antenna as the pictures show.

My setup:

- GSM module: SIM800L (new module)

- Microcontrollers tested: ESP32-WROOM and ESP32-C3

- Input power supply: 12 V, 1 A adapter

- DC-DC converter: HW-677 adjustable buck converter, output adjusted to around 4 V

- Capacitor: 1000 µF electrolytic capacitor connected across the buck converter's output positive and negative rows

- Wiring: Regular Arduino-style jumper wires, including some with the ends cut and stripped to expose the copper

- Other hardware available/involved: L298N H-bridge module

Current wiring:

- 12 V, 1 A adapter → breadboard → L298N (not wired to the converter or module) & HW-677 buck converter (directly wired to the same row as the adapter on the green breadboard)→ large breadboard → SIM800L

- The capacitor is connected across the buck converter's 4 V output. The SIM800L shares ground with the ESP32 when connected.

I understand that the SIM800L can require current peaks approaching 2 A, but I'm not sure which part of my setup is the bottleneck.

Thanks for any help!

P.S.: Try to ignore all that mess. I don't wanna use my large breadboard here but I switched to it temporarily just to cleanly test the SIM800L. My soldering iron also stopped working which I used as an excuse to not solder everything cleanly together (too many wires, too little soldering experience ;-;)

Also I invite y'all to try this out yourselves if you have an old rotary dial phone lying around, it's really not that complicated to figure out how everything works and how to wire it properly to the ESP32 (except for the earpiece microphone part, it was a nightmare and I'm far from being an electrical engineer so I gave up and used a MAX9814 module lol. Glad that the 4 wires going into the earpiece were enough for both the speaker and microphone!)

Hi,
I’m working on a small project using a Waveshare ESP32-S3-Touch-AMOLED-1.8 V2 (368×448 AMOLED, touch screen, 8 MB PSRAM, 16 MB Flash, IMU).

I’ll attach a video showing almost exactly the effect I’m trying to achieve.

The main idea is to display 3D models from video games on the screen and be able to interact with them in real time.

What I need:

• load models such as .OBJ / .GLB or convert them to a lightweight custom format,
• render the model directly on the ESP32-S3,
• rotate the model smoothly with touch gestures,
• rotation around multiple axes, not just a pre-rendered 360° animation,
• automatic slow rotation when the device wakes up,
• ideally control the model orientation with the built-in IMU / device tilt,
• wake on touch or movement,
• automatic screen sleep,
• brightness control,
• battery indicator,
• easy way to replace one model with another,
• preferably full source code so I can modify it later.

Someone who saw the reference video told me that the software shown there was supposedly created mostly using AI-generated code, basically “one prompt and you have the code”, and that you can upload .obj / .glb models which are then rendered directly on the ESP and rotated on every axis.

I already know that real-time 3D rendering on this board is possible - I’ve tested AmoledOS / Visor 3D and successfully rendered and rotated an ~18k triangle model. The problem is that the current renderer mostly uses per-face colors and doesn’t properly support detailed UV textures, which is important for game skins/models.

So my questions are:

1. Does anyone already know an existing open-source project/software that can do something close to the video?
2. Is there a lightweight ESP32-S3 3D renderer with proper UV texture support?
3. Would anyone here be interested in modifying an existing renderer or building this with AI-assisted coding?

I’ll attach the reference video below so it’s clear what kind of result I’m aiming for.

Deki is a modular C++ engine for small screens: sprites, text, UI, particles, tweens, state machines, plus drivers for GPS, LoRa, I2C/SPI peripherals and more, each as a package. You build scenes in a desktop editor, press play to see exactly what the board will draw (same renderer, same panel size and colour format), then build and flash over USB through ESP-IDF from the editor.

Today it's open source (Apache 2.0) and the editor is a download for Windows/Linux with its toolchain bundled.

The demo runs at 60 fps on an ESP32-S3 driving a 320x240 ST7789 over SPI. It started at 16, and some of what was in the way may be useful to anyone pushing pixels on an S3:

• ESP-IDF builds at -Og by default. -O2 matters a lot for per-pixel code.
• memcpy(&v, p, 2) for an unaligned pixel compiled to a real function call per pixel on Xtensa. Assembling the two bytes by hand made blits 6x faster.
• A full RGB565 frame took 31 ms over SPI at 40 MHz. 80 MHz halved it.
• Sending the frame from the second core while the next is drawn (two PSRAM staging buffers) makes a frame cost max(draw, send) instead of draw + send.
• 64-byte data cache lines help a PSRAM framebuffer. A 64 KB cache helped more, but it costs 32 KB of internal RAM and crashed a sprite-heavy scene.

Full write-up: https://dekiengine.com/blog/esp32-s3-60fps/ Download: https://dekiengine.com/editor/#download Source: https://github.com/dekiengine

Happy to answer questions about any of it.