There is a SimpleApp routine in the routine provided by TI. For application development, the routine SimpleApp shows the use of a simplified API, reduces a series of API functions and callback functions, and simplifies the process of starting the protocol stack. These simplified APIs are highlighted here.
1. Overview of Z-Stack Simple API
Z-Stack is a free protocol stack provided by TI for CC2430/CC2431, etc., referred to as ZCP, which consists of the following units:
HAL (Hardware Abstraction Layer)
OSAL (Operating System Abstraction Layer)
Zigbee Stack + IEEE 802.15.4 MAC
User Application
MT (moniter test)--communicate with PC through serial port, mainly used for debugging
Simple Zigbee API consists of the following parts:
1 Initialization
eg_SystemReset
eg_StartRequest
2 Configuration
zb_ReadConfiguration
eg_WriteConfiguration
zb_GetDeviceInfo
3 Discovery(device,netword and service discovery)
eg_FindDeviceRequest
eg_BindDeviceRequest
zb_PermitJoinRequest
4 Data transfer
zb_SendDataRequest
zb_ReceiveDataIndication
1.1 Join a device to the network
As part of the network, each device has a "network-specific" parameter configured to the same value.
Each device's "device-specific" parameter can be configured to a different value, but ZCD_NV_LOGICAL_TYPE must be set to
Ensure that there is only one coordinator device in the entire network, and all other battery-powered devices are configured as end devices.
Under the above two premises, any device can be started in any order. After the coordinator is started, it will complete the components of the network, and other devices will
Discover the network and join it.
The coordinator performs the following steps when it starts up:
Channel scan (ZCD_NV_CHANLIST), select a channel with the smallest energy; if many channels are low energy channels, (low energy means that the channel is being used)
The coordinator will then pick a channel with the least amount of usage.
Finally the coordinator will choose the network ID, which is defined in ZCD_NV_PANID.
The routing device and the terminal device will scan the channel (ZCD_NV_CHANLIST) and try to discover the network'
1.2 Device binding
A binding is a logical link formed between the application layers of two devices. Multiple bindings can be created on a device, each with its own packet type. A binding can also consist of multiple destination devices.
Once the binding is created on the source device, the application can send data without knowing the address of the destination device (calling the zb_SendDataRequest() function, the invalid address is -0XFFFE can be used as the destination address). The remote device will look up the destination address in its binding list.
A binding junction may have more than one destination address, in which case the protocol will automatically copy the data to be transmitted and send them to each address device.
If NV_RESTORE is defined in the change, the binding list will be placed in the non-volatile storage device, so that the original binding relationship can be saved and restored after the endpoint and restart.
When a binding list is to be established without knowing the extended address of the destination address, the destination device will be in a state of allowing binding, and the function zb_AllowBindResponse() will be used as a response. The source device will send a binding request through the function zb_BindDeviceRequest().
The establishment of the binding table is based on the matching of the endpoints. The so-called matching is the same endpoint and the same descriptor.
1.3 Develop a simple personal accessory (profile)
Here we describe how to create an application by using a simple API
(1) Define all devices in the application, for example
-e.g. temperature sensor, occupancy sensor, thermostat, heating unit and remote control
-assign a device_id(unique 16bit identifier)to each of them
(2) Define "commands", these "commands" commands are transmitted between devices, and 16-bit IDs should be assigned to them, for example:
-temperature reading
-occupancy reading
-thermostat setting object
-heating/cooling unit control object
(3) Define the corresponding device input and output for each command, for example:
-The temperature reading is "output" from the temp sensor and "input" to the thermostat
-The occupancy reading command is "output" from the occupancy sencor device and "input" to the thermostat
(4) Create a simple descriptor structure for each device, including the following:
--Assign device ID, device version number
--Define the list of input and output commands
--Define a profile ID
(5) for each command
--Define message format conversion function and its related interpretation function
--例如：temperature value can be exchanged as
?(format)"an 8bit value"
?(interpretation)"0 indicates 0.C and 255 indicates 64.C in steps of 0.25.C"
(6) Write a device application for each device
--The device can generate data packets periodically or by external triggers
--The device can parse the input command
(7) Define a binding strategy so that devices can exchange data packets correctly
2 Application cases
2.1 Sensor data
Build a sensor data collection network that can collect sensor data from all over the place to one or more devices for further operations. This network requires the ability to have the following capabilities:
l Automatically build a network
l The sensor node can bind to the target node and automatically join the network
l The sensor device must be able to periodically transmit data to the target device, and this is a point-to-point response process
l If the sensor device does not receive the response from the destination device after receiving the data, it will unbind the item, and then re-establish a new binding
(1) Devices: Two devices, SimpleSensor and SimpleCollector. The former is used as a terminal device, and the latter is used as a router or coordinator device.
(2) Command: A simple command SENSOR_REPORT_CMD_ID, which is defined as an output command on the sensor device and an input command on the device that collects information. This command has a two-byte payload. The first byte is used to indicate the reading type of the sensor, and the second byte is used to indicate the reading value of the sensor.
(3) Device discovery and binding: After joining the network, the sensor device tries to discover and bind to the corresponding collection device. If it finds one or more bindable devices, it will choose the first one to respond. device (other devices are bound separately in subsequent cycles). If binding cannot be achieved, it will continue to search periodically. After joining the network, the receiving device will be placed in a state of allowing binding, waiting to respond to the binding request sent by the sensor device. This function is triggered by the button SW1 set on the receiving device, and SW2 is used to close this state.
(4) Transmission and reception of data packets: After successful binding, the sensor device will read two types of data: temperature, battery capacity, and then transmit these data to the collection device. Data transmission is a point-to-point reply mode. If no response information is received from the receiving device, the sensor device deletes the binding and tries to establish a new binding. After the collection device receives the packet, it will send it to the serial port.
(5) Create such an application: set up some sensor nodes (terminal devices), some collector nodes (there is only one coordinator, others are routing devices). After the devices are powered on, press the SW1 button of the collection device to allow the device to be bound. In this way, the collection device can respond to the binding request of the sensor device and send the data received from the sensor to the serial port.
2.2 Application routines
This application is contained in the Z-Stack folder and will be analyzed in depth in the ZStacks routine (2). There is not much introduction here.
3. API Reference Manual
A part will receive the following three
l API Functions
l Callback functions
l Configuration Properties
3.1 API Functions
eg_SystemReset
eg_StartRequest
zb_PermitJoiningRequest
eg_BindDevice
eg_AllowBind
zb_SendDataRequest
zb_ReadConfiguration
eg_WriteConfiguration
zb_GetDeviceInfo
eg_FindDeviceRequest
3.2 Callback function
zb_StartConfirm
eg_BindConfirm
eg_AllowBindConfirm
zb_SendDataConfirm
zb_ReceiveDataIndication
eg_FindDeviceConfirm
zb_HandleKeys
zb_HandleOsalEvent
3.3 Configuration parameters
3.3.1 Network parameters
ZCD_NV_PANID
ZCD_NV_CHANLIST
ZCD_NV_PRECFGKEY
ZCD_NV_PRECFGKEYS_ENABLE
ZCD_NV_SECURITY_LEVEL
ZCD_NV_BCAST_RETRIES
ZCD_NV_PASSIVE_ACK_TIMEOUT
ZCD_NV_BCAST_DELIVERY_TIME
ZCD_NV_ROUTE_EXPIRY_TIME
3.3.2 Device Parameters
ZCD_NV_STARTUP_OPTION
ZCD_NV_START_DELAY
ZCD_NV_EXTADDR
ZCD_NV_LOGICAL_TYPE
3.3.3 poll parameters
ZCD_NV_POLL_RATE
ZCD_NV_QUEUED_POLL_RATE
ZCD_NV_RESPONSE_POLL_RATE
ZCD_NV_POLL_FAILURE_RETRIES
ZCD_NV_INDIRECT_MSG_TIMEOUT
3.3.4 Point-to-point response parameters
ZCD_NV_APS_FRAME_RETRIES
ZCD_NV_APS_ACK_WAIT_DURATION
3.3.5 Others
ZCD_NV_BINDING_TIME
ZCD_NV_USERDESC
Note: For specific definitions and usage, see the manual
4. Summary
It mainly introduces the simple API of ZStack and its related applications, including application steps.