msstate ZIGBEE協(xié)議棧介紹

1、MSSTATE_LRWPAN V0.2.6/March 2007A Zigbee-subset/IEEE 802.15.4 Multi-platformProtocol StackDr. Robert B. Reese ()Links: (homepage), (stack )(C) Copyright by R. Reese, all rights reserved.Executive Summary: This document details the usage and implementation of a Zigbee-subset/IEEE 802.15.4 wireless st

2、ack, named MSSTATE_LRWPAN. Version 0.1 of the stack provides support for coordinator/router/RFD nodes, tree routing, direct messaging, and indirect messaging using static binding. Platforms currently supported are: Platform: PICDEMZ (PIC18 + CC2420 radio), Compiler: MCC18 or HI-TECH Platform: CC2430

3、 Evaluation board/SOC_BB (CC2430/31 which has an 8051+802.15.4Radio integrated in one die), Compiler: IAR51, HI-TECH C51 Platform: MSP430 + CC2420 (Tmote), Compiler: mspgcc, Author: Rostislav Spinar Platform: WIN32 simulated RF nodes+ Virtual Board interface, Compiler: MicrosoftVisual Studio .NET 20

4、05 (on the web page there is a separate archive that has files compatible with Visual Studio .NET 2003 these files will not be updated in future releases).This stacks target audiences are educational, research, and hobbyist users who are looking to experiment with private personal-area networks usin

5、g available Zigbee/802.15.4 platforms. This stack only implements a very small subset of the Zigbee 1.0 standard, and is not Zigbee compliant. Use of this stack is non-restricted for research, educational, and personal use. Commercial use of the NWK, APS, APL layers of this stack is bound by the Zig

6、bee Trademarks, Designations, and Logos Policy 8 as these layers use Zigbee Alliance intellectual property.1. BackgroundMy name is Robert Reese, and I am an associate professor in the Electrical & Computer Engineering department at Mississippi State University. I first began experimenting with t

7、he Microchip Zigbee stack and the PICDEMZ platform in May 2005, and developed some examples over Summer 2005 to help our students use the PICDEMZ in senior design projects. During the Fall 2005 and Spring 2006 semesters, we had three senior teams use the PICDEMZ in their projects (456). In Fall 2006

8、, I modified the Microchip 3.3 Stack to include security for use with the Wireless Inventory project (4) as a means to educate myself further on the internals of the Microchip stack, and the Zigbee 2 and 802.15.4 1 standards. In May 2006, based upon the experience of helping our senior design teams

9、use the Microchip stack, I decided to develop a new Zigee/802.15.4 software stack from scratch for the following reasons: I wanted our students to be able to experiment with wireless platforms other than theMicrochip PICDEMZ and the Microchip stack. Microchip gives users permission to use the Microc

10、hip stack only with Microchip processors (this is the principle reason for the new stack).1 of 55MSSTATE_LRWPAN V0.2.6/March 2007 I looked at other options for wireless PANs such as TinyOS7 and commercial Zigbeestacks. TinyOS is an impressive platform for wireless sensors, but it uses a C-based prog

11、ramming language called NesC that requires a modified-GCC compiler for your target CPU. Porting this environment to new platforms such as the ChipCon CC2430 (8051+embedded radio) is non-trivial, and also the learning curve of NesC can be daunting for senior design students. Commercial Zigbee stacks

12、are an attractive option, except that you are limited to the platforms supported by them, and you generally cannot experiment with their source code to try out new ideas. Our student design teams do not need a full-featured Zigbee stack (at least at this time) they used only a small subset of the av

13、ailable features in the Microchip stack. There were some recurring problems with the Microchip V3.3 stack that proved difficultto fix. The main problem was nodes losing connection because the radio would lock up or the processor would reset itself because of a watchdog timer reset (V3.3). It was a v

14、ery time-consuming process to try to track down these problems; David Flowers at Microchip was very helpful during this time. However, we never did get the occasional network disconnects solved the teams simply programmed their applications in a very defensive manner to combat nodes becoming unable

