1. Memory Model

Texas Instruments company manufactures a wide range of microcontrollers that use the MSP430 core. Depending on the version, the processor contains different amount of flash memory and random-access memory (RAM), e.g., MSP430f2201 has 1KB/128B correspondingly, but MSP430f5438 has 256KB/16KB. When the size of the memory exceeds 64 KB limit, as happens when the memory cannot fit in a range 0–64 KB, 16-bit 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-bit) and new instructions for processing them.

At compiling, the 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, the far model must be used.

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

2. Thread 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 most important to least. 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 is not permitted to call any functions that would block from inside this thread. The idle thread can be used to determine total system load.

3. Features of the System

The DioneOS system provides:

• items for synchronisation: mutexes and counting semaphores, used for thread synchronization, 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 use of deleted object or double memory deallocation, etc.

4. Context Switch

As it was stated in the '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^[1] (for f_osc=25 MHz).

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

• 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,
• 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 f_osc=25 MHz) in the DioneOS system.

5. 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 */ [...]