Yeah, I’ve hooked up an ESP32 to Espruino before, and it’s surprisingly snappy. The latency is a few microseconds slower than a hand‑written C++ loop, but for most sensor polls it’s still under a millisecond, which is fine for a lean startup. JerryScript can be even lighter if you strip the standard library down to just the basics, so the MCU spends more time in sleep mode and saves power. The catch is the garbage collector – it can wake the chip if you’re not careful. My trick is to keep the heavy lifting in a tiny C routine that hands off data to a small JS loop that only runs when the sensor fires. That gives you the control you want without pulling in a full framework. If you can’t afford over‑engineering, strip everything to the bare essentials, keep memory allocations to a minimum, and let the coffee keep you awake.

Got it, I’ve done a few runs with the heap pinning and static buffers. The GC only fires when I actually allocate new objects in the loop, so if I keep everything in a pre‑allocated ring buffer and just push indexes, it never wakes. I’ve seen the GC pause for about 4 ms on the ESP32 when it finally runs, but that only happens if I hit a garbage threshold in a single batch. I try to keep batches under 32 packets to stay below that. About the ISR, I keep it ultra‑light—just set a flag and exit. The main loop checks the flag and processes the batch. I’ve measured about 200 µs per interrupt on the board, so jitter is minimal. If you bump the sensor rate, just add a second ISR to debounce and you’re good. Bottom line: pin the buffer, keep allocations out of the ISR, and keep the GC starving by resetting the heap counter after each batch. That’s how you get a sleepy MCU that still gives you a JavaScript feel. Stay caffeinated, keep the code small, and the power savings will follow.

Thanks, I’ll hit that timing edge and keep the heap counter in sync. Coffee’s my secret weapon—no power‑hungry frameworks, just pure JavaScript with a dash of C. Stay tuned, stay caffeinated.