15、to talk on the network. I believe that Microchip fixed these problems when they released their totally re-written stack (V3.5) in Spring 2006. I dont have much experience with the V3.5 stack, as we had made many modifications to the V3.3 stack and did not want to try correlating these changes with t

16、he new stack code. Also, the user API changed rather dramatically between from V3.3 to V3.5 the V3.5 API provides a lot more power to the user in terms exposing all of the services defined in the Zigbee standard, but it also requires users to be fairly conversant in Zigbee standard details, which ca

17、n be confusing for new users. The long debugging sessions with the Microchip stack made me wish for an environment in which I fully understood the implementation details and in which the stack debugging was easier. I do applaud Microchips effort at providing both a hardware platform (PICDEMZ) and a

18、software stack for experimenting with Zigbee it made a huge difference in raising awareness of these topics within our ECE program. Carol Popovich, University Program Coordinator, helped in our Senior design projects by donating two PICDEMZ boards over the ones that we had already purchased.Because

19、of the above reasons, I have begun developing our own Zigbee-subset/802.15.4 stack, and this document details the implementation and usage of that stack. I have written this document as a way to help our students use this stack, and to help others outside of Mississippi State to use the stack if the

20、y are interested. I believe that the Microchip PICDEMZ platform is a nice platform for experimenting with wireless applications, and I hope that this stack stimulates additional interest in it for educational use.Table 1 compares the features in the current stack release against the Microchip Zigbee

21、 stack, V3.6. This table is provided as a reference for anybody considering using this stack in their own project you easily see what the MSSTATE_LRWPAN stack code provides and what it does not provide.Table 1 Feature ListFeature Microchip Stack (V3.6) MSSTATE_LRWPAN2 of 55MSSTATE_LRWPAN V0.2.6/Marc

22、h 2007Tree Only Network ConfigurationDynamic, network nodes startup and issue discovery discoveryDynamic (Generated at Static, assigned by user startup)searched at network start 2.4GHz, 900MHz? Key/Value Pair, MSG 2.4GHz only MSGPAN ID Selection FrequencyZigbee Message Format Binding, Indirect Messa

23、gesDynamic Binding, non-Static Binding (binding determinedstored on the coordinator coordinator in a non-volatile table; node. Binding table size available non-volatile memory. non-volatile memory.NET bindingdemo application and the pcbindcoordinator. Essentially allows for unlimited size binding ta

24、ble. NO (not specified in Zigbee yet) Zigbee yet) YESYESnodes. Beacon-enabled networks APS acks for MessagesYES sleeping. PICDEMZ/MCC18/HI-TECH C(CC2420, UZ2400 (CC2420 radio only) radios)Restricted to Microchip HI-TECH C51 processors.WIN32 Virtual Nodes/Msoft.NETCan be ported to other platforms for

25、 educational, research, hobbyist use. Zigbee CompliantYESNO3 of 55MSSTATE_LRWPAN V0.2.6/March 2007As is seen, the current feature set of the MSSTATE_LRWPAN stack is very limited compared to the Microchip stack. While more features will be added to the MSSTATE_LRWPAN stack over time (see the section

26、on Future Releases), these features are sufficient for many student and hobbyist projects. At this time, I do not see this stack as ever becoming Zigbee compliant or being promoted for commercial use, as this would require membership in the Zigbee Alliance as per the Zigbee Trademarks, Designations,

27、 and Logos Policy 8.2. TerminologyThis document assumes that you familiar with Zigbee/802.15.4 basic terminology. See the Zigbee2 and 802.15.4 1 standards for more information. The following terms/acronyms are used in this document:IEEE Address 8-byte 802.15.4 network address of a node, also called

28、the long address Network Address 2-byte network address of a node, also called the short address PAN personal area networkPAN ID : personal area network identifierFFD full function device (capable of routing)RFD reduced function deviceCoordinator The network coordinator, forms the networkHAL Hardwar

29、e Abstraction Layer of the stackPHY Physical layer of the stackMAC Medium access control layer of the stackNWK Network layer of the stackAPS Application support layer of the stackAPL Application layer of the stackIDE Integrated Design EnvironmentSee Section 16 for a short description of Zigbee/802.1

