XBee.rar_XBee-PRO_xbee_xbee api_xbee atmega_蜂群

******************************************************************************** XBee Tips and Behavior ******************************************************************************** * If a coordinator leaves a network, a router will not be able to reassociate to any network, even if the original coordinator forms a network with the same PAN ID. A router node can be forced to reassociate by issuing a Network Reset 0 command (ATNR 0). * ZigBee coordinators currently allow only 8 devices to directly join. The connections are permanent and in order to allow different nodes to join a network reset "NR 0" command must be issued at the coordinator. Router nodes are required in order to connect more than 8 nodes to a network. * The Rabbit is currently unable to wake up from sleep on IO input to the XBee module. Sleeps can only be terminated by received RF messages or a timeout. * The macros ZB_JOINING() and ZB_ND_RUNNING() call zb_tick() but do not present the return code to the application for processing. * A wake up message from End Device sleep will be received during xbee_init() but not immediately presented to the application. * Changing network and sleep mode parameters can cause a network reset. Network resets place the XBee module into an indeterminate state. While the Rabbit library attempts to detect this, the exact timing and duration is impossible to predict. Changing compiled-in library parameters may cause errors on the first run, following runs should be fine. * Sending too many broadcast messages will fill buffers on the XBee module, causing timeouts until it can finish processing and flush the buffers. * Each broadcast message is buffered and retransmitted for 4 seconds. There is finite buffer room, and larger broadcasts will cause the radio to run out of space sooner. A separate buffer tracks the last 8 broadcasts, storing each entry for 8 seconds. * Broadcast messages are received by all nodes on the network and transmitted to the Rabbit library. If they aren�t properly addressed towards that node (endpoint/cluster) they will fall through to the general message handler or returned from zb_tick(). * If profile checking is enabled, every node must have the endpoint definition of nodes it wants to communicate with. If a given node doesn�t implement functionality of that endpoint it can leave cluster functions undefined, but the profile number must be included. * Network Discovery is performed once at program startup. For a coordinator this will often mean that no nodes will be detected as endpoints and routers have not had the chance to join. Once routers and endpoints have joined, the coordinator application can either initiate ND again using AT commands or restart to get new node information. * Certain radio values are programmed into the rabbit library as constants or read in during xbee_init(). NT and ST should not be modified by the application at runtime. **************************** Sleep mode on RCM4510W **************************** * Sleep mode is currently delayed at start time by at least 2 seconds of full power execution. Messages may arrive in this time and must be processed immediately or be lost. Any serial communication or RF activity during this 2 second period will also reset the timer resulting in greater than 2 seconds till sleep. * When the Rabbit wakes up, full initialization and network discovery will be performed taking at least another 6 seconds. Short sleeps won�t be efficient. * When an End Device wakes up from sleep mode the wake up message will begin processing inside of xbee_init(). Ensure that all data is initialized prior to xbee_init() for message processing. ********************************************************************* Changes to support ZNet 2.5 and ZB Pro firmware on XBee modules ********************************************************************* The XBee_API.lib library in Dynamic C releases made before DC 10.44 worked with ZNet 2.5 firmware on XBee Series 2 modules. Although similar to ZigBee, the ZNet 2.5 protocol is not ZigBee-compatible. With the release of ZB firmware, XBee Series 2 modules are ZigBee 2007 (aka ZigBee Pro) compliant. You will need to make the following changes to your program to support various changes made to XBee_API.lib to support this new firmware variant. * zigbee_init() was renamed to a more generic xbee_init(). The old name will still work, but you should switch to using the new name. * Various directories called "ZigBee" were renamed to "XBee": Samples/ZigBee -> Samples/XBee Samples/RCM4500W/ZigBee -> Samples/RCM4500W/XBee * SleepMode.c and SleepMode2.c were moved from Samples/ZigBee to Samples/RCM4500W/XBee. * ModemFWLoad.c was moved from Samples/RCM4500W to Samples/XBee. * API_Test.c was moved from Samples/RCM4500W to Samples/RCM4500W/XBee. * Libraries used for firmware updates were moved from Lib/Rabbit4000/RCM4xxx/RCM45xxW_XBee_firmware to Lib/Rabbit4000/XBee/XBee_Firmware. * Functions registered to clusters in the endpoint table are now passed the length of the RF payload as the second parameter. Updating your functions to take advantage of this information is optional; they will continue to work with a single parameter in their declaration. * Instead of defining ZIGBEE_COORDINATOR, ZIGBEE_ROUTER or ZIGBEE_ENDDEV to select the role of your device on the network, your program should define XBEE_ROLE to one of NODE_TYPE_COORD, NODE_TYPE_ROUTER or NODE_TYPE_ENDDEV. * Your program can make use of the compile-time macros XBEE_IS_COORD, XBEE_IS_ROUTER, and XBEE_IS_ENDDEV to conditionally compile code based on the XBee module's role. * Your program can make use of the run-time macros XBEE_IS_ZNET and XBEE_IS_ZBPRO to behave differently based on what firmware is installed on the XBee module. Since this information is only available at run-time, you cannot use the macros with the C preprocessor (i.e., in #if statements). * The RF Data payload for ZNet 2.5 is 72 bytes, and for ZB Pro is 80 bytes. To design a program to properly work with both types of firmware, use the compile-time macro XBEE_MAX_RFPAYLOAD (currently set to 80) to allocate buffers and the run-time macro XBEE_RFPAYLOAD_SIZE (set to 72 or 80 based on the XBee module's firmware) for limiting assembled packet size. Note that the 2x21 ZB firmware has a known bug that limits its RF payload to 72 bytes. The XBee_API.lib library has been updated to work around that bug. * The macro ZB_COMPAT_FWVER was replaced with XBEE_MIN_VER_ZNET, and XBEE_MIN_VER_ZBPRO. Each macro represents the lower byte of an XBee firmware version number. MIN_VER is the minimum version required to work correctly with XBee_API.lib. If you use a newer version than MIN_VER, and the macro XBEE_VERBOSE is defined, you'll get a warning on stdout that you're using an untested XBee firmware version. VER_ZNET is for ZNet 2.5 firmware and VER_ZBPRO is for ZB Pro firmware. * Dynamic C 10.46 corrected a long-standing bug where the zb_MakeEndpointClusterAddr function used the destination end point (instead of the source end point) when searching the end point table to set the profile ID. If you are upgrading and your application made use of profile IDs, make sure it is still sending frames with the expected ID. *********************************************** Known Problems with XBee firmware & X-CTU *********************************************** Note: All problems listed below were resolved in the firmware and X-CTU versions shipped with Dynamic C 10.46 and later. Versions: All ZB End Device firmwares before 2x40