nesC nesC is an extension to the C programming language designed to embody the structuring concepts and execution model of TinyOS.
Download

nesC Ranking & Summary

nesC Tags

programming interpreter language programming language execution model TinyOS extension

nesC Description

nesC is an extension to the C programming language designed to embody the structuring concepts and execution model of TinyOS. nesC is an extension to the C programming language designed to embody the structuring concepts and execution model of TinyOS. TinyOS is an event-driven operating system designed for sensor network nodes that have very limited resources (e.g., 8K bytes of program memory, 512 bytes of RAM).The basic concepts behind nesC are:· Separation of construction and composition: programs are built out of components, which are assembled ("wired") to form whole programs. Components have internal concurrency in the form of tasks. Threads of control may pass into a component through its interfaces. These threads are rooted either in a task or a hardware interrupt.· Specification of component behaviour in terms of set of interfaces. Interfaces may be provided or used by components. The provided interfaces are intended to represent the functionality that the component provides to its user, the used interfaces represent the functionality the component needs to perform its job.· Interfaces are bidirectional: they specify a set of functions to be implemented by the interface's provider (commands) and a set to be implemented by the interface's user (events). This allows a single interface to represent a complex interaction between components (e.g., registration of interest in some event, followed by a callback when that event happens). This is critical because all lengthy commands in TinyOS (e.g. send packet) are non-blocking; their completion is signaled through an event (send done). By specifying interfaces, a component cannot call the send command unless it provides an implementation of the sendDone event.· Typically commands call downwards, i.e., from application components to those closer to the hardware, while events call upwards. Certain primitive events are bound to hardware interrupts.· Components are statically linked to each other via their interfaces. This increases runtime efficiency, encourages rubust design, and allows for better static analysis of programs.· nesC is designed under the expectation that code will be generated by whole-program compilers. This should also allow for better code generation and analysis.What's New in This Release:- C preprocessor is integrated into nesC, which should significantly speed up compilation (esp. on Windows)- support for the Deputy type-safety-for-C system (see deputy.cs.berkeley.edu). To use Deputy, you add type annotations to your nesC code, then compile with the -fnesc-deputy flag. A bunch of small changes to nesC support the use of deputy. Flags to nescc: -fnesc-deputy: use Deputy in this compilation. You need to have a version of Deputy customized for use with nesC installed for this to work. -fnesc-deputy-args: extra arguments to pass to Deputy. -fnesc-default-safe/-fnesc-default-unsafe: the default safety for C functions and nesC modules (with no option specified, -fnesc-default-unsafe is assumed) Type annotations: NONULL, COUNT(...), etc (see the Deputy-for-nesC documentation for full details), which are actually macros which expand to nesC attributes (@nonnull(), @count(...), etc. Using macros allows Deputy-annotated code to be used with earlier versions of nesC. Type annotations in nesdoc comments: to reduce clutter for non-Deputy users, Deputy's annotations can be placed within a nesdoc comment rather than in a function signature (which then looks like a regular C signature): /** ... @param 'int *@count(n) x' x is an array of n ints ... */ void f(int *x, int n); is the same as void f(int *@count(n) x, int n); Macros can be used in the comment, so the above could also be /** ... @param 'int *COUNT(n) x' x is an array of n ints ... */ void f(int *x, int n); where COUNT(expr) expands to @count(expr).- internal support (in nesc1) for Deputy based on @deputy_scope() and @macro("NAME") attributes, and a -fnesc-genprefix= option.- @macro() and -fnesc-genprerix= may be useful in other contexts too: if a nesC attribute declaration has an @macro() attribute: struct @myattr @macro("MYMACRO") { int x; char *y; }; then uses of @myattr in nesC source are output as calls to MYMACRO in nesC's intermediate C output. For instance int x @myattr(23, "fun"); becomes int x MYMACRO(23, "fun"); The -fnesc-genprefix= adds to the start of the generated C output, e.g., it could be a #define definition for MYMACRO, or a #include of a file with appropriate definitions.- wide strings in XML output now show up as arrays of bytes (and follow the target's byte-level representation of wide strings)- ability to process a C file through nesC (this provides support in C for external types, atomic statements and unique), as follows: nescc -x nesc .c This forces nescc to pass the C file .c through the nesC compiler (normally it would be sent to the regular C compiler), which will process the nesC extensions and then compile the generated C code with the regular C compiler (or whatever compiler was specified with -fnesc-gcc=...)- inside a module, you can now write void f(void) or void f() interchangeably

nesC Related Software