Non-blocking code architecture in Arduino - Time & Space Complexity
When writing non-blocking code on Arduino, we want to keep the program running smoothly without waiting too long in one place.
We ask: how does the time spent change as the program handles more tasks?
Analyze the time complexity of the following non-blocking code snippet.
unsigned long previousMillis = 0;
const long interval = 1000;
void loop() {
unsigned long currentMillis = millis();
if (currentMillis - previousMillis >= interval) {
previousMillis = currentMillis;
// perform task
}
// other code runs here without delay
}
This code checks time repeatedly and runs a task only when the interval passes, without stopping the rest of the program.
Look for repeated actions in the code.
- Primary operation: The loop() function runs continuously, checking the time.
- How many times: It runs as fast as the Arduino can, many thousands of times per second.
Imagine the input as how often the task needs to run.
| Input Size (task frequency) | Approx. Operations per second |
|---|---|
| 10 times | Loop runs thousands of times, task runs 10 times |
| 100 times | Loop runs thousands of times, task runs 100 times |
| 1000 times | Loop runs thousands of times, task runs 1000 times |
Pattern observation: The loop runs very fast and often, but the task runs only when needed, so the main work grows with task frequency, not loop speed.
Time Complexity: O(n)
This means the time spent on the task grows directly with how many times the task runs, while the loop itself runs continuously without delay.
[X] Wrong: "The loop() function runs only once per task interval."
[OK] Correct: The loop() runs repeatedly and very fast; the task inside runs only when the time condition is met, so the loop keeps the program responsive.
Understanding non-blocking code shows you can write programs that stay responsive and efficient, a skill useful in many real-world embedded projects.
What if we replaced the time check with a blocking delay? How would the time complexity change?
Practice
Solution
Step 1: Understand blocking vs non-blocking
Blocking code stops the program until a task finishes, while non-blocking code lets the program keep running other tasks.Step 2: Identify the benefit of non-blocking
Non-blocking code allows multitasking and keeps the Arduino responsive.Final Answer:
It allows the Arduino to perform multiple tasks without waiting. -> Option CQuick Check:
Non-blocking = multitasking [OK]
- Thinking non-blocking slows code down
- Confusing memory use with blocking behavior
- Believing non-blocking fixes hardware issues
Solution
Step 1: Identify blocking vs non-blocking code
delay() and while loops that wait block the program, stopping other tasks.Step 2: Recognize millis() usage
Using millis() to check elapsed time allows the program to continue running other code.Final Answer:
if (millis() - previousMillis >= interval) { /* do task */ } -> Option BQuick Check:
millis() check = non-blocking [OK]
- Using delay() which blocks the program
- Using while loops that wait for time
- Confusing delayMicroseconds with non-blocking
unsigned long previousMillis = 0;
const long interval = 1000;
void loop() {
if (millis() - previousMillis >= interval) {
previousMillis = millis();
Serial.println("Tick");
}
}Solution
Step 1: Analyze the millis() timing check
The code checks if 1000 milliseconds (1 second) have passed since last print.Step 2: Understand the loop behavior
When 1 second passes, it updates previousMillis and prints "Tick" again, repeating forever.Final Answer:
Prints "Tick" every second repeatedly. -> Option AQuick Check:
millis() timer triggers print every 1 second [OK]
- Thinking it prints only once
- Assuming continuous printing without delay
- Believing there is a syntax error
unsigned long previousMillis = 0;
const long interval = 1000;
void loop() {
if (millis() > previousMillis + interval) {
Serial.println("Hello");
}
}Solution
Step 1: Check the timing logic
The code checks if millis() is greater than previousMillis + interval but never updates previousMillis.Step 2: Understand the effect
Without updating previousMillis, the condition stays true, so "Hello" prints continuously without delay.Final Answer:
It never updates previousMillis, causing continuous prints. -> Option AQuick Check:
Missing previousMillis update = continuous print [OK]
- Forgetting to update previousMillis
- Changing comparison operator incorrectly
- Thinking Serial.println() is invalid in loop
Solution
Step 1: Understand multitasking with millis()
Each task needs its own timer to run independently without blocking.Step 2: Evaluate options
Use two millis() timers, one for LED and one for sensor, each updating separately. This uses two separate millis() timers, allowing LED and sensor to run at different intervals smoothly.Final Answer:
Use two millis() timers, one for LED and one for sensor, each updating separately. -> Option DQuick Check:
Separate timers = true multitasking [OK]
- Using delay() which blocks all tasks
- Combining intervals causing missed timings
- Using while loops that block execution
Ready to prove it?
Pass the test and this pattern moves unknown
