DioneOS

From Wikipedia, the free encyclopedia

DioneOS (pronounced /djoneos/) is multitasking preemptive, real-time operating system. The system is designed for Texas Instruments MSP430x microcontrollers.

Target microcontroller platform has limited resources, i.e. system clock frequency in tens of MHz and memories amount from tens to a few hundreds KB. The system is adapted to such conditions by providing its compact and efficient image. The efficiency term means here minimization of additional CPU load caused by the system usage. According to this definition, the system is more effective when it consumes less CPU time for execution of its internal parts (e.g. threads management).

The DioneOS system is intended for autonomic devices where user interface has limited functions. The core functionality provided by the system is an environment for building multitasking firmware by means of standard, well known concepts (e.g. semaphores, timers, etc.). Because of the target domain of application, the system has not graphic user interface.

Memory model

Texas Instruments company manufactures wide range of microcontrollers that use msp430 core. Depending on the version, the chip contains different amount of flash memory and RAM (e.g. msp430f2201 has 1KB/128B correspondingly, but msp430f5438 - 256KB/16KB). When the size of the memory exceeds 64 KB limit,[1] 16 bits addressing is insufficient. Due to this constraint, chips with larger memory are equipped with extended core (msp430x). This version of the processor has wider registers (20 bits) and new instructions for processing them.

At the time of compilation programmer selects the type of memory model ('near' or 'far') that is used for FLASH and RAM memories. This choice determines accessible memory range, hence when the FLASH above 64 KB limit is programmed, 'far' model must be used.

The DioneOS supports 'far' model for code modules, so large firmware that uses extended FLASH can be developed and run under the system control. The system uses 'near' memory model for data segments.

Threads management

The firmware started under the DioneOS system consists of threads that are executed in pseudo-parallel way. Each thread has its own, unique priority used for ordering the threads from the most important to the least one. The thread priority value defines a precedence for running over others.

In the DioneOS system the thread can be in one of following states:

  • RUNNING - the thread is currently executed by processor,
  • READY - the thread is ready to be run,
  • WAITING - the thread is blocked and waits on some synchronization object.

Because there is only one core in the processor, only one thread can be in RUNNING state. This is the thread that has the highest priority from all threads that are not in WAITING state. Change of the thread state can be caused by:

  • triggering an object, that hold the thread,
  • unsuccessful acquiring the object that is already locked (e.g. a mutex that is owned by someone else),
  • elapsing timeout,
  • state change of another thread, that may lead to preemption.

The system handles up to 16 threads, including idle one with the lowest priority. The idle thread should be always ready to be run, and never switched to 'waiting' state, so it not permitted to call any functions that would block from inside this thread. The idle thread can be used to determine total system load.

Features of the system

The DioneOS system provides:

  • items for synchronisation: mutexes and counting semaphores, used for thread synchtonization, signalling from ISR to a thread and guarding shared resources,
  • methods for time management: timers, thread sleeping, timeouts,
  • communications items implemented by events and queues available as circular buffers,
  • memory management by memory pool that allocates memory only in fixed-size blocks but is free of fragmentation issues that may appear when heap is used. Regular allocation by malloc/free on heap is also available, it is provided by standard C libraries.
  • testing support objects: signaling events on chip pins, critical exceptions, objects marking that helps is detection of errors like usage of deleted object or double memory deallocation, etc.

Context switch

As it was stated in 'Threads Management' chapter, the firmware consists of pseudo-parallel threads. Each thread has its own context, that contains core registers of the processor, last execution address and private stack. During the switch between threads the system saves the context of stopped thread and recovers the context of the one being run. This state saving makes possible breaking the thread execution and further continuation, even if between them other thread has been executed. Note that preemption followed by context switch may happen in any moment, even if no system function is called in the thread. Although it may happen in unexpected location in the executed code, the thread work is not distorted due to the system and the context saving. From the thread point of view, the switch can be done in background.

The context switch is critical operation in the system and the time of its execution determines if how effective the system is. Because of that the context switch in the DioneOS system was optimized for short time. The most important parts were written in assembler, so the switch can be done in 12–17 μs[2] (for fosc=25 MHz).

In the DioneOS system the context switch can be initiated from interrupt service routine. This property is useful for moving an event handling to the thread and commonly implemented in two-layer architecture:

  1. the interrupt handler - is called after hardware interrupt has occurred. In this part interrupts are disabled, so execution cannot be continued for long time, otherwise the system responsiveness is compromised. In this layer only jobs that require fast response for interrupt should be processed, any others should be passed to higher layer,
  2. higher layer - processing in separated thread without blocking interrupts; this thread can be preempted. Constraints are not so tight here as in the interrupt handler. The code execution does not block the system.

The context switch measured from signaling point in ISR to other thread recovery takes 10us (for fosc=25 MHz) in the DioneOS system.

Configuration

The DioneOS has multiple configuration options that affects features inserted in the compiled image of the system. A lot of them are source code switches that are gathered in configuration file and can be altered by a developer of firmware. By this means it is possible to control additional testing parts. If they are enabled the system is built in a version that provides more detection of unusual conditions and run-time information that helps in debugging process. When the errors are found and eliminated these extra features can be disabled for having full performance of the system.

Example of a fragment of configuration file: 

[...]
#define CFG_CHECK_OVERFLOW              /* overflow testing in semaphores/mutexes */
#define CFG_CHECK_LOCK                  /* lock issue detection caused by preemption conditions during scheduler lock */
#define CFG_LISTDEL_WITH_POISON         /* marking deleted items on the list in os_list1_del()*/
#define CFG_MEM_POOL_POISON_FILL 0xDAAB /* pattern for marking de-allocated memory items */
#define CFG_LISTDEL_POISON     0xABBA   /* pattern for marking removed list items */
#define CFG_CHECK_EMPTY_SEM_DESTROY     /* testing semaphore before destroy in os_sleep()*/ 
#define CFG_FILL_EMPTY_MEM_POOL         /* free memory fill with pattern */
[...]

Footnotes

  1. ↑ it happens when the memory cannot fit in a range 0–64 KB
  2. ↑ switching time depends on the system configuration, the longer value appears when the switch is interfered by system tick interrupt.

External links

References

This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply for the media files.