30、5.4 networks.3. Installation, Directory OrganizationThe project files in the distribution assume that the file archive is unzipped to your top-level C: drive. The directory structure after the file archive is extracted is as follows:C:msstate_lrwpanbin (.NET application binaries, currently Virtual B

31、oard, Binding Demo) msoft_netbindingdemo (source for .NET Virtual Board application)virtual_board (source for .NET Virtual Board application)objcompiletest (contains IDE project files, object files for target platforms) hitech_picdemziar51_cc2430iar51_cc2430_soc_bb1mcc18_picdemz4 of 55MSSTATE_LRWPAN

32、 V0.2.6/March 2007win32pcbind (IDE project files, object files for pcbind , a node application) srcpcbind source for the pcbind applicationsimpletests source for various application test codestackstack source code filestarget (contains HAL layer files for targets)iar51cc2430_31cc2430evbmcc18pic18pic

33、demzwin324. Target Platforms, Testing EnvironmentTable 2 gives the support platforms/compilers for the current version of the stack.Table 2 Support Platforms/CompilersConfigurations PICDEMZ Four nodes coordinator, routers, RFDs MCC18/HI-TECH (PIC184620+CC2420) in various configurationsCC2430 EVB CC2

34、430 nodes has also been used in IAR8051 conjunction with PICDEMZ nodes to (Integrated 8501+Radio)form larger networks.Five nodes coordinator, routers, RFDs WIN32 Virtual Nodes MS Visual .NET 2003 in various configurationsThe HAL layer of the stack assumes a platform that has a serial port, two pushb

35、uttons, and two LEDs. When testing with PICDEMZ boards or the CC2430 boards, I used USB-to-serial port adapters to give me multiple serial ports, and Hyperterm as the serial console.The WIN32 Virtual nodes are a WIN32 console application plus a .NET GUI application called VirtualBoard that provides

36、simulation of the pushbuttons, LEDs, and other debugging features (see the WIN32 quickstart for more information). The WIN32 Virtual node capability is useful for debugging new features of the stack as you can use the full power of the Visual Studio .NET environment for debugging. The virtual nodes

37、use shared memory and mutexes to simulate the ether I have simulated up to five nodes using this approach. More nodes could be simulated, but it can become somewhat cumbersome to bring up multiple console windows for the simulation. Also, I am unsure as to how well the shared memory approach scales

38、as the number of nodes grow large even though it works fine for small numbers of nodes there may be unanticipated contention problems for the mutex that controls access to the shared memory as the number of nodes increases, which may give undesired simulation results. I have used the WIN32 Virtual n

39、ode capability extensively in developing this stack by using small numbers of virtual nodes, and 5 of 55MSSTATE_LRWPAN V0.2.6/March 2007have found it quite handy in tracking down problems. It is probably a good idea to test your application with a two or three Virtual nodes before trying it on actua

40、l hardware.Figure 1 shows a photograph of some of the nodes used in testing this stack.Figure 1 Current platforms that are compatible with this stack5. Example ApplicationsSeveral example applications can be found in the srcsimpletests directory.Table 3 Example ApplicationsUsed to test the UART func

41、tions of Single node test helloworld.c the HAL .functions of the HAL for the target Single node test boardest.cevaluation board.Used to test the LED, Switchfunctions of the HAL for the target Single node test timertest.cevaluation board.Uses to test HAL functionality for Single node test slowtimerte

42、st.c the slow timer interrupt.Single node test memtest.c allocation functions in stack.An RFD sends a packet to a Coord +RFDping_pong.c coordinator, and the coordinator Coord + 2 RFDsincrements a counter in the packet Coord + Router + RFD6 of 55MSSTATE_LRWPAN V0.2.6/March 2007 ping_pong_rejoin.ccoor

43、d_ep_indirect.cdirect_msg_test.calarm_test.cmax_msg_test.c and sends it back. Can have multiple RFDs sending packets. Uses direct messaging. A more complex version of ping_pong.c that has rejoins/joins if failures in TX/RX occurs. Tests indirect messaging between an endpoint on the Coordinator and a

