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 110 Proposed system model and design-flow for SM synthesis � A hardware System Monitor (SM) that controls the execution of all the hardware micro-tasks. The SM is responsible for the turning-on/off of the hardware microtasks as well as the power-gated memories depending upon their usage. The detailed architecture, working of the SM and the design-flow for its synthesis are discussed later in this chapter. � Event triggering peripherals (such as wake-up radio, timer etc.) that can send events to the SM. � A set of memory resources that are used to store the global data shared among different micro-task. These memories can be power-gated or non-power-gated depending upon their usage. Later in this chapter, we will provide the details of the specificities and limitations of our proposed system-level model and compare them to the features of standard OSbased WSN implementations. However, to be able to perform this comparison, we first need to take a closer look at the system-level view and management aspects of conventional OS-based WSN nodes. In typical embedded systems, concurrency, event and shared resource management are handled by a real-time embedded OS, which provides adequate constructs for the programmer (preemptive task scheduling, mutex, etc.). However, such full featured OSs cannot be implemented in WSN nodes because of the strong constraints on memory footprint. As a result, several light-weight operating systems have been developed by the WSN community that handle the power- and taskmanagement in current WSN nodes. The next section summarizes the features of some of these WSN-specific OSs. 5.3 WSN-specific OS Due to strong constraints on memory resources available on a WSN node, several WSNspecific OSs have evolved that are very light-weight in terms of memory requirement and can run on low-power embedded MCUs such those discussed in Section 2.5. This section outlines the characteristics of the most commonly used OS infrastructures targeted at WSN. 5.3.1 TinyOS TinyOS [101] is one of the earliest and the most commonly used OS in WSN platforms. It is a flexible OS built from a set of reusable components that are assembled into an application-specific system. TinyOS supports an event-driven concurrency model and uses asynchronous events, and deferred computation called tasks. TinyOS is implemented in the NesC language [44], which supports the TinyOS component and concurrency model as well as cross-component optimization and compile-time race detection. A TinyOS program is a graph of components where each component is an independent computational entity that exposes one or more interfaces. Components have three computational abstractions: commands, events, and tasks. Commands and events

tel-00553143, version 1 - 6 Jan 2011 WSN-specific OS 111 are mechanisms for inter-component communication, while tasks are used to express intra-component concurrency and computation. A command is typically a request to a component to perform some service, such as initiating a sensor reading, while an event signals the completion of that service. Commands and events cannot block, rather a request for service is split-phase i.e. the command returns immediately and the event signals completion at a later time. Tasks may perform significant computation and follow a run-to-completion execution-model. This allows tasks to be much lighter-weight than threads. The standard TinyOS task scheduler uses a non-preemptive, FIFO scheduling policy. Since TinyOS uses a system of smaller components that are statically linked with the kernel to form a complete image of the system, so after linking, modifying the system is not possible. However, in order to provide run-time reprogramming for TinyOS, Levis et al. have developed Maté [81], a virtual machine for TinyOS devices. Code for the virtual machine can be downloaded into the system at run-time. 5.3.2 Contiki Contiki [29] is another WSN-specific OS proposed by Dunkels et al. It features an event-driven kernel where multi-threading is not present as an inherent feature but can be implemented as a library that is linked only with programs that explicitly require it. Contiki is implemented in the C language and has been ported to a number of microcontroller architectures, including the MSP430 and the Atmel AVR. A running Contiki system consists of kernel, libraries, program loader, and a set of processes. A process may either be an application program or a service. A service implements a functionality used by more than one application processes. All processes, both application programs and services, can be dynamically replaced at runtime. Communication between processes always goes through the kernel. The kernel does not provide a hardware abstraction layer, but lets device drivers and applications communicate directly with the hardware. A Contiki system is partitioned into two parts: the core and the loaded programs as shown in Figure 5.5. The partitioning is made at compile time and is specific to the deployment in which Contiki is used. Typically, the core consists of the Contiki kernel, the program loader, the most commonly used parts of the language run-time and support libraries, and a communication stack with device drivers for the communication hardware. The core is compiled into a single binary image that is stored in the devices prior to deployment. The core is generally not modified after deployment, even though it is possible to use a special boot loader to overwrite or patch the core. Programs are loaded into the system by the program loader. The program loader may obtain the program binaries either by using the communication stack or by using directly attached storage such as Electrically Erasable Programmable ROM (EEPROM). Typically, programs to be loaded into the system are first stored in EEPROM before they are programmed into the code memory. So, the major benefit of Contiki OS over its competitors is its feature to dynamically load and unload an application program or service. But there is a question of the efficiency of this process as the number of nodes in a WSN can go up to 10,000, will it be possible to dynamically update all these nodes

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