EmberZNet serial protocol
7
EmberZNet serial protocol
SN260
EmberZnet Serial Protocol (EZSP)has been designed to be very familiarr to customers who
have used the EmberZNet 2.x stack API. The majority of the commands and responses are
functionally identical to those found in EmberZNet 2.x. The variations are due mainly to the
timing differences of running the application on a separate processor across a serial
interface. Communication between the SN260 and the Host consists of a two-message
transaction. The Host sends a command message to the SN260 and then the SN260 sends
a response message to the Host. If the SN260 needs to communicate asynchronously with
the Host, it will indicate this by using the interrupt line and then waiting for the Host to send
the callback command.
All EZSP frames begin with a Frame Control Byte followed by a Frame ID Byte. The format
of the rest of the frame depends on the frame ID. Section 7.3: Protocol format on page 38
defines the format for all the frame IDs. Most of the frames have a fixed length. A few, such
as those containing application messages, are of variable length. The frame control
indicates the direction of the message (command or response). For commands, the frame
control also contains power management information, and for responses it also contains
status information.
When a command contains an application message, the Host must supply a one-byte tag.
This tag is used in future commands and responses to refer to the message. For example,
when sending a message, the Host provides both the message contents and a tag. The tag
is then used to report the fate of the message in a later response from the SN260.
7.1
Byte order
All multiple octet fields are transmitted and received with the least significant octet first, also
referred to as little endian. This is the same byte order convention specified by 802.15.4 and
ZigBee. Note that EUI64 fields are treated as a 64-bit number and are therefore transmitted
and received in little endian order. Each individual octet is transmitted with the most
significant bit first, as shown in Section 6.1: Physical interface configuration on page 22.
7.2
7.2.1
34/88
Conceptual overview
This section provides an overview of the concepts that are specific to the SN260 or that
differ from the EmberZNet 2.x stack API. The commands and responses mentioned in this
overview are described in more detail later in this document.
Stack configuration
The Host can use the version command to obtain information about the firmware running
on the SN260. There are a number of configuration values that affect the behavior of the
stack. The Host can read these values at any time using the getConfigurationValue
command. After the SN260 has reset, the Host can modify any of the default values using
the setConfigurationValue command. The Host must then provide information about
the application endpoints using the addEndpoint command.
Table 17 gives the minimum, default and maximum values for each of the configuration
values. Also listed is the RAM cost. This is the number of bytes of additional RAM required
to increase the configuration value by one. Since the total amount of RAM is fixed, the