Event-driven architecture in FreeRTOS - Deep Dive

Overview - Event-driven architecture

What is it?

Event-driven architecture is a way to design software where the flow is controlled by events. An event can be anything like a button press, a sensor reading, or a message arriving. Instead of running code step-by-step, the system waits for events and reacts to them. This makes programs more responsive and efficient, especially in embedded systems like those using FreeRTOS.

Why it matters

Without event-driven architecture, programs would waste time checking for changes constantly, using more power and slowing down other tasks. Event-driven design lets devices respond instantly to important actions, saving energy and improving performance. This is crucial in real-time systems like FreeRTOS where timing and resource use matter a lot.

Where it fits

Before learning event-driven architecture, you should understand basic programming concepts and how FreeRTOS tasks and interrupts work. After this, you can explore advanced FreeRTOS features like queues, semaphores, and timers that help implement event-driven systems effectively.

Mental Model

Core Idea

Event-driven architecture means the program waits for signals (events) and reacts only when something happens, instead of running all the time.

Think of it like...

It's like a doorbell at home: you don't watch the door all day, but when the bell rings (event), you respond immediately by opening the door.

┌───────────────┐
│   Event Bus   │
└──────┬────────┘
       │
┌──────▼───────┐      ┌─────────────┐
│ Event Source │─────▶│ Event Handler│
└──────────────┘      └─────────────┘
       ▲
       │
┌──────┴───────┐
│   FreeRTOS   │
│  Scheduler   │
└──────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Events and Handlers

Concept: Learn what events are and how handlers respond to them.

An event is a signal that something happened, like a button press or a timer finishing. An event handler is a piece of code that runs when the event occurs. In FreeRTOS, events can come from hardware interrupts or software signals. Handlers react to these events to perform tasks.

Result

You know that events are triggers and handlers are responses, forming the basic interaction in event-driven systems.

Understanding events and handlers is the foundation for building responsive programs that act only when needed.

2

Foundation

FreeRTOS Tasks and Interrupts Basics

Concept: Learn how FreeRTOS manages tasks and interrupts which generate events.

FreeRTOS runs multiple tasks that share the CPU. Interrupts are signals from hardware that pause tasks to handle urgent events. Tasks can wait for events using synchronization tools. This setup allows FreeRTOS to manage events efficiently.

Result

You see how FreeRTOS multitasks and uses interrupts to handle events quickly.

Knowing how tasks and interrupts work helps you understand where and how events happen in FreeRTOS.

3

Intermediate

Using Queues for Event Communication

🤔Before reading on: do you think queues store data or just signals? Commit to your answer.

Concept: Queues in FreeRTOS pass event data safely between tasks.

A queue is like a mailbox where one task puts event data and another task picks it up. This lets tasks communicate events without interfering with each other. For example, an interrupt can send a message to a queue, and a task waiting on that queue will react.

Result

You can pass event information between tasks safely and efficiently.

Understanding queues unlocks how FreeRTOS tasks coordinate through events without conflicts.

4

Intermediate

Implementing Event Groups for Multiple Events

🤔Before reading on: do you think event groups handle one event or multiple events at once? Commit to your answer.

Concept: Event groups let tasks wait for one or more events simultaneously.

Event groups are like flags that tasks can wait on. Each bit in the group represents a different event. Tasks can wait until one or all flags are set, allowing complex event synchronization. This is useful when a task depends on multiple conditions.

Result

You can synchronize tasks based on multiple events happening together or separately.

Knowing event groups helps manage complex event dependencies in FreeRTOS applications.

5

Advanced

Designing Non-blocking Event Loops

🤔Before reading on: do you think event loops block the CPU or allow other tasks to run? Commit to your answer.

Concept: Event loops wait for events without stopping other tasks from running.

An event loop checks for events and runs handlers when events occur. In FreeRTOS, this means using non-blocking calls or waiting on queues with timeouts. This design keeps the system responsive and allows multitasking without wasting CPU time.

Result

Your program reacts to events efficiently while sharing CPU time fairly.

Understanding non-blocking loops prevents freezing and keeps embedded systems responsive.

6

Expert

Optimizing Event-driven Systems for Real-time

🤔Before reading on: do you think all event handlers should run immediately or can some be deferred? Commit to your answer.

Concept: Balancing immediate and deferred event handling improves real-time performance.

In FreeRTOS, some events must be handled immediately in interrupts, while others can be deferred to tasks. Using techniques like deferred interrupt handling and prioritizing events ensures deadlines are met without blocking critical operations. This requires careful design of event priorities and handler code.

Result

Your system meets real-time constraints while handling many events smoothly.

Knowing when to defer event handling avoids missed deadlines and system crashes in real-time applications.

Under the Hood

FreeRTOS uses a scheduler to switch between tasks based on priority and readiness. Events often come as interrupts that signal hardware or software changes. Interrupt Service Routines (ISRs) quickly capture these events and use synchronization tools like queues or event groups to notify tasks. Tasks then process events in their own time, allowing multitasking without conflicts.

Why designed this way?

This design separates urgent event detection (in ISRs) from event processing (in tasks) to keep ISRs short and fast, preventing system delays. It balances responsiveness with system stability, which is critical in embedded real-time systems where timing matters.

