# A C-Based Framework for Low-Cost Real-Time Embedded Systems
## 8 Performance Evaluation and Analysis
### Event-Driven Reactivity  
The reaction time of RtFw to an external event originating from a remote I/O card, which is crucial for event-driven programming performance, has been evaluated in the scenario shown in Figure 13. It consists of the following steps:  
* A remote Modbus I/O card generates an event and sends an asynchronous event notification message 1 to the controller card via a real-time bus.
* The controller card firmware reacts by activating the event handling task and then the control task 2.
* The control task performs a selective input operation 3, activates the control function to handle the event 4, and performs a selective output operation 5.  
The input and output operations that the controller card performs are seen by remote I/O cards as a sequence of Modbus register read and write operations, respectively. For writes, the timestamping point has been placed after the remote I/O card received the Modbus request from the controller card and the data to be written, but before it sent the corresponding acknowledgment. For reads, the timestamping point has been placed as soon as the remote I/O card becomes aware of the request. Therefore, \(t_{E,O}\) represents the total reaction time of the controller card to a remote event, measured from event generation  
Figure 13: Framework timing diagram, event-driven execution. Bus traffic not shown for clarity.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Number of Outputs**} & \multicolumn{4}{c}{**Total Delay \(t_{O}\) (us)**} \\  & \(\mu\) & \(\sigma\) & **Min** & **Max** \\ \hline
1 & 410.19 & 0.83 & 408.42 & 412.43 \\
2 & 428.00 & 0.64 & 426.56 & 430.15 \\
4 & 524.22 & 0.62 & 522.87 & 525.78 \\
8 & 663.05 & 1.45 & 660.05 & 665.68 \\ \hline \hline \multirow{2}{*}{**Number of Inputs**} & \multicolumn{4}{c}{**Total Delay \(t_{I}\) (us)**} \\  & \(\mu\) & \(\sigma\) & **Min** & **Max** \\ \hline
1 & 280.55 & 1.09 & 278.39 & 283.49 \\
2 & 360.54 & 1.59 & 357.83 & 367.03 \\
4 & 405.67 & 3.41 & 398.87 & 415.32 \\
8 & 544.20 & 3.91 & 536.81 & 557.93 \\ \hline \hline \end{tabular}
\end{table}
Table 2: Behavior of \(t_{O}\) and \(t_{I}\) as a function of the number of 16-bit I/O points, 490 sample points.  
to the time at which the reaction becomes externally observable as a change of state of some of its outputs. Time \(t_{E,I}\leq t_{E,O}\), instead, is the earliest point in time when the remote I/O card that generated the event becomes aware that event handling has started.  
Table 3 lists experimental results, as before, as a function of the number of 16-bit I/O points. The interval between consecutive remote event generations was set to a value greater than \(t_{h}\) for the experiment to avoid triggering the activation of event gathering and hold-off interval extension. Moreover, care has been taken to avoid any interference from time-driven activities while handling an event. As in the previous set of experiments, the control function content was kept to a minimum.  
Barring measurement noise, \(t_{E,I}\) remained constant as the number of I/O points varied. This was to be expected because a Modbus register read request has a fixed length, regardless of the number of registers to be read. Instead, \(t_{E,O}\) depends on the number of I/O points because their values are transferred together with the Modbus register write request. What is more important though, is that \(t_{E,O}\) remained below 1.3 ms, even in the worst case, with a standard deviation below 4 us, thus confirming that RtFw is able to respond to external events timely and consistently.