MsstatePAN protocol stack transplantation of ZigBee

MsstatePAN protocol stack transplantation of ZigBee

[Date:]

Source: MCU and embedded systems Author: Chen Yanming, Harbin Institute of Technology, Wang qiuguang

[Font:Large Medium Small]

　

Wireless Sensor Networks (WSN) are task-oriented self-organizing Networks composed of multiple nodes. They generally do not require high channel bandwidth, however, it should have a low transmission delay and extremely low power consumption, so that users can complete the task within a limited battery life. The IEEE 802.15.4/ZigBee standard focuses on low power consumption and low cost, providing a platform for wireless sensor networks to communicate with each other. Therefore, it is of practical significance to combine ZigBee technology with wireless sensor network technology.

1 architecture of ZigBee technology
In ZigBee technology, the architecture usually consists of layers to quantify its various simplified standards. Each layer is responsible for completing the specified tasks and providing services to the upper layer. Interfaces between layers provide services through defined logical links. The architecture of ZigBee technology consists of the physical (PHY) layer, the Media Access Control (MAC) layer, the Network/security layer, and the application framework layer. The distribution of each layer is 1.

2. network topology of ZigBee technology
The ZigBee technology network has two kinds of topology structures: star topology and peer-to-peer topology, as shown in figure 2. Two types of devices are defined: Full Funetion Device (FFD) and Re-dueed Function Device (RFD ). Compared with RFD, FFD provides complete hardware functions. In terms of communication capability, FFD can communicate with all other FFD or RFD, while RFD can only communicate with the FFD associated with it. The FFD device associated with RFD is called the Coordinator of the RFD )". In the network, an FFD acts as the network Coordinator ). In addition to directly participating in applications, the Network Coordinator also needs to complete tasks such as member identity management, link status information management, and group forwarding.
The protocol stack topology transplanted in this article is a type of peer-to-peer topology-tree cluster network. In the tree cluster network, most of the nodes do not have FFD, and RFD can only be used as the leaf node at the end of the Branch. This is mainly because RFD can only connect one FFD at a time. Any FFD can act as the master coordinator and provide synchronization services for other slave devices or master devices. In the entire PAN, as long as the device has more resources than other devices in the PAN towel, such devices can become the main coordinator of the PAN.
When creating a PAN, the PAN primary coordinator sets itself as a cluster header (CLH) with the ID (CID) as O ). Then, select an unused PAN identifier and send a beacon frame to other neighboring devices as a broadcast to form the first cluster network. A candidate device that receives a beacon frame can request to join the network in the cluster header. If the PAN primary coordinator allows the device to join, the device adds the primary coordinator as its parent node to its neighboring table to become a slave device of the network. Similarly, other devices follow the same method, request to join the network. If a candidate device cannot be added to the network, it searches for other parent nodes. In a tree cluster network, the simplest network structure is a network with only one cluster, but most of the network structures are composed of multiple adjacent networks. Once the first cluster network meets the predefined application or network requirements, the PAN master Coordinator will specify a slave device as the cluster header of the other cluster, so that the slave device becomes a master coordinator. The other devices will be added one by one to form a multi-cluster network, as shown in 3.

3 node Structure of Wireless Sensor Networks
The target board transplanted in this article is a self-designed wireless sensor network node module. Among them, the processor module using Atreel company AT-megal28L, wireless communication module using TI Company CC2420, power module using NCPl402 chip will be two battery DC-DC after conversion, sensor module using DSl8820.
CC2420 uses four pins, SFD, FIFO, ipvop, and CCA, to indicate the status of data sending and receiving. ATmegal28L exchange data and send commands with CC2420 through the CC2420 SPI interface (CSn, SO, SI, SCK), reset the chip using the RSTn pin, and enable the CC2420 voltage regulator using the VREG_EN pin, make it generate the 1.8 V voltage required by CC2420, so that CC2420 enters the normal working state. CC2420 communicates with each other through a single pole antenna or PCB antenna. Figure 4 shows the overall node architecture.

