Programming Tutorials

  In the constraint-heavy world of low-power IoT, the radio is your enemy. An ESP32 attempting to maintain a Wi-Fi connection consumes between 160mA and 260mA. In contrast, Deep Sleep mode draws approximately 10µA to 150µA (depending on the board design). The mathematical reality is harsh: if you transmit data every time you sample a sensor (e.g., every minute), a 2500mAh battery might last a few days. If you batch data and transmit once an hour, that same battery can last months. However, Deep Sleep introduces a significant architectural hurdle:  Volatility . When the ESP32 enters Deep Sleep, the main CPU, wireless peripherals, and standard SRAM (volatile memory) are powered down. When the device wakes up, it does not resume execution where it left off; it reboots. It runs the bootloader and  setup()  from scratch. Consequently, your sensor reading variables, counters, and flags are wiped. Writing to NVS (Non-Volatile Storage) or EEPROM every minute is not a viable ...

  If you have ever pushed an ESP32 to its limit with heavy sensor aggregation or cryptographic calculations while maintaining a Wi-Fi connection, you have likely encountered the infamous   Task Watchdog Got Triggered   error or unexplained network disconnects. The ESP32 is a dual-core system, yet many firmware engineers treat it like an Arduino Uno (single-core), dumping all logic into the main loop or generic FreeRTOS tasks. This results in the "Application" code fighting for CPU cycles with the "Protocol" (Wi-Fi/Bluetooth) stack. When your blocking code wins, the Wi-Fi stack starves, the watchdog bites, and the system resets. To build industrial-grade firmware, you must explicitly leverage the symmetric multiprocessing (SMP) capabilities of the ESP32 by pinning tasks to specific cores. The Root Cause: PRO_CPU vs. APP_CPU The ESP32 architecture consists of two Tensilica Xtensa LX6 microprocessors: Core 0 (Protocol CPU / PRO_CPU):  By default, the ESP-IDF (and Ardui...