Forget last video featuring very helpful artificial intelligence - this week we plummet back down to "NO intelligence" (NI) as we open a pile of packets arriving from China to my bench-top.
It's a problem when you have too many clocks - but oh so nice when they all show the same time!
Enjoy the video - leave a comment if you have any questions!
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!
An exploration of two ESP32 programming methodologies, highlighting why the implementation approach is more critical than the library choice.
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.
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.
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.
Explore the four key differences in approach below.
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
});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...
}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.
}
}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...
}
}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
}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
}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()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 neededThis 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.
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.
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.
A quick(ish) video about modifying a little butterfly toy. Just to make a nice change from all the coding!
I hope that you enjoy the change of pace - regular programming will resume shortly!
I have been tinkering with Solar Power and WiFi for a while now - and the arrival of some new solar panels and the tiny Seeed Studio ESP32-C6 prompted me to put together a prototype for testing.
I also decided to (briefly) use an IP2312 charging module - but as you will see in the video below it didn't really work out for me - more exploration required at this point!
Another snag was that the little board needed a software coded switch to activate the external antenna, and so I had to insert that code into the project, and ended up creating my own github folder with the tweaks, including compiled binary files if you want to just lock and load the code.
// Added by OneCircuit (and Gemini AI) on Tue 12 Aug 2025 14:49:14 AEST // https://www.youtube.com/@onecircuit-as #include "driver/gpio.h" #include "freertos/FreeRTOS.h" #include "freertos/task.h" // Define GPIO pin numbers #define ESP32C6_WIFI_ENABLE_PIN GPIO_NUM_3 #define ESP32C6_WIFI_ANT_CONFIG_PIN GPIO_NUM_14 void initialise_ext_antenna(void) { // Configure GPIO pins as outputs gpio_reset_pin(ESP32C6_WIFI_ENABLE_PIN); gpio_set_direction(ESP32C6_WIFI_ENABLE_PIN, GPIO_MODE_OUTPUT); gpio_reset_pin(ESP32C6_WIFI_ANT_CONFIG_PIN); gpio_set_direction(ESP32C6_WIFI_ANT_CONFIG_PIN, GPIO_MODE_OUTPUT); // Set pin levels gpio_set_level(ESP32C6_WIFI_ENABLE_PIN, 0); // Activate RF switch control (LOW) // Delay vTaskDelay(pdMS_TO_TICKS(100)); // Use a FreeRTOS delay function gpio_set_level(ESP32C6_WIFI_ANT_CONFIG_PIN, 1); // Use external antenna (HIGH) }
This is a version of the ESP32 router code found at:
https://github.com/dchristl/esp32_nat_router_extended, which in turn is a version of the code found here:
https://github.com/martin-ger/esp32_nat_router
I also slightly modified the partitions csv file to work with the ESP32C6, and added a file of the commands I used to load the binaries using esptool.py
Also thanks to Gemini AI who came in after three days of me banging me head against a wall trying to merge two coding platforms and sorted out the last little hiccups in my code.
Finally, for LOLS, I moved from the Arduino IDE to Visual Code Studio with PlatformIO and ESP-IDF extensions running - it's own little adventure in the end.
The whole project taught me a great deal about all of these components - hardware, software, tweaking and even some antenna rabbit holes!
Enjoy and please leave a comment if you have a moment!
It's funny how you can do something for so long without realising that it's a bit kooky!
For years I've been making various flavours of the "candle project" and each time I spend W-A-Y too long poking about in the cupboard for all the components (and swearing a bit as well).
Recently I took delivery of a new "super capacitor" PCB (gerbers available here) based version of this project, and I was once again contemplating gathering all the components when...it suddenly occurred to me to make up a specific project box.
Game changer!
So the video below is both a testament to my stupidity and a nod to the concept of project file boxes. Enjoy - it's a long one so go get your favourite beverage before clicking!
Last time we looked at the RV2 it was for LOLS, but I would really like to have a screen and 'puter in the lab/work area for music, internet, conferencing, video capture, etc., - so in this video I house the beast in a case and sling it up on the wall in front of my workbench.
Short story 'tis true - but another great addition to the channel workflow. Check it out in the video below.
Well it's 2025 and apart from craziness erupting all over the planet the big news is RISCV continues to impress the punters with it's speed, reliability and efficiency.
Orange Pi are now officially on the RISCV bandwagon which means of course so am I, with a delivery recently of the RV2 single board computer.
It's a lovely piece of kit and in the video below I take it for a spin and hook it up to a touch screen via the Ubuntu sanctioned OS image.
Only one hiccup - the EMMC card needs to be loaded via the OS, not from the image itself. It's a minor issue that I was easily able to solve (in fact I over complicated the whole thing a bit - as usual).
Sit back and enjoy - and please like and subscribe!