Microchip PIC16F88 Handleiding


Lees hieronder de 📖 handleiding in het Nederlandse voor Microchip PIC16F88 (22 pagina's) in de categorie Niet gecategoriseerd. Deze handleiding was nuttig voor 18 personen en werd door 2 gebruikers gemiddeld met 4.5 sterren beoordeeld

Pagina 1/22
© 2010 Microchip Technology Inc. DS01066B-page 1
AN1066
INTRODUCTION
Implementing applications with wireless networking is
now common. From consumer devices to industrial
applications, there is a growing expectation that
devices will have built-in the ability to communicate
with each other without a hard-wired connection. The
challenge is to select the right wireless networking
protocol and implement it in a cost-effective manner.
The Microchip MiWi™ Wireless Networking Protocol
Stack is a simple protocol designed for low data rate,
short distance, low-cost networks. Fundamentally
based on IEEE 802.15.4™ for Wireless Personal Area
Networks (WPANs) later expanded to support
Microchip proprietary RF transceivers, the MiWi
protocol provides an easy-to-use alternative for
wireless communication. In particular, it targets smaller
applications that have relatively small network sizes,
with few hops between. MiWi protocol now is one of the
wireless communication protocols that are supported in
MiWi Development Environment (DE). It uses
MiMAC interface to communicate with Microchip RF
transceivers and uses MiApp interface to interact with
application layer.
For more information, please refer to the Microchip
application note AN1283 Microchip Wireless Media
Access Controller - MiMAC (DS01283) and AN1284
Microchip Wireless Application Programming
Interface - MiApp” (DS01284).
This application note covers the definition of the MiWi
Wireless Networking Protocol Stack and how it works.
For completeness, this document also introduces
several aspects of wireless networking, as well as key
features of IEEE 802.15.4. However, it is assumed that
the user is already familiar with the C programming
language and IEEE 802.15.4. You are strongly advised
to read the IEEE 802.15.4 specification and MiMAC/
MiApp application notes in detail prior to using the
Microchip MiWi Wireless Networking Protocol Stack.
FEATURES
The current implementation of the MiWi protocol has
these features:
Support all Microchip RF transceivers on different
frequency bands.
Portable between various Microchip MCU
families.
RTOS and application independent
Out-of-box support for the MPLAB® C18, C30 and
C32 compilers
Easy-to-use API
CONSIDERATIONS
A network using the MiWi protocol is capable of having
a maximum of 1024 nodes on a network. Each
coordinator is only capable of having 127 children, with
a maximum of 8 coordinators in a network. Packets can
travel a maximum of 4 hops in the network and 2 hops
maximum from the PAN coordinator.
If, after reading this application note, you determine
that you require a standardized wireless platform,
larger network sizes or common marketing logos,
please refer to the application notes AN1232
Microchip ZigBee-2006 Residential Stack Protocol
(DS01232) and AN1255 Microchip ZigBee PRO
Feature Set Protocol Stack(DS01255). Alternatively,
users may consider using the basic MiWi protocol and
modifying it to suit their own applications.
For more information on the most up-to-date list of
limitations of the Stack, refer to the Readme file located
with the Stack download at http://www.microchip.com/
miwi.
TERMINOLOGY
In describing the MiWi protocol, two specific terms are
used throughout that are borrowed from the IEEE
standard.
The first term is cluster, which refers to a grouping of
nodes that form a network. A MiWi protocol cluster can
be up to 3 nodes deep and is controlled by a cluster-
head. In the current implementation of the MiWi protocol,
the cluster-head is always the PAN coordinator. (For
more information, see Table 2.)
The second term is socket, also referred as “Indirect
Message” in MiApp interface. It refers to a virtual
connection between two devices. Rather than have an
exclusive hard-wired connection between devices,
many devices with many types of sockets share a
common communications medium and use some
common method to associate applications and
devices. When a new device or application is added to
the network, it requires configuration to communicate
Author: David Flowers and Yifeng Yang
Microchip Technology Inc.
Microchip MiWi™ Wireless Networking Protocol Stack
AN1066
DS01066B-page 2 © 2010 Microchip Technology Inc.
to other devices or applications. By using sockets,
nodes in the network can find communication partners
dynamically without having to know any information
about them.
MiWi PROTOCOL OVERVIEW
The MiWi protocol is based on the MAC and PHY
layers of the IEEE 802.15.4 specification, and is
tailored for simple network development in the 2.4 GHz
and subGHz ISM frequency bands. The protocol
provides the features to find, form and join a network,
as well as discovering nodes on the network and route
to them. It does not cover any application-specific
issues, such as how to select which network to join to,
how to decided when a link is broken or how often
devices should communicate.
IEEE 802.15.4 MAC
The MiWi protocol uses IEEE Standard 802.15.4 as
reference to develop its MAC layer.
Similar to IEEE 802.15.4, MiWi protocol uses an
Acknowledged data transfer mechanism in the MAC.
This method uses a special ACK flag in the packet
header. When this flag is set, Acknowledgement to the
transmitter by its receiver is required; this ensures that a
frame is, in fact, delivered. If the frame is transmitted with
an ACK flag set and the Acknowledgement is not
received within a certain time-out period, the transmitter
will retry the transmission for a fixed number of times
before declaring an error.
It is important to note that the reception of an
Acknowledgement simply indicates that a frame was
properly received by the MAC layer. However, it does not
indicate that the frame was processed correctly. It is
possible that the MAC layer of the receiving node
received and Acknowledged a frame correctly, but due
to the lack of processing resources, a frame might be
discarded by upper layers. As a result, the upper layers
of the application may require additional
Acknowledgement response.
Device Types
IEEE 802.15.4 defines devices based on their overall
functionality. There are basically two device types as
shown in Table 1.
The MiWi protocol defines three types of MiWi protocol
devices, based on their functions in the network: PAN
Coordinator, Coordinator and End Device. The MiWi
Wireless Networking Protocol Stack functionality helps
to determine the type of IEEE functionality that the
device requires. The MiWi protocol device types and
their relationship to IEEE device types are shown in
Table 2.
TABLE 1: IEEE 802.15.4™ FUNCTIONAL DEVICE TYPES
TABLE 2: MiWi™ PROTOCOL DEVICE TYPES
Device Type Services Offered Typical Power Source Typical Receiver Idle
Configuration
Full Function Device (FFD) All or Most Mains On
Reduced Function Device
(RFD)
Limited Battery Off
Device Type IEEE Device Type Typical Function
PAN Coordinator FFD One per network. Forms the network, allocates network
addresses, holds binding table.
Coordinator FFD Optional. Extends the physical range of the network. Allows
more nodes to join the network. May also perform monitoring
and/or control functions.
End Device FFD or RFD Performs monitoring and/or control functions.
© 2010 Microchip Technology Inc. DS01066B-page 3
AN1066
MiWi PROTOCOL NETWORK
CONFIGURATIONS
Of the three device types defined in the MiWi protocol,
the most essential type to networking is the PAN
coordinator. The PAN coordinator is the device that
starts the network, and selects the channel and the
PAN ID of the network. All other devices joining onto
the PAN have to obey the instructions of the PAN
coordinator.
Star Network Configuration
A star network configuration (Figure 1) consists of one
PAN coordinator node and one or more end devices. In
a star network, all end devices communicate only with
the PAN coordinator. If an end device needs to transfer
data to another end device, it sends its data to the PAN
coordinator, which in turn, forwards the data to the
intended recipient.
Cluster Tree Network Configuration
In a cluster tree network (Figure 2) there is still only one
PAN coordinator; however, other coordinators are
allowed to join on to the network. This forms a tree-like
structure, where the PAN coordinator is the root of the
tree, the coordinators are the branches of the tree and
the end devices are the leaves of the tree. In a cluster
tree network, all of the messages sent through the
network follow the path of the tree structure. Since
messages may be routed through more than one node
to reach their eventual destination, cluster tree networks
are sometimes also referred to as multi-hop networks.
FIGURE 1: STAR NETWORK CONFIGURATION
FIGURE 2: CLUSTER TREE TOPOLOGY
PAN Coordinator
FFD End Device
RFD End Device
Legend
PAN Coordinator
FFD End Device
RFD End Device
Coordinator
Legend
AN1066
DS01066B-page 4 © 2010 Microchip Technology Inc.
Mesh Network Configuration
A mesh network (Figure 3) is similar to a cluster tree
configuration, except that Full Function Device (FFDs)
can route messages directly to other FFDs instead of
following the tree structure. Messages to Reduced
Function Device (RFDs) must still go through the
RFD’s parent node. The advantages of this topology
are that message latency can be reduced and reliability
is increased. Like cluster tree networks, mesh networks
are multi-hop.
Multi-Access Networks
An IEEE 802.15.4 network is a multi-access network,
meaning that all nodes in a network have equal access
to the medium of communication. There are two types
of multi-access mechanisms: beacon and non-beacon.
In a beacon enabled network, nodes are allowed to
transmit in predefined time slots only. The PAN
coordinator periodically begins with a superframe,
identified as a beacon frame, and all nodes in the
network are expected to synchronize to this frame. Each
node is assigned a specific slot in the superframe, during
which, it is allowed to transmit and receive its data. A
superframe may also contain a common slot during
which all nodes compete to access the channel.
In a non-beacon enabled network, all nodes in a
network are allowed to transmit at any time as long as
the channel is Idle. The current version of the Microchip
MiWi Wireless Networking Protocol Stack supports
only non-beacon networks.
FIGURE 3: MESH NETWORK
PAN Coordinator
FFD End Device
RFD End Device
Coordinator
Legend
© 2010 Microchip Technology Inc. DS01066B-page 5
AN1066
ADDRESS ASSIGNMENT
The MiWi protocol uses the addresses provided by
IEEE 802.15.4. There are three different addresses
defined by the specification:
1. Extended Organizationally Unique Identifier
(EUI): This is an 8-byte number that is globally
unique. Every device shipped using the IEEE
802.15.4 specification, should have a unique EUI
address. The upper 3 bytes of the EUI are
purchased from IEEE (see link for the site in the
Section “References” to buy them). The lower
5 bytes of the EUI are available for the user, as
they see fit, as long as they are globally unique.
For SubGHz proprietary RF transceivers, the EUI
address length is in the range of two to eight
bytes, defined by the application.
2. PAN Identifier (PANID): The PANID is a 16-bit
address that defines a group of nodes. All
nodes in the PAN share a common PANID. A
device assumes the PANID for a network when
it selects to join that PAN.
3. Short Address: Also known as the device
address, this is a 16-bit (2-byte) address that is
assigned to a device by its parent. This short
address is unique within a PAN and is used for
addressing and messaging within the network.
IEEE specifies that the PAN coordinator always
has an address of 0000h. The address
allocation is up to the PAN coordinator from that
point forward.
The MiWi protocol uses the 16 available bits in the
short address to help with routing and exchanging node
information. The bit fields within the address are shown
in Figure 4.
The Parent’s Number field (bits 10-8) is unique for each
coordinator on the network, including the PAN
coordinator. As the Parent’s Number field is only 3-bits
long, this limits the number of coordinators in a network
to 8.
The Child’s Number field (bits 6-0) of any coordinator
on the network will be 00h. This indicates that they are
operating as a coordinator. Other values for this field
are determined by the type of device (FFD or RFD), as
well its function within the PAN. Figure 5 gives a
general idea of how short addresses are determined.
The RxOffWhenIdle field (bit 7) is the inverse of the
IEEE 802.15.4 defined property of RxOnWhenIdle.
When this bit is set, it indicates that this device will turn
off its transceiver when it is Idle and will be unable to
receive packets. Any device, other than this device’s
parent, should route any packets that have this bit set
to the device’s parent. The target device’s parent will
buffer the message for the child until it wakes up and
requests the data. If this bit is not set in the device’s
address, then this device is always capable of receiving
packets.
Bits 15 through 11 are always 0in this implementation.
FIGURE 4: BIT FIELD ARRANGEMENT FOR THE MiWi™ PROTOCOL SHORT ADDRESS
Reserved Parent’s Number Child’s Number
00000xxxxxxxxxxx
RxOffWhenIdle
bit 15 bit 0
AN1066
DS01066B-page 6 © 2010 Microchip Technology Inc.
FIGURE 5: ASSIGNING SHORT ADDRESSES WITHIN A TYPICAL MiWi™ PROTOCOL NETWORK
MiWi PROTOCOL MESSAGING
Once a network has been formed, the next major
concern is how to send messages through the network.
Any device that is a member of a MiWi protocol network
will use its short address to communicate through the
network. This short address helps other devices in the
network to determine the location of the node and how
to route to that device.
Packet Format
For a IEEE 802.15.4 compliant RF transceiver, MiWi
protocol uses 16-bit short address to transmit and
receive messages whenever possible. The packets
should be constructed according to Section 7.2 of the
IEEE 802.15.4 specification. Proprietary SubGHz RF
transceiver, however, use EUI address in MAC layer.
For more information on the packet format in MAC
layer for Microchip proprietary RF transceiver, refer to
the Microchip application note AN1283 Microchip
Wireless Media Access Controller - MiMAC
(DS01283).
Above this layer resides the MiWi protocol header that
contains information needed for routing and packet
processing. This header format is shown in Figure 6.
It is comprised of the following components:
Hops: The number of hops that the packet is
allowed to be retransmitted (00h means don’t
retransmit this packet – 1 byte).
Frame Control: The Frame Control field is a
bitmap that defines the behavior of this packet.
The individual bits are defined in Table 3 (1 byte).
Dest PANID: The PANID of the final destination
node (2 bytes in the MiWi protocol).
Dest Short Address: The final destination’s short
address (2 bytes).
Source PANID: The PANID of the node that
originally sent the packet (2 bytes).
Source Short Address: The short address of the
node that originally sent the packet (2 bytes).
Sequence Number: A sequence number that can
be used to track the status of packets as they
travel through the network (1 byte).
FIGURE 6: MiWi™ PROTOCOL PACKET HEADER FORMAT
BCF
G
DE
A
PAN Coordinator
FFD End Device
RFD End Device
Coordinator
Legend
0000h
0100h 0200h 0282h
0300h 0201h
0381h xxxxh Short Address
Hops
Frame Control
Dest PANID
Dest
Short Address
Source PANID
Source Short Address
Sequence Number
Report Type
Report ID
1 1 1 12 2 2 2 1
Legend: Numbers indicate packet component size in bytes.
© 2010 Microchip Technology Inc. DS01066B-page 7
AN1066
Routing
Routing in wireless networks can be a very difficult and
resource intensive task. The MiWi protocol solves this
problem by using the address allocation to indicate the
parent of the device you want to send the packet to,
and by using the already provided IEEE services to
help exchange and relay routing information in the
network.
LEARNING ABOUT NEIGHBORING
COORDINATORS
One of the tasks of a routing algorithm is determining
the next hop for any outgoing packet. The MiWi
protocol uses the IEEE network join mechanism, in
addition to regular network traffic, to discover these
paths. When any device is joining onto the network, it
first sends out a beacon request packet. All of the
coordinators that hear the beacon request packet
sends out a beacon packet informing neighboring
devices of their network information.
In the MiWi protocol, three bytes of additional
information are attached to the beacon payload to
assist with routing:
Protocol ID (1 byte): This helps distinguish MiWi
protocol networks from other IEEE 802.15.4 net-
works that may be operating in the same radio
range. Protocol ID should always be 4Dh.
Version Number (1 byte): The version number of
the specification.
Local Coordinators (1 byte): This field is a
bitmap that indicates which coordinators are
currently visible by the coordinator that is sending
the beacon. Each bit position directly represents
one of 8 possible coordinators. Bit 0 is 0000h (the
PAN coordinator). Bit 1 indicates that this
coordinator can talk directly to 0100h, and so on.
For example: Coordinator 0x200 is capable of talking to
0x500 and the PAN coordinator. The Local
Coordinators field would be ‘b00100101.
Through the Local Coordinators field of the beacon
payload, all of the coordinators on the network will learn
about various possible routes to all of those nodes
without having to send out unique requests.
ROUTING TO OTHER DEVICES
Routing in MiWi protocol networks becomes easy once
we have knowledge of the neighboring coordinators, as
well as what those coordinators can see. Sending a
packet to another node follows the logic, as shown in
Figure 7.
TABLE 3: FRAME CONTROL BIT FIELD
0 0 0 0 0 x 1 0
r r r r r ACKREQ INTRCLST ENCRYPT
bit 7 bit 0
bit 7-3 Reserved: Maintain as ‘0’ in this implementation
bit 2 ACKREQ: Acknowledge Request bit
When set, the source device requests an upper layer Acknowledgement of receipt from the destination device.
bit 1 INTRCLST: Intra Cluster bit
Reserved in this implementation, maintain as ‘1’.
bit 0 ENCRYPT: Encrypt bit
When set, data packet is encrypted at the application level.
Note: Abbreviated bit names are for convenience of display only; they are not an official part of IEEE 802.15.4™.


Product specificaties

Merk: Microchip
Categorie: Niet gecategoriseerd
Model: PIC16F88

Heb je hulp nodig?

Als je hulp nodig hebt met Microchip PIC16F88 stel dan hieronder een vraag en andere gebruikers zullen je antwoorden




Handleiding Niet gecategoriseerd Microchip

Handleiding Niet gecategoriseerd

Nieuwste handleidingen voor Niet gecategoriseerd