44、nd RFD. Tests different forms of direct messages from RFD to coordinator. function (causes LED#1 to flash on target node). Tests maximum sized messagepayload from RFD to Coord.Tests indirect messages betweentwo RFDs.Runs the stack, and prints out anypackets in the format used by theping_pong.c and r

45、fd_sleep.cexamples.Tests HAL sleep/wakeup functions intended for use on an RFD nodethat sleeps between direct messagesends to a target node (default targetis Coordinator, but can be changedin the file). A good target node isone that is running the node_sink.capplication so that you can seewhen the p

46、acket reaches the target.Must be used with the .NETbindingdemo application. Reportsnode status to the PC-based .NETapplication, and uses the .NETapplication to resolve indirectmessage targets. See section 8A router application that canrecover from a dropped connectionwith its parent. Coord + Router

47、+ 2 RFDs Coord + 2 Routers + 2 RFDs Same as ping_pong.c Intended as a two node test only (Coord +RFD ) Same as ping_pong.c Two node test (Coord + RFD) Coord+RFD Minimum configuration is three nodes. Tested with: Coord + 2 RFDs. Coord + Router + RFD Single node application, after joining the network

48、does not transmit any packets. indirect_msg_test.c node_sink.c rfd_sleep.c Same as ping_pong.c pcbind.c Various configurations. router_app.c Intended as the application to run on router nodes.The PingPong example is the default example that is linked into the project files for different targets and

49、is the example discussed in the Quickstart sections.The PingPong example is the application that I like to leave running over night or over the weekend with four nodes (coord, router, two RFDs) to test long-term network stability. The 7 of 55MSSTATE_LRWPAN V0.2.6/March 2007current longest time that

50、I have left nodes running is 72 hours, using PICDEMZ nodes. I use log files to track output, and occasionally I see the CC2420 on the PICDEMZ unable to perform a transmission, but on successive retries the nodes recover. I do not see nodes becoming unable to communicate on the network as I used to s

51、ee in our applications on the V3.3 Microchip stack. I do not know the reason for this, all I know is that this stack appears to at least have a stable connection to the CC2420 on the PICDEMZ boards (similar stability has also been observed on the CC2430 nodes) The stack code itself is undoubtedly le

52、ss stable in terms of higher stack functionality (routing, ill-formatted packets, etc.) than the Microchip stack because it simply has not been tested as much.6. QuickStarts for different platform targets6.1. WIN32 Target QuickStartThis section discusses how to simulate virtual hardware nodes under

53、Windows. It assumes that you have Visual Studio .NET 2003 or later (the project files have been created with VS .NET 2003). Before trying a hardware target, it is a good idea to try out the WIN32 target first to get an idea of how the application is supposed to work.Steps to run the PingPong example

54、.1. Start Visual Studio .NET and use File Open Project to open the solution namedcompiletest that is located at C:msstate_lrwpanobjcompiletestwin32. Ensure that the ping_pong.c file is linked as the sourcefile for this project.2. Use BuildConfiguration Manager andselect the coord configuration. UseB

55、uildRebuild to rebuild the solution.Then use DebugStart withoutDebugging to start the application.3. You should see a console window as seen below. This indicates the coordinator node hasstarted a network and is waiting for packets. The Address is the coordinators long address. This is set by the C+

56、 preprocessor #defines in the compiletest property pages (use ProjectcompileTest Properties to open the property pages, browse to C/C+Preprocessor , and look at the Preprocessor definitions the #defines for aExtendedAddress_B0 (Least significant byte), aExtendedAddress_B1, etc. are used to define th

57、e bytes of this nodes long address.Coordinator console:8 of 55MSSTATE_LRWPAN V0.2.6/March 2007Property pages for compiletest, see the preprocessor definitions for #defines:When using the WIN32 nodes, the coordinator node always has to be started first as it creates the shared memory segment used by

58、all of the nodes. Starting a router or RFD node first will generate errors.4. Now use the configuration manager to select the RFD1 configuration, rebuild it, andlaunch the application. It should open a similar window, and you will see it join the coordinator network. If Visual Studio does not let you change the configuration while the coordinator console is opened, then this means that you started the coordinat