nesCPPT资料.pptVIP

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 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! 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 External Types nesC 1.2 introduces “external types”, which have a platform-independent representation: OLD NEW 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 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 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 Status All featu