Novos EFB Technical Concepts
Superior Interrupt Handling concept
The efficiency of handling interrupts is usually an important aspect in most embedded systems. The general dictum is to spend as little time servicing an interrupt as possible. There are several concepts of how to handle interrupts but usually it is a choice between ease-of-use and processing time. Processing time relates directly to responsiveness, an important design aspect in most systems. Ease of use often relates to how the interrupt service routine (ISR) communicates the occurrence of the interrupt to other entities of the application.
One choice is the simple solution of disabling all interrupts during the ISR and not re-enabling them until the ISR completes. It is simple and effective but it extends the time spent in the ISR, adversely affecting responsiveness. Communication of the interrupt and any related data with the application can be similarly simple provided the ISR doesn’t step on data structures that are in an intermediate state at the time of the interrupt. To avoid that situation, the usual solution is for the application code to disable interrupts around any code that is vulnerable to interrupt processing, thereby creating even more critical regions and reducing responsiveness. As stated, it is a simple solution,
A second concept creates a special set special services callable from an ISR with limited functionality. These services improve responsiveness but at the cost of forcing the developer to create a special set of services. Critical regions will still exist but they are shorter than those of the first option. Nevertheless, this is a very valid design choice. But if the ISR needs complex processing, this model extends the amount of time spent in the ISR.
The method all Novos environments employ is a third choice, involving a two-tiered ISR model. The first tier, the Immediate Interrupt Handler (IIH), handles any immediate servicing of the device. This level generally runs with some or all interrupts disabled, depending on the capabilities of the processor. Time in the IIH is usually very short, adhering to the minimal time dictum. For ISRs that require further processing, the first tier can invoke a second tier, the Deferred Interrupt Handler (DIH), that handles non-time critical or more involved processing of interrupt-related data. In the Novos interrupt model, the DIH runs with interrupts enabled, a primary advantage of the model.
The Novos ISR model is beneficial for several reasons. First, it promotes minimal time in the ISR when interrupts are disabled, improving responsiveness to other interrupt requests. Secondly, it supports devices that have only a need for one tier of handling. Thirdly , any deferred processing (as in the DIH) obeys the rules of priority lest there be a hardware priority inversion, which is also to be avoided. Lastly, communication with the application uses the same services and objects as are used by the application.
“Foreground Entitiy” concept
Application code that executes in the foreground, such as a Deferred Interrupt Handler, is called a “Foreground Entity”. The Foreground Entity can take on a variety of flavors: it could handle any form of interrupt servicing with predictable performance, or it could take on the role of a high priority process such as a DSP algorithm or some type of task. The main attribute is that all Foreground Entities operate in an orderly manner managed by the Foreground Scheduler.
The managed order of foreground processing is a major departure from the Super Loop design and a distinguishing feature of the Novos fEFB. The Scheduler uses a priority queue to manage the execution of the Foreground Entities. Each slot in the queue represents a Foreground Priority at which there can be any number of Foreground Entities awaiting execution.
Any such entry in the priority queue indicates a need for processing that has greater priority than any entity with a lower priority and, of course, all background operations in the Super Loop. With little overhead and only requiring saving or restoring the volatile processor registers when there is a pre-emptive invocation, the Scheduler ensures minimal latency between invocation of the foreground entity and its execution.
In Novos EFB, as in the Super Loop model, the Foreground Scheduler and the entities it schedules do not block or suspend operations awaiting some event except as provided by the application code. The result is an application framework that turbocharges the capabilities of the classic Super Loop application model is very responsive and capable of meeting real-time requirements.
Data Acquisition and Data Passing
Almost every embedded system has to acquire data from various sources, process it in some manner and pass it on to another part of the application or out of the system completely. Novos EFB uses these common constructs:
- Queues to level a load yet still allow reliable, event-based processing
- Alarms (or Timers) for keeping track of time and temporal events
- Counter classes to manage the temporal aspects of the application
- Semaphores to manage general event occurrences
- Event Groups to allow Boolean (AND, OR) testing of one or more event occurrences unrelated to Semaphores
The Novos model extends the concept of events, adding enormous power to the Novos EFB model via a type of Foreground Entity called an “Event Action Routine”.
“Event Action Routines” concept
The Event Action Routines can be associated with Queue events, Alarm events and Event Group events to permit immediate handling of an event. For instance, a queue reaching its maximum size could trigger an Event Action Routine that does something to stop the queue’s producer or consume all the data in the queue..
The main thing is that no matter where in the application the event occurs, the processing of the event occurs immediately. And because the processing of the event occurs in the foreground, it takes priority over the other jobs in the background. Furthermore, the deferred processing portions of ISRs may cause events to occur and those events get scheduled and processed via the foreground scheduler.
Minimised Event Jitter
The EAR is a user-defined program and can do whatever the application developer determines it needs to do in response to the event. It can processes the data in the Queue, cancel or start an alarm, post a signal to a semaphore, set or clear event flags or schedule a Background Task.
Whatever it does, the EAR must complete its operations before any other entity below its Foreground priority or in the Background can get CPU control, thereby minimizing the Jitter in responding to the event.
No Race Conditions
The usual way to control the race condition typically involves acquiring exclusive access to the resource so that the integrity of the operation can be guaranteed. However, that requires additional code (perhaps even an additional, specialized class and services for the class) and more time, neither of which is all that desirable. With Novos EFB Services, race conditions are eliminated. Every service has inherent, built-in protection against race conditions. It means that every service produces results with 100% integrity.
Hard Real-Time Performance
Although many applications do not require it, the Novos EFB application framework can achieve hard real-time performance through use of the foreground entities of DIH, EAR and Foreground Tasks, regardless of what the application is doing in the background. With formal use of an Event Group, the developer can create a very efficient way to achieve a low level prioritization of background Super Loop processes.
Bottom line on Novos EFB is that it is very powerful and an excellent fit for many “small” applications.