How Gemini turned "Brute strength" into "Elegant code"
Awhile back I did a Little Bin project which worked fine until our TelCo (Optus, based in Singapore) decided to nuke it's network (and kill a few people in the process. I got off lightly, but still had some issues with compiling (library updates and some code noodling required), hardware access (the ESP32-S3 was literally in a little bin!) and finally some code snafus which Gemini helped me sort out. See below for Gemini's analysis, and see my github site (https://github.com/bovineck/LittleBin/tree/main) for the code. Video below!
Interactive Analysis
An exploration of two ESP32 programming methodologies, highlighting why the implementation approach is more critical than the library choice.
The Crucial Distinction: Library vs. Methodology
This is the most important concept to understand. While the first code file used a "non-blocking" library, its implementation was fundamentally blocking. Conversely, the second file used a simpler "blocking" library but implemented a brilliant non-blocking methodology, making its overall approach far superior.
❌ File 1's Problem
The `ESPAsyncWebServer` library is powerful and non-blocking, but the code's use of `while` loops and `delay()` for tasks like connecting to WiFi and NTP effectively **froze the microcontroller**. This prevented it from doing anything else and negated the library's primary advantage. It's a classic case of using a powerful tool incorrectly.
✔ File 2's Strength
The `WebServer` library is simpler, but the programmer's decision to use a **state-based, `millis()`-driven approach** allowed the program's main loop to run continuously. This non-blocking methodology ensures all tasks are managed concurrently, leading to a much more stable and responsive system.
Side-by-Side Comparison
Explore the four key differences in approach below.
Approach 1: `ESPAsyncWebServer`
This non-blocking, event-driven library is powerful. Like a modern waiter handling multiple tables at once, it doesn't wait for one task to finish before starting another. However, its benefits were undermined by blocking code elsewhere in the program.
// Event-driven handlers are set up once
server.on("/", HTTP_GET, [](AsyncWebServerRequest* request) {
request->send(200, "text/html", index_html);
});
server.on("/", HTTP_POST, [](AsyncWebServerRequest* request) {
// Logic to handle form data
});Approach 2: `WebServer`
This standard library is simpler but blocking. Like a traditional waiter who serves one table at a time, `server.handleClient()` must be called constantly in the main loop, otherwise the server becomes unresponsive.
// Must be called in every loop iteration
void loop() {
server.handleClient();
// Other non-blocking code...
}Approach 1: Blocking with `delay()`
The code relies on `delay()` and `while` loops that halt the entire program. While waiting for WiFi to connect, the ESP32 can do nothing else—it can't serve web pages or update LEDs. This is known as "blocking" and is highly inefficient.
void initWiFi() {
while (WiFi.status() != WL_CONNECTED) {
delay(100); // Program is FROZEN here
// No other tasks can run.
}
}Approach 2: Non-Blocking with `millis()`
This approach avoids `delay()` entirely. It uses `millis()` to check if enough time has passed to perform a task. The main `loop` runs thousands of times per second, ensuring all tasks are managed concurrently and the system remains responsive.
void loop() {
unsigned long currentMillis = millis();
if (currentMillis - lastCheck >= interval) {
lastCheck = currentMillis;
// Perform a non-blocking task...
}
}Approach 1: Restart on Failure
The error handling is blunt: if a connection fails after a set number of tries, the device reboots with `ESP.restart()`. This is disruptive, causing several seconds of downtime and losing any temporary state.
if (numtries > wifitries) {
numtries = 0;
ESP.restart(); // Forces a full reboot
}Approach 2: Graceful Retries
This method is far more graceful. If the connection is lost, it continuously tries to reconnect in the background while signaling the failure with a visual indicator (blinking LEDs). The rest of the system remains fully operational.
if (WiFi.status() != WL_CONNECTED) {
isWifiConnected = false;
signalFailure(); // Calls a non-blocking function
}Approach 1: Redundant Logic
The same logic for flashing LEDs is duplicated in multiple functions (`initWiFi()`, `GetLocalTime()`). This makes the code harder to read, maintain, and debug, as a change in one place must be remembered in others.
// In GetLocalTime()...
while (!getLocalTime(&timeinfo)) {
// ... LED flashing code ...
delay(100);
}
// Same logic exists in initWiFi()Approach 2: Modular Functions
The code is broken down into small, reusable, single-purpose functions like `signalFailure()` and `handleRoot()`. This modular approach makes the code clean, easy to understand, and simple to extend with new features.
// A reusable, single-purpose function
void signalFailure() {
// Logic for blinking LEDs
}
// Called from anywhere it's neededVisualizing Concurrency
This diagram illustrates the "Delay is Death" principle. The blocking loop gets stuck on long tasks, while the non-blocking loop handles multiple tasks concurrently, leading to a responsive system.
❌ Blocking Loop Execution
Start Loop
Begin checking tasks...
Attempting WiFi Connect...
Program is FROZEN. Waiting for 3 seconds...
Handle Web Request
Cannot run. Blocked by WiFi task.
Update LEDs
Cannot run. Blocked by WiFi task.
✔ Non-Blocking Loop Execution
Check WiFi Status
Is it time? Yes. Check and move on. (1ms)
Handle Web Request
Any requests? No. Move on. (1ms)
Update LEDs
Is it time? Yes. Update and move on. (1ms)
Check NTP Time
Is it time? No. Move on. (1ms)
Loop repeats thousands of times per second.
