"BERT" : Basic Embedded Real Time Operating System for Micro-controller Applications BERT features... The kernel module contains support code and "device driver" functions for:
The kernel is easily scalable to include required features and to exclude unwanted features. BERT provides additional code modules (source files) to support these options...
Your application firmware only needs to include the required RTOS support modules. The build can be easily customised by means of #define directives provided in the kernel header file, "kernel.h". BERT will allow you to implement embedded applications ranging from very small to quite large, with most of the benefits of a more sophisticated RTOS, e.g. robustness and reliability of execution, ease of code maintenance and extension, but without the drawbacks of excess memory requirements, heavier processor overheads, etc. Characteristics of the BERT operating system... BERT supports simple "Foreground/Background" processing, where background tasks may be interrupted by foreground tasks. (A "foreground" task is any interrupting task.) The kernel provides a task scheduler for periodic background tasks. Simplicity is achieved by compromise... of course. The overall philosophy is to put as much as possible of the application code into background processes, i.e. scheduled tasks and the (optional) Command Line Interface (CLI). Background tasks are best implemented using a "state machine" model of some sort, because they are not permitted to cause delays. (For example, see the generic "setmenu" module.) Background tasks are prioritised. Tasks may be scheduled periodically by the Task Scheduler, or they may be invoked on an 'ad hoc' basis, as required, e.g. by a CLI command function or by another task. Tasks are not permitted to contain "wait loops". If a process involves waiting for some external event to happen, e.g. a delay timer to expire, or another task to complete, etc, the process should be implemented as a "state machine". While a task is "stuck" in the same state, waiting for an event to occur before it can advance to a subsequent state, it must set its own task status to "DEFERRED" and then promptly return control to the dispatcher. This has the effect of allowing lower priority tasks to execute while one or more higher priority tasks are "waiting". In
any RTOS, care must be taken to prevent data corruption
during data transfers between tasks. More sophisticated
RTOS's use semaphores, message queues, etc, to control
inter-task data communications. There is no difficulty with data transfers between background tasks, since they are inherently prevented from "interrupting" each other at inconvenient times. As the majority of processing occurs in background, inter-task communications will rarely require special handling. Similarly, assuming the application disallows nesting of interrupts (with possible exemptions), there is no need to control data transfers among foreground tasks. In summary, while a task (foreground or background) is processing data that another task needs to read, assuming also that background tasks disable interrupts when shared data is being modified, the data is never available for reading until the update is complete. Shared data simply cannot be modified by one task while it is being read by another. BERT does not provide generic mechanisms for synchronisation of inter-task data communications. There are two reasons for this: 1) Such mechanisms can add significant overheads to processor load and memory requirements; 2) Mechanisms developed specifically to suit the application are likely to be more efficient and less obscure than a generalised set of system calls. |
Copyright 2004++ Michael J Bauer