The ESP32 family is popular for connected products, and teams increasingly want it to run control loops too. Whether that works depends on how much timing jitter the application can tolerate.
Where latency comes from
- Interrupt handlers and code running from external flash through the cache.
- RTOS critical sections that briefly disable interrupts.
- Wi-Fi and Bluetooth stacks with their own high-priority work.
- Task scheduling between the time an interrupt fires and your code runs.
Reducing latency in ESP-IDF
Run critical code from RAM
Place interrupt handlers and hot functions in internal RAM so they never wait on flash.
Pin work to a core
Keep wireless on one core and control on the other.
Use hardware peripherals
Let timers, PWM and capture units do timing in hardware instead of software.
Keep handlers short
Do the minimum in the interrupt and defer the rest.
Measure with an oscilloscope
Toggle a GPIO and measure latency and jitter under real wireless load.
When bare metal makes sense
If the product needs fast, fixed-rate control loops with jitter in the sub-microsecond range while also running wireless, the RTOS layers become the limit. A bare-metal framework removes them. My open-source esp-ndf project reaches 46-cycle interrupt latency and 20 kHz control loops on both ESP32-S3 cores.
Frequently asked questions
Can I disable Wi-Fi to improve timing?
Yes, wireless activity is a major source of jitter. Many designs schedule radio use around critical periods.
Is a second MCU a bad idea?
No. A small real-time MCU next to an ESP32 is a common, robust design.
How do I know what my product needs?
Write down the loop rate and the maximum allowed jitter, then measure your current firmware against it.
Embedded systems consultant at TechProgeny, Bengaluru. 7+ years and 29+ shipped products across firmware, embedded Linux, edge AI, apps and IoT servers.