26/AWSN/nesC, Component Specification, Component Implementation Concurrency and Atomicity, ContikiOS

CLICK Here https://www.youtube.com/channel/UC-s9vNBHUJP3SEofXwrXccQ/?sub_confirmation=1 nesC  nesC is a component-based, event-driven programming language used to build applications for the TinyOS platform. TinyOS is an operating environment designed to run on embedded devices used in distributed wireless sensor networks.  The name nesC is an abbreviation of “network embedded systems C”. nesC is an extension of C.  nesC programs are subject to whole program analysis (for safety) and optimization (for performance). Therefore we do not consider separate compilation in nesC’s design. The limited program size on motes makes this approach tractable.  nesC is a “static language”. There is no dynamic memory allocation and the call- graph is fully known at compile-time. These restrictions make whole program analysis and optimization significantly simpler and more accurate. nesC’s component model and parameterized interfaces eliminate many needs for dynamic memory allocation and dynamic dispatch.  nesC is based on the concept of components, and directly supports TinyOS’s event based concurrency model. Additionally, nesC explicitly addresses the issue of concurrent access to shared data. In practice, nesC resolved many ambiguities in the TinyOS concepts of components and concurrency. Component Specification  nesC applications are built by writing and assembling components. A component provides and uses interfaces. These interfaces are the only point of access to the component. An interface generally models some service (e.g., sending a message) and is specified by an interface type. Some Interface Types  TimerM provides the logic that maps from a hardware clock (Clock) into TinyOS’s timer abstraction (Timer).  Interfaces in nesC are bidirectional. They contain commands and events, both of which are essentially functions. The providers or an interface implement the commands, while the users implements the events. For instance, the Timer interface (Figure 5.4) defines start and stop commands and a fired event.  In Figure 5.3 provided interfaces are shown above the TimerM component and used interfaces are below; downward-pointing arrows depict commands and upward- pointing arrows depict events. Although this same interaction between the timer and its client could have been provided via two separate interfaces (one for start and stop, and one for fired), grouping these commands and events in the same interface makes the specification much clearer and helps prevent bugs when wiring components together.  Split-phase operations are cleanly modelled by placing the command request and event response in the same interface. Figure 5.4 shows two examples of this.  The Send interface has the send command and sendDone event of the split-phased packet send. The ADC interface is similarly used to model split-phase sensor value reads. The separation of interface type definitions from their use in components promotes the definition of standard interfaces, making components more reusable and flexible.  A component can provide and use the same interface type (e.g., when interposing a component between a client and service), or provide the same interface multiple times. In these cases, the component must give each interface instance a separate name using the as notation shown for Clk in Figure 5.3.  The components are also a clean way to abstract the boundary between hardware and software. For instance, on one sensor board, the temperature sensor (accessed via a component named Temp) is mostly in hardware; Temp is a thin layer of software accessing on-chip hardware registers. Component Implementation  There are two types of components in nesC: modules and configurations. Modules provide application code, implementing one or more interfaces. Configurations are used to wire other components together, connecting interfaces used by components to interfaces provided by others. Concurrency and Atomicity  nesC detects the data races at compile time. Data races occur due to concurrent updates to shared state. In order to prevent them, a compiler must • Understand the concurrency model, • Determine the target of every update 5.4 ContikiOS  ContikiOS is open source operating system for resource constraint hardware devices with low power and less memory. It was developed by Adam Dunkels in 2002. This OS is fully GUI based system requires only 30 KB ROM and 10 KB RAM. It also provide multitasking feature and have the built in TCP/IP suit.  The working environments of the WSNs are often energy-limited. This is one of the most important constraint for WSNs. Likewise, tiny and simple designs of the nodes are the other constraints. For this reason, WSNs should have some important hardware and software features to cope with these constraints.