Client storyFirmware

esp-ndf: Why I Rebuilt the ESP-IDF Stack to Fix Timing on the ESP32-S3

Control products want ESP32-S3 pricing and wireless with microcontroller-class timing. ESP-IDF's RTOS layers made that hard, so I built esp-ndf, a bare-metal framework with its own drivers and wireless stacks.

46 cyclesinterrupt latency
20 kHzcontrol loop on both cores
0RTOS required
Type
Open-source R&D
Platform
ESP32-S3, dual core
Goal
Hard real-time timing with wireless
Built
Bare-metal framework, drivers, BLE, Wi-Fi, TLS

The problem

The ESP32-S3 is a great chip for connected products: dual core, Wi-Fi, BLE and a low price. But motor control and power electronics need tight, predictable timing, and ESP-IDF is built around FreeRTOS, with interrupt paths and system tasks that add latency and jitter.

Clients kept running into the same wall: either accept the jitter, or add a second microcontroller just for timing-critical work.

What I built

  1. Bare-metal core

    A startup and interrupt layer with no RTOS, so the path from hardware event to handler is as short as the silicon allows.

  2. Deterministic control loops

    Each core can run a fixed-rate control loop at 20 kHz with sub-microsecond jitter.

  3. Own drivers

    Peripheral drivers written for predictable timing, not convenience.

  4. Wireless and security

    BLE, Wi-Fi and TLS integrated so they never block the control loop.

  5. Benchmarked

    Every part measured against ESP-IDF on the same board, so the gains are numbers, not claims.

What clients get from it

Results

  • One ESP32-S3 instead of an ESP32 plus a separate real-time MCU.
  • Interrupt latency of 46 cycles and stable 20 kHz loops.
  • Wireless connectivity without losing control-loop timing.
Related guideESP32 Interrupt Latency and Jitter: FreeRTOS vs Bare Metal for Real-Time Control
Nikhil Robinson

Embedded systems consultant at TechProgeny, Bengaluru. 7+ years and 29+ shipped products across firmware, embedded Linux, edge AI, apps and IoT servers.