#Blink app tinyos code#
The ROM overhead is due to bounds-checking code inserted by the Deputy compiler.
Since Blink contains no known safety errors, the safe version of Blink should act just like its unsafe counterpart.Īs a sanity check, you may want to make sure that the safe version of Blink has a larger code size than the unsafe version: $ make micazĬompiled BlinkAppC to build/micaz/main.exeĪvr-objcopy -output-target=srec build/micaz/main.exe build/micaz/main.srecĪvr-objcopy -output-target=ihex build/micaz/main.exe build/micaz/main.ihex Getting started is easy: cd $TOSROOT/apps/Blink Safe compilation is supported by default by TinyOS 2.1 for these platforms: Safe TinyOS is described in detail in a paper from SenSys 2007: Efficient Memory Safety for TinyOS. They might permit someone to own your motes.Since deployed motes are difficult to debug, and since other failure modes exist (concurrency errors, battery outage, connectivity failure, etc.) it can be very hard to tell when memory corruption is the root cause of a serious deployment problem.Since memory objects are tightly packed, walking even one element past the end of an array is likely to corrupt RAM that your application relies on.Lacking memory protection hardware and a user/kernel boundary, it is easy to accidentally corrupt OS code these errors are never trapped as segmentation violations.Untrapped memory errors are particularly harmful in sensor network applications because: Together, type and memory safety give Java-like guarantees to TinyOS programs: pointer and array errors are trapped before they occur. Safe TinyOS is a modified compilation toolchain, released as part of TinyOS 2.1, that uses the Deputy compiler (now part of the Ivy project) to enforce type and memory safety at run time on motes.