1 / 15

nesC 1.2

nesC 1.2 David Gay Intel Research Berkeley Introduction nesC 1.2 is a major revision to the nesC language “external” types (with Kevin Chang, UCLA) generic components binary components attributes Goals simplify TinyOS programming make it easier to define new abstractions and services

liam
Download Presentation

nesC 1.2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. nesC 1.2 David Gay Intel Research Berkeley

  2. Introduction • nesC 1.2 is a major revision to the nesC language • “external” types (with Kevin Chang, UCLA) • generic components • binary components • attributes • Goals • simplify TinyOS programming • make it easier to define new abstractions and services

  3. External Types: Why? • Current message formats defined as C structures • machine-dependent representation • different padding • different endianness • Until recently, not a problem: • homogeneous networks, with platform-specific radios • mig tool decodes structures for PCs • Now: 802.15.4 on telos, micaz, imote2 • want interoperability!

  4. Standard Solutions • Marshalling/unmarshalling: • needs extra RAM • protocol stack built by wiring components, so no obvious central place to do marshalling/unmarshalling • Unix-style htons, htonl, etc calls • programmer-unfriendly • only addresses endiannness • gcc’s “packed” attribute • only addresses padding

  5. External Types • nesC 1.2 introduces “external types”, which have a platform-independent representation: OLDNEW struct TOSMsg { nx_struct TOSMsg { uint16_t addr; nx_uint16_t addr; uint8_t group; nx_uint8_t group; … … • nx_structs have no padding • nx_uint16_t, etc are big-endian on all platforms • these types can be used like any C types (some minor restrictions) • Very easy to convert TinyOS code to use external types

  6. Generic Components • Components with numeric and type arguments, that can be instantiated at compile-time • Interfaces can also have type arguments • Uses: • utility components: filters, adapters, queues, buffers, etc • wiring patterns: see OSKI generic module QueueC(typedef t, int n) { provides interface Queue<t>; } implementation { t q[n]; … } configuration App { } implementation { components AppM, new QueueC(TOSMsg, 10) as MyQ; AppM.MsgQ -> MyQ; }

  7. Other Changes (in brief) • Attributes (inspired by Java 1.5) • programmers can add custom annotations to nesC programs • external tools can extract program information • uses: wiring checks, network management attributes, etc • Binary components • compile nesC “app” to .o file with specified entry, exit points • uses: • build, use, distribute components in binary form • encapsulate set of components as C library

  8. Status • All features implemented • Alpha release at http://sf.net/projects/nescc • Being used for TinyOS 2.x development work • Will be released with TinyOS 2.0

  9. Backup

  10. Generic Configurations generic configuration SomeAssembly() { provides interface X; } implementation { components new SomeAssemblyM() as SA, new QueueC(TOSMsg, 10) as SomeQ; X = SA.X; SA.Queue -> SomeQ; } • Every instantiation of SomeAssembly will create new instances of SomeAssemblyM and IntQueueC

  11. Generic Interfaces • Many interfaces similar, except for result, argument types • Generic interfaces support this by allowing interfaces to take type parameters • Two generic interfaces are connectable iff they have the same type arguments • Generic components with type arguments can use generic interfaces to: • Provide functionality dependent on that type • Express requirements of operations on that type

  12. configuration MyApp { } implementation { components MyCode, new QueueC(int, 10) as MyQ; MyCode.Queue -> MyQ; } interface Queue<t> { command void push(t x); command t pop(); } generic module QueueC (typedef t, int n) { provides interface Queue<t> as Q; } implementation { t q[n]; int p1, p2; command void Q.push(t x) { q[p1++] = x; if (p1 == n) p1 = 0; } … }

  13. Another example interface Compare<t> { command bool lessthan(t x1, t x2); } generic module Sort(typedef t) { uses interface Compare<t> as C; } implementation { void f() { t x1, x2; … if (call C.lessthan(x1, x2)) …

  14. Binary Components component ExternalInterface { provides interface StdControl; uses interface Timer; } • entry points (of program including ExternalInterface): • ExternalInterface.Timer.fired • exit points: • ExternalInterface.StdControl.{init, start, stop} • ExternalInterface.Timer.{start, stop}

  15. Attributes struct @atmostonce { }; struct @snms { int key; }; … provides interface Timer @atmostonce(); … provides interface SNMSAttribute @snms(KEY_PARENT); • Information on attributes, etc output in XML • Java-based parser for this XML schema • Sample “wiring check” demo app

More Related