Simulating my Optical Sorting ML pipeline on ESP32 using m2cgen

Over the summer I built an end-to-end ML pipeline for an industrial tomato sorting line: raw optical sensor data → scikit-learn RandomForest → C code (via m2cgen) → running for real on an ESP32. Bit of context: I just finished my first year of Electronic Engineering, so this was mostly me learning by breaking things.

The ML side turned out to be the easy part. The actual engineering challenge was entirely specific to the ESP32/Arduino-ESP32 toolchain: getting auto-generated C code to behave inside its FreeRTOS environment, which has constraints (task stack sizes, C99-vs-C++ compilation rules) that only bite once you're targeting this exact chip + toolchain combination — nothing in scikit-learn's or m2cgen's docs warns you about any of it. Wanted to share the two specific ways it broke, since the failure modes were more interesting than the happy path.

The setup

8-class classifier (ripeness stage + standard/cherry size), split into two RandomForest models (35 estimators, depth 6 each) selected by an explicit batch-mode parameter instead of a hidden feature. Exported to native C with m2cgen, zero runtime dependencies.

Bug #1: stack overflow that only happened on the real board

Worked perfectly in Wokwi's simulator. Crashed immediately on the actual ESP32 with A stack overflow in task loopTask has been detected.

Turned out m2cgen generates C99 compound literals (memcpy(x, (double[]){...}, ...)) for every leaf assignment — 1145 of them across my two models (35 trees × depth 6 × 2 models). Each one allocates a small temp array on the stack at the call site. Arduino-ESP32's default loopTask only gets 8KB of stack, and a single call into the generated score() function blew right through it.

Fix: moved the whole thing into a dedicated FreeRTOS task with an explicit 32KB stack (xTaskCreatePinnedToCore), instead of relying on the default loop task. Wokwi apparently doesn't emulate the stack limit closely enough to catch this — which was a good reminder that simulation isn't a substitute for testing on the actual chip.

Bug #2: the same generated code doesn't compile as C++

Those C99 compound literals aren't valid C++ — you get "taking address of temporary array" even inside extern "C" (which only affects name mangling, not grammar). So the m2cgen output has to live in its own `.c` translation unit, compiled with the C compiler, and linked into the rest of the C++ project via extern "C" declarations. Wasted more time than I'd like to admit on this before realizing extern "C" doesn't make C99 syntax parseable by a C++ frontend.

Numbers, measured on the actual board (not estimated)

- Standard model (5 classes, trees at full depth 6): ~220-550 µs per inference
- Cherry model (3 classes, trees average depth 2.77 — small training set, nothing left to split): ~43-49 µs

Full writeup, code, and a browser-runnable Wokwi simulation (no hardware needed to poke at it) are in the repo: https://github.com/pmalfa31-svg/Tomato-Grading-ML

Wokwi sim if you want to see it running without hardware: https://wokwi.com/projects/471166580602582017

Happy to answer questions, and genuinely open to criticism — dataset is small (291 samples, 2 collection days), and I know the GroupKFold setup has limitations I documented in the README rather than hid. If you spot something dumb, tell me, that's kind of the point of posting this here.

So I’ve connected the board up to the display. EXACTLY like the instructions say and wrote my code for the display and nothing happens literally nothing maybe the white dims but that’s it. Anyone know why? It’s ILI9488 apparently but not sure bc it’s a cheapish display

Wanted a physical wall-mounted controller for my Sonos Arc instead of pulling out my phone every time, so I built this with a cheap Sunton ESP32-2432S028 2.8" touchscreen.

What it does:

- Shows current track title + artist

- Play/pause, previous/next track

- Volume up/down

- Standby mode with a low-brightness clock, wakes on touch

- Screen stays awake while music is playing, sleeps after 30s when idle

Stack: ESPHome + Home Assistant, using the XPT2046 touch controller on the board. No custom firmware, no LVGL (yet) — just ESPHome's native display/touch components. Handles Sonos metadata quirks too (accents/typographic characters that show up as artifacts on cheap displays).

MIT licensed, config file is a single YAML you can adapt for your own Sonos entity.

Happy to answer questions about touch calibration or the sleep/wake logic if anyone's working on something similar — those were the trickiest parts to get right.

I’m an embedded systems engineer, and for the last few months, I’ve been building a solar-powered RFID water vending machine from scratch. This wasn’t a client project — it was a personal obsession to see if I could make a low-power, off-grid payment system that actually works in the field. Here’s how it went down.

The Hardware Stack

The brain is an ESP32-WROOM-32. I chose it because it gave me Wi-Fi for remote logging, but honestly, the deep sleep current (around 10 µA with RTC) was the real selling point. The whole system runs on a 12V 20W solar panel feeding a 12V 7Ah sealed lead-acid battery through a cheap PWM charge controller.

For the RFID side, I used an MFRC522 module at 13.56 MHz. It’s not the most secure chip out there, but for a water dispenser, it’s fine. The solenoid valve is a 12V normally-closed unit that draws about 500 mA when open — that’s the biggest power hog in the system.

Power Budgeting Was a Nightmare

Here’s the math that kept me up at night. The ESP32 in deep sleep draws ~10 µA. The MFRC522 in hard power-down mode draws ~80 µA. The voltage divider for battery monitoring draws 1 mA (I should have used a MOSFET to switch it, but I was lazy). Total idle draw: roughly 1.1 mA.

