Views
5 years ago

Synthèse de haut-niveau de contrôleurs ultra-faible consommation ...

Synthèse de haut-niveau de contrôleurs ultra-faible consommation ...

tel-00553143, version 1

tel-00553143, version 1 - 6 Jan 2011 112 Proposed system model and design-flow for SM synthesis in real-time? Contiki uses a notion of protothreads. Protothreads are programming abstraction that provide a conditional blocking statement to simplify the event-driven programming for memory constrained systems. The operation takes the conditional statement and blocks the protothread until the statement evaluates to true. If the statement evaluates to true at the very first time, the protothread continues its execution without being interrupted; otherwise the protothread is blocked and condition is re-evaluated each time the protothread is invoked. In Contiki, protothreads are stack-less i.e. local variable contents are lost whenever the scheduler switches from one protothread to another. Hence the programmer must take great care while using such variables inside his program. We have observed that programmers using Contiki in their WSN system usually avoid using local variables to reduce complications and due to the fact that they are not familiar with the concept. For instance, PowWow [64] is an open-source WSN platform, that uses Contiki as OS, where programmers have completely avoided the use of local variables. Core ROM Loaded Program Comm. Service Lang. Run-time Prog. Loader Kernel Core RAM Loaded Program Comm. Service Kernel Figure 5.5: System overview of Contiki OS [29] (portioning into core and loaded programs). 5.3.3 MANTIS OS The MANTIS Operating System (MOS) [14] uses a traditional multi-threaded approach. It offers a time-sliced approach in which an interleaved concurrency of multithreading is used to prevent one long-lived task from blocking execution of a second time-sensitive task. However, a larger memory resource is needed for threadmanagement as task preemption requires that the complete stack of the preempted thread is to be saved. Average stack size of TinyOS is approximately 16 KB and it does not support multi-threading, while MOS dedicates 128 Bytes/thread having a multi-threading based kernel.

tel-00553143, version 1 - 6 Jan 2011 WSN-specific OS 113 5.3.4 LIMOS LIMOS [146] is a resource-aware, low-power-consuming and distributed real-time microkernel which is specially designed for the real-time applications. It uses the notions of event and thread to build a two-level system architecture. It also exploits a two-level scheduling policy: non preemptive priority based high-level scheduling for events and preemptive priority-based low-level scheduling for threads. The scheduling scheme is predictable and deterministic with respect to real-time applications. An event is the job-unit of LIMOS and a thread is an atomic unit of an event. Threads are the essential system units, each containing a block of independent program that has a particular function. A group of relative threads are organized into an event, each containing the threads that deal with a certain aspect of a system by cooperating with others. Therefore, LIMOS consists of a set of events and each event contains a number of relative threads. LIMOS events follow a run-to-completion semantic without preempting one another i.e. events are non-preemptive and adopt a priority-based non-preemptive scheduling, such as Earliest-Deadline-First (EDF) algorithm. On the other hand, LIMOS threads run in parallel to implement an event by interacting with each other. Hence, threads are preemptive and thus each one needs a memory to store its context and other status information. There is a static priority-based preemptive scheduling scheme for threads. Threads are selected to run in order of priority and the selected thread can preempt any other lower priority thread at any execution point outside of critical. When the threads of an active event are running, the threads of other events are not eligible to obtain CPU resource. This allows events to run to completion. Since threads follow a static scheduling that is determined prior to run-time, the priorities of threads must be allocated carefully to avoid a deadlock situation. 5.3.5 SenOS SenOS [73] is a totally different OS than all the above mentioned OSs due to the fact that it does not follow a conventional thread-based operation style. It deploys a state machine based programming model. A state machine has been recognized as a powerful modeling tool for reactive and control-driven embedded applications. Sensor network applications are one of those applications that can mechanize a sequence of actions, and handle discrete inputs and outputs differently according to its operating modes. Being in a state implies that a system reacts only to a predefined set of legal inputs, produces a subset of all possible outputs after performing a given function, and changes its state immediately in a mechanical way. SenOS has four system-level components: � an event queue that stores inputs in a FIFO order, � a state sequencer that accepts an input from the event queue, � a callback function library that defines output functions,

Synthèse, caractérisation et intérêt biomédical de (glyco ...
Synthèse, caractérisation et polymérisation par ouverture de cycle ...
Analyse et synthèse de sons de piano par modèles physiques et de ...
Emission gamma de haute énergie dans les systèmes binaires ...
Martin Teichmann Atomes de lithium-6 ultra froids dans la ... - TEL