TinyOS Tools Working Group |
DescriptionThe goal of the tools WG is to make it easier to develop sensornet applications through software tools. Specifically, the WG will facilitate and perform technology transfer between the software tool research community and the TinyOS developer community. The WG's scope encompasses tools that add value to the existing TinyOS toolchain, such as GUI-type tools for designing, analyzing, modeling, and debugging configurations; model-checking-type tools for finding and preventing bugs; and, compiler-type tools for measuring or improving resource usage. The charter of this group explicitly excludes TOSSIM and other simulators, and also does not include value-added software components such as TinySec and Deluge, that are not tools.MembersJohn Regehr, University of Utah (chair)David Gay, Intel Research Berkeley Ben Greenstein, Intel Research Seattle Todd Millstein, UCLA Jens Palsberg, UCLA PlanOur initial plan, which has no particular time frame, is to integrate these tools into the main TinyOS distribution:Stack depth analysisAs the RAM utilization of a TinyOS program approaches the limit, it becomes important to know how big the C call stack can get, in the worst case. Computing this bound is difficult due to complications such as interrupts and recursion. A stack depth tool automatically computes a conservative estimate of the worst-case stack usage, and can thus label a given TinyOS program "safe," "potentially unsafe," or "definitely unsafe." The interface will be via typing, for example, make micaz stack-check.Memory safetyPointer errors in TinyOS program, such as null pointer dereferences and array bounds errors, are rather hellish to debug because they generally corrupt RAM is some way. Corruption leads to node misbehavior that is hard to trace back to the offending unsafe operation. We plan to deploy a safety solution based on Deputy that developers invoke by typing, for example, make micaz safe. Once a safety violation is detected, there are a number of options. The violation can be reported over the radio, the serial line, and/or the LEDs. Then, the node can keep going, power down, or reboot.Mailing ListsGeneral Discussion: tinyos-tools-wg@mail.millennium.berkeley.eduTo subscribe: Open only to working group members. Archives: http://mail.millennium.berkeley.edu/pipermail/tinyos-tools-wg/ regehr@cs.utah.edu |