┌───────────────┐
│   Hardware    │
│ (Sensors, etc)│
└──────┬────────┘
       │ Interrupt
       ▼
┌───────────────┐
│     ISR       │
│ (Quick Event  │
│  Capture)     │
└──────┬────────┘
       │ Send event
       ▼
┌───────────────┐
│ FreeRTOS Task │
│ (Event Handler│
│  Processes)   │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do event-driven systems always run faster than polling? Commit to yes or no.

Common Belief: Event-driven systems are always faster than polling systems.

Reality: Event-driven systems are more efficient in resource use but not always faster in raw speed. Polling can be simpler and sometimes faster for very simple or predictable tasks.

Why it matters: Assuming event-driven is always faster can lead to overcomplicated designs where simple polling would suffice, wasting development time.

Quick: Do all events in FreeRTOS come from hardware interrupts? Commit to yes or no.

Common Belief: All events in FreeRTOS come only from hardware interrupts.

Reality: Events can come from hardware interrupts, software timers, or inter-task communication like queues and event groups.

Why it matters: Limiting events to hardware interrupts restricts design options and misses powerful software-driven event mechanisms.

Quick: Can event handlers in FreeRTOS run for a long time inside interrupts? Commit to yes or no.

Common Belief: Event handlers can run long inside interrupt service routines without issues.

Reality: Interrupt handlers must be short and fast; long processing inside interrupts can block other interrupts and cause system instability.

Why it matters: Ignoring this can cause missed events, system crashes, or unpredictable behavior in real-time systems.

Quick: Does using event groups mean tasks always wait for all events? Commit to yes or no.

Common Belief: Event groups force tasks to wait for all events before proceeding.

Reality: Tasks can wait for any one event or all events, depending on how event groups are configured.

Why it matters: Misunderstanding this limits flexibility in task synchronization and can cause inefficient waiting.

Expert Zone

1

Event-driven systems in FreeRTOS often mix interrupt-level and task-level event handling, requiring careful priority and timing management to avoid priority inversion.

2

Using deferred interrupt handling via task notifications or queues improves system responsiveness and reduces ISR complexity, a pattern many beginners miss.

3

Event groups use bitwise operations internally, so understanding bitmask manipulation is key to advanced synchronization and debugging.

When NOT to use

Event-driven architecture is not ideal for simple, linear tasks where polling is sufficient or when event overhead outweighs benefits. In extremely time-critical loops, direct polling or dedicated hardware may be better.

Production Patterns

In real FreeRTOS projects, event-driven design uses ISRs to capture hardware events, queues to pass data safely to tasks, and event groups for complex synchronization. Deferred interrupt handling and priority-based scheduling ensure real-time deadlines are met.

Connections

Reactive Programming

Event-driven architecture builds on the same idea of reacting to data changes or events asynchronously.

Understanding event-driven design in FreeRTOS helps grasp reactive programming concepts used in modern software frameworks.

Operating System Interrupts

Event-driven systems rely heavily on interrupts to signal events from hardware to software.

Knowing how interrupts work at the OS level clarifies why event-driven architecture is efficient and how it manages real-time constraints.

Neuroscience Neural Signaling

Both systems use signals (events) to trigger responses in different parts of a network.

Recognizing event-driven architecture as similar to how neurons fire and communicate deepens understanding of asynchronous signaling in complex systems.

Common Pitfalls

#1 Blocking inside interrupt handlers for long processing.

Wrong approach:

void ISR_Handler() {
// Long processing
for(int i=0; i<10000; i++) {
process_data(i);
}
}

Correct approach:

void ISR_Handler() {
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
// Send event to task
xQueueSendFromISR(queue, &data, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Root cause:

Misunderstanding that ISRs must be short and deferring work to tasks avoids blocking and priority issues.

#2 Using polling loops instead of event synchronization.

Wrong approach:

while(1) {
if(sensor_ready()) {
read_sensor();
}
}

Correct approach:

if(xSemaphoreTake(sensorSemaphore, portMAX_DELAY) == pdTRUE) {
read_sensor();
}

Root cause:

Not using FreeRTOS synchronization tools leads to wasted CPU cycles and poor responsiveness.

#3 Waiting for all events when only one is needed.

Wrong approach:

xEventGroupWaitBits(eventGroup, EVENT1 | EVENT2, pdTRUE, pdTRUE, portMAX_DELAY);

Correct approach:

xEventGroupWaitBits(eventGroup, EVENT1 | EVENT2, pdTRUE, pdFALSE, portMAX_DELAY);

Root cause:

Misunderstanding the 'wait for all' vs 'wait for any' parameter causes unnecessary delays.

Key Takeaways

Event-driven architecture lets programs react only when something important happens, saving resources and improving responsiveness.

In FreeRTOS, events come from interrupts or software signals and are handled by tasks using queues, event groups, and notifications.

Interrupt handlers should be short and defer heavy work to tasks to keep the system stable and responsive.

Using FreeRTOS synchronization tools correctly avoids wasted CPU time and ensures tasks coordinate efficiently.

Balancing immediate and deferred event handling is key to meeting real-time requirements in embedded systems.