Bring big system features to small RTOS devices with downloadable app modules
Getting the Dynamic Advantage to the Small Footprint RTOS
With a small footprint RTOS, the trick is getting dynamically downloadable applications via to efficiently call for RTOS services embodied in a distinct, separately linked piece of code. What’s needed is an interface that delivers services efficiently to applications, while also offering the advantages of dynamic downloading. To provide such an architecture for small RTOS systems, you need an “application module” structure (Figure 4, below). Application modules are collections of one or more application threads, not linked with the kernel, but instead built as a separate executable that is loaded into target memory when needed.
Figure 4. To get dynamically downloadable apps in a small RTOS system, you need an “application module” structure.
The modules use kernel services via an interface with the module manager, an agent within the kernel image that loads and initializes a module as well as fielding all module requests for RTOS services.
Threads within modules make service calls exactly as they would make calls if the service function were directly linked with the application. In the module, however, these calls are handled by an interface component that communicates with the module manager. The trap mechanism is avoided, enabling a low overhead service call interface.
Although there is only one copy of the module manager, there is no limit on the number of modules that can be loaded at the same time, and no limit on the number of threads in any one module. In this manner, the kernel resides in a distinct execution entity, running continuously to serve module requests.
As shown in Figure 5 below, for maximum efficiency, application threads alternatively can be linked with the kernel and reside with the kernel in target memory as part of its executable image.
Figure 5. In the DAM architecture, application threads alternatively can be linked with the kernel and reside with the kernel in target memory as part of its executable image.
While this option avoids the need to reload the modules containing these threads, and providing the most efficient interface, it increases the size of the resident kernel image, leaving less memory for use by modules, and foregoes the opportunity to dynamically replace these application threads.
Downloadable application modules enable the RTOS to dynamically load and run additional application threads beyond those linked with the kernel. Applications gain increased functionality without the cost of an increased footprint or additional memory, and while retaining an efficient service call interface.
This technique also provides on-demand reconfiguration and updates for deployed systems. Downloadable application module technology ideally suits situations where application code size exceeds available memory (Figure 6, below), when new modules need to be added after a product is deployed, or when partial firmware updates are required.
Another advantage downloading separate application modules is that each module can be developed by its own team or individual programmer. The team can then focus on one aspect of a product’s functionality, without having to be concerned with the underlying details.
Figure 6. The DAM approach is best suited for situations where the app code size exceeds available memory, when new modules need to be added after a product is deployed, or when partial firmware updates are required. (To view larger image, click here).
A disadvantage of such an approach is the increased risk of malfunction when the module is inserted into the system and has to interact with the kernel and other modules.
Developers have increased concern about whether the external modules can be trusted to “play nicely” with the other “children.” Worse than a program bug that produces errors or causes the module from crashing is a bug that causes contamination of another module or the RTOS kernel itself.
Despite testing, there is risk of accidental stack or memory corruption due to an erroneously calculated pointer or array limit, or stack overflow. These faults can be catastrophic and difficult to find, especially if only one portion of the development team is familiar with the offending module.
The challenge gets even worse if such a failure is traced back to the offending code, which in this case resides within a completely different module. The extreme difficulty in tracing to the source of such catastrophic failures makes it all the more important to avoid such errors.
To protect systems from this type of accidental corruption, it is beneficial to prevent module threads (Figure 7, below) from accessing locations beyond their own module’s memory, and to provide RTOS services that perform message passing instead.
Figure 7. To protect systems using DAMs it is necessary to prevent module threads from accessing locations beyond their own module memory.
This kind of protection helps prevent modules and the kernel from accidental corruption due to errant writes or jumps, or even errant reads if desired. Using the system’s MMU or MPU, memory boundary registers can be set to constrain each module’s code to accesses within its own memory.
Downloadable Application Modules provide a breakthrough for small-footprint applications, which require the reliability and responsiveness of a small RTOS, but also benefit from this new functionality to achieve an even greater range of features, maintainability, and modularity in their designs.
Further, with memory protection, any desired level of granularity—from one thread to an unlimited number—can be protected and prevented from unintended access, eliminating a common cause of difficult-to-diagnose program crashes.
John A. Carbone, vice president of marketing for Express Logic, has 35 years experience in real-time computer systems and software, ranging from embedded system developer and FAE to vice president of sales and marketing. Mr. Carbone has a BS degree in mathematics from Boston College.
Loading comments... Write a comment