The Arduino ceiling has an address: 20 kHz sampling next to a live WiFi stack

An engineer writing on dev.to has published an account of leaving the Arduino IDE for ESP-IDF, and it is more useful as a scheduling signal than as a conversion story ^[1]. The failure point is specific: sampling a sensor at 20 kHz with consistent timing while writing to an SD card and holding a WebSocket open ^[2].

That spec sets a hard budget. 20 kHz means one sample every 50 microseconds ^[3], and inside the Arduino model the author says the available instruments were delay() and millis() ^[4]. The reported result was bad jitter, WiFi dropping when the loop blocked for too long, and the watchdog resetting the board ^[5]. His summary is that he was not fighting his code, he was fighting the assumptions baked into the framework ^[6].

The mechanism is structural, not a bug. On ESP32, Arduino runs on FreeRTOS whether you asked for it or not, placing setup() and loop() inside a task and creating a separate task for WiFi and networking ^[7]. The author calls that arrangement elegant until the thing you need to control is those tasks ^[8]. His framing of the wider point is worth borrowing: every good abstraction is a ceiling by design, and the only question is whether you have hit it yet ^[9].

Crossing it has a stated price. Per the author, going bare metal on ESP32 means using ESP-IDF directly, owning the boot process, writing the linker script that decides what lives in flash versus RAM, configuring the interrupt allocator, and deciding which core does what ^[10]. The first attempt does not boot; you get a Guru Meditation Error and a register dump ^[11]. The reference material is the ESP32 Technical Reference Manual, over 600 pages covering two Xtensa LX6 cores at 240 MHz, an interrupt matrix, hardware timers, DMA engines, eFuses and clock trees that gate power to whole subsystems ^[12].

The returns he claims are the ones you would expect to appear in a schedule justification: sub-microsecond timing, because calls no longer pass through layers that re-check whether a pin is valid ^[13]; WiFi pinned to core 0 and the real-time loop on core 1, so they stay out of each other's way ^[14]; the brownout detector and task watchdog told what the application is doing so they stop resetting it for being busy ^[15]; and a binary that went from 800 KB to 80 KB because only what is used gets linked ^[16], a 90 percent reduction on that one project ^[17].

None of this is an argument against Arduino, and the author does not make one. He credits it with solving distribution, documentation and community, with functions that read like English such as analogRead() and Wire.begin() ^[18], notes that museums and satellites have run on it ^[19], and says his first three products that made money ran on it ^[20]. His stated position is that Arduino is capable of the work, but that when you need that level of control it is easier to work with the silicon directly than to fight an abstraction that was trying to protect you ^[21].

What to watch for in your own requirements: two constraints landing on one die, a deadline measured in microseconds and a network stack whose scheduling you do not own. When both appear, the toolchain stops being a matter of preference and becomes a line item, with linker script, interrupt allocation, watchdog configuration and core assignment as tasks somebody has to be paid to do.

Two caveats. This is a single self-reported account of one project, so the 800 KB to 80 KB figure reflects what that author had been linking, not a general ratio. And the automotive framing, the CAN bus payoff advertised in the headline, is not delivered in the supplied text, which breaks off while turning toward it ^[22].