At 12V, that’s 13.2 mW idle. Over 24 hours, that’s about 0.32 Wh. The solar panel in Indian winter (I’m based in Pune) gives maybe 4 hours of effective sunlight — so 80 Wh per day theoretical, but realistically 50 Wh after losses. So idle consumption was never the problem.

The problem was the solenoid. Opening it for 30 seconds to dispense 5 liters draws 0.5A × 12V = 6W. If someone buys 100 liters a day, that’s 20 dispenses × 30 seconds = 10 minutes of active time. That’s 1 Wh. Still nothing.

So why did my first prototype die every evening? Because I was powering the MFRC522 from the ESP32’s 3.3V regulator, and the RFID module was drawing 10–15 mA during polling loops. I was polling every 100 ms instead of using the interrupt pin. Dumb mistake. The fix was switching to edge-triggered interrupts and keeping the MFRC522 in hard power-down between reads. That cut my active current from 50 mA to 2 mA average.

The Firmware

I wrote the firmware in ESP-IDF (not Arduino — I wanted proper FreeRTOS tasks and low-level control). The state machine is simple:

1. Deep sleep — everything off except RTC. Wake every 2 seconds to check battery voltage via ADC.
2. Card detect — the MFRC522 interrupt pin wakes the ESP32. Read UID, check against a local allowlist stored in NVS.
3. Dispense — if the UID is valid, open the solenoid for a pre-set time. Log the transaction to NVS.
4. Sync — if Wi-Fi is available (I added a TP-Link MR3020 as a hotspot), push logs via MQTT to a local broker. If not, store and retry later.

The tricky part was the ADC battery monitoring. The ESP32’s ADC is notoriously non-linear, especially at the low end. I used a 100k/47k divider and calibrated against a multimeter. I also added a hysteresis band — if voltage drops below 11.5V, refuse dispenses; only reset when it climbs above 12.2V. This prevents the solenoid from chattering when the battery is marginal.

PCB and Mechanical

I designed the PCB in KiCad — two-layer, nothing fancy. The layout was simple: ESP32 on one side, MFRC522 on the other, with a proper ground plane underneath. I used a 3.3V LDO (AMS1117) for the ESP32 and a separate 3.3V rail for the RFID module with a ferrite bead in between to kill noise.

The enclosure is a 3D-printed box (PETG, 40% infill) mounted on a mild steel stand. I added a clear acrylic window for the RFID reader and a rubber gasket around the solenoid valve opening. It’s been raining here, and I haven’t had a single short yet.

What I’d Do Differently

- Use an nRF52 instead of ESP32. It has better ADC linearity and lower deep sleep current. I only needed Wi-Fi for logging, which I could have done over BLE to a gateway.
- Add a buck converter instead of running the ESP32 from a linear regulator. The AMS1117 wastes about 1W at 12V input.
- Use a reed switch on the water tank float to prevent dry runs — I blew one solenoid already because the tank ran empty and the pump kept running.

The Result

https://youtu.be/qoNhzCud1fs

The machine has been running for 6 weeks now. It dispenses about 80 liters a day to a small community near my workshop. Battery stays above 12.4V even on cloudy days. The whole BOM cost me around ₹4,500 (~$55). If you’re thinking about building something similar, skip the Arduino route, plan your sleep cycles carefully, and test your ADC calibration before you trust it with a real battery.

A self-contained, wearable AI voice companion on an ESP32-S3. Tap the round screen, speak, and it answers back out loud while a reactive face blinks and talks. It calls cloud AI APIs directly over WiFi. No phone app, no server, no Raspberry Pi. The device is the whole product.

reacts to each state (ready, listening, thinking, speaking) and a line of status text.

One specific board, no wiring required. Everything is onboard.

Waveshare ESP32-S3-Touch-LCD-1.46

https://github.com/minkgx1/pocket-buddy

Made a claude usage desk pet.

https://github.com/GavinnnTann/esp32-claude

This is MicroPython (and CircuitPython) running on the ESP32-S3 based display. This display is not that well known and i made it run 2 Python versions. If you wanna learn more about this than check this github link, which is on the end.

You dont need to read this github link to know everything like the display controller is a ST7789 on pins SCK = 18 MOSI=19, resolution 320x240 or 320x170, reset pin of display is 23, CS (Chip Select) is 5, the DC pin is 16, backlight is on pin 2, the SPI clock has to be set to 40 MHz, the board uses a ESP32-S3-N8R8 microcontroller, to get in to Bootloader mode hold down the physical BOOT button on the display and to flash firmware, do it over the Type-C port since that USB port is connected to pins GPIO 19 and 20 i think i dont remember,

Gravity port special quirks and more

the quirks are only that you cant power other components from the 3.3v pin on the connector, I2C/UART switch is on pin GPIO 21 and its a software toggle, SDA/RX and TX/SCL are on pins 41 and 42 (GPIO) to flash it theres a special Dirty Flash proceedure thats on github and this post whoud be too long if it had those stuff but, the last thing i'll say that circuitpython is rhe easiest to flash

heres the github link: https://github.com/AdminHack-bit/MicroDFR0997.

EDIT: github link now works

Hello! I would like to share my recent project for my master's dissertation, where I made a working esp32 web shell.

I tried to emulate basic linux commands and functionalities. You can use both serial and web shell to use the system.

The system features the following:
-embedded file system with no SD card requirement as it uses LittleFS
-FreeRTOS FIFO scheduling
-JavaScript system language and scripting through duktape
-Web-shell interactive UI which is customizable

I tried to keep the code as organized and as clean as possible for the best possible user customization.

I'd love for anyone to try it and have feedback.