|
Overcoming Challenges of TinyOS Use in Commercial ZigBee Applications
Luxoft Labs required a functioning networking protocol stack, based on ZigBee standard for wireless sensor networks
What is ZigBee Stack?
• ZigBee is based upon stack architecture that is made up of a set of blocks called layers.
• There are Physical Layer (PHY) and Medium Access Layer (MAC) defined by IEEE 802.15.4.
• ZigBee builds on that foundation by providing the Network/Security Layer (NWK) and the Application Support Layer (APS).
• Companies that wish to adopt the new standard can choose a level of ZigBee compatibility. Depending on their needs, they can license the entire ZigBee stack, including public and private profiles for specific applications, or simply license the Network Layer (NWK) to ensure the network level interoperability
ZigBee Stack Development. Why TinyOS?
MeshNeticsTM eZeeNet network protocol stack was written, based on TinyOS open-source operating system. TinyOS was selected for a number of reasons:
• Bi-directional interfaces of nesC/TinyOS perfectly suit the ZigBee protocol stack development task due to their similarity to ZigBee layer interaction model (request-confirm, indication-response)
• TinyOS’s event-driven model enables fine-grained power management that is crucial for Wireless Sensor Network (WSN) applications
• TinyOS’ component-based architecture enables rapid innovation and implementation while minimizing code size
• TinyOS’s libraries already include a lot of protocols and services that can be easily re-used
• TinyOS is an open source system, ported to numerous hardware platforms, incl. AVR, MSP430, Jennic, Renesas, MICAz
• It’s free!
Limitations of Current nesC Compiler
While implementing the stack, certain nesC compiler limitations became apparent. In greater or lesser degree it lacked the following features:
• Separate compilation
• Wiring with C-written modules
• OS independency
• Heterogeneous simulation (TOSSIM simulator lacks it)
• Code optimization
• Language runtime connections implementation
• Separation of the program logic from the program implementation
meshC Compiler Features
· Language transparency
o meshC translator can wire meshC-written modules/components directly to C-written functions.
· Binary transparency
o meshC translator supports separate compilation and can wire meshC-written modules/components directly to object code.
· Connection methods
o The module wirings implementation is not predefined. The developer can use any user-defined connection method to wire the modules into the application (e.g. via ZigBee between motes, or via sockets on PC emulation).
o No source code modifications are needed!
· Runtime connections
o Runtime wiring operators support
· Independent Infrastructure
o meshC-to-C translator does not depend on runtime engine.
o Another runtime engine (written in C/NesC or precompiled into binary code) can be used instead of TinyOS.
· Various C Dialects’ Support
o meshC translator recognizes GNU, CrossWorks, Metrowerks, Keil, IAR extensions;
o meshC translator can generate C code using any given C extension(s).
· Backward compatibility with NesC
o Fully compatible with Berkeley NesC 1.1
· Built-in simulation of heterogeneous WSNs
- meshC can simulate WSN regardless of the motes’ firmware.
· Full support of C99
· Improved built-in concurrency checking
- meshC features improved diagnostics thanks to the built-in concurrency support
· Improved component-oriented, event-driven programming model
- meshC features generalized NesC-like constructions, such as tasks with arbitrary signatures.
· Smart optimizations
- meshC translator contains built-in high-level algorithm analyzer that detects non-optimal (code size, efficiency) algorithms in the meshC code (e.g. per byte memory copying on 16-bit target).
|
