I recently came across the concept of Event Loop Programming, but I’ve been struggling to find a clear, beginner-friendly explanation. I realized that part of the problem is that I’m missing an understanding of the basic, foundational concepts that support event loop programming. What are the essential, fundamental concepts I should understand before trying to implement event loop programming in my own projects?

Describe what you are wanting to do.

Hello drunyan0824 Take a look at this small and simple code example for your studies. // Make task names enum TaskName {TaskOne, TaskTwo}; // Make array of tasks uint16_t (*tasks[])(uint32_t currentTime) { taskOne, taskTwo }; // Make taskOne uint16_t taskOne(uint32_t currentTime) { Serial.print(__func__), Serial.print(" @ "), Serial.println(currentTime); return TaskTwo; // call TaskTwo } // Make tasktwo uint16_t taskTwo(uint32_t currentTime) { Serial.print(__func__), Serial.print(" @ "), Serial.println(currentTime); return TaskOne; // call TaskOne } void setup() { Serial.begin(115200); } void loop() { static uint16_t index = TaskOne; // start with TaskOne uint32_t currentTime = millis(); index = tasks[index](currentTime); // call task and save return for next call delay(1000); // for testing only !! }

This example from your second link seems like the "core" of "event loop programming": void loop() { if (event_foo_happened()) handle_event_foo(); if (event_bar_happened()) handle_event_bar(); if (event_baz_happened()) handle_event_baz(); // etc... } (and additional info about event types in that reply is also good.) There's not a lot of "concept" TO that. I guess the main thing to remember is that each of test and handle_event_xxx() functions needs to be "fast" compared to the time frames of the events that you are dealing with - no delay() calls or big loops. I might have written it more like: void loop() { handle_foo(); handle_bar(); handle_baz(); // etc... } void handle_foo() { if (event_foo_idle()) { return(); // return quickly if nothing to do } // code to actually do something, if there is something to do. // (still "quickly"!) // : } //etc If a particular event would be long, you need to further divide it into sub-events, which is where concepts like "state machines" come in. You might do: void loop() { // separate "event" states for serial input in the main event loop. handleSerial(); // input serial data (if any) until there is a full line handleLines(); // if a full line was received, process it. // : Or you might do: void loops() { handleInput(); // read and process Serial data : } void handleInput() { // separate states in the input event int c = Serial.read(); if (c < 0) return; // no data. if (c == '\r') { // process line } else { inputLine += (char) c; } }

How about this: you may have heard that Node.js is single-threaded with an event loop. In the basic web server case, it opens up a port. The OS will notify when a connection occurs, thus creating an event. Parse enough of the request, and it might ask for a file. The process will ask the OS for that file, which takes some non-zero amount of time. Now the process is free to handle the next event. That event could be the OS saying, here's that file; or the start of another request, or something else. And if the file is large enough, you wouldn't send it all at once, but a piece (or chunk) at a time. The basic idea is there's an event queue of things to do. Maybe it's empty: nothing to do. Something comes in, and do that thing, as long as that thing doesn't involve some indeterminate wait, or is likely/known to take "too long", since that will block everything else. Because a task like downloading a big file can be interleaved with other tasks, the system is effectively multi-tasking. But as a single thread, there are no issues with concurrency and contention, locks and memory models, etc. There are other potential issues :slight_smile: Several Node helper functions take other functions setInterval: periodically add this function to the event queue; repeat unless cancelled setTimeout: wait a while, then add this function to the event queue setImmediate: add this function to the end of the event queue. If there are other things waiting, do those first, but get to this new function as soon as possible. On Arduino, there's not much "built-in" that will trigger an event; you have to go "get it" yourself. To do something similar, here's a WorkItem class; with an array of them acting as a ring buffer, it can impersonate a simple event queue typedef void(*work_t)(void); constexpr size_t wqSize = 10; size_t wqHead, wqLen; class WorkItem { unsigned long previousMillis; unsigned long interval; bool repeat; work_t work; void requeue(); bool doWork() { if (repeat) { if (millis() - previousMillis interval); // even when falling behind requeue(); // after work(), which may enqueue something else } return true; } public: static bool enqueue(work_t work, unsigned long interval = 1000, bool repeat = true); static bool doNext(); } workQueue[wqSize]; // ring buffer void WorkItem::requeue() { size_t tail = (wqHead + wqLen++) % wqSize; WorkItem *item = workQueue + tail; item->previousMillis = previousMillis; item->interval = interval; item->repeat = repeat; item->work = work; } bool WorkItem::enqueue(work_t work, unsigned long interval, bool repeat) { if (wqLen == wqSize) { return false; // queue is full! } size_t tail = (wqHead + wqLen++) % wqSize; WorkItem *item = workQueue + tail; item->previousMillis = millis(); item->interval = interval; item->repeat = repeat; item->work = work; return true; } bool WorkItem::doNext() { const size_t tail = wqHead + wqLen; size_t head = wqHead; // index may go past wqSize while (head doWork()) { return true; } } return false; } The rest of the sketch has two functions that represent work-to-do. One of them uses a static variable, which is one way of having per-function persistent data; but it could easily reference a global variable. void blink() { static int ledState = LOW; if (ledState == LOW) { ledState = HIGH; } else { ledState = LOW; } digitalWrite(LED_BUILTIN, ledState); } void tick() { Serial.println(millis()); } void setup() { Serial.begin(115200); pinMode(LED_BUILTIN, OUTPUT); WorkItem::enqueue(tick); WorkItem::enqueue(blink, 750); } void loop() { if (!WorkItem::doNext()) { // If there was "nothing to do", waiting a little bit until checking again // is "nicer" and may allow other tasks or an idle task, or use less power delay(1); } } setup enqueues two repeating items. loop then scans the queue. The work functions can enqueue other items. Each repeating item adds itself back; so the queue has more "traffic" than a "pure" queue of "stuff to do". Another simplification: the queue size is fixed, more than big enough.

[image] drunyan0824: but my understanding is that the Void loop would contain nothing but function calls and all the complicated programing would be do in the individual functions called in the void loop. don't know why that approach would have such a name. I have a model RR signaling system composed of 14 files, 1800+ lines void loop () { msec = millis (); ledStatus (); #if 1 wifiMonitor (); sigCheck (); #endif pcRead (); tglTest (); }

[image] alto777: The wikipedia article allows an interpretation that works well with some projects. seems that all programs can be describes as either IPO or simply PO.

[image] gcjr: seems that all programs can be describes as either IPO or simply PO. IMO, this whole discussion is much ado about nothing. All techniques being discussed here are just variations on the same theme used over and over in Arduino (and most embedded) programming … check an “input”, compute a response, send the response, repeat. The “input” can be user data, a time interval, position of a switch, sensor data, state of a state machine, etc. Whether the above tasks are coded inline in the loop() function or in functions called by loop() is just an implementation detail.

[image] drunyan0824: What are the essential, fundamental concepts I should understand before trying to implement event loop programming in my own projects? Perhaps the most important concept is that events may involve TIME, not all happen instantly.

[image] gcjr: either IPO or simply PO. LOL! These fora are full of programs ("sketches") that could defy description of any kind from any angle on any formal basis. a7

[image] westfw: handle_bar(); Too early but tempting. a7

Basic Concepts Of Event Loop Driven Programming

Projects Programming

grb March 13, 2025, 11:51am 24

This tutorial might be helpful to you:

Topic		Replies	Views
Feedback on "Task Scheduler for Arduino" tutorial Programming	31	584	August 7, 2026
Do you struggle with multitasking or events in your project? General Guidance	108	3479	June 14, 2023
learner's question (could be wrong) - Event-driven programming best practices? Programming	89	13816	August 10, 2016
Tutorial Task Scheduler for Arduino Tutorials	1	653	March 1, 2026
Best emtpy loop() Programming	43	976	February 17, 2026

Basic Concepts Of Event Loop Driven Programming

Related topics