4 transplantation of zigBee protocol stack
4.1 msstatePAN protocol stack porting
Msstatepan protocol stack is developed by R. professor Reese developed the lite version of The ZigBee protocol stack for a wide range of wireless technology enthusiasts. Based on the Standard C language, Professor Reese basically has the functions stipulated in the ZigBee protocol standard. The latest version is v0.2.6, which supports multiple development platforms, including picdem Z, cc2430 evaluation board, MSP430 + CC2420 (tmote), and Win32 virtual platform. Because of the above features of the protocol stack and the open source code, this article chooses it as a learning and porting
Object.
Porting is to transplant the code of the msstatepan protocol stack on the picdem Z platform to the target board designed above, use winavr20070525 as the compiler, and download the program to the target board through the JTAG interface. The following describes the porting process.
(1) Compile the makefile file
Winavr 20070525 adopts the GCC compiler. You need to compile the MAKEFILE file to compile the program. Specify the MCU as ATmegal28, set the CPU operating frequency to f_cpu to 8 000 000Hz, set the format of the file generated after compilation to ihex, and change the target to the file name of the main project file, as the ing_pong.c file is used for subsequent tests, the target is defined as ping_pong. The SRC file is defined as SRC, which should contain all files in the entire project, and the names of each file must be opened in an empty grid. The protocol stack requires the current compiler to compile the Coordinator code, IEEE 64-bit long address, and other macro definitions, such as lrwpan_coordinator, so the corresponding macro definition code should be added to the MAKEFILE file.
(2) Replace compiler-related definitions
This porting uses the GCC compiler, so we need to replace the Code related to the PIC compiler. To this end, we need to modify the compiler. h header file and the data definition of the specific compiler. For example, replace the ROM data type or delete it directly.
(3) porting parts related to the hardware platform
This part of the Code involves the underlying things. Through a thorough understanding of the protocol stack, it is concluded that the files to be modified include halstack. c. Hal. h. halheepspace. h. cc2420.c /. h. evboard. c /. h. evbradio. h. evbconfig. h. The files halstack. C and evboard. C are greatly changed. These two files include hardware interface definition, serial port definition, LED light definition, hardware system initialization definition, and interrupt processing function and protocol stack clock function implementation. First, transplant the interrupt processing function. Pay attention to trigger the interrupt with the descent edge. Second, the protocol stack clock is transplanted, and the target board uses the atmegal28l timer 1 as the running clock of the protocol stack. Because the single-chip microcomputer uses 8 MHz crystal oscillator, when the timer uses 64 frequency division (At-megal28L timer 1 No 128 frequency division), at this time the timer count a time required for 8 μs, the time required for transmitting a symbol (symbo1) in the protocol stack is 16 μs, so the timer count is defined as a symbol time twice. Therefore, in the design, modify the Hal-mactickstous function and the symbols_to_macticks (X) and msecs_to_macticks (x) macro definitions.
(4) modify the internal layers of the protocol stack
This part of the porting work is simpler than step 1, some Mac and PHY layer-related functions closely related to the hardware are placed in the ev-board.c and halstack. c files. The specific analysis is as follows:
① Modify the stack required by the protocol stack according to your needs. The default value of the Protocol is L 024 bytes, which can be adjusted according to your actual situation.
② Debug. some definitions in the C function require a large amount of Ram at runtime. If the compilation is the coordinator, the entire protocol stack requires a ram storage unit greater than 6 kb, while the atmagal28l has only 4 kB RAM internally, some debugging display information is blocked to meet the system requirements.
③ Modify the staticbind. h function. Because the protocol stack is a static allocation address, and the function is used to define its address, the function is crucial to the entire Protocol Stack. First, consider whether the address is consistent with the one defined in makefile. If the address does not match, modify the address accordingly. Otherwise, the CC2420 address decoding will fail, so that the network cannot be established. Second, you should determine whether the data storage mode is based on the big-end mode or the small-end mode. If it is reversed, the addresses will be different. ATmegal28L is a small-end mode, which is consistent with the PIC single-chip microcomputer. Therefore, you do not need to modify it. However, you need to modify the macro definition in the function so that the compiler can select the corresponding program for compilation and generate the correct address.
(5) Compile and download
Through the above transplantation, the program should be able to properly compile and link to generate the HEX file, and then download the program to the corresponding node using AVRStudio4.12 software for protocol stack testing.
4.2 Test Method
Two nodes are used to test whether protocol stack transplantation is successful. One is the coordinator and the other is the RFD device node. In makefile, set the IEEE address of the Coordinator to Ox001248000001216F, the IEEE address of the RFD device to 0x0012480000012170, and use the function provided by the ping_pong.c file for testing.
First, the network is established. The Coordinator calls the aplFormNetwork () function to establish a network. Then, the Coordinator waits for the RFD device to join the network. The RFD device calls the aplJoinNetwork () function to apply to join the network. After the network is successfully established, execute the ping_pong process. This process is like playing table tennis. First, the Coordinator sends data to the RFD device, and the RFD device sends the information back to the Coordinator. This is also the reason why the file name is ping_pong, as shown in step 5.

Note the following when compiling and linking the ping_pong.c file: if it is a coordinator,-you must add the macro LRWPAN_COORDINATOR. Otherwise, the compiled program is the RFD device program. After compilation, download the generated files to each node, connect the node to the serial port debugging assistant, and set parameters of the serial port debugging assistant according to program requirements, such as the baud rate and data bit length. After completing these settings, open each node, start the Coordinator node, and then start the RFD device node. Figure 6 shows information about the serial port debugging assistant connected by the clientworker.

As shown in figure 6, Ox0012480000012170 is added to the network, and its IEEE long address is Ox0012480000012170. The short address assigned to the node by the Coordinator is Oxl699, and the Coordinator has a neighbor node, data transmission has started between the two nodes. It can be seen that the migration is successful.

Knot
Wireless sensor networks are emerging technologies. Currently, hardware nodes in sensor networks are expensive and software support is insufficient. If a relatively mature protocol stack can be transplanted, the node cost will be minimized. From this perspective, this article designs the corresponding hardware platform and successfully transplanted the msstatePAN protocol stack, which is of reference significance from the perspective of learning and scientific research.