# A C-Based Framework for Low-Cost Real-Time Embedded Systems
## 5 Event-Driven Programming  
Event-driven programming relies on the timely reaction of the embedded system to external events, typically detected by sensors connected to remote I/O cards. In this case, the challenge was to design an event management system that provided a timely reaction to events and adequate overload protection while staying within the computing and memory constraints of typical IoT systems and allowing it to coexist with the time-driven part of the framework. This goal was achieved by means of a single, dedicated event management task, a couple of semaphores, and a timer. In fact, on the controller card used for the experimental evaluation, the event-to-input and event-to-output reaction times commented in Section 8 are I/O-bound rather than CPU-bound. Moreover, the event-management system represents a modest 6% of the RTfw total size, as also described in the same section.  
As shown in Figure 4, the event management task waits for events coming from one of the RTfw real-time I/O libraries. It then collects and aggregates them and eventually delivers them to the control task as event notifications through the main RTfw event system. In addition, the task maintains information on which remote I/O cards generated an event, and hence, need the attention of the control function, in each specific control function activation. The mechanism used by remote I/O cards to send an event is protocol-specific but, in any case, its implementation and peculiarities are kept hidden from RTfw by the corresponding I/O libraries. As an example, it may consist of event-driven PDOs in the case of CANopen [42] or an unsolicited message with a non-zero protocol identifier in the case of Modbus-CAN [41].  
As shown in Figure 4, when an event arrives, the task first applies the hold-off algorithm to be discussed in Section 5.1 to aggregate events as necessary and avoid overloading the control task by sending it events too closely in time. Then, if the hold-off mechanism permits, it sends an event notification, which may contain multiple aggregated events, to the control task. Finally, the control task calls the control function, surrounded by the  
Figure 4: Relationship between the event management task and other RTfw components.  
selective I/O procedure discussed in Section 5.2, to update PI variables before and after the call. When the control task has finished servicing the event, it must provide feedback to the event management task so that it can update the hold-off algorithm state and, possibly, deliver a new event notification to the control task.  
While handling an event, the control task may query which remote I/O cards must be serviced during the current activation to properly drive selective I/O and minimize the number of I/O operations it performs. The control function, instead, has a more abstract view of the situation and is informed of which PI variables need to be serviced because the remote I/O card they come from has generated an event. After working on them, the control function gets the opportunity to inform the control task of which other PI variables it has updated, again, with the purpose of optimizing selective I/O.