Bring big system features to small RTOS devices with downloadable app modules
Tying Things Together
These applications are not monolithic and don’t link with the RTOS, so access to RTOS services take place via a “trap” mechanism. A “trap” is a software interrupt that results from any one of several mechanisms that vary across different architectures (Figure 3 below).
It typically is used to catch errors before they propagate or to stop the system if it’s impossible to perform the requested operation. A divide by zero or the loading of unaligned data illustrate possible illegal operations that would activate an interrupt handler, just like an external interrupt. In other cases, an intentional trap can be generated through an instruction such as a “software interrupt” or “swi” instruction.
Figure 3. A “trap” is a software interrupt that results from any one of several mechanisms that vary across different architectures
When it is necessary for the OS to handle an application’s request for an OS service, one of these mechanisms can be used to intentionally cause a trap.For example, when an application wishes to use a service that is in the kernel and not able to be called directly from the application, the application instead can cause a trap.
The trap handler then examines a register (usually loaded by the processor with an identifiable value immediately prior to generating the trap) to determine which event caused the trap.
Once the handler sees that it’s a service call, it examines other registers (loaded by the requesting module) and determines which service is being requested. It then gathers the parameters for that service from the registers pre-loaded by the application. Finally, the trap handler calls the service (which is local to its executable) as a linked function, with the specified parameters.
This whole process requires interrupt servicing, some processing, a function call, and then the same in reverse. For a desktop or large RTOS, this overhead is insignificant compared to how much other code it continuously executes just to keep housekeeping in order.
The overhead is also reasonably unimportant in light of the lack of urgency for the system to get things done. The larger OSes are comparable to the sluggish nature of a tractor trailer’s acceleration and maneuverability.
It’s not a problem, because most of the time, the truck is cruising on the highway unlike a car which primarily needs to get going quickly and to be able to maneuver in traffic.
Within a larger system such as Linux, Windows or larger RTOSes, function call overhead is insignificant because they have no requirements for that fast low-overhead maneuverability.
But, for small RTOS used in hard real-time applications, low overhead response is counted on and a trap interface represents an undesirable amount of overhead, relative to the otherwise super-efficiency of the directly linked access method.
Loading comments... Write a comment