Már
io S
ilva
Julho de 2012UMin
ho |
201
2
Universidade do MinhoEscola de Engenharia
Mário Alexandre dos Santos Marinho da Silva
Aplicação para reprogramação sem fios dacamada de aplicação Zigbee
Aplic
ação
par
a re
prog
ram
ação
sem
fios
da
cam
ada
de a
plic
ação
Zigb
ee
Julho de 2012
Tese de MestradoCiclo de Estudos Integrados Conducentes ao Grau de Mestreem Engenharia Electrónica Industrial e Computadores
Trabalho efectuado sob a orientação doDoutor José Gerardo Vieira Rocha
Universidade do MinhoEscola de Engenharia
Mário Alexandre dos Santos Marinho da Silva
Aplicação para reprogramação sem fios dacamada de aplicação Zigbee
iii
Agradecimentos
Quero expressar o meu sincero agradecimento a todas as pessoas que me apoiaram e
encorajaram, tornando este projecto possível, em especial ao meu orientador, o Doutor José
Gerado Vieira Rocha.
Agradeço à minha família pelo tempo que me dispensou para que eu pudesse realizar esta
tese de mestrado e agradeço a todos os meus professores que pacientemente me transmitiram ou
indicaram conhecimentos.
A todos, muito obrigado.
iv
Resumo
Existe, por vezes, a necessidade de actualizar o firmware de diversos dispositivos
existentes numa rede de sensores e actuadores zigbee. A aplicação desenvolvida durante o
trabalho realizado nesta dissertação teve como principal objectivo permitir, numa rede de
aparelhos zigbee, a actualização do firmware de cada dispositivo independentemente por via
wireless na camada de aplicação. Outro objectivo da aplicação é permitir executar actualizações
de software em dispositivos móveis ou robóticos.
Assim sendo, pretendeu-se desenvolver um programa capaz de actualizar a camada de
aplicação referente ao utilizador, sem que seja necessário desligar fisicamente os sensores. A
reprogramação da aplicação zigbee deve ser efectuada usando as camadas zigbee e 802.15.4,
podendo ser usado outro micro controlador, ou uma parte da memória do mesmo que é
propriamente a aplicação. Este micro controlador ou parte da memória flash deve ser
reprogramado.
Foi desenvolvida uma aplicação que permite enviar os ficheiros já compilados em
formato hexadecimal, e através dos canais zigbee enviar os ficheiros para o respectivo micro
controlador, o qual deverá ter um bootloader que permita reprogramar a memória flash.
Por uma aplicação específica podemos considerar um robô que se desloca num ambiente
fechado para entregar caixas com encomendas entre departamentos. Se pretender reprogramar os
micros controladores responsáveis por sensores de movimento, distância, orientação ou outros,
pode ser usada a aplicação descrita, sem ter necessidade de estar próximo fisicamente do mesmo.
Foi ainda realizado um estudo sobre a camada PHY e MAC do protocolo IEEE 802.15.4
e ainda da camada NETWORK do protocolo zigbee.
Palavras-chave (Tema):
Protocolo zigbee, Protocolo IEEE 802.15.4, wireless bootloader
v
Abstract
Sometimes there is a necessity to update the firmware of several components in a
network of sensor and zigbee actuators. The application developed in this work has as a primary
objective which is the allowing of independent wireless firmware updates of components within
a zigbee network within the application layer. Another objective of this application is to allow
software updating in mobile or robotic devices.
Therefore it was our intent to develop a program capable of updating the user layer
without physically disconnecting the sensors. The reprogramming of the zigbee application
should be made using the zigbee layers and 802.15.4, allowing for the use of another micro
controller or part of its memory which is the application. This micro controller or part of the
flash memory must be reprogrammed.
An application was also developed allowing for the sending of compiled hexadecimal
files, as well as the sending of files through the zigbee channels to the micro controller, which
must include a bootloader that allows for flash memory reprogramming.
As an example we may consider a robot that circulates in a closed environment delivering
packages between departments. If we wanted to reprogram the micro controllers responsible for
the movement of the robot, i.e, distance, orientation the described application may be used to that
effect without the need for being in proximity to the robot.
A study on the PHY and MAC layers of the IEEE 802.15.4 protocol, as well as the zigbee
network layer protocol was also made.
Key words
zigbee protocol, IEEE 802.15.4 protocol, wireless bootloader
Índice vi
Índice
Introdução ...................................................................................................................................... 1
1.1 Enquadramento e Apresentação do Projecto .................................................. 1
1.2 Objectivos do Trabalho .......................................................................... 1
1.3 Ferramenta Utilizada ............................................................................ 2
1.4 Organização da Tese ............................................................................. 3
2 Estado da Arte ....................................................................................................................... 4
2.1 A evolução das redes sem fios de baixa potência e transferência de dados. ................. 4
3 Protocolo 802.15.4 e Zigbee ................................................................................................... 7
3.1 Componentes da rede ............................................................................ 7
3.2 Topologias de Rede ............................................................................... 7
3.3 Características do rádio .......................................................................... 9
3.4 Camada de endereçamento, rota. ............................................................. 12
3.4.1 Mecanismo de Ad hoc on Demand Distance Vector. .................................................. 13
3.4.2 Cluster-Tree algoritmo .................................................................................. 16
3.5 Mecanismos de Acesso Zigbee ................................................................. 23
3.5.1 Mecanismo de acesso Zigbee ........................................................................... 23
3.5.2 Terminologia do protocolo Zigbee ..................................................................... 23
3.5.3 Comunição via mensagem .............................................................................. 25
4 Materiais e Métodos ............................................................................................................ 33
4.1 Aplicação downloader para Bootloader ...................................................... 35
4.1.1 Zigbee bootloader multiaddres ......................................................................... 35
4.2 Aplicação em VB.net, para actualizar o firmware. .......................................... 37
4.2.1 COMANDOS USADOS PARA PROGRAMAR O FIRMWARE ................................... 38
4.2.2 Fluxograma de envio do firmware. ..................................................................... 39
4.2.3 Circuito electrónico ..................................................................................... 41
Índice vii
4.3 Segurança dos dados enviados................................................................. 43
4.3.1 Encriptação desabilitada ................................................................................ 45
4.3.2 Tempo usado no envio de dados. ....................................................................... 46
4.3.3 Pedido de associação. ................................................................................... 49
4.3.4 Descoberta de dispositivos .............................................................................. 49
4.3.5 Envio de código em formato HEX file com chave de rede AES 128 ................................. 50
5 Discussão dos Resultados e Conclusões ............................................................................. 52
Referências ................................................................................................................................... 53
Acronyms and abbreviations 802.15.4 e Zigbee ....................................................................... 54
Anexos .......................................................................................................................................... 61
Anexo A: Algoritmo de acesso ao meio ........................................................... 61
Anexo B: Aplicação em Vb 2008.net ............................................................. 81
Anexo C: Código Assembler ......................................................................... 89
Índice de Ilustrações viii
Índíce de Ilustrações
Ilustração 1, Topologias de rede ......................................................................... 7
Ilustração 2, Arquitetura de dispositivo LR-WPAN .................................................... 9
Ilustração 3, Frequências de bandas e taxa de transferência de dados ........................... 10
Ilustração 4, Bandas de operação de frequência. .................................................... 11
Ilustração 5, Formato de PPDU .......................................................................... 12
Ilustração 6, Caminho Direto e inverso na formação de protocolo AODV ......................... 14
Ilustração 7, Processo de Selecção do Clustr Head ................................................... 16
Ilustração 8, Ligação entre Cluster Head e Nó membro ............................................. 17
Ilustração 9, Procedimentos de instalação do Cluster Multi Hop .................................. 18
Ilustração 10, Atribuição de Cluster ID 1. ............................................................. 18
Ilustração 11, Atribuição de Cluster ID 2. ............................................................. 19
Ilustração 12, Atribuição de Cluster ID 3. ............................................................. 21
Ilustração 13, Atribição de Cluster ID 4 ................................................................ 22
Ilustração 14, Rede multi cluster e nó de fronteira.................................................. 22
Ilustração 15, Atributos , cluster e endoits nos vários profiles. ................................... 25
Ilustração 16, Exemplo de uma entrada na tabela de grupo. ....................................... 28
Ilustração 17, Placas de desenvolvimento Zigbee da Microchip .................................... 33
Ilustração 18, Módulos Zigbee a 2.4 Ghz da MaxStream ............................................. 34
Ilustração 19, mapeamento da memória, com e sem boot loader. ................................ 36
Ilustração 20, Aplicação para download, janela principal. ......................................... 38
Ilustração 21, Fluxograma de funcionamento da aplicação bootloader. .......................... 40
Ilustração 22, Fluxograma de seleção de endereço. ................................................. 41
Ilustração 23, esquema de micro controlador com interface ao módulo de 2.4 Ghz ............ 42
Ilustração 24, desenho da placa de circuito impresso com componentes SMD ................... 43
Ilustração 25, Frame encriptada com chave simétrica AES128. .................................... 44
Ilustração 26, Chave Simetrica. ......................................................................... 45
Índice de Ilustrações ix
Ilustração 27, Quadro com envio de dados sem encriptação AES. ................................. 45
Ilustração 28, Download de código para programação, com aplicação bootloader. ............. 46
Ilustração 29, Envio de Start byte “0xEA” ............................................................. 47
Ilustração 30,Frames de ACK. e confirmação ......................................................... 48
Ilustração 31,Vista dos módulos capturados pelo programa ZENA. ................................ 48
Ilustração 32, pedido de associação ao coordenador ................................................. 49
Ilustração 33, Resposta do coordenador, quando da descoberta do node route2010. .......... 50
Ilustração 34, download de hex file com chave de rede AES 128 .................................. 51
Íntrodução 1
Introdução
Com os recentes avanços da tecnologia o uso das redes sem fios (wireless) tem sido
adoptado em detrimento das redes convencionais de cabo ou fibra óptica. Na maioria das redes
sem fios pretendia-se uma grande taxa de débito, o que tornava os equipamentos bastante
dispendiosos e pouco interessantes e práticos para aplicações simples. Por causa da evolução das
tecnologias das redes sem fio e das exigências do mercado, estas redes de baixas taxas de
transferência sem fios começaram a ser usadas em variadas aplicações e sensores.
Habitualmente, essas redes têm como função controlar vários equipamentos domésticos e
aparelhos usados em domótica e periféricos para computador eliminando os cabos e tornando
prática a utilização destes periféricos como o rato ou teclado. Uma das tecnologias mais recentes
dentro desse grupo de redes para aplicações pessoais é o padrão zigbee e que assenta no
protocolo IEEE 802.15.4, homologado em Maio de 2003. Este protocolo de comunicação, no
entanto, não permite realizar actualizações de firmware e/ou software dos dispositivos por via
wireless, exigindo sempre uma ligação física por cabos de programação aos dispositivos.
1.1 Enquadramento e Apresentação do Projecto
Neste contexto, surgiu o enquadramento para o presente projecto, dado que com frequência
e independentemente da camada de aplicação usada, é necessário actualizar o firmware dos
diversos sensores e actuadores existente numa rede de dispositivos. Nessa situação, tem que se
reprogramar a memória flash do micro controlador, podendo essa reprogramação ser efectuada
com um programador dedicado através da porta de programação ou com um cabo se existir uma
ligação e um bootloader. No entanto, o acesso a alguns sensores e/ou actuadores pode ser difícil
ou demorado, dificultando a actualização do firmware dos diversos dispositivos.
1.2 Objectivos do Trabalho
A aplicação desenvolvida durante o trabalho realizado nesta dissertação teve como
principal objectivo permitir, numa rede de aparelhos zigbee, a actualização do firmware de cada
dispositivo independentemente, por via wireless, na camada de aplicação. Outro objectivo da
aplicação é permitir executar actualizações de software em dispositivos móveis ou robóticos.
Íntrodução 2
Dada a necessidade frequente de actualização dos diversos dispositivos existentes numa
rede, surgiu o tema desta dissertação, que consistiu no desenvolvimento de uma aplicação que
permita actualizar o firmware de cada dispositivo por via wireless. A actualização por wireless
reduz o tempo de programação dos vários sensores, que na prática, numa rede de aparelhos
zigbee pode chegar a algumas centenas. Actualmente, numa rede de sensores e actuadores,
quando se pretende actualizar o firmware dos dispositivos é necessário ligar fisicamente o
mesmo através de um cabo de programação e actualizar a memória flash do micro controlador. A
aplicação desenvolvida visa actualizar a camada de aplicação referente ao utilizador, sem que
seja necessário desligar fisicamente os sensores. A reprogramação da aplicação zigbee deve ser
efectuada usando as camadas zigbee e 802.15.4, podendo ser usado outro micro controlador ou
uma parte da memória do mesmo que é propriamente a aplicação. Este micro controlador ou
parte da memória flash deve ser reprogramado.
Outra utilização imediata desta aplicação é permitir efectuar actualizações ao software de
dispositivos móveis ou robóticos, visando ultrapassar a limitação da ligação física para
actualização dos dispositivos.
Para cumprir os objectivos propostos foi desenvolvida uma aplicação que permite enviar
os ficheiros já compilados em formato hexadecimal, e através dos canais zigbee enviar para o
respectivo micro controlador, o qual deve ter um bootloader que permita reprogramar a memória
flash.
Por uma aplicação específica podemos considerar um robô que se desloca num ambiente fechado
para entregar caixas com encomendas entre departamentos. Se se pretender reprogramar os
micros controladores responsáveis por sensores de movimento, distancia, orientação ou outros,
pode ser usado a aplicação descrita nesta tese, sem ter necessidade de estar próximo fisicamente
do mesmo.
1.3 Ferramenta Utilizada
A aplicação usada permite a reprogramação sobre o canal zigbee e 802.15.4 dos micro
controladores. Para efeitos de diagnóstico foi usado o programa ZENA da microchip como sniffer
de rede escutando os pacotes enviados pelos aparelhos Xbee Power, da Maxim e os módulos
802.15.4 da microchip. Para implementar a pilha zigbee foram usados os micro controladores da
microchip da serie 18Fxxxx com 64k de Flash e 32k de RAM.
Íntrodução 3
1.4 Organização da Tese
A tese encontra-se organizada em seis capítulos principais. No primeiro capítulo é feita a
abordagem ao problema e são apresentados os principais objectivos da tese.
No capítulo 2 apresenta-se o estado da arte global, e no capítulo 3 é feita uma
caracterização do protocolo 802.15.4 com as camadas PHY e MAC e o protocolo zigbee com as
camadas de rede e de aplicação, e salientadas as principais características dos protocolos e a sua
implementação nos micro controladores.
No capítulo 4, materiais e métodos, é efectuada uma descrição geral da aplicação para fazer
a reprogramação dos micro controladores por via wireless, é efectuada ainda uma descrição das
ferramentas de diagnóstico e do sniffer de frames zigbee, o ZENA da microchip, sendo ainda
analisada a máxima transferência de dados com uma ligação directa.
No capítulo 5 são discutidos os resultados obtidos após a implementação da aplicação.
São apresentadas as conclusões destes trabalhos, nomeadamente os resultados obtidos em
termos de ganhos de produtividade e ainda de redução de custos. Fazem-se ainda algumas
comparações entre os processos tradicionais e são ainda apresentadas sugestões e perspectivas
para trabalhos futuros.
Em anexo encontra-se informação suplementar, como a descrição do software para micro
controlador com aplicação bootloader e ainda a brochura da aplicação de sniffer.
Estado da Arte 4
2 Estado da Arte
2.1 A evolução das redes sem fios de baixa potência e transferência de dados.
A necessidade de comunicação sem fios, em particular quando os intervenientes na
comunicação não estão numa posição fixa, obrigou a tentar a comunicação entre aparelhos
móveis, e com a integração surgiu a possibilidade de construir aparelhos de reduzido tamanho e
custo. À medida que foi crescendo a necessidade de mobilidade e o custo de implementação de
novos cabos, a motivação para uma ligação pessoal independente da localização dessa mesma
rede também aumentou. A cobertura de uma área grande é providenciada por (1-2 km) células
que colaboram com os seus vizinhos para criar uma quase rede continua. Exemplos de standard
são GSM, IS-136, IS-95. Standards de telemóveis foram basicamente criados para facilitar a
comunicação por voz dentro de uma área metropolitana [10].
Durante meados de 1980, resultou que uma cobertura de mesmo uma área pequena é
necessária para uma densidade de alto uso e o aparecimento de tráfego de dados. A IEEE 802.11
grupo de trabalho para WLANs é formada para criar uma rede sem fios numa área local
standard.
Enquanto a IEEE 802.11 se preocupava com características como Ethernet matching
speed, longo alcance (100m), complexidade para lidar com roaming contínuo, reenvio de
mensagens, e taxa de transferência de 2-11 Mbps, WPANs preocupavam-se com o espaço a volta
da pessoa ou objecto que tipicamente se estendia ate 10 m em todas as direcções. O focus da
WPANs é baixo custo, baixo consumo, curto alcance e tamanho muito pequeno. O grupo de
trabalho IEEE 802.11 é formado para criar WPAN standard. Este grupo tem correntemente
definido 3 classes de WPAN que são diferenciadas por taxa de transferência, duração da bateria
e qualidade do serviço (QoS). A alta data rate WPAN (IEEE 802.15.3) é apropriada para
aplicações multi-media que requerem um muito alto QoS. Médium rate WPANs (IEEE
802.15.1/blueetooth) conseguem conciliar uma variedade de funções que vão desde
comunicações telemóveis a PDA e possuem um QoS apropriado para comunicações por voz. Os
low rate WPANs (IEEE 802.15.4/LR-WPAN) são feitos para servirem um leque de aplicações
na industria, residência e aplicações médicas com um poder de consumo muito baixo e
requerimento de custo não considerado pelas acima WPANs e com necessidades relaxadas para
data rate e QoS. A baixa data rate permite a LR-WPAN um consumo muito pequeno [10].
Estado da Arte 5
A tecnologia ZigBee é uma tecnologia com baixo data rate, com baixo consumo, baixo
custo, protocolo de rede sem fios orientada para automatização e aplicações de controlo remoto.
O comité IEEE 802.15.4 começou a trabalhar numa low data rate standard um pouco mais tarde.
Depois a aliança ZigBee e o IEEE decidiram unir forças e ZigBee é o nome comercial para esta
tecnologia [11].
Ao ZigBee é esperado proporcionar conectividade de baixo custo e baixo consumo para
equipamentos que precisem de tempo de vida de bateria grande, desde vários meses até vários
anos, mas não precisa de transferência de data rates tão altas como as permitidas por bluetooth.
E ainda, ZigBee pode ser implementado em redes mesh maiores do que é possível com
bluetooth. Aparelhos que detenham uma rede sem fios ZigBee são esperadas distâncias de
transmissão entre 10-75 metros, dependendo do ambiente RF e do consumo necessário para uma
dada aplicação, e irão operar nas frequências RF worldwide (2.4 GHz global, 915 MHz
Américas ou 868 MHz Europa). A data rate é de 250 kbps a 2.4 GHz, 40 kbps a 915 MHz e 20
kbps a 868 MHz [10].
A aliança IEEE e ZigBee têm trabalhado conjuntamente para especificar todo o protocolo.
IEEE 802.15.4 foca-se na especificação das duas baixas camadas do protocolo (física e camada
data link). Por outro lado, a aliança ZigBee tem por objectivo providenciar a camada alta do
protocolo (desde a rede até à camada da aplicação) para intra operacional data networking,
serviços de segurança e uma gama de controlo de segurança sem fios casa e edifício,
providenciam intra operatividade testes de conformidade, marketing do standard e engenharia
avançada para a evolução do standard. Isto irá assegurar ao consumidor a compra de produtos de
diferentes produtores com a confiança de que esses produtos irão trabalhar juntos [11].
IEEE 802.15.4 está agora a detalhar a especificação do PHY e MAC oferecendo os blocos
construtivos para diferentes tipos de networking conhecidos como “star, mesh e cluster tree”.
Esquemas de network routing são desenhados para assegurar duração da bateria, e uma latência
baixa através de guaranteed time slots. Uma característica única do ZigBee network layer é a
communication redundacy eliminando “single point of failure” nas mesh networks.
Características chave do PHY incluem energia e link quality detection, teste canal livre (clear
channel assesment) para melhorada co existência com outras redes sem fio [1].
O ZigBee é idêntico ao bluetooth só que é mais simples no que se refere a pilha de
software, tem uma mais baixa data rate e gasta a maioria do seu tempo num estado dormente.
Esta característica significa que um nó numa rede ZigBee deve ser capaz de trabalhar por 6
meses a 2 anos com apenas duas baterias do tipo AA [10].
Estado da Arte 6
O alcance operacional do ZigBee é de 10-75m comparado com 10 m para o bluetooth (sem
amplificador de potência).
O ZigBee está abaixo do bluetooth em termos de data rate. A data rate do ZigBee é de
250kbps a 2.4 GHz, 40kbps a 915 MHz e 20 kbps a 868 MHz enquanto a do bluetooth é de
1Mbps [11].
O ZigBee usa uma configuração básica master-slave satisfatória para static star networks
de muitos aparelhos usados pouco frequentemente que “falam” via uma pequena “data packets”.
Permite até cerca de 254 nós. O protocolo do bluetooth é mais complexo uma vez que é
orientado para lidar com voz, imagens e transferência de ficheiros em ad hoc networks.
Aparelhos bluetooth, só permitem até 8 slave nodes num básico master-slave [11].
Quando o nó ZigBee é desligado, pode acordar e receber a “packet” em cerca de 15 msec,
enquanto o bluetooth demora cerca de 3 sec para acordar e responder.
Protocolo 802.15.4 e Zigbee 7
3 Protocolo 802.15.4 e Zigbee
3.1 Componentes da rede
O sistema ZigBee consiste em vários componentes. O mais básico é o aparelho. O aparelho
pode ser um “full-function device” (FFD) ou um “reduced-function device” (RFD). A rede deve
incluir pelo menos um FFD, que opere como o PAN coordenador.
O FFD pode operar em 3 modos: coordenador personal área network (PAN),
encaminhador ou aparelho final. O RFD é solicitado para aplicações que são extremamente
simples e não precisam de mandar uma grande quantidade de dados. Um FFD pode comunicar
com um RDF ou FFD, enquanto um RFD apenas pode comunicar com um FFD.
3.2 Topologias de Rede
A Figura 1 mostra três tipos de topologias que o zigbee suporta: star tipology, mesh
tipology e cluster tree.
Ilustração 1, Topologias de rede
Protocolo 802.15.4 e Zigbee 8
Topologia em estrela.
Nesta topologia, a comunicação é estabelecida entre aparelhos e uma única central
controladora, chamada de PAN coordenador. O PAN coordenador pode ser de alimentação
central enquanto os aparelhos serão certamente de alimentação por baterias. Aplicações que
beneficiam desta topologia incluem: home automation, personal computar (PC) peripherals,
brinquedos e jogos.
Depois de uma FFD activada pela primeira vez, pode estabelecer a sua própria rede e ficar
o PAN coordenador. Cada rede inicial escolhe o PAN identificador, que não é correntemente
usado por nenhuma outra rede dentro da esfera rádio de influência. Isto permite a cada star
network operar independentemente.
Ponto a Ponto.
Neste tipo de topologia também existe um PAN coordenador. Em contraste com a star
topologia, qualquer aparelho pode comunicar com qualquer outro aparelho desde que estejam no
alcance, um dos outros. A peer-to-peer topologia pode ser ad hoc, organizar-se a si própria e
reparar-se a si própria. Aplicações como controlo industrial e monitorização, redes sensor sem
fios (wireless sensor networks), identificação de bens e inventário beneficiariam de uma
topologia como esta. Também permite “hops múltiplos” para mensagens encaminhadas de
qualquer aparelho para qualquer outro aparelho na rede.
Topologia em conjunto de estrela e ponto a ponto.
Redes cluster-tree são um caso especial das peer-to peer networks nas quais a maioria dos
aparelhos são FFDs e os RFD podem ligar a um cluster-tree network como um nó de saída ao
fim de um ramo. Qualquer um dos FFD pode agir como coordenadores e providenciar serviços
de sincronização a outros aparelhos e coordenadores. Só um destes coordenadores é no entanto o
PAN coordenador.
O coordenador PAN forma o primeiro cluster por estabelecimento de si próprio como a
cabeça do cluster (CLH) com um identificador de cluster (CID) de zero, escolhendo um
identificador PAN não usado, e emitindo “beacon frames” a aparelhos vizinhos. O candidato que
recebe a beacon frame pode pedir para se juntar à rede ao CLH. Se o coordenador PAN permitir
Protocolo 802.15.4 e Zigbee 9
ao aparelho juntar-se, ele irá adicionar este novo aparelho como um aparelho “filho” á sua lista
de vizinhos. O novo aparelho adicionado ira adicionar o CLH como “pai” na sua lista de
vizinhos e começar a transmissão periódica de beacons, para que outros aparelhos candidatos
possam juntar-se á rede nesse aparelho. Uma vez cometidos os requerimentos desse aparelho ou
rede, o coordenador PAN pode instruir o aparelho a tornar-se o CLH de um novo cluster
adjacente ao primeiro. A vantagem desta estrutura cluster é a maior cobertura de área ao custo de
uma maior latência de mensagem.
Ilustração 2, Arquitetura de dispositivo LR-WPAN
A Figura 2 mostra um aparelho LR-WPAN. Este aparelho engloba as camadas, que contêm
uma frequência de rádio (RF) transceiver juntamente com o seu mecanismo de baixo nível de
controlo, e uma sob camada MAC que providencia o acesso ao canal físico para todos os tipos de
transferência. A camada superior consiste numa camada de rede, que providencia configuração
de rede, manipulação, e reenvio de mensagens (message routing), e camada de aplicação, que
providencia a intencionada função do aparelho. O controlo de ligação lógico do IEEE 802.2
(LLC) (logical link control) pode aceder à sob camada MAC através de específico serviço
convergência sob camada (SSCS) (service specific convergence sublayer).
3.3 Características do rádio
O PHY providencia dois serviços: o PHY data service e o PHY management service que
faz interface com a camada física entidade gestora (PLME) (physical layer management entity).
Protocolo 802.15.4 e Zigbee 10
O PHY data service permite a transmissão e recepção de PHY protocol data units (PPDU)
através do canal de rádio físico.
As características do PHY são a activação e desactivação do rádio transceiver, energy
detection (ED), link quality indication (LQI), selecção de canal, clear channel assessment (CCA)
e transmitir bem como receber pacotes através do meio físico.
O standard oferece 2 opções PHY baseadas na frequência de banda. Ambas são baseadas
em direct sequence spread Spectrum (DSSS). A data rate é 250kbps a 2.4 GHz, 40kbps a 915
MHz e 20 kbps a 868 MHz. A mais alta data rate a 2.4 GHz é atribuída a um esquema de
modulação de ordem alta. Baixas frequências proporcionam alcances maiores devido à baixa
perda de propagação. Uma baixa transferência de dados pode ser traduzida em melhor
sensibilidade e uma área de cobertura mais alargada. Uma transferência de dados mais alta
significa um mais alto throughput, baixa latência. Esta informação está sumarizada na figura 3.
Ilustração 3, Frequências de bandas e taxa de transferência de dados
Existe um único canal entre 868 e 868.6 MHz, 10 canais entre 902.0 e 928.0 MHz, e 16
canais entre 2.4 e 2.4835 GHz como mostrado na figura 4. Mais canais em diferentes frequências
de banda permitem a habilidade de relocar no espectro. O standard também permite uma
selecção de canal dinâmica, uma função scan que entra por uma lista de canais suportados em
busca do beacon frame, detecção da energia do receptor, link quality indication,torna possivel
mudar de canal.
A sensibilidade do receptor é de -85dBm para o 2.4GHz e de -92dBm para o 868/915MHz.
A vantagem de 6-8dB vem da vantagem da baixa data rate. O alcance conseguido é uma função
da sensibilidade do receptor e do poder de transmissão.
O poder máximo de transmissão tem de se conformar com regulamentos locais. Um
aparelho que faz uso do cumprimento de regras deverá ter o seu nível de poder de transmissão
nominal indicado no parâmetro PHY, PhyTransmitPower.
Protocolo 802.15.4 e Zigbee 11
Ilustração 4, Bandas de operação de frequência.
A medição de energia (ED) no receptor é usada pela network layer como variável de um
algoritmo, o do selector de canal. É uma estimativa da potencia do sinal recebido dentro da
largura de banda do canal IEEE 802.15.4. Não há tentativa de identificar ou descodificar o sinal
no canal. O tempo de ED deverá ser igual a 8 períodos de símbolo.
O resultado ED deverá ser reportado como um inteiro de 8-bit, que vai de 0x00 a 0xff. O
valor mínimo de ED (0) devera indicar o poder recebido menor que 10 dB acima da
especificação da sensibilidade do receptor. O intervalo da potência recebida ED, deve ser pelo
menos 40dB. Dentro deste intervalo, a informação do poder recebido em decibéis para os valores
ED deve ser linear com uma precisão de +-6dB.
Aquando a recepção de um pacote, o PHY envia o comprimento PSDU (Phy Service Data
Unit), o próprio PSDU e link quality (LQ) na PD-DATA. Indication primitive. A medida de LQI
é a caracterização da força e/ou qualidade do pacote recebido. A medição pode ser implementada
usando o receptor ED. O uso do resultado do LQI é de acordo com a rede ou a aplicação das
camadas.
O resultado LQI devera ser reportado como um inteiro de 8 bits no intervalo 0x00 para
0xff. O mínimo e o máximo valores de LQI devem ser associados com a menor e a maior
qualidade dos sinais IEEE 802.15.4 detectáveis pelo receptor e valores LQ devem ser
uniformemente distribuídos entre estes dois limites.
O CCA é feito de acordo com pelo menos um dos seguintes 3 métodos:
Protocolo 802.15.4 e Zigbee 12
Ilustração 5, Formato de PPDU
- Energia acima do threshold. CCA deverá reportar um meio ocupado ao detectar qualquer
energia acima do threshold.
- Unicamente sensor de portadora (carrier). CCA deverá reportar um meio ocupado apenas
ao detectar um sinal com características de modulação e transmissão do IEEE 802.15.4. Este
sinal pode ser acima ou abaixo do ED threshold.
- Sensor carrier detected com energia acima do threshold. CCA deverá reportar um meio
ocupado apenas ao detectar um sinal com características de modulação e transmissão do IEEE
802.15.4 com energia acima do ED threshold.
A estrutura do pacote PPDU está ilustrado na fig. 4 Cada pacote PPDU consiste nos
seguintes componentes básicos:
- SHR, que permite um aparelho receptor sincronizar e bloquear no bit stream
- PHR, que contem informação do comprimento da frame
- Uma variável de comprimento payloads, que transporta a frame da sob camada MAC.
3.4 Camada de endereçamento, rota.
O algoritmo de routing do ZigBee pode ser pensado como uma routing hierárquica com
table-driven optimizations (método de testes autónomos que requerem a construção de tabelas de
dados) aplicadas onde possível. A routing layer é uma camada como tendo como principio a
beacom de domínio público, o algoritmo Ad hoc On Demand Distance Vector (AODV) e
algoritmo Motorola Cluster-Tree. É apresentado o AODV na secção 3.5.1 e o algoritmo Cluster-
Tree na secção 3.5.2.
Protocolo 802.15.4 e Zigbee 13
3.4.1 Mecanismo de Ad hoc on Demand Distance Vector.
AODV é um algoritmo de aquisição de route on demand, nodes que não estão em
caminhos activos nem mantêm nenhuma routing de informação ou nem participam em nenhuma
periodic routing table exchanges. Mais, um node não tem de descobrir ou manter uma route para
outro node até os dois necessitarem de comunicar, a não ser que o node prévio ofereça serviços
como um intermediário forwarding station para manter conectividade entre outros dois nodes.
O objectivo primário do algoritmo é emitir pacotes descobertos só quando for necessário,
para distinguir entre gestão de conectividade local e general topology maintenance e para
disseminar informação acerca de mudanças na conectividade local para os nodes mobiles
vizinhos que são capazes de precisar dessa informação.
Quando um node de origem necessita de comunicar com outro node para o qual não existe
informação de routing na sua tabela, o processo Path Discovery é iniciado. Cada node mantém
dois counters separados: sequence number e broadcast id. O node de origem inicia o caminho de
descoberta emitindo um pedido de route (RREQ) pacote aos seus vizinhos, que inclui source
addr, source sequence number, broadcast id, dest addr, dest sequence number, hop cnt. (source
sequence number é para manter a informação actualizada acerca da route reversa enquanto o
destination sequence number é para manter a frescura da route para o destino antes de poder ser
aceite pela fonte).
O par source addr, broadcast id identificam unicamente a RREQ, onde broadcast id é
incrementada quando a fonte/origem emita um novo RREQ. Quando um node intermediário
recebe um RREQ, se já tiver recebido um RREQ com o mesmo broadcast id e endereço de
origem, “deixa cair” (drops) o RREQ redundante e não o reenvia. Senão, iria reenviá-lo para os
seus vizinhos depois de aumentar o hop cnt. Cada node mantém a seguinte informação:
destination IP Address, source IP Address, broadcast id, expiration time for reverse path route
entry and source node´s sequence number.
Protocolo 802.15.4 e Zigbee 14
Ilustração 6, Caminho Direto e inverso na formação de protocolo AODV.
À medida que as RREQ viajam da origem para os destinos, automaticamente cria um
reverse path a partir de todos os nodes de volta a origem. Para criar o reverse path, o node grava
o endereço do vizinho do qual recebeu a primeira cópia do RREQ. Estas entradas de reverse path
route são mantidas pelo menos por tempo suficiente para o RREQ atravessar a rede e produzir
uma resposta ao sender.
Quando o RREQ chega ao node, possivelmente o próprio destino, que possui uma route
actual para o destino, o node receptor primeiro verifica que o RREQ foi recebido num link
bidireccional. Se este node não é o destino, mas possui a route para o destino, determina se a rota
é actual comparando o número sequência de destino na sua própria route entry com o destination
sequence number no RREQ. Se o número de sequência do RREQ para o destino é maior que o
gravado no node intermediário, o node intermediário não deve usar esta rota para responder ao
RREQ, em vez disso deve reenviar o RREQ.
Se a rota tem um destination sequence number que é Maior do que o RREQ contem ou
igual ao que o RREQ contem mas com uma menor hop count, pode unicast (emitir para um) um
route reply packet (RREP) de volta ao seu vizinho do qual recebeu o RREQ. A RREP contém a
seguinte informação: source addr, dest addr, dest sequence number, hop cnt and lifetime. Á
medida que o RREP viaja de volta á origem, cada node ao longo do caminho sets up a forward
pointer para o node do qual o RREP veio, faz um update do timeout information para entrada de
Protocolo 802.15.4 e Zigbee 15
routes para a origem e o destino, e regista o último destination sequence number para os destinos
requisitados.
Os node que estão ao longo do caminho determinado pelo RREP vão timeout depois do
route request expiration timer, e serão apagados os reverse pointers uma vez que eles não estão
no caminho desde a origem até ao destino como mostrado na fig. 20. O valor deste tempo
timeout depende do tamanho do ad hoc network. Também existe uma routing catching timeout
que está associada com cada entrada de routing para mostrar o tempo após a qual a rota é
considerada inválida. Cada vez que a entrada de rota é usada para transmitir data desde a origem
até ao destino, o timeout para esta entrada é posta ao actual time plus active-route-timeout.
O node de origem pode começar a transmitir data desde logo que o primeiro RREP é
recebido, e pode mais tarde actualizar a sua informação de rota se aprender uma rota melhor.
Cada tabela de entrada de rota contém os seguintes campos: destino, próximo hop, número
de hops, número de sequência do destino, vizinhos activos para esta rota, tempo de validade para
a entrada de tabela de rota.
Para a manutenção do caminho, cada node mantêm o endereço dos vizinhos activos,
através dos quais os pacotes para um dado destino são recebidos, e é mantido. Este vizinho é
considerado activo se origina ou repõe pelo menos um pacote para esse destino dentro do último
active-timeout period.
Uma vez que o próximo hop no caminho da origem ao destino se torna inacessível (hello
messages não são recebidas durante um certo tempo, hello messages também garantem que só os
nodes com conectividade bidireccional são considerados vizinhos, então cada hello message
inclui os nodes dos quais o node ouviu), o node acima da quebra propaga um RREP não
solicitado com um novo número de sequência e um hop count de “infinito” para todos os nodes
acima da corrente. Este processo continua até que todos os nodes activos de origem são
notificados. Ao receber a notificação de uma quebra do link, os nodes de origem podem
recomeçar o processo de descoberta se ainda for necessário uma rota para o destino. Se ele
decide que quer reconstruir a rota para o destino, envia um RREQ com uma sequência número
de destino maior em 1 que a sequência previamente conhecida, para assegurar que ela constrói
uma nova rota viável, e que nenhum node responde se eles ainda reconhecem a rota prévia como
válida.
Protocolo 802.15.4 e Zigbee 16
3.4.2 Cluster-Tree algoritmo
O protocolo Cluster-Tree é um protocolo do link lógico e camadas de rede que usa um
pacote link-state para formar ou um único cluster network ou uma potencial cluster-tree network
mais larga. A rede basicamente organiza-se a si própria e suporta redes redundantes para obter
um nível de resistência a falhas e auto reparação.
Os nodes seleccionam um cluster head e formam um cluster de acordo com um modo de
auto organização. Então, os cluster que se desenvolveram a si próprios ligam-se uns aos outros
usando um Designated Device (DD).
Um único Cluster
O processo de formação do cluster começa com a selecção da cabeça do cluster. Depois de
seleccionar a cabeça do cluster, a cabeça do cluster expande links com outros membros nodes e
formam um cluster.
Ilustração 7, Processo de Selecção do Clustr Head.
Depois de um node se ligar, faz um scan aos canais á procura de HELLO message de
outros nodes (HELLO message correspondem aos beacon na MAC camada do IEEE 802.15.4).
Se não consegue nenhuma mensagem HELLO durante um certo período de tempo, este node fica
Protocolo 802.15.4 e Zigbee 17
a cabeça cluster como mostrado na fig. 21 e envia HELLO messages aos seus vizinhos. A nova
cabeça cluster espera por respostas dos seus vizinhos durante um certo tempo. Se não recebe
nenhum pedido de conexão, volta-se para um node regular e escuta outra vez. A cabeça de
cluster também pode ser seleccionada baseado em parâmetros armazenados de cada node, como
alcance de transmissão, capacidade energética, computing ability ou informação de localização.
Depois de se tornar a cluster head (CH), o node emite uma mensagem HELLO periódica
que contem parte da cabeça cluster MAC Address e node ID 0 que indica cluster head. Os nodes
que recebem esta mensagem enviam um CONNECTION REQUEST message ao cluster head.
Quando o CH recebe esta mensagem, responde ao node com uma CONNECTION RESPONSE
message que contêm uma node ID para esse node (node ID corresponde ao endereço curto nas
camadas MAC). O node ao qual foi atribuído um node ID responde com uma mensagem ACK
ao cluster head. A troca de mensagens é mostrada na fig. 22.
Ilustração 8, Ligação entre Cluster Head e Nó membro.
Se todos os nodes estão localizados no alcance do cluster head, a topologia das
comunicações transforma-se numa estrela (star) e cada node member está ligado ao cluster head
por um hop. Um cluster pode expandir para uma multi-hop estrutura quando cada node suporta
ligações múltiplas. A troca de mensagens para o multi hop cluster set up procedure é mostrada na
fig. 23.
Protocolo 802.15.4 e Zigbee 18
Ilustração 9, Procedimentos de instalação do Cluster Multi Hop.
Ilustração 10, Atribuição de Cluster ID 1.
Protocolo 802.15.4 e Zigbee 19
Ilustração 11, Atribuição de Cluster ID 2.
Se a cluster head não tem mais nenhuma node ID ou a cluster head alcançou outro limite
definido, deve rejeitar pedidos de ligação de novos nodes. A rejeição é feita por atribuição de um
ID especial ao node.
A entrada na lista de vizinhos e as rotas são actualizadas pela mensagem HELLO
periódica. Se uma entrada node não se actualiza até um certo tempo timeout limite, deverá ser
eliminada.
Um node pode receber uma mensagem HELLO de um node que pertence a um cluster
diferente. Nesse caso, o node adiciona a cluster ID (CID) do node transmissor da lista vizinha e
depois manda um LINK STATE REPORT interno ao CH, para que o CH saiba quais são os
clusters com os quais esse cluster tem intersecção.
A mensagem LINK STATE REPORT também contém a lista de nodes ID vizinhos do
node para que o CH saiba a completa topologia para fazer optimizações topológicas. Se é
necessária uma mudança de topologia, então o CH manda uma mensagem de TOPOLOGY
UPDATE. Se um membro recebe uma mensagem de TOPOLOGY UPDATE em que o diferente
Protocolo 802.15.4 e Zigbee 20
pai node esta ligado a esse node, então muda o pai node como indicado na mensagem. E também
grava os node filhos e os nodes abaixo deste na árvore naquele ponto no tempo.
Se um membro node tem problemas e fica incapaz de comunicar, a tree route do cluster
deve ser reconfigurada. O CH sabe da presença de problemas pela periódica mensagem LINK
STATE REPORT. Quando o cluster head tem problemas, a distribuição da mensagem HELLO
para e todos os membros nodes sabem que perderam o CH. O cluster é então reconfigurado do
mesmo modo que o processo de formação do cluster.
Multiplos Cluster
Para formar uma rede, um Designated Device (DD) é necessário. O DD tem a
responsabilidade de atribuir um único cluster ID para cada cluster head. Este cluster ID
combinado com a node ID que cada CH atribui a cada node dentro do cluster forma um endereço
lógico e é usado para route packets. Outro papel do DD é calcular a route mais curta desde o
cluster ao DD e informá-lo a todos os nodes dentro da rede.
Quando o DD se junta à rede, ele actua como o CH do cluster 0 e começa a enviar
mensagens HELLO aos vizinhos. Se um CH recebeu esta mensagem, ele envia uma mensagem
CONNECTION REQUEST e junta-se ao cluster 0. Depois disso, o CH pede uma CID ao DD.
Neste caso, o CH é um node fronteiriço que tem dois endereços lógicos. Um é para membro do
cluster 0 e o outro é para o CH. Quando o CH recebe um novo CID, informa os seus node
members enviando uma mensagem HELLO.
Se o membro recebeu a HELLO message a partir do DD, adiciona CID 0 na sua lista de
vizinhos e reporta ao seu CH. O CH reportado selecciona o membro node como um node
fronteiriço ao seu cluster pai e envia uma mensagem NETWORK CONNECTION REQUEST ao
membro node para preparar uma ligação com o DD. O node fronteiriço pede uma ligação e
junta-se ao cluster 0 como seu node membro. Depois envia uma mensagem CID REQUEST ao
DD. Depois da chegada da mensagem CID RESPONSE, o node fronteiriço envia uma
mensagem NETWORK CONNECTION RESPONSE que contém um novo CID ao CH. Quando
o CH recebe o novo CID, informa os seus membros nodes através da mensagem HELLO.
Os clusters que não pertencem à fronteira do cluster 0 usam clusters intermediários para
conseguir um CID. Outra vez, ou o CH se transforma no node fronteiriço ao seu cluster pai, ou o
CH nomeia um node member como fronteira ao seu cluster pai. Estes processos estão descritos
nas fig. 25, 26, 27 e 28.
Protocolo 802.15.4 e Zigbee 21
Cada membro node do cluster tem de gravar o seu cluster pai, cluster filhos abaixo e os ID
dos nodes fronteiriços associados com ambos os clusters pais e os clusters filhos. O DD
(designated device) deverá armazenar a inteira estrutura árvore (tree) dos clusters.
Como nos nodes dos clusters, os CHs reportam a sua informação de estado de link ao DD.
O CH periodicamente envia uma mensagem NETWORK LINK STATE REPORT que contém
uma lista dos CID dos seus clusters vizinhos ao DD. Depois esta informação pode ser usada para
calcular uma rota optimizada e fazer um update periódico da topologia para a redundância de
rede. Da mesma maneira, o DD pode enviar uma mensagem TOPOLOGY UPDATE para
informar up-to-date da rota desde o DD até aos clusters.
Um backup BDD (Backup Designated Device) pode ser preparado para prevenir network
down time devido a problemas com o DD.
Comunicação inter-cluster, que é demonstrada na fig. 26, é realizada por routing. Os nodes
fronteiriços actuam como routers que ligam os clusters e repõe pacotes entre os clusters. Quando
um node fronteiriço recebe um pacote, examina o endereço de destino, e depois faz um forward
ao próximo node fronteiriço no cluster adjacente ou para o node destinatário dentro do cluster.
Só o DD pode mandar uma mensagem para todos os nodes dentro da sua network. A
mensagem é forward ao longo da tree route of clusters. O node fronteiriço deve fazer um
forward do pacote emitido desde o pai cluster para o filho cluster.
Ilustração 12, Atribuição de Cluster ID 3.
Protocolo 802.15.4 e Zigbee 22
Ilustração 13, Atribição de Cluster ID 4.
Ilustração 14, Rede multi cluster e nó de fronteira.
Protocolo 802.15.4 e Zigbee 23
3.5 Mecanismos de Acesso Zigbee
3.5.1 Mecanismo de acesso Zigbee
Existem dois tipos de acesso múltiplo mecanismos: beacon e non-beacon. Numa rede non-
beacon, é permitido a todos os nodes na rede transmitir a qualquer tempo se o canal está livre
(livre é aquele canal que não esta a ser usado). Numa rede beacon, os nodes são permitidos
transmitir em slots pré-definidos apenas. O coordenador periodicamente transmite uma
superframe identificada como uma beacon frame, e todos os nodes da rede são esperados
sincronizar-se com a frame. Cada node é atribuído um slot específico na superframe durante o
qual é permitido transmitir e receber data. Uma superframe também pode conter um slot comum
durante o qual todos os nodes competem para aceder ao canal.
3.5.2 Terminologia do protocolo Zigbee
Abaixo estão as descrições mais comuns do protocolo zigbee:
- Application Profiles: permitem ao utilizador da aplicação enviar comandos, pedir data e
processar comandos e pedidos de outros aparelhos na rede de uma maneira definida e
consistente. A Application Profile é simplesmente a descrição dos aparelhos na rede bem como a
interface e mensagens que são comunicadas entre os aparelhos. Existem dois tipos de profiles:
Public e Private profiles. Um profile público é um que é totalmente definido pela ZigBee
Alliance. Permite aos produtos que são construídos num particular Public profile, para sem
problemas, entre operar com os outros porque eles partilham a mesma mensagem e mecanismo
de comunicação.
Um profile Privado é definido por uma companhia individual ou por um grupo de
companhias, e é adequado para uso em sistemas fechados, onde a interoperabilidade não é
necessária. Com um private profile, a ênfase muda para a “co-existência” com outras redes
ZigBee em vez da interoperabilidade e partilha de um esquema comum de mensagem. A aliance
ZigBee, é todavia, responsável por emitir a identificação private profile que é usada dentro da
rede.
- Attributes: cada pedaço de data que pode ser passado entre os aparelhos, como o estado
de um switch (on/off) ou a leitura de intensidade da corrente (100 Ampere) é chamado um
atributo. Dentro de um profile, cada atributo é atribuído um único identificador – Attribute ID.
Protocolo 802.15.4 e Zigbee 24
- Clusters: um cluster é um grupo de atributos. A Cada cluster é atribuído um único
identificador – Cluster ID.
- Endpoints: um dado aparelho pode ser capaz de suportar um número de applets ou
aplication objects. Por exemplo um aparelho pode simultaneamente suportar um sistema de
segurança composto por câmaras e alarme, e operar um sistema de luzes separado. Cada um dos
application objects, neste exemplo o security application object bem como o light application
object, é identificado por um único identificador chamado Endpoint. Até 240 endpoints únicos
(application objects) podem ser definidos por aparelho.
O profile define os valores dos Attribute ID e os Cluster ID, bem como o formato de cada
atributo. Por exemplo, no Home Control Automation profile, o cluster OnOffDRC do Dimmer
Remote Control (DRC), do aparelho contem um atributo, OnOff, que deve ser atribuído (com um
valor de 8-bit, com o valor 0xFF significando “ON”, o valor 0x00 significa “Off” e o valor 0xF0
significa “toggle output” muda de estado a saída.
O profile também descreve quais os clusters obrigatórios e quais são opcionais para cada
aparelho. Em adição, o profile pode definir algum serviço optional ZiggBee protocol como
obrigatório.
Diferentes aparelhos comunicam via os endpoints e os clusters que suportam. A Figura 29
mostra graficamente como os vários termos se relacionam uns com os outros. A figura mostra
dois aparelhos do Home Control Automation profile. Cada aparelho tem apenas um endpoint. O
Switch Load Controler (e.x. uma luz) tem um input cluster nesse endpoint. O Switch Remote
Control (e.g. um interruptor) tem um output cluster e um input cluster no seu endpoint. O
interruptor pode também ser implementado de maneira a que os dois clusters estão em endpoints
separados.
Protocolo 802.15.4 e Zigbee 25
Ilustração 15, Atributos , cluster e endoits nos vários profiles.
3.5.3 Comunição via mensagem
Aparelhos na rede comunicam uns com os outros usando mensagens. Se um aparelho
conhece o endereço de rede de um outro aparelho com o qual deseja comunicar, envia uma
mensagem usando o endereço de destino do aparelho de rede. Este tipo de comunicação por
mensagem é chamado Direct Addressing. Enquanto Direct Addressing é de simples uso e
compreensão, vem com algum overhead. A Cada aparelho é requerido primeiro descobrir e
depois manter um registo de endereços dos aparelhos de destino de interesse.
Quando um aparelho de origem deseja comunicar com um aparelho com o qual está ligado
(bind), simplesmente cria uma mensagem sem especificar um endereço de destino. Interno ao
Stack e transparente á aplicação, a Binding table é procurada, e se um correspondente é
encontrado que contém um endereço de destino e um endpoint, então o endereço de destino é
extraído da tabela, e anexado á mensagem, antes que esta seja transmitida. Esta forma de
comunicação é chamada de Indirect Addressing.
O protocolo ZigBee oferece um segundo meio de mandar mensagens via um mecanismo
chamado de binding. Quando um aparelho suporta binding, mantém uma binding table, onde
cada entrada de tabela contém o endereço de destino e endpoint de destino do outro aparelho ao
Protocolo 802.15.4 e Zigbee 26
qual o aparelho de origem está ligado. Figura 30 é uma representação do tipo de informação
armazenado na binding table.
Figura 1 – Exemplo de uma entrada na tabela de ligação.
Formato de mensagem do protocolo ZigBee
Uma mensagem de protocolo ZigBee consiste em até 127 bytes nos seguintes campos:
- MAC Header – o MAC Header contem o MAC frame campos de controlo, Beacon
Sequence Number (BSN) e informação de endereço da mensagem como está actualmente sendo
transferida. De Notar que pode não reflectir a actual origem ou o destino final da mensagem se a
mensagem esta sendo encaminhada (ROUTED). A geração e uso deste header, são transparentes
ao código da aplicação.
- Network Layer (NWK) Header – este header contem, ao mesmo tempo que outra
informação, a origem actual e o destino final da mensagem. A geração e o uso deste header são
transparentes ao código de aplicação.
- Application Support Sub-Layer (APS) Header – este header contem o profile ID,
Cluster ID e endpoint de destino da mensagem corrente. A geração e o uso deste header são
transparentes ao código de aplicação.
- APS Payload – este campo contém o ZigBee protocol frame para o processo da
aplicação. O código da aplicação é responsável por preencher o APS Payload.
ZigBee Protocol Frame Format
Cada especificação de profile é responsável por definir o formato de frame de cada
mensagem que esse profile suporta.
Addressing
Cada node numa rede ZigBee protocol terá dois endereços: um de 64-bit endereço MAC, e
um de 16-bit endereço de rede. Também existem dois tipos de endereçamento de mensagem.
Protocolo 802.15.4 e Zigbee 27
IEEE Extended Unique Identifiers – EUI-64
Cada aparelho que comunica usando o ZigBee protocol tem de ter um único 64-bit MAC
address. Este endereço é constituído por um 24-bit Organizational Unique Identifier (OUI) e
mais 40 bits designados pelo produtor. OUIs devem ser comprados ao IEEE para assegurar
exclusividade global. Pode obter o seu próprio número OUI através do endereço Web:
https://standards.ieee.org/regauth/oui/forms/OUT-form.shtml, se uma organização já tem
um OUI para Ethernet, o mesmo OUI pode ser usado para o ZigBee.
Network Addresses
Aparelhos usam o seu endereço estendido (64 bit) para comunicar enquanto eles estão no
processo de se juntar a uma rede. Depois de um aparelho se juntar com sucesso uma rede
ZigBee, é atribuído um endereço de 16 bit de rede pelo seu PAI, o qual depois é usado para
comunicar com outros aparelhos na rede.
Unicast
Numa mensagem unicast, o endereço do node de destino é providenciado na MAC layer
header do pacote. Apenas o aparelho que tem esse endereço recebe a mensagem. Todos os outros
aparelhos irão filtrar mensagens que não são intencionadas para eles.
Broadcast
Num broadcast packet, o endereço de destino da MAC layer é 0xFFFF. Qualquer
transceiver do qual o Receiver está apto ira receber a mensagem. Esta forma de endereçar é
usada aquando se junta a uma rede, descobrindo ROUTERS na rede e realizando outras ZigBee
protocol discovery functions. O protocolo ZigBee implementa um “passive-acknowledge” dos
pacotes broadcast. O que se quer dizer por passive-acknowledge é quando um aparelho origina
ou volta a transmitir um broadcast packet, irá ouvir todos os seus vizinhos conhecidos
retransmitir esse pacote. Se todos os vizinhos não replicarem a mensagem dentro de
nwkPassiveAckTimeout segundos, irá retransmitir o pacote até ouvir as retransmissões de todos
os seus vizinhos conhecidos ou o pacote times out depois de nwkNetworkBroadcastDeliveryTime
segundos.
Multicast
Uma aplicação pode escolher designar uma colecção de aparelhos e endpoints específicos a
esses aparelhos, para formar um único grupo. Depois, essa colecção de aparelhos pode ser
endereçada simultaneamente usando um único grupo endereço ou Group ID. Um exemplo de
Protocolo 802.15.4 e Zigbee 28
multicasting pode ser agrupar todas a luzes num quarto (de dormir por exemplo) num único
multicast group. Depois enviando uma única mensagem “on” de um interruptor pode ser usada
para ligar todas as luzes ao mesmo tempo. Multicasting pode ser empregado como uma maneira
efectiva de reduzir o tráfego numa dada rede.
Multicasting é uma nova característica do ZigBee-2006 protocol stack. É uma variante de
broadcast Addressing, onde a Group ID é usada como endereço de destino em vez do endereço
0xFFFF ao nível da aplicação.
Na actual implementação do ZigBee-2006 protocol stack, versão v2.0-2.6, até 8 grupos por
aparelho podem ser suportados. Os Utilizadores têm a opção de mudar esta limitação no tempo
de compilação enquanto estão a construir o seu código.
É importante notar que multicasting pode ser combinado com indirect addressing para
providenciar uma ligação com o grupo. Neste caso o endereço de destino na bind table é
realmente o endereço do Group ID.
Quando um aparelho suporta multicasting, mantém uma Group table onde cada entrada de
tabela conte o Group ID e uma lista de endpoints destinatários para os quais as mensagens
recebidas são direccionadas quando correspondem ao Group ID. Figura 31 é uma representação
do tipo de informação armazenada numa Group table.
Ilustração 16, Exemplo de uma entrada na tabela de grupo.
Interno ao Stack e transparente á aplicação, a Group table é procurada aquando uma
mensagem multicast é recebida, e se um correspondente é encontrado que contenha a Group ID,
então a mensagem é direccionada para todas as aplicações endpoints encontradas no Group table
entry.
Data Transfer Mechanism
Numa non beacon enabled network, quando um aparelho quer mandar data frame,
simplesmente espera para o canal se tornar idle (desimpedido). Ao detectar uma condição canal
IDLE, o aparelho pode transmitir a frame.
Se o aparelho de destino é um FFD, então o seu transceiver está sempre ON, e outros
aparelhos podem transmitir para ele a qualquer altura. Esta capacidade permite redes mesh
Protocolo 802.15.4 e Zigbee 29
networking. No entanto, se o aparelho de destino é um RFD, pode desligar o transceiver quando
este está idle para conservar energia. O RFD não conseguirá receber mensagens enquanto está
neste estado. Esta condição é resolvida com a necessidade que todas as mensagens para e desde o
RFD irem através dos PAIS do RFD. Quando o RFD liga o seu transceiver, pede mensagens do
seu PAI. Se o PAI armazenou na memória uma mensagem para o RFD, ele irá reenviar essa
mensagem para a RFD filho. Isto permite ao RFD Filho conservar energia, mas necessita que o
PAI do RFD tenha RAM suficiente para armazenar mensagens para todos os seus Filhos. Se o
RFD filho não pede mensagens dentro de um certo período de tempo
(macTransactionPersistenceTime), a mensagem irá time out, e o FFD PAI irá ver-se livre da
mensagem.
Routing
A pilha ZigBee tem a habilidade de reencaminhar mensagens. O Routing é feito
automaticamente pelo Stack sem qualquer intervenção da end application.O Routing permite
aumentar o alcance da rede por permitir end devices para além da distância rádio do coordenador
ZigBee para se ligar a rede através do ROUTER ZigBee.
O tipo de routing desejado para uma mensagem é indicado quando a mensagem é enviada.
Existem 3 opções routing disponíveis:
SUPPRESS – se existe uma “mesh route”, a mensagem é routed ao longo dessa route.
Senão, a mensagem é routed ao longo da árvore.
ENABLE – se é descoberta uma “mesh route”, a mensagem é routed ao longo dessa route.
Se uma mesh route não foi encontrada, o router pode iniciar o route discovery. Quando a
descoberta é completa, a mensagem será enviada ao longo da route calculada. Se o router não
possui route capacity, irá encaminhar a mensagem ao longo da árvore.
FORCE – se o router possui route capacity, irá iniciar route discovery, mesmo que uma
route já exista. Quando a descoberta é completa, a mensagem será enviada ao longo da route
calculada. Se o router não possui route capacity, irá enviar a mensagem ao longo da árvore. Esta
opção deverá ser usada de leve, pois gera uma grande quantidade de tráfego de rede. É usada
primariamente para reparar uma route quebrada.
Formação e união a rede.
Formação da rede.
Protocolo 802.15.4 e Zigbee 30
Uma rede ZigBee nova é primariamente estabelecida por um coordenador ZigBee. Ao
começar, o coordenador ZigBee procura por outros coordenadores ZigBee que operem nos
canais permitidos. Baseado na energia do canal e no número de redes encontradas em cada canal
permitido, estabelece a sua própria rede e escolhe um exclusivo 16-bit Personal Area Network
(PAN) ID. Quando a nova rede estiver estabelecida, Routers ZigBee e end devices estão
autorizados a juntarem-se á rede.
Uma vez formada a rede, é possível que devido a mudanças físicas, mais do que uma rede
possam sobrepor-se e um conflito PAN ID resultar dessa proximidade. Nessa situação, um
coordenador pode iniciar uma procedimento de resolução de conflito PAN ID e um dos
coordenadores iria mudar o seu PAN ID e/ou canal. O coordenador afectado iria instruir todos os
seus aparelhos filhos para realizar as mudanças necessárias.
Network Association
A relação pai-filho é formada quando um aparelho que já é membro da rede permite a um
novo aparelho juntar-se. Neste caso, o novo aparelho fica a criança, e o velho primeiro aparelho
fica o pai. Uma maneira de o novo aparelho se juntar ao primeiro aparelho é usando o
procedimento de associação ZigBee.
O aparelho filho inicia um procedimento de associação ao realizar um scan activo dos
seus canais permitidos. A quantidade de tempo que um aparelho passa a determinar a energia do
canal e redes disponíveis em cada canal é especificado pelo parâmetro ScanDuration. Para a
frequência de banda 2.4 GHz, o tempo de scan em segundos é calculado pela equação:
EQUAÇAO 1
0.01536 * (2ScanDuration + 1)
Para o Stack, o ScanDuration pode ser entre 0 e 14, dando um scan time de 0.031 segundos
a 4.2 os minutos por canal. Se o ScanDuration é de 8 e todos os 16 canais estão especificados, o
aparelho demora mais de um minuto a realizar cada scan necessário. ZigBee routers e end
devices realizam um scan para determinar redes disponíveis, mas os coordenadores ZigBee
realizam dois scans, um para amostragem da energia do canal e um para determinar redes
existentes. A duração específica do scan precisa de ponderar o tempo necessário para realizar
adequadamente cada scan nos canais específicos com a quantidade de tempo alocada para o
sistema start-up.
Protocolo 802.15.4 e Zigbee 31
Pais potenciais que estejam à escuta no canal em que é feito um scan pelo filho, respondem
com uma beacon frame. Beacon frames contêm, entre outra informação, dados que indicam se o
aparelho que responde está a aceitar associações de aparelhos adicionais. Uma colecção da
informação da beacon frame que é recebida pelo novo aparelho é primeiro armazenada na sua
Neighbor table (tabela de vizinhança). No final do scanning process, as entradas na Neighbor
table são examinadas e o “melhor” potencial pai é seleccionado. O novo aparelho transmite então
um pedido de junção ao potencial pai. Se uma confirmação de sucesso da junção (adição) é
recebida do pai potencial, o novo aparelho fica junto/associado com o primeiro aparelho numa
relação pai-filho. O aparelho pai é responsável por atribuir ao filho o endereço de rede exclusivo
de 16-bit.A Informação relevante como o endereço de rede do filho, o endereço de rede do pai, a
profundidade de rede ao qual o aparelho se juntou, são armazenados em ambos o pai e o filho
nonvolatile Neighbor Table.
Network Orphaning
Aparelhos ZigBee armazenam informação acerca de outros nodes na rede, incluindo nodes
pais e filhos, numa área de memória não volátil chamada Neighbor Table. Ao ligar-se, se o
aparelho filho determina através da sua Neighbor table que já foi uma vez parte da rede, pode
executar um procedimento de notificação Orphaning para localizar a associação prévia rede.
Aparelhos que recebem a notificação Orphaning vão verificar as suas Neighbor tables e ver se
esse aparelho é um dos seus filhos. Se sim, o aparelho pai irá informar o aparelho filho do seu
lugar na rede. Se a notificação órfã falha, ou o filho não tem nenhuma entrada pai na sua
Neighbor table, então irá tentar juntar-se á rede como um novo aparelho. Irá gerar uma lista de
pais potenciais e tentar juntar-se a uma rede existente á profundidade óptima.
Network Rejoin
Quando um end device perde contacto de comunicação com os seus pais, ou é pedido que
deixe a rede com o seu “rejoin bit” seleccionado, irá automaticamente iniciar um procedimento
rejoin. Diferente do procedimento orphaning, onde o aparelho filho tenta reunir-se com os seus
antigos pais, o procedimento de rejoin (re-união) começa com um scan activo e um novo
potencial pai é escolhido da lista de beacons que o filho recebe. Depois de o filho escolher um
pai potencial, um pedido de network level rejoin é enviado para o potencial pai. Depois de
receber a resposta de um rejoin bem sucedido do pai, o aparelho filho junta-se de novo á rede
com um novo pai e um novo endereço de rede. É importante notar que esta é uma maneira
efectiva de reposicionar um aparelho na rede simplesmente pedindo-lhe para sair e depois
executar um netwhork rejoin. Adicionalmente, o processo de rejoin é iniciado e levado a cabo de
Protocolo 802.15.4 e Zigbee 32
forma transparente á aplicação. Este é uma maneira efectiva dos end devices voltarem á rede, se
se perde comunicação com o pai por qualquer razão.
Os Routers não iniciam automaticamente rejoins porque não têm uma maneira directa de
determinar que os seus pais não estão na rede, diferente dos RFD devices, que executam o
procedimento de polling aos seus pais. A intervenção na aplicação é necessária para ter um
router a executar um network rejoin à rede.
Materiais e Métodos 33
4 Materiais e Métodos
Um dos equipamentos usados, foi o kit PICDEM™ Z 2.4 GHz Demonstration Kit da
microchip constituído por dois MRF24J40 transceiver e duas placas de desenvolvimento com os
micro controladores PIC18LF4620. Este kit é utilizado no desenvolvimento de aplicações que
executem sobre o protocolo IEEE 802.15.4, está prevista uma interface de 6 pinos para
programação com o programador e depurador “pickit 3” da microchip e desenvolvimento com o
compilador “c” CC18 que corre sobre o MPLAB. Existe uma pilha de P2p e zigbee que pode ser
descarregada da microchip e configurada com alguns parâmetros com ajuda do configurador da
aplicação Zena.
Ilustração 17, Placas de desenvolvimento Zigbee da Microchip.
Materiais e Métodos 34
As vantagens do Kit de desenvolvimento são:
Pilha de software zigbee para RFD (dispositivo de funções reduzidas), FFD (dispositivo
de múltiplas funções) e coordenador.
Micro controlador PIC18LF4620 com tecnologia nano Watt, 64Kb de flash RAM e com
periféricos robustos e com fiabilidade.
Trasnceiver de rede MRF24J40 Rf com antena incluída para maior flexibilidade
O analisador de redes sem fios “Zena”, este analisador inclui o configurador.
Interface para programador e depurador MPLAB ICD 2
RS-232 interface
Regulador de tensão de 9V DC to 3.3V.
Sensor de temperatura (Microchip TC77).
Outros dispositivos foram testados o “XBee”, com uma fácil configuração por porta serie
e uma aplicação de configuração proprietária da maxtrim, contudo estes dispositivos usam um
espaçamento de 2mm entre pinos que difere do padrão internacional do DIP que é de 2,54mm
obrigando a adaptadores específicos.
Ilustração 18, Módulos Zigbee a 2.4 Ghz da MaxStream.
Materiais e Métodos 35
Os aparelhos XBee & XBee-PRO DigiMesh 2.4 embedded RF, utilizam rede ponto a
ponto “DigiMesh” que usa a frequência de 2.4 GHz que é global. Este inovador protocolo de
redes de malha oferece, adição de utilizadores, estabilidade de rede com auto reparação, auto
descoberta e trabalho sobre uma rede com múltiplos dispositivos com suporte para routers com a
função de hibernação para uma maior duração da bateria.
4.1 Aplicação downloader para Bootloader
4.1.1 Zigbee bootloader multiaddres
Quando é necessário actualizar o firmware dos sensores ou actuadores, a aplicação tem
como objectivo permitir numa rede de aparelhos com os módulos zigbee, actualizar o firmware
de cada dispositivo por wireless, ou fazer o update a um dispositivo móvel.
A aplicação pode ser usada para fazer o update dos vários receptores, no caso da domótica,
dos vários sensores, detectores, actuadores, variadores de luminosidade, onde o update do
firmware deve ser efectuado com vista a melhorias no sistema.
No mapeamento da memória é possível verificar que quando é efectuado o reset ao micro
ele começa no endereço 0x0000. No seguimento está os vetores de interrupção desde ao da porta
serie à interrupção dos timers e conversão analógica digital. O programa do utilizador vem de
seguida e corresponde à função main () do código em “C”. Quando é usado o bootloader é
alterado o endereço 0x0000, esta alteração obriga o microntrolador a ir para o fim da memória
que é onde se encontra o loader. Esta espera cerca de dois segundos pela recepção do simbolo
0x07 pela porta série, caso não receba volta para a posição User Start.
O loader deve ser capaz de configurar a porta série e o microcontrolador e gerir o protocolo
que permite o envio da nova aplicação User_Main. O Loader ocupa menos de 1kbyte e é
colocado no fim da memória recorrendo ao programador Pik-Kitt3.
Quando é enviado as frames HEX, o interpretador verifica o byte de Cheksum e se estiver
correto escreve na memória os dados correspondentes. No caso é enviado 8 Bytes de dados de
cada vez. Se O endereço for o Start ele é redirecionado para a posição de memória logo abaixo
do Loader, ficando este o novo start.
A gravação na memória flash do microcontrolador quando efectuada com sucesso, é
enviado um DATA_OK, e continua a gravação até que receba um DONE, finalizando o loader e
saltando para o novo Start.
Materiais e Métodos 36
Ilustração 19, mapeamento da memória, com e sem boot loader.
Formato Intel hex
O formato hex dos ficheiros é vulgarmente usado para guardar os valores de eprom ou
memória, cada byte de memória é representado em formato hexadecimal por dois bytes ASCII
de “0” até “F”, é incluído um start byte normalmente o caracter “:”, o número de bytes da linha
entre, o endereço de 16 bits, permite endereçar 65535 posições e um byte de soma de
verificação.
O ficheiro intel hex contém em cada linha valores hexadécimais contendo uma sequência
de dados. Cada linha do ficheiro é constituído por:
Start code, um character normalmente é usado os “: ”.
Byte count, dois dígitos hexadecimais que correspondem ao número de bytes de dados
normalmente é usado 0x10, dezasseis bytes.
Address, quatro dígitos hexadecimais que corresponde à posição de memória onde vão ser
gravados os dados é limitado a 64 Kbytes.
Materiais e Métodos 37
Record type, dois dígitos, 00 até 05, definindo o tipo de dados.
Data, sequência de bytes, normalmente 16.
Checksum, dois dígitos de verificação.
Por exemplo na sequência, : 0300300002337A1E03 + 00 + 30 + 00 + 02 + 33 + 7A = E2,
o complemento para dois é 1E.
Existem seis tipos de dados.
00, data record, contêm dados e 16-bit de endereço no formato descrito em cima.
01, End Of File record, Informação de fim de ficheiro.
02, Extended Segment Address Record, quando os 16 bits de endereço não são suficientes
03, Start Segment Address Record. Para Cpu 80x86 especifica os registos CS: IP.
4.2 Aplicação em VB.net, para actualizar o firmware.
O programa foi desenvolvido em Visualstudio2005.Net, com recurso aos timers, e a porta
série, ou conversor usb/série foi adicionado um terminal série, para visualização dos dados
recebidos e permitir enviar comandos.
O uso na retransmissão de tramas sem sucesso garante que se consiga fazer o download
completo, permite escolher o número de repetições, com um tempo entre elas de 2^N*100ms, o
que significa para a 3ª repetição um tempo de 800ms.
Pode-se escolher o endereço de destino a programar este deve ser um número
Hexadécimal de 16 bits. Antes de iniciar a programação do ficheiro hex, é pedido ao micro
controlador para entrar no modo bootloader, enviando o byte 0xEA, e recebendo a resposta
0xEB, sabemos que entrou no modo bootloader. Antes é efectuado um reset ao micro
controlador com a função da camada de aplicação Zigbee ao cluster id switch remote, com os
atributos ON/OFF, e quando recebe o carácter 0xEA no início do boot, ele envia o 0xEB.
A cada linha do ficheiro hex, o programa envia uma cadeia de texto com o seguinte
formato: High Address, Low Address, Tamanho, Checksum, dados High, dados Low.
High Address, os 8 bits mais significativos de endereço de 16 bits.
Materiais e Métodos 38
Low Address, os 8 bits menos significativos de endereço de 16 bits.
Tamanho, o número de bytes a serem enviados.
Cheksum, os 8 bits menos significativos da soma dos vários bytes enviados.
Dados High, no micro controladores que foram utilizados da Microchip as instruções tem
12 bits, os dados High são os 4 bits mais significativos.
Dados low, 8 bits de dados menos significativos.
Ilustração 20, Aplicação para download, janela principal.
4.2.1 COMANDOS USADOS PARA PROGRAMAR O FIRMWARE
O envio das frames Hex é efetuado da porta serie do Pc até ao microcontrolador. O envio
obedece ao seguinte protocolo, para que seja possível o envio e a gravação na memória flash do
microcontrolador. Os dados são enviados com um comando de WRITE e ADDRESS isto
permite ao microcontrolador saber qual o endereço flash a ser gravado. Se a gravação foi
efectuada com sucesso o microcontrolador responde com um WOK seguido de um DATAOK.
WRITE 0xE3
<WRITE> <ADH><ADL><TAMANHO><CHKSUM><BYTEH><BYTEL>
Permite escrever dados na memória flash.
Materiais e Métodos 39
WOK 0XE4
Se o endereço é correcto envia WOK
WBAD 0xE5
Se o endereço não é correcto
DATOK 0xE7
Se os dados foram gravados com sucesso na memória flash
DATBAD 0xE8
Se os dados não foram gravados com sucesso
IDENT 0XEA
Pede para ir para o programa de bootloader quando se faz o reset ao micro controlador
IDACK 0XEB
Acknowledge do pedido do bootloader
DONE 0XED
Finaliza o download, o micro faz o reset e vai para o Endereço USER_MAIN
USER_MAIN, é o endereço que é atribuído a função main, quando compilado
Pelo utilizador
4.2.2 Fluxograma de envio do firmware.
Primeiro envia a instrução IDENT, e espera até receber do micro a instrução IDACK
Entretanto foi enviado a instrução de reset ao micro, ao arrancar o micro vai para
O endereço 0x1f00, e durante 5 segundos espera receber IDENT, e envia o IDACK.
Ao ser actuado o botão DOWLOADHEX, vai ser lido o ficheiro HEX e vai ser
Carregado o valor TOTALLINHAS a serem enviadas.
Lê a 1ª linha, verifica se é valido, recolhe o ADDRESS, TAMANHO, DATA…e calcula
A CHECKSUM. Envia a linha com a instrução WRITE seguido do ADDRESS,
TAMANHO, CHEKSUM E DATA.
Espera receber DATAOK e WOK, se sim lê a próxima linha enquanto for válida.
Materiais e Métodos 40
Se não retransmite a FRAME e espera o tempo de 2^N*100ms até ao máximo número de
tentativas, se ultrapassou o número de tentativas dá ERRO DE TRANSMIÇÃO.
Se conseguiu enviar todas as linhas envia DONE ao micro que faz um JUMP para o
USERMAIN.
Ilustração 21, Fluxograma de funcionamento da aplicação bootloader.
Materiais e Métodos 41
Ilustração 22, Fluxograma de seleção de endereço.
4.2.3 Circuito electrónico
O esquema é constituído por regulador de tensão de 3v, porto I2C do micro é ligado
diretamente ao módulo de rádio mrf24j40mb. O módulo de rádio trabalha a 2.4 Ghz e
implementa o protocolo 802.15.4. É constituído por componentes em SMD com cristal,
regulador de voltagem interno, amplificador de potência, amplificador de baixo ruido e antena
integrada com desenho no PCB.
O módulo mrf24j40 é compatível com a pilha zigbee da microchip. Implementa a camada
física e de acesso ao meio.
Materiais e Métodos 42
O circuito eletrónico mostra a ligação com o microcontrolador pic18f2620. A interface é
efectuada por 4 pinos recorrendo a interface serie SPI, interrupt, Wake, Reset, e alimentação.
Ilustração 23, esquema de micro controlador com interface ao módulo de 2.4 Ghz.
O pino Reset permite ao micro efetuar um reset ao módulo, o pino Wake permite “acordar”
o módulo quando está no modo Sleep garantindo um baixo consumo. O pino INT é activado
quando o módulo recebe dados ou comandos alertando o microcontrolador para processar as
instruções de recepção do módulo. O pino SDI como o nome indica é serial data input e permite
enviar dados ao módulo, e o SDO permite receber dados do módulo. O pino SCK marca a
frequência de transferência de dados entre o micro e o módulo rádio.
No circuito proposto é usada uma ficha de programação ICP (programação no circuito
final). Depois de soldado o microcontrolador é programado com o programador PIc-KITT 3,
com o hex file correspondente ao firmaware do bootloader.
Foi usado uma pilha de lítio de 3.7v, a sua tensão pode variar entre 3v e 4.2v é conveniente
usar um regulador de tensão com bom rendimento para aumentar o tempo da bateria.
Materiais e Métodos 43
A ligação do micro controlador ao adaptador de rede de 2.4 Ghz 802.15.4 é por I2C, o
micro controlador usado tem tecnologia nano Watt o que permite quando no modo de hibernação
uma duração longa quando alimentado por de pilha. É possível desenhar o circuito
correspondente a aplicação específica, caso seja um variador de intensidade de iluminação pode
ser usado um circuito de potência com triac e detecção de passagem por 0v.
No desenho da placa de circuito impresso foi dado especial importância ao tamanho da
placa por isso os componentes utilizados são SMD (componentes de montagem em superfície).
Ilustração 24, desenho da placa de circuito impresso com componentes SMD.
4.3 Segurança dos dados enviados
No envio das frames de dados, é codificado com AES 128, aqui na figura 25 está
representado
O envio de uma frame encriptada com a chave simétrica AES128.
Materiais e Métodos 44
Ilustração 25, Frame encriptada com chave simétrica AES128.
Foi usado o programa ZENA da microchip wireless network analyzer software, Para
Identificar as FRAMES enviadas, ao ser enviado um byte de dados exemplo o carácter “a”,
Verificou-se que foi enviado 4 frames, pois não teve o ACK, com um tamanho de 33 bytes cada
uma, quando os dados foram encriptados com o AES 128 bits.
Em Criptografia, o Advanced Encryption Standard (AES, ou Padrão de Criptografia
Avançada), é uma cifra adoptada como a referência de criptografia pelo governo dos Estados
Unidos. É usado por grande parte dos programadores e analisada em pormenor. O AES foi
comunicado pelo NIST (Instituto Nacional de Padrões e Tecnologia dos EUA) em 26 de
Novembro de 2001, depois de 5 anos de um processo de padronização. Tornou-se um padrão
efectivo em 26 de Maio de 2002. Em 2010, o AES é um dos algoritmos mais conhecidos e
utilizados para criptografia de chave simétrica.
Materiais e Métodos 45
Ilustração 26, Chave Simetrica.
4.3.1 Encriptação desabilitada
Comparativamente foi enviado as mesmas frames de dados agora com o AES desabilitado
Como foi verificado o número de bytes foi reduzido pois quando usado o AES 128 o
número mínimo de bits enviado é de 128, ou 16 bytes, mesmo quando é enviado 1 byte, o qual
corresponde ao comprimento da chave de encriptação.
Ilustração 27, Quadro com envio de dados sem encriptação AES.
Materiais e Métodos 46
4.3.2 Tempo usado no envio de dados.
Quando Não usado o AES 128, verificamos que são enviadas 4 frames de 14 bytes cada
quando é enviado a letra “a”. Podemos identificar o dado enviado no campo “INVALID DATA”
com o valor 0x61, que corresponde à letra “a” na tabela ASCII.
Verificamos que em média é enviada uma frame a cada 2500us.
Ilustração 28, Download de código para programação, com aplicação bootloader.
Quando é enviado uma FRAME não encriptada com um tamanho de 16 bytes de dados,
correspondente a uma linha do ficheiro Hex, verificamos que o tamanho da frame é de 34 Bytes.
Com um tempo entre frames de 2700us.
Analisando os dados quando se faz o download do hex file.
Materiais e Métodos 47
Ilustração 29, Envio de Start byte “0xEA”.
Neste caso foram configurados os módulos com os seguintes parâmetros:
PANID, personal área network identification, com o valor 0x1222.
DEST Address, 0x2000 o endereço do zigbee RFD, sensor com bootloader.
Source Address, 0x0000 o endereço do zigbee que envia o ficheiro hex do pc.
Verificamos que foram enviados várias frames com a string “ EA” até receber a string “
EB”
Que corresponde à tentativa de download do HEX file.
Verificamos que existem várias FRAMES de ACK.
Materiais e Métodos 48
Ilustração 30,Frames de ACK. e confirmação.
Vista dos módulos capturados pelo programa ZENA
Ilustração 31,Vista dos módulos capturados pelo programa ZENA.
Materiais e Métodos 49
4.3.3 Pedido de associação.
Seguidamente foi analisado um pedido de associação, entre um módulo filho e o
coordenador da rede zigbee, Beacom request, pedido de associação quando um módulo zigbee
inicia, depois do reset, é correspondido pelo coordenador com um associação request, e
association Success por parte do coordenador.
Ilustração 32, pedido de associação ao coordenador.
4.3.4 Descoberta de dispositivos
Quando é pedido ao coordenador a descoberta de nós, com o comando ATND, node
discovery, o coordenador como resposta ao comando envia uma lista dos aparelhos que estão na
rede e que estão identificados por este.
A frame contém os caracteres correspondentes as palavra “ROUTE2010” antes definida
pelo comando, ATNI “node identifier “ no aparelho que foi detectado. O MAC Address do
aparelho é também devolvido.
Materiais e Métodos 50
Ilustração 33, Resposta do coordenador, quando da descoberta do node route2010.
4.3.5 Envio de código em formato HEX file com chave de rede AES 128
No exemplo seguinte foi enviado da aplicação desenvolvida, um Hex file para reprogramar
o micro controlador e efectuar o download do firmware. Os aparelhos contêm a chave de rede
especificada em seguida,
KEY AES 128 bits “AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF”
Materiais e Métodos 51
Ilustração 34, download de hex file com chave de rede AES 128.
Quando os dados são enviados encriptados com AES128, o ACK dado pelo uP, demora
cerca de 2700uS, quando enviados 16bytes, ficando a máxima velocidade de 16*8/2*1000 bits /s
= 64000 baud.
Segundo as características do Zigbee, os dados são enviados a 250kbs, mas para a nossa
aplicação a velocidade é menor pois é necessário por os dados dentro da frame que o protocolo
zigbee e 802.15.4 obrigam. Sendo o over head mais significativo quanto menor for os dados da
aplicação enviados, neste caso foi usado 16 bytes de dados da aplicação por cada frame e o
protocolo zigbee pode conter 127 bytes no máximo no tamanho da frame ficando a possibilidade
do uso de maior número de bytes de dados por cada frame, o valor de 16 Bytes é usado porque o
formato HEX file contêm 16 Bytes por linha, mas não é rígido, pois é possível ler várias linhas e
enviar de seguida, contudo quanto maior a frame maior a possibilidade de erros de transmissão.
Discussão dos Resultados e Conclusões 52
5 Discussão dos Resultados e Conclusões
Analisando os resultados obtidos verifica-se que é possível e praticável usar a programação
do firmware da camada de aplicação usando o protocolo 802.15.4 para transferência de dados
com verificação de erros. Com esta melhoria implementada numa rede sem fios de actuadores e
sensores é possível criar, de forma dinâmica, as várias funções dos actuadores e sensores.
O trabalho proposto e desenvolvido nesta tese verificou que é possível reprogramar as
funções dos vários objectos zigbee.
Com este projecto pretendeu-se realizar a programação sem fios da camada de aplicação da
pilha zigbee, tendo os objectivos sido alcançados com sucesso.
A realização deste projecto permitiu também uma familiarização com outras tecnologias e
aplicações, como o analisador de rede 2.4Ghz.
Neste trabalho foi usada a reprogramação, usando dois micros controladores por aparelho
na rede. Seria interessante, num trabalho futuro, usar apenas um micro controlador, usando uma
parte da memória e reprogramando apenas essa parte de memória.
Adicionalmente, o sistema desenvolvido poderia ser testado com um número maior de aparelhos,
por exemplo numa habitação, e com funções extra por cada aparelho. Deste modo, poder-se-ia
estudar se cada aparelho era capaz de verificar se estava a usar o último firmware e de se
actualizar automaticamente por via wireless. Seria ainda interessante verificar se o aparelho
efectuava as actualizações com a função que lhe fosse designada ou outra, se analisando o seu
histórico de actividades se chegasse à conclusão que era mais útil para a comunidade de
aparelhos possuir uma função diferente.
A realização deste projecto de mestrado permitiu-me adquirir competências na área de
comunicações e redes sem fios, em particular 802.15.4 e zigbee.
Referências 53
Referências
[1] The ZigBee Alliance [Consulta em 9 Maio 2011]. Disponivel em: http://www.zigbee.org/
[2] [Consulta em 9 Maio 2011]. Disponivel em: http://www.microchip.com
[3] IEEE Standard, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), IEEE, April 2003
[Consulta em 12 Maio 2011]. Disponivel em: http://www7.informatik.uni-
erlangen.de/~fengchen/omnet/802154/802.15.4-2006.pdf
[4] ZigBee Document 08006r03, ZigBee-2007 Layer PICS and Stack Profiles,
Revision 03, June 2008 [Consulta em 19 Maio 2011]. Disponivel em:
http://www.ee.oulu.fi/~kk/dtsp/tutoriaalit/ZigBeeSpecification2.pdf
[5] ZIGBEE HOME AUTOMATION PUBLIC APPLICATION PROFILE,
Home Automation Profile Specification ZigBee Profile: 0x0104 Revisions 25
Version 1.0
[6] Microchip ZigBee-2006 Residential Stack Protocol [Consulta em 20 Maio 2011]. Disponivel em:
http://www.eetasia.com/ART_8800551784_499488_AN_dfd37dec.HTM
[7] Redes sem fio no Mundo em Desenvolvimento. Hacker Friendly LLC. Outubro 2008. [Consulta em
2 Junho 2011]. Disponivel em: http://wndw.net/pdf/wndw-pt/wndw-pt-ebook.pdf
[8] Gislason, Drew - ZigBee Wireless Networking. Newnes. 2008
[9] Carlos M. Cordeiro, Hrishikesh Gossain, Roy L. Ashok and Dharma P. Agrawal. The Last Mile:
Wireless Technologies for Broadband and Home Networks. Center for Distributed and Mobile
Computing, ECECS, University of Cincinnati: Cincinnati, OH 45221-0030-USA. [Consulta em 10 Junho
2011]. Disponivel em: www.cs.uc.edu/~cordeicm/course/wirelessbroadband-text.pdf
[10] Andrea Goldsmith - Wireless Communications. Cambridge University. 2005 [[Consulta em 15
Junho 2011]. Disponivel em: http://wsl.stanford.edu/~andrea/Wireless/SampleChapters.pdf
[11] Vadym Samosuyev - Bluetooth Low Energy Compared to ZigBee and Bluetooth Classic. May
2010 [Consulta em 15 Junho 2011]. Disponivel em:
https://publications.theseus.fi/bitstream/handle/10024/15812/FinalThesis_Samosuyev.pdf
[12] IEEE 802.15 WPAN Task Group 4 (TG4) [consulta em 15 Junho 2011]. Disponivel em:
http://www.ieee802.org/15/pub/TG4.html
Acrónimos 54
Acronyms and abbreviations 802.15.4 e Zigbee
ACL access control list
AES advanced encryption standard
ASN.1 Abstract Syntax Notation Number 1
AWGN additive white Gaussian noise
BE backoff exponent
BER bit error rate
BI beacon interval
BO beacon order
BPSK binary phase-shift keying
BSN beacon sequence number
CAP contention access period
CBC-MAC cipher block chaining message authentication code
CCA clear channel assessment
CCM CTR + CBC-MAC
CFP contention-free period
CID cluster identifier
CLH cluster head
CRC cyclic redundancy check
CSMA-CA carrier sense multiple access with collision avoidance
CTR counter mode
CW contention window (length)
DSN data sequence number
DSSS direct sequence spread spectrum
ED energy detection
Acrónimos
55
EIRP effective isotropic radiated power
EMC electromagnetic compatibility
ERP effective radiated power
EVM error-vector magnitude
FCS frame check sequence
FFD full-function device
FH frequency hopping
FHSS frequency hopping spread spectrum
GTS guaranteed time slot
IFS interframe space or spacing
IR infrared
ISM industrial, scientific, and medical
IUT implementation under test
LAN local area network
LIFS long interframe spacing
LLC logical link control
LQ link quality
LQI link quality indication
LPDU LLC protocol data unit
LR-WPAN low-rate wireless personal area network
LSB least significant bit
MAC medium access control
MCPS MAC common part sublayer
MCPS-SAP MAC common part sublayer-service access point
MFR MAC footer
Acrónimos
56
MHR MAC header
MIC message integrity code
MLME MAC sublayer management entity
MLME-SAP MAC sublayer management entity-service access point
MSB most significant bit
MSC message sequence chart
MPDU MAC protocol data unit
MSDU MAC service data unit
NB number of backoff (periods)
O-QPSK offset quadrature phase-shift keying
OSI open systems interconnection
PAN personal area network
PANPC personal area networkcomputer
PD-SAP PHY data service access point
PDU protocol data unit
PER packet error rate
PHR PHY header
PHY physical layer
PIB PAN information base
PICS protocol implementation conformance statement
PLME physical layer management entity
PLME-SAP physical layer management entity-service access point
PN pseudo-random noise
POS personal operating space
PPDU PHY protocol data unit
Acrónimos
57
PRF pulse repetition frequency
PSD power spectral density
PSDU PHY service data unit
ppm parts per million
RF radio frequency
RFD reduced-function device
RSSI received signal strength indication
RX receive or receiver
SAP service access point
SD superframe duration
SDL specification and description language
SPDU SSCS protocol data units
SDU service data unit
SFD start-of-frame delimiter
SHR synchronization header
SIFS short interframe spacing
SO superframe order
SRD short-range device
SSCS service specific convergence sublayer
SUT system under test
TRX transceiver
TX transmit or transmitter
UML unified modeling language
WLAN wireless local area network
WPAN wireless personal area network
Acrónimos
58
Acronyms and Abbreviations zigbee
AIB Application support layer information base
AF Application framework
APDU Application support sub-layer protocol data unit
APL Application layer
APS Application support sub-layer
APSDE Application support sub-layer data entity
APSDE-SAP Application support sub-layer data entity ñ service access point
APSME Application support sub-layer management entity
APSME-SAP Application support sub-layer management entity ñ service access point
ASDU APS service data unit
BRT Broadcast retry timer
BTR Broadcast transaction record
BTT Broadcast transaction table
CCM* Enhanced counter with CBC-MAC mode of operation
CSMA-CA Carrier sense multiple access ñ collision avoidance
EPID Extended PAN ID
FFD Full function device
GTS Guaranteed time slot
HDR Header
IB Information base
LQI Link quality indicator
LR-WPAN Low rate wireless personal area network
MAC Medium access control
Acrónimos
59
MCPS-SAP Medium access control common part sub-layer ñ service access point
MIC Message integrity code
MLME-SAP Medium access control sub-layer management entity ñ service access point
MSC Message sequence chart
MSDU Medium access control sub-layer service data unit
MSG Message service type
NBDT Network broadcast delivery time
NHLE Next higher layer entity
NIB Network layer information base
NLDE Network layer data entity
NLDE-SAP Network layer data entity ñ service access point
NLME Network layer management entity
NLME-SAP Network layer management entity ñ service access point
NPDU Network layer protocol data unit
NSDU Network service data unit
NWK Network
OSI Open systems interconnection
PAN Personal area network
PD-SAP Physical layer data ñ service access point
PDU Protocol data unit
PHY Physical layer
PIB Personal area network information base
PLME-SAP Physical layer management entity ñ service access point
POS Personal operating space
QOS Quality of service
Acrónimos
60
RFD Reduced function device
RREP Route reply
RREQ Route request
RN Routing node
SAP Service access point
SKG Secret key generation
SKKE Symmetric-key key establishment
SSP Security services provider
SSS Security services specification
WPAN Wireless personal area network
XML Extensible markup language
ZB ZigBee
ZDO ZigBee device object
Anexo A: Aplicação em VB 2008,net 61
Anexos
Anexo A: Algoritmo de acesso ao meio
Acesso ao meio no protocolo 802.15.4
A sob camada MAC providencia 2 serviços: a MAC data service e o MAC serviço de gestão
interface com a sob camada do MAC entidade gestora (MLME) service acess point (SAP)
(MLME-SAP) atravessando o PHY data service.
As características da sob camada do MAC são gestão da beacon frame, acesso ao canal, gestão
GTS, validação da frame, acknowledged frame delivery, associação e dissociação.
Estrutura de um quadro de sinalização.
LR-WPAN permite o uso opcional da superframe structure. O formato da superframe é definido
pelo coordenador. A supeframe está ligada por network beacons e esta dividida em 16 slots de
igual tamanho. A beacon frame é enviada no primeiro slot de cada superframe. Se um
coordenador não quiser utilizar a superframe structure, poderá desligar a transmissão de beacons.
Os beacons são usados para sincronizar os aparelhos anexados, para identificar o PAN e para
descrever a estrutura das superframes.
A superframe pode ter uma parte activa e uma parte inactiva. Durante a porção inactiva, o
coordenador não devera interagir com o seu PAN e poderá entrar num low-power mode. A
porção activa consiste no contention Access period (CAP) and contention free period (CFP).
Qualquer aparelho que deseje comunicar durante o CAP devera competir com outros aparelhos
usando um mecanismo slotted CSMA-CA. Por outro lado, o CFP contém guaranteed time slots
(GTSs). O GTSs aparecerá sempre no final da superframe activa começando na ligação slot que
sucede imediatamente ao CAP. O PAN coordenador pode alocar até 7 destes GTSs e um GTS
pode ocupar mais de um slot period.
As durações das diferentes porções da superframe são descritas pelos valores do
macBeaconOrder e macSuperFrameOrder. MacBeaconOrder descreve o intervalo no qual o
coordenador ira transmitir as suas beacon frames. O intervalo beacon, BI, está relacionado com o
macBeaconOrder, BO, pelo seguinte: BI= aBasesSuperFrameDuration2 BO
, 0 BO 14. A
superframe é ignorada se BO=15.
O valor da macSuperFrameOrder descreve o comprimento da porção activa da superframe. A
duração da superframe, SD, está relacionada com a macSuperFrameOrder, SO, pelo seguinte:
Anexo A: Aplicação em VB 2008,net 62
SD= aBasesSuperFrameDuration2 SO
, 0 SO 14. Se SO=15, a superframe não devera
permanecer activa depois do beacon.
A porção activa de cada superframe esta dividida em aNumSuperFrameSlots igualmente
espaçados slots de duração 2so
aBaseSlotDuration, e é composta de 3 partes: um beacon, o CAP
e CFP. O beacon é transmitido no início do slot 0 sem o uso do CSMA. O CAP começa
imediatamente depois do beacon. O CAP devera ser no mínimo aMinCAPLength símbolo, a não
ser que espaço adicional seja necessário para temporariamente acomodar o aumento no beacon
frame length para realizar manutenção do GTS. Todas as frames, excepto as frames de
reconhecimento ou qualquer data frame que imediatamente segue o reconhecimento de um
comando de requerimento de data que são transmitidos no CAP deverão usar slotted CSMA-CA
para aceder ao canal. Uma transmissão no CAP será completo um período IFS antes do fim do
CAP. Se isto não for possível, defere a sua transmissão ate ao CAP da superframe seguinte. Um
exemplo de uma estrutura de uma superframe é demonstrado na fig. 5.
Figura 7, estrutura Superframe
O CFP se presente começara numa ligação slot imediatamente depois do CAP e estende-se ate ao
fim da porção activa da superframe. A duração do CFP é determinada pela duração total de todos
os GTSs combinados. Nenhuma transmissão dentro do CFP devera usar um mecanismo CSMA-
CA. Um aparelho transmitindo no CFP devera assegurar que as suas transmissões são completas
num período IFS antes do fim do seu GTS.
O tempo IFS é a quantidade de tempo necessária para proceder o pacote recebido por PHY.
Frames transmitidas serão seguidas por um período IFS. O comprimento do IFS depende do
tamanho da frame que acabou de ser transmitida. Frames que têm um comprimento ate ao
Anexo A: Aplicação em VB 2008,net 63
comprimento da aMaxSIFSFrameSize serão seguidas por um SIFS, enquanto frames de um
comprimento maior serão seguidas de um LIFS.
Os PANs que não queiram usar a superframe num não beacon-enabled (permitido) deverão
colocar ambos macBeaconOrder e macSuperFrameOrder para 15. Neste tipo de network, um
coordenador não devera transmitir nenhum beacon, todas as transmissões excepto o
reconhecimento frame deverão usar unslotted CSMA-CA para aceder ao canal, GTSs não devera
ser permitido.
Algoritmo de acesso ao meio.
Se uma estrutura superframe é usada no PAN, então o slotted CSMA-CA devera ser usado. Se os
beacons não estão a ser usados no PAN, ou um beacon não pode ser localizado numa beacon-
enabled network, unslotted CSMA-CA algoritmo é usado. Em ambos os casos, o algoritmo é
implementado usando unidades de tempo chamadas backoff periods, o que é igual a uma
aUnitBackoffPeriod símbolo.
Anexo A: Aplicação em VB 2008,net 64
Figura 2 – Mecanismo CSMS-CA
No mecanismo de acesso de canal slotted CSMA-CA, os limites do backoff period de cada
aparelho no PAN estão alinhados com os limites da superframe slot do PAN coordenador. Nas
slotted CSMA-CA, cada vez que um aparelho deseje transmitir data frames durante CAP, devera
localizar o limite do próximo backoff period. Nas unslotted CSMA-CA, os backoff periods de
um aparelho não precisam de estar sincronizados com os backoff periods de outro aparelho.
Cada aparelho tem 3 variáveis: NB, CW e BE. NB é o número de vezes que o algoritmo CSMA-
CA precisou de backoff enquanto tentava a transmissão actual. É inicializado a zero antes de
cada nova transmissão. CW é a o comprimento de janela de contention, que define o número de
Anexo A: Aplicação em VB 2008,net 65
periods backoff que precisam de ser limpos de actividade antes da transmissão poder começar. É
inicializado a 2 antes de cada tentativa de transmissão e reset to 2 cada vez que o canal é acedido
como ocupado. CW é apenas usado para slotted CSMA-CA. BE é o exponencial backoff, que
está relacionado com quantos backoff periods um aparelho deve esperar antes de tentar aceder ao
canal. Embora o receptor do aparelho esteja activado durante a porção do algoritmo que analisa o
canal, o aparelho devera descartar qualquer frame recebida durante este tempo.
Nas slotted CSMA-CA, NB, CW e BE são inicializadas e o limite do no período backoff é
localizado. Nas unslotted CSMA-CA, NB e BE são inicializadas (passo 1). A camada MAC
devera atrasar por um numero random de um período completo backoff no intervalo 0 a 2BE
-1
(passo 2) depois pede a PHY que um CCA (clear channel assessment) (passo 3). A subcamada
Mac devera então proceder nos restantes passos do algoritmo CSMA-CA, a transmissão da
frame, e qualquer reconhecimento pode ser completado antes do fim do CAP. Se a sob camada
MAC não poder prosseguir, devera esperar ate ao início do CAP na próxima superframe e repetir
a avaliação.
Se o canal é dado como ocupado (passo 4), a sob camada MAC devera incrementar ambos NB e
BE de 1, assegurando que BE seja não mais que aMaxBE. Em slotted CSMA-CA, CW também
pode ser reset a 2. Se o valor de NB é menor ou igual a macMaxCSMABackoffs, a CSMA-CA
devera voltar ao passo 2, ou a CSMA-CA devera terminar com um Channel Acess Failure status.
Se o canal é avaliado como livre (passo 5) numa slotted CSMA-CA, a sob camada MAC devera
assegurar que a janela de desacordo (contention) é expirada antes de começar a transmissão. Para
tal, a sob camada MAC primeiro diminui CW em 1. Se o CW não é igual a zero, siga para o
passo 3 ou comece a transmissão no limite do próximo backoff period. Nas unslotted CSMA-
CA, a sob camada MAC começa a transmissão imediatamente se o canal for avaliado como livre.
A totalidade do algoritmo CSMA-CA é ilustrada na fig. 7.
Tipos de tranferencia de dados
Existem 3 tipos de transacção de transferência de data: de um coordenador para um aparelho, do
aparelho para o coordenador e entre dois peer devices. O mecanismo de cada uma destas
transferências depende se a rede suporta a transmissão dos beacons.
Quando um aparelho deseja transferir data numa nonbeacon-enabled network, simplesmente
transmite a sua data frame, usando unslotted CSMA-CA, para o coordenador. Existe também um
reconhecimento opcional no fim como demonstra a fig. 8.
Anexo A: Aplicação em VB 2008,net 66
Figura 3 – Comunicação com o coordenador numa rede em farol activo
Quando um aparelho deseja transmitir data para um coordenador numa beacon-enabled network,
primeiro escuta a rede beacon. Quando o beacon é encontrado, sincroniza com a estrutura da
superframe. No tempo certo, transmite a sua data frame, usando slotted CSMA-CA, para o
coordenador. Há um reconhecimento opcional no final como demonstrado na fig. 9.
Figura 4 – Comunicação com o coordenador numa rede de farol não activo
As aplicações das transferências são completamente controladas pelos aparelhos num PAN em
vez do coordenador. Isto providencia a conservação da energia característica da ZigBee network.
Quando um coordenador deseja transmitir data para um aparelho numa beacon-enabled network,
aparece indicado na rede de beacons que a mensagem esta pendente. O aparelho periodicamente
escuta a rede de beacons, e se uma mensagem está pendente, transmite um comando MAC
pedindo esta data, usando slotted CSMA-CA. O coordenador tem a opção de reconhecer o
sucesso da transmissão deste pacote. A data frame pendente é então transmitida usando slotted
CSMA-CA. O aparelho reconhece o sucesso da transmissão de data transmitindo uma frame de
Anexo A: Aplicação em VB 2008,net 67
reconhecimento. Ao receber o reconhecimento, a mensagem é removida da lista de mensagens
pendentes no beacon como demonstrado na figura 10.
Figura 5 – Comunicação de um coordenador numa rede de farol activo
Quando um coordenador deseja transmitir data para um aparelho numa nonbeacon-enabled
network, armazena a data para o aparelho apropriado para estabelecer contacto e pedir data. O
aparelho pode estabelecer contacto transmitindo um comando MAC pedindo essa data, usando
unslotted CSMA-CA, para o seu coordenador a uma application-defined rate. O coordenador
reconhece este pacote. Se existe data pendente, o coordenador transmite uma data frame com um
comprimento zero payload para indicar que não existia data pendente. O aparelho reconhece este
pacote como demonstrado na fig 11.
Figura 6 – Comunicação de um coordenador numa rede de farol não activo
Numa network peer-to-peer, todo o aparelho pode comunicar com qualquer outro aparelho no
seu raio de transmissão. Há duas opções para isto. No primeiro caso, o node escuta
Anexo A: Aplicação em VB 2008,net 68
constantemente e transmite a data usando unslotted CSMA-CA. No segundo caso, os nodes
sincronizam com os mesmos poupando assim energia.
A formação da rede
Um PAN será começado por um FFD apenas depois de um scan a um canal activo ou canal ED
seja realizado e uma adequada selecção do identificador PAN foi realizada como mostra a fig.
11. O scan activo permite o FFD localizar qualquer coordenador transmitindo beacon frames
dentro de um POS (personal operating space).
Figura 7 – Inicio gráfico de sequência de mensagens PAN – Coordenador PAN
Anexo A: Aplicação em VB 2008,net 69
Um scan de um canal activo é requisitado sobre um específico conjunto de canais lógicos. Para
cada canal lógico, o aparelho deve primeiro mudar para o canal e mandar um comando de
beacon request. O aparelho devera então permitir ao receptor pelo menos
aBaseSuperframeDuration*(2n+1) símbolos, onde n esta entre 0 e 14. Durante este tempo, o
aparelho devera rejeitar todas as nonbeacon frames e gravar a informação contida em todos
únicos beacons no PAN descritor estrutura.
Se o coordenador do beacon-enabled PAN recebe o pedido comando do beacon, devera ignorar o
comando e continuar a transmitir os seus beacons como usual. Se o coordenador de um
nonbeacon-enabled PAN recebe este comando, devera transmitir uma única beacon frame
usando unslotted CSMA-CA.
O scan activo de um canal em particular termina quando o número de PAN descriptors
armazenados iguala o máximo especificado na implementação ou
aBaseSuperframeDuration*(2n+1) símbolos, onde n está entre 0 e 14. O scan inteiro deverá
terminar quando o número de PAN descriptors armazenados iguala o máximo específico de
implementação ou cada canal no set de canais disponíveis foi verificado.
Então, SELECTING um PAN identifier adequado POR prospective PAN coordenador da lista de
PAN descritores reenviada do scan dos canais activos É DE ACORDO COM A APLICAÇAO.
Um scan ED permite o FFD obter uma medida do pico de energia de cada canal requisitado.
Durante o scan ED, a sob camada MAC devera descartar todas as frames recebidas sobre o PHY
data service. O scan ED é realizado sobre um conjunto de canais lógicos. Para cada canal lógico,
repetidamente realize uma medida de ED para aBaseSuperframeDuration*(2n+1) onde n é o
valor da scanDuration. A medida máxima de ED obtida durante este período deve ser apontada
antes de seguir para o próximo canal na lista de canais. O scan ED devera terminar quando ou o
número de medidas de canais ED armazenados iguala o máximo especificado pela
implementação, ou a energia foi medida em cada um dos específicos canais lógicos.
Em alguns casos, uma situação pode ocorrer em que dois PANs existem na mesma POS com o
mesmo PAN identificador. Se este conflito acontece, o coordenador e os seus aparelhos deverão
realizar um procedimento de PAN identificador resolução de conflito.
O coordenador PAN deve concluir que o conflito do PAN identificador esta presente se um dos
beacon frames é recebido pelo PAN coordenador com o PAN coordenador subfield seleccionado
a 1, por exemplo, transmitido pelo PAN coordenador, e o PAN identificador é igual ao
Anexo A: Aplicação em VB 2008,net 70
macPANId ou um PAN ID conflito comando de notificação é recebido pelo PAN coordenador
por um aparelho no seu PAN. O aparelho deve concluir que um conflito do PAN identificador
está presente se uma beacon frame é recebida pelo aparelho com o PAN coordenador subfield
seleccionado a 1, o PAN identificador igual a macPANId, um endereço que não é igual a ambos
o macCoordShortAddress e o macCoordExtendedAddress.
O aparelho ao detectar um conflito do PAN identificador deve criar um comando de PAN ID
notificação de conflito e envia-la para o coordenador PAN. Se o comando de notificação de
conflito do PAN ID é recebido correctamente, o PAN coordenador devera mandar um ACK e
resolver o conflito.
Se é o coordenador a detectar o conflito do PAN identificador, o coordenador devera primeiro
executar um scan activo e depois seleccionar um novo PAN identificador baseado na informação
do scan. O coordenador devera então emitir o comando de realinhamento do coordenador
contendo o novo PAN identificador com a origem do PAN identificador field igual ao valor
macPADId. Uma vez que o coordenador realinhamento field foi enviado, o coordenador devera
set macPANId para o novo PAN identificador.
Início do quadro de sinalização.
Dependendo dos parâmetros do MLME-START-request primitive, o FFD pode operar num modo
sem beacons ou pode começar a transmitir beacons ou como um PAN coordenador ou como um
aparelho previamente definido PAN. Um FFD que não seja um PAN coordenador devera
começar a transmitir beacon frames só quando associado com sucesso a um PAN. Esta primitiva
também inclui parâmetros macBeaconOrder e macSuperFrameOrder que determinam a duração
do intervalo beacon e a duração das porções activas e inactivas.
O tempo de transmissão do beacon mais recente devera ser gravado na macBeaconTxTime e
devera ser computorizado para que o seu valor seja tomado no mesmo símbolo limite de cada
beacon frame, do qual a localização é especificamente implementada.
Associação a rede.
Uma FFD poderá indicar a sua presença numa PAN ou outros aparelhos transmitindo beacon
frames. Isto permite outros aparelhos realizar descoberta de aparelhos. Uma FFD que não é um
PAN coordenador devera começar a transmitir beacon frames só quando for associado com
sucesso a um PAN.
Anexo A: Aplicação em VB 2008,net 71
A associação de um aparelho começa quando estiver concluído ou um scan de canais activos ou
um scan de canais passivos. O scan passivo, ao contrário do scan activo, permite ao aparelho
localizar qualquer coordenador transmitindo beacon frames dentro da POS enquanto um
comando requisição de beacons não é necessário para um scan passivo.
Os resultados do scan de canal são então usados para escolher um PAN apropriado. Um aparelho
devera apenas tentar associar-se a um PAN que esteja actualmente a permitir associações. Como
escolher um PAN adequado com o qual associar na lista de descritores de PAN enviada pelo
SCAN ao canal e de acordo com a aplicação. Seguida a selecção de um PAN com o qual
associar, as próximas camadas altas pedem que o MLME configure o phyCurrentChannel para o
canal lógico apropriado com o qual associar, macPANId para o identificador do PAN com o qual
associar e macCoordExtendedAddress ou macCoordShortAddress para o endereço do
coordenador com o qual se associa.
Um aparelho não associado devera iniciar o seu processo de associação enviando um pedido de
associação comando para o coordenador de um PAN existente. Se o comando de pedido de
associação é recebido correctamente, o coordenador devera enviar um reconhecimento. Este
reconhecimento todavia não significa que o aparelho tenha sido associado. O coordenador
necessita de tempo para determinar se as fontes correntes disponíveis no PAN são suficientes
para permitir outro aparelho associar-se. Esta decisão deve ser feita dentro de uma
aResponseWaitTime símbolo. Se já esta associada, remova toda a informação. Se estão
disponíveis recursos suficientes, o coordenador devera alocar um endereço curto ao aparelho e
gerar um comando de resposta associada contendo o novo endereço e um status que indique o
sucesso da associação. Se não há recursos suficientes, o coordenador devera gerar um comando
resposta de associação contendo um status indicando falha. Esta resposta é enviada para o
aparelho usando transmissão indirecta (pending request).
Por outro lado, o aparelho, depois de obter a frame de reconhecimento, espera pela resposta do
aResponseWaitTime símbolo. Ou verifica os beacons na beacon-enabled network ou extrai o
comando de resposta da associação do coordenador depois de uma aResponseWaitTime símbolo.
Ao receber o comando de resposta da associação, o aparelho deve enviar um reconhecimento. Se
a associação tem sucesso, armazene o endereço do coordenador com o qual se associou.
O procedimento da associação é mostrado na fig 4.8 no lado do coordenador, e fig 4.9 do lado do
aparelho.
Anexo A: Aplicação em VB 2008,net 72
Quando um coordenador quer que um dos seus aparelhos associados deixa a PAN, deve enviar
um comando de notificação de dissociação para o aparelho usando transmissão indirecta. Após
recepção do pacote, o aparelho deve enviar uma frame de reconhecimento. Mesmo que o ack não
seja recebido, o coordenador devera considerar o aparelho dissociado.
Quando um aparelho associado quer deixar a PAN, devera enviar um comando de notificação de
dissociação ao coordenador. Após recepção, o coordenador envia um ack. Mesmo que o ack não
seja recebido, o aparelho devera considerar-se dissociado.
Um aparelho associado devera desassociar-se a si próprio removendo todas as referências ao
PAN. O coordenador devera dissociar um aparelho removendo todas as referências relativas a
esse aparelho.
Sincronismo dos quadros.
Para PANs que suportam beacons, a sincronização é realizada pela recepção e descodificação
desses beacon frames. Para PANs que não suportem beacons, a sincronização é feita por polling
ao coordenador.
Numa beacon-enabled network, aparelhos estão permitidos a adquirir sincronização apenas com
beacons que contêm o PAN identificador especificado no macPANId. Se tracking é especificado
no MLME-SYNC-request primitive, o aparelho devera tentar adquirir o beacon e manter o seu
registo por regulares e temporizadas activações do seu receptor. Devera permitir ao seu receptor
um tempo antes da nova transmissão do beacon esperado, por exemplo, mesmo antes do
conhecido inicio da próxima superframe. Se tracking não é especificada, o aparelho devera tentar
adquirir o beacon apenas uma vez.
Para adquirir a sincronização beacon, o aparelho devera tornar apto (enable) o seu receptor e
procura pelo aBaseSuperframeDuration*(2n+1) símbolos, onde n é a macBeaconOrder. Se os
beacon frame que contem o actual PAN identificador do aparelho não são recebidos, o MLME
devera repetir a procura. Uma vez que o número de beacons falhados atingir aMaxLostBeacons,
o MLME notifica a camada superior seguinte atribuindo uma indicação MLME-SYNC-LOSS
com a razão BEACON-LOSS.
O MLME devera timestamp (marcar o tempo a que foi recebido) cada beacon frame recebida no
mesmo limite (fronteira), dentro de cada frame, a localização de qual é especifica da
implementação.
Anexo A: Aplicação em VB 2008,net 73
Se uma nonbeacon-enabled network, os aparelhos deverão ser capazes de poll (adquirir
informação por tentativa num ciclo a intervalos normalmente regulares) á discrição da próxima
camada superior. Ao receber o MLME-POLL-request primitive, o MLME segue o procedimento
para extrair data pendente do coordenador.
Outro problema com sincronização é orphaned device (aparelho órfão). Se a próxima camada
superior recebe comunicação repetida de falhas a seguir ao requerimento para transmitir data,
pode concluir que se tornou órfã. Uma única falha de comunicação ocorre quando a transacção
de um aparelho falha o alcance ao seu coordenador, um reconhecimento não é recebido depois
de uma aMaxFrameRetries tentar enviar data. Se a próxima camada superior conclui que o
aparelho foi tornado órfão, pode ou fazer reset á sob camada MAC e conduzir um procedimento
associativo ou conduzir no aparelho órfão um procedimento de realinhamento.
Se a decisão é para alinhamento de um aparelho órfão, scan do órfão é realizado. Durante o scan
do órfão, a sob camada do MAC devera descartar todas as frames recebidas sobre o PHY data
service que não são frames do MAC comando do realinhamento do coordenador. Para cada canal
lógico sobre um específico set de canais lógicos, o aparelho manda um comando de notificação
órfão. O aparelho deve então tornar apto o seu receptor para o máximo de aResponseWaitTime
símbolo. Se o aparelho recebe com sucesso o comando de realinhamento do coordenador dentro
deste tempo, o aparelho devera desactivar o seu receptor.
Se um coordenador recebe o comando de notificação órfão, procura a lista desse aparelho pelo
aparelho que esta a enviar esse comando. Se o coordenador encontra um registo desse aparelho,
devera mandar um comando de realinhamento do coordenador ao aparelho órfão. Senão, ira
ignorar o pacote. O scan órfão termina quando o aparelho recebe um comando de realinhamento
do coordenador ou o set específico dos canais lógicos foi feito o scan.
Ìnicio de transmição e confirmação.
Para poder transmitir data ou um beacon ou uma frame de comando MAC, a sob camada MAC
devera copiar o valor de DSN (destination sequence number) para a sequência do número field
(campo) do MHR da frame de saída e depois aumenta-la em 1. O endereço de campo de origem
devera conter o endereço do aparelho que envia a frame. Se ao aparelho foi alocado um endereço
curto, deverá usar esse endereço preferencialmente do que o seu endereço alargado de 64 bits. Se
o campo de endereço de origem não esta presente, o originador da frame devera ser assumido
como um PAN coordenador e o endereço de destino devera conter o endereço do recipiente. O
endereço de destino devera conter o recipiente pretendido da frame, que tanto pode ser um 16 bit
Anexo A: Aplicação em VB 2008,net 74
endereço curto ou um 64 bits endereço alargado. Se o campo de endereço de destino não esta
presente, o recipiente da frame devera ser assumido como o PAN coordenador. O endereço de
destino e de origem podem ser em PANs diferentes, o que é identificado pelo campo de
identificação do PAN.
Numa beacon-enabled PAN, o aparelho transmissor devera tentar encontrar o beacon antes de
transmitir. Se não conseguir encontrar o beacon, devera usar unslotted CSMA-CA. Uma vez
encontrado o beacon, transmite na porção apropriada da superframe. Transmissão no CAP
devera usar slotted CSMA-CA e aqueles em GTS não deverão usar CSMA-CA. Numa
nonbeacon-enabled network, as frames são transmitidas usando unslotted CSMA-CA.
Ao receber os pacotes, a sob camada MAC ira descartar as frames recebidas que não contêm um
valor correcto no seu FCS campo no MFR.
Recepção é importante em termos de consumo de energia. Cada aparelho pode escolher se a sob
camada MAC vai autorizar o seu receptor durante períodos idle. Durante estes períodos idle, a
sob camada MAC devera ainda “service transceiver task” pedidos pela camada superior próxima.
Ao completar cada transceiver task, a sob camada MAC devera pedir que o PHY active ou
desactive o seu receptor, dependendo se macRxOnWhenIdle esta set para TRUE ou FALSE,
respectivamente. Se o beacon está activo, devera considerar o valor de macRxOnWhenIdle
apenas durante períodos idle do CAP.
Outra característica de conservação de energia do standard é a característica de transmissão
indirecta. As transacções começam pelos aparelhos em si, em vez do coordenador. Por outras
palavras, ou o coordenador necessita de indicar no seu beacon quando existem mensagens
pendentes para os aparelhos, ou os aparelhos mesmos necessitam de poll o coordenador para
determinar se têm alguma mensagem pendente.
Um aparelho numa beacon-enabled PAN pode determinar se existe alguma frame pendente para
esse aparelho, examinando o conteúdo da beacon frame recebida. Se o endereço do aparelho esta
presente na lista de campos de endereços do beacon frame, o MLME do aparelho enviará um
comando de pedido de data ao coordenador durante o CAP. Após receber este comando, o
coordenador envia um ack. Indica na ack frame se existe alguma data pendente para esse
aparelho. Ao receber o ack, o aparelho devera activar o receptor no máximo por um
aMaxFrameResponseTime CAP símbolo numa beacon-enabled PAN ou símbolos numa
nonbeacon-enabled PAN para receber a correspondente frame do coordenador. Se existe data
Anexo A: Aplicação em VB 2008,net 75
pendente, o coordenador devera enviar a trama ou enviar a frame contendo comprimento zero
payload, indicando que não existe data presente.
A data frame é transmitida sem usar CSMA-CA se a sob camada MAC pode começar a
transmissão da data frame entre aTurnaroundTime e aTurnaroundTime + aUnitBackoffPeriod
símbolos e existe tempo restante no CAP para a mensagem, IFS apropriado e reconhecimento, e
usando CSMA-CA se não.
Uma frame transmitida quando o campo de reconhecimento esta set para 1 devera ser
reconhecida pelo recipiente. Se o recipiente pretendido recebe a frame de forma correcta, devera
gerar e enviar um reconhecimento frame contendo o mesmo DSN do que a data ou frame de
comando MAC que foi reconhecida. A transmissão do ack devera começar entre
aTurnaroundTime e aTurnaroundTime + aUnitBackoffPeriod símbolos após a recepção do
último símbolo da data ou da frame de comando do MAC.
Gestão do tempo, garantia de envio de quadros.
O GTS permite ao aparelho operar no canal dentro da porção da superframe que é
exclusivamente dedicada a esse aparelho. Um aparelho devera tentar alocar e usar a GTS só se
estiver actualmente a localizar beacons (currently tracking beacons). A GTS deve ser alocada
apenas pelo PAN coordenador e deve ser usada apenas para comunicações entre o PAN
coordenador e o aparelho. Um único GTS pode estender-se sobre um ou mais superframe slots.
O coordenador PAN pode alocar até 7 GTSs ao mesmo tempo, desde que haja capacidade
suficiente na superframe.
O GTS devera ser alocado antes do uso, com o coordenador PAN a decidir onde alocar a GTS
baseado nos requerimentos do pedido GTS e na actual capacidade disponível na superframe.
GTS deve ser alocado numa fisrt-came-first-serve basis e todos os GTSs devem ser localizados
contiguamente no final da superframe e depois do CAP. Cada GTS deve ser desalocado quando
o GTS não for mais preciso, e um GTS pode ser desalocado em qualquer tempo à descrição do
coordenador PAN ou pelo aparelho que originalmente pediu o GTS. Um aparelho ao qual foi
alocado GTS também pode operar em CAP.
A gestão dos GTSs deve ser feita pelo coordenador PAN unicamente. Para cada GTS, o
coordenador PAN deve ser capaz de armazenar o seu slot de iniciação, comprimento, direcção e
endereço do aparelho associado.
Anexo A: Aplicação em VB 2008,net 76
A direcção GTS é especificada como ou transmissão ou recepção. Cada aparelho pode pedir uma
transmissão de GTS e/ou recepção de GTS. Por cada GTS alocado, o aparelho deve ser capaz de
armazenar o seu starting slot, comprimento e direcção. Se um aparelho foi alocado uma recepção
GTS, devera activar o seu receptor para a totalidade do GTS. Do mesmo modo, um coordenador
PAN devera activar o seu receptor para a totalidade do GTS se o aparelho foi alocado para
transmitir GTS.
Um aparelho é instruído a pedir a alocação de um novo GTS através do comando de pedido de
GTS, com as características GTS (direcção, comprimento, etc) set de acordo com os
requerimentos da aplicação entendida. Ao receber este comando, o coordenador PAN devera
enviar uma frame de reconhecimento. Seguida a transmissão ack, o coordenador PAN devera
verificar primeiro se existe capacidade disponível na actual superframe, baseando no
comprimento restante do CAP e o comprimento desejado do GTS pedido. A superframe devera
ter capacidade disponível se o máximo número de GTSs não foi alcançado e alocar GTS do
comprimento desejado não ira reduzir o comprimento do CAP para menos de aMinCAPLength.
O coordenador PAN devera realizar a sua decisão num aGTSDDescPersistenceTime
superframes. Ao receber o ack do coordenador, o aparelho devera continuar a localizar os
beacons (track) e esperar pelo máximo aGTSDDescPersistenceTime superframes. Se não há
GTS descriptor na superframe, notifique a próxima camada superior de falha (failure).
Quando o coordenador determina se há capacidade disponível para os GTS requisitados, ira
gerar um GTS descriptor com as especificações requisitadas e o endereço curto do aparelho
requisitado. Indica o comprimento e o início do GTS na superframe e notifica a próxima camada
superior da nova alocação de GTS. Se não existia capacidade suficiente para alocar o GTS
requisitado, o start slot devera ser set a zero e o comprimento ser o maior comprimento GTS que
pode actualmente ser suportado. Este GTS descriptor devera permanecer na beacon frame por
uma aGTSDDescPersistenceTime superframes.
Ao receber a beacon frame, o aparelho devera processar o descriptor e notificar a camada
próxima superior de sucesso.
Do mesmo modo, um aparelho é instruído para pedir a desalocação de um GTS existente através
de um comando de pedido GTS usando as características to GTS que pretende desalocar. A
partir deste momento, o GTS a ser desalocado não devera ser utilizado pelo aparelho. Depois um
ack do PAN coordenador para o aparelho. O PAN coordenador faz a desalocação então do
pedido das características de GTS no pacote combina com as da alocação. O coordenador PAN
Anexo A: Aplicação em VB 2008,net 77
devera também garantir que quaisquer gap ocorridas no CFP, que aparece devido á desalocação
do GTS, são removidas para maximizar o comprimento de CAP.
O MLME do coordenador PAN também devera tentar detectar quando um aparelho parou de
usar a GTS usando uma das seguintes regras: para uma GTS transmissão frame, o MLME do
coordenador PAN devera assumir que esse aparelho não esta mais a usar o GTS se uma data
frame não é recebida por pelo menos 2*n superframes. Para receber GTSs, o MLME do
coordenador PAN devera assumir que o aparelho não esta mais a usar o seu GTS se uma frame
de reconhecimento não for recebida por pelo menos 2*n superframes. O valor de n é igual a 28-
macBeaconOrder se 0 ≤ macBeaconOrder ≤ 8 e 1 se 9 ≤ macBeaconOrder ≤ 14.
Formato dos quadros de acesso ao meio
O formato da MAC frame geral é dado na fig. 11. Cada MAC frame consiste nos seguintes
componentes básicos:
. MHR, que engloba frame control, sequencia de números, e informação do endereço.
. A MAC payload de comprimento variável, que contêm informação específica do tipo de frame.
Frames de reconhecimento (ACK) não incluem a payload.
. Um MFR, que contêm FCS.
LR-WPAN define 4 estruturas: beacon frame (fig. 12), data frame (fig 13), frame de
reconhecimento (aknowledgement) (fig.14), MAC comand frame (fig. 15).
Anexo A: Aplicação em VB 2008,net 78
Figura 8 – Associação gráfica de sequência de mensagens - Coordenador
Anexo A: Aplicação em VB 2008,net 79
Figura 9 – Associação gráfica de sequência de mensagens - Dispositivo
Anexo A: Aplicação em VB 2008,net 80
Figura 10 – Formato geral de um quadro MAC
Figura 11 – Vista esquemática do quadro Frame
Figura 12 – Visão esquemática do quadro de dados
Figura 13 – Visão esquemática do quadro de aviso
Anexo A: Aplicação em VB 2008,net 81
Figura 14 – Visão esquemática do quadro de comando MAC
Anexo B: Aplicação em Vb 2008.net
Public Class Form1
Public Decimas As Integer
Public READ As Char
Public RACK As Char
Public WRITE As Char
Public WOK As Char
Public WBAD, DATAOK, DATBAD, IDENT, IDACK, DONE As Char
Public Buff_Leitura(200) As Byte
Public Buff_escrita(200) As Byte
Public Posicao As Integer
Public Total_confirmado As Integer
Public ModoBite As Integer
Public Total_linhas As Integer
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click
Buff_Leitura(1) = "1"
Control.CheckForIllegalCrossThreadCalls = False
Inicializa_Variaveis()
Try
SerialPort1.PortName = TextBox10.Text
SerialPort1.Open()
Timer1.Enabled = True
Timer1.Start()
'' só chama interrupção quando recebe pelo menos 1 caracter
SerialPort1.ReceivedBytesThreshold = 1
Catch ex As Exception
MsgBox("A porta Ja esta Aberta")
End Try
End Sub
Anexo A: Aplicação em VB 2008,net 82
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim Valor As Integer
Valor = 234
Dim TestData() As Byte = {&HEA, &H11, &H11, &HFF}
TextBox9.Text = "Procura..boot..."
Posicao = 0
Buff_Leitura(0) = 0
Try
SerialPort1.ReadExisting()
SerialPort1.DiscardOutBuffer()
TestData(0) = &HEA
SerialPort1.Write(TestData, 0, 1)
Delay()
While Buff_Leitura(0) <> 235 '' espera IDACK
Delay()
TestData(0) = &HEA
Posicao = 0
SerialPort1.Write(TestData, 0, 1)
Delay()
End While
Posicao = 0
Delay()
TextBox9.Text = "RECEBEU IDACK"
Catch ex As Exception
MsgBox("Nao é possivel enviar os dados Verifique se Abriu Porta")
End Try
End Sub
Private Sub TextBox6_TextChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs)
End Sub
Anexo A: Aplicação em VB 2008,net 83
Private Sub Event_DataReceived(ByVal sender As Object, ByVal e As
System.IO.Ports.SerialDataReceivedEventArgs) Handles SerialPort1.DataReceived
Buff_Leitura(Posicao) = SerialPort1.ReadByte
If Buff_Leitura(Posicao) = 228 Then Total_confirmado =
Total_confirmado + 1
If (ModoBite = 1) Then Me.TextBox1.Text = Me.TextBox1.Text +
Str(Buff_Leitura(Posicao))
If (ModoBite = 0) Then Me.TextBox1.Text = Me.TextBox1.Text +
Chr(Buff_Leitura(Posicao))
Posicao = Posicao + 1
If (Posicao > 190) Then
Posicao = 0
End If
End Sub
Private Sub Form1_FormClosed(ByVal sender As Object, ByVal e As
System.Windows.Forms.FormClosedEventArgs) Handles Me.FormClosed
SerialPort1.Close()
End Sub
Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Timer1.Tick
Decimas = Decimas + 1
If Decimas > 1000 Then Decimas = 0
End Sub
Sub Delay()
'' espera 200 ms
Decimas = 0
While Decimas < 2
My.Application.DoEvents()
End While
End Sub
Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button3.Click
Dim oFile As System.IO.File
Dim oRead As System.IO.StreamReader
oRead = oFile.OpenText(TextBox13.Text)
Anexo A: Aplicação em VB 2008,net 84
Dim intSingleChar As Byte
Dim chksum1 As Integer
Dim cSingleChar As String
Dim cstring As String
Dim contador As Integer
Dim TestData() As Byte = {&HEA, &H11, &H11, &HFF}
Dim valor As Integer
Dim Endereço As Integer
Dim endH As Integer
Dim endL As Integer
Dim Tamanho As Integer
Dim Nr_repeticao As Integer
Dim Temp As Integer
Dim Total_repeticao As Integer
ModoBite = 1
'' vai ler o total de linhas
Total_linhas = 0
While oRead.Peek <> -1
cstring = oRead.ReadLine
Tamanho = Val("&h" + Mid$(cstring, 2, 2))
If Tamanho = 0 Then GoTo fim_de_linhas
Total_linhas += 1
End While
fim_de_linhas:
oRead.Close()
ProgressBar1.Maximum = Total_linhas
oRead = oFile.OpenText(TextBox13.Text)
Total_confirmado = 0
While oRead.Peek <> -1
' intSingleChar = oRead.Read()
' Convert the integer value into a character
cstring = oRead.ReadLine
Tamanho = Val("&h" + Mid$(cstring, 2, 2))
If Tamanho = 0 Then GoTo final
TextBox11.Text = cstring
chksum1 = 0
contador = 12
'' If Tamanho < 16 Then Stop
While contador < (Tamanho * 2 + 11)
intSingleChar = Val("&h" + Mid$(cstring, contador, 2))
Buff_escrita(contador / 2 - 1) = intSingleChar
chksum1 = intSingleChar + chksum1
Anexo A: Aplicação em VB 2008,net 85
contador -= 2
intSingleChar = Val("&h" + Mid$(cstring, contador, 2))
Buff_escrita(contador / 2 + 1) = intSingleChar
chksum1 = intSingleChar + chksum1
contador += 6
End While
valor = (chksum1 / 256 - Int(chksum1 / 256)) * 256
Endereço = Val("&h" + Mid$(cstring, 4, 4))
Endereço = Endereço >> 1
endH = Int(Endereço / 256)
endL = Endereço - endH * 256
Buff_escrita(0) = &HE3 ' comando de escrita
Buff_escrita(1) = endH 'Address high
Buff_escrita(2) = endL 'Address low
Buff_escrita(3) = Tamanho ' tamanho
Buff_escrita(4) = valor ' chksum
Nr_repeticao = 0
Total_repeticao = Val(TextBox4.Text)
retransmite:
SerialPort1.ReadExisting()
Buff_Leitura(0) = 33
Posicao = 0
SerialPort1.Write(Buff_escrita, 0, 5 + Tamanho)
TextBox12.Text = Str(Total_confirmado)
TextBox12.Text += " /"
TextBox12.Text += Str$(Total_linhas)
If Total_confirmado <= ProgressBar1.Maximum Then
ProgressBar1.Value = Total_confirmado
Delay()
''If Buff_Leitura(0) <> 231 Then MsgBox("erro na transmição na
linha" + Str$(Total_confirmado)) : GoTo final
'' retrasmição
If Not (Buff_Leitura(0) = 231 Or Buff_Leitura(1) = 231) Then
Nr_repeticao += 1
Temp = 2 ^ Nr_repeticao - 1
While Temp
Anexo A: Aplicação em VB 2008,net 86
Delay()
Temp -= 1
TextBox9.Text = "retran.." + Str(Nr_repeticao) + " Li=" +
Str(Total_confirmado)
End While
If Nr_repeticao >= Val(TextBox4.Text) Then MsgBox("erro na
transmição na linha" + Str$(Total_confirmado)) : GoTo final
GoTo retransmite
End If
End While
final:
oRead.Close()
Delay()
TextBox9.Text = "completo"
Buff_escrita(0) = &HED 'done faz o reset ao up
SerialPort1.Write(Buff_escrita, 0, 1)
ModoBite = 0
End Sub
Private Sub Button4_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs)
Try
SerialPort1.Write(Chr(13))
Delay()
Catch ex As Exception
MsgBox("Nao é possivel enviar os dados Verifique se Abriu Porta")
End Try
End Sub
Sub Inicializa_variaveis()
READ = Str$(&HE0)
RACK = Str$(&HE1)
WRITE = Str$(&HE3)
WOK = Str$(&HE4)
WBAD = Str$(&HE5)
DATAOK = Str$(&HE7)
DATBAD = Str$(&HE8)
IDENT = Str$(&HEA)
IDACK = Str$(&HEB)
DONE = Str$(&HED)
End Sub
Private Sub TextBox10_TextChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles TextBox10.TextChanged
Anexo A: Aplicação em VB 2008,net 87
End Sub
Private Sub TextBox11_TextChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles TextBox11.TextChanged
End Sub
Private Sub Button4_Click_1(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button4.Click
TextBox1.Text = ""
End Sub
Private Sub TextBox12_TextChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles TextBox12.TextChanged
End Sub
Private Sub TextBox1_TextChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles TextBox1.TextChanged
End Sub
Private Sub Button5_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button5.Click
Try
SerialPort1.WriteLine(TextBox2.Text + Chr(13))
Catch ex As Exception
MsgBox("abre a porta ")
End Try
End Sub
Private Sub Button6_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button6.Click
Buff_escrita(0) = Asc("+")
Buff_escrita(1) = Asc("+")
Buff_escrita(2) = Asc("+")
Buff_escrita(3) = Asc("A")
Buff_escrita(4) = Asc("T")
Buff_escrita(5) = Asc("D")
Buff_escrita(6) = Asc("L")
Buff_escrita(7) = Asc("+")
Buff_escrita(8) = Asc("+")
Buff_escrita(9) = Asc("+")
Buff_escrita(10) = Asc("+")
Try
SerialPort1.Write(Buff_escrita, 0, 3)
Delay()
MsgBox("Prima_Ok")
Anexo A: Aplicação em VB 2008,net 88
SerialPort1.Write(TextBox3.Text + Chr(13))
MsgBox("ok para Sair Comand Modo")
SerialPort1.Write("ATCN" + Chr(13))
Catch ex As Exception
MsgBox("erro ...")
End Try
End Sub
End Class
Anexo B: Código Assembler 89
Anexo C: Código Assembler
;****************************************************************************** ; Bootloader for Microchip PIC16F873A/876A/877A * ; ; ; Author: Petr Kolomaznik * ; Modified for zigbee by: Mário Silva * ; ; (c) 2001-2010 , * ; Freely distributable * ;****************************************************************************** ; * ; Name of file: bootldra.asm * ; Date: 7th Jul 2004 * ; Version: 1.2 * ; * ; Author: Peter Huemer * ; Company: HTBLA Steyr, Abt. Elektronik / Techn. Informatik * ; Email: [email protected] * ; Url: www.htl-steyr.ac.at * ;****************************************************************************** ; Notes on Version 1.2: * ; - there is no more need for manual quad alignment * ; * ; Notes on Version 1.0 (13.11.2003): * ; - Code must be "quad aligned" (better version is planned) * ; - only "quad aligned" start Addresses of segments * ; - add 3 NOP's at the end of each memory segment, if you cannot be * ; sure, that the last segment address is xxx11 * ;****************************************************************************** ; >>>>>>>> based on: * ;****************************************************************************** ; Bootloader for Microchip PIC16F870/871/873/874/876A/877A * ; (c) 2000-2002, Petr Kolomaznik * ; Freely distributable * ;****************************************************************************** ; * ; Name of file: bootldr.asm * ; Date: 29th Dec 2002 * ; Version: 2.8 * ; * ; Author: Petr Kolomaznik * ; Company: EHL elektronika, Czech Republic * ; Email: [email protected] * ; Url: www.ehl.cz/pic * ; Modified by: Shane Tolmie * ; Company: DesignREM * ; Email: [email protected] * ; Url: www.microchipc.com * ; * ;****************************************************************************** ; How to use this bootloader: *
Anexo B: Código Assembler 90
; - open project bootldr.pjt in MPLAB * ; - check and modify of parameters in the user setting section with <<< mark * ; - make project with MPLAB and MPASM * ; - use any programmer for programming of bootldr.hex to microcontroller * ; - set configuration bits * ; - use PIC downloader program for user program download * ; - check if user program doesn't use the top 214 program memory locations * ; * ; Notes: * ; - tab size for editor is 2 * ; - bootloader is compatible with HI-TECH's and Shane Tolmie's bootl./downl. * ;****************************************************************************** ; 2.80 - 27.08.2005 (Shane Tolmie [[email protected] and Herman Aartsen * ; [email protected]). Added warning note about BOR and dirty power * ; supplies leading to the PIC dying. * ; 2.70 - 24.09.2004 (Shane Tolmie [[email protected] and Peter Huemer * ; [email protected]). Fixed quad-alignment problem with 16F87xA devices. * ; The code used to fail unless the .hex file had a length that wasn't a * ; multiple of 4. * ; 2.60 - 29.12.2002 (Shane Tolmie [[email protected]]) * ; - made it so that frequencies <=4Mhz have XT, and freq >4Mhz have HS * ; configuration in the fuse bits, to enable it to work at all freq with * ; resonators. * ; 2.50 - 28.8.2002 (Shane Tolmie [[email protected]]) * ; - switched off BODEN which resets part if low voltage power supply used * ; (many grateful thanks to Richard ([email protected]) * ; 2.50 - 28.8.2002 (Shane Tolmie [[email protected]]) * ; - switched off BODEN which resets part if low voltage power supply used * ; (many grateful thanks to Richard ([email protected]) * ; 2.20 - 8.8.2001 (Shane Tolmie [[email protected]]) * ; - added watchdog user change, defaults to off (leaving it on can create * ; difficult to track down problems) * ; 2.10 - 3.8.2001 ([email protected]) * ; - substantially reduced size of program * ; - restores USART to reset condition before starting user program * ; - made user program start variable * ; - added trap to avoid unintended running into bootloader * ; - watchdog timeout is directly handled over to user program * ; 2.00 - 30.03.2001 (Shane Tolmie [[email protected]]) * ; - for the 16F876, the 4 instructions in the original .hex file at 0x0000 * ; to 0x0003 are copied to 0x1F00 to 0x1F03, and executed once the * ; bootloader is finished, to jump back to user code. The reset vector in * ; the chip at 0x0000 to 0x0003 points to the bootloader. Inserted a * ; pagesel 0x0000 (2 instructions) at 0x1F00 to make a short jump into a * ; long jump so it would work with .hex files that didnt have a long jump * ; as the first 4 instructions in the .hex file. * ; This addition dramatically increases compatibility with .hex files. * ; 1.06 - 30.03.2001 (Shane Tolmie) * ; - added config bits * ; - program now jumps immediately to user program after download * ; 1.02 - 15.11.2000 * ; - added check of user constants * ; - added support for the new 16F870/1/2 * ; - added errorlevel directive for message 302 and 306 * ;******************************************************************************
Anexo B: Código Assembler 91
errorlevel -302, -306 ; no message 302 and 306 list b=2 ; tabulator size = 2 ;================== User setting section ====================================== list p=16f877a ; <<< set type of microcontroller (16f873a or 16f876a) ; set same microcontroller in the project #define ICD_DEBUG 0 ; <<< if using MPLAB ICD Debugger, moves bootloader down 256 bytes to make room for it [0|1] #define FOSC D'20000000' ; <<< set quartz frequence [Hz], max. 20 MHz #define BAUD D'38400' ; <<< set baud rate [bit/sec] #define BAUD_ERROR D'4' ; <<< set baud rate error [%] #define TIME ; <<< set method of bootloader start PIN/TIME ; PIN : start on low level of trigger pin ; TIME: start on receive IDENT byte in TIMEOUT #define TRIGGER PORTB,7 ; <<< only for PIN - set PORT_X,PIN_NR #define TIMEOUT D'2' ; <<< only for TIME - set time [0.1s], max. 25 sec #define WATCHDOGTIMER 0 ; <<< Watchdog timer default OFF/ON [0|1] ;=================== Configuration ============================================ __IDLOCS H'2100' ; version ID of bootloader IF WATCHDOGTIMER == 0 #define MY_WDT _WDT_OFF ELSE #define MY_WDT _WDT_ON ENDIF IF FOSC<=D'4000000' #define _MYCRYSTAL _XT_OSC ;see datasheet ELSE #define _MYCRYSTAL _HS_OSC ENDIF ;note: for high voltage parts, you can set BODEN_ON, but for low voltage parts ;it resets the circuit continuously! ;NOTE: IF AT ALL POSSIBLE, SET BROWN OUT DETECT TO 'ON' TO AVOID DIRTY POWER ;SUPPLIES KILLING THE PIC MEMORY ;--start email from Herman Aartsen-- ;Dear Shane, ; ;Although I'm still very positive about the PIC16F877 boatloader I have ;recently expierenced a very nasty side effect I think others should know about ;it before they start using it for their rocket detonators, breathing devices ;etc. ; ;At the research institute where I work, I have added the bootloader to the ;firmware of about a 100 sensors. This has proven to be very handy for field ;upgrading, changing calibration tables etc. But after a while sensors started ;coming back. When I readback the code, I noticed a few bits of code had ;changed. Very scary !!! ;
Anexo B: Código Assembler 92
;So I spend some of time finding the cause. I made a little 'spurious write ;detection' program that compares the lower half of the code memory with the ;upper half where I put a mirror of the code. When I programmed this into a ;PIC16F877 (using ICD2) and connected the device to a 'very very dirty power ;supply' I carried out the following experiments: ; ;- with a bootloader, Brownout Detect (BOR)=off, Power Up Timer=off, LVP=on: ;spurious writes after a just few power interrupts; ; ;- without bootloader, same config setting: no problem after many power ;interrupts; ; ;- with bootloader, with BOR on: also no problems after many power interrupts; ; ;Conclusion: never use this bootloader with the BOR switched off! ; ;I think you should put this warning very loud and clear to all the user of ;this bootloader. ; ;Kind Regards, ; ;Herman Aartsen. ; ;Note: most user would not even get the bootloader working if the BOR was ;enabled by default turning on the BOR makes the bootloader inoperable with ;low voltage PIC's. For this reason, and others (including the inability of a ;PIC18F2550 to erase its code protection bits unless the voltage is 5V) I would ;highly recommend running your PIC at 5V and turning the BOR bit on ; ;Shane Tolmie (www.microchipc.com) ; ;--end email from Herman Aartsen-- __CONFIG _CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_ON & _MYCRYSTAL & _WRT_OFF & _LVP_OFF & _DEBUG_OFF & _CPD_OFF ;=============== End of user setting section ================================== ;================== Check User Constants ====================================== IFNDEF FOSC ERROR "FOSC must be defined" ENDIF IFNDEF BAUD ERROR "BAUD must be defined" ENDIF IF FOSC > D'20000000' ERROR "max. quartz frequency = 20 MHz" ENDIF IFNDEF PIN IFNDEF TIME ERROR "wrong start method of bootloader, must be PIN or TIME"
Anexo B: Código Assembler 93
ENDIF ENDIF IF TIMEOUT > D'254' ERROR "max. timeout = 25.4 sec" ENDIF IF ICD_DEBUG != 0 IF ICD_DEBUG != 1 ERROR "ICD debug must be 1 (enabled) or 0 (not used)" ENDIF ENDIF ;========================== Constants ========================================= IF ((FOSC/(D'16' * BAUD))-1) < D'256' #define DIVIDER (FOSC/(D'16' * BAUD))-1 #define HIGH_SPEED 1 ELSE #define DIVIDER (FOSC/(D'64' * BAUD))-1 #define HIGH_SPEED 0 ENDIF BAUD_REAL EQU FOSC/((D'64'-(HIGH_SPEED*D'48'))*(DIVIDER+1)) IF BAUD_REAL > BAUD IF (((BAUD_REAL - BAUD)*D'100')/BAUD) > BAUD_ERROR ERROR "wrong baud rate" ENDIF ELSE IF (((BAUD - BAUD_REAL)*D'100')/BAUD) > BAUD_ERROR ERROR "wrong baud rate" ENDIF ENDIF IF FOSC > D'10240000' #define T1PS 8 #define T1SU 0x31 ELSE IF FOSC > D'5120000' #define T1PS 4 #define T1SU 0x21 ELSE IF FOSC > D'2560000' #define T1PS 2 #define T1SU 0x11 ELSE #define T1PS 1 #define T1SU 0x01 ENDIF ENDIF ENDIF TIMER EQU (D'65538'-(FOSC/(D'10'*4*T1PS))); reload value for TIMER1 (0.1s int) ;>>> ADAPT
Anexo B: Código Assembler 94
IFDEF __16F873A #include <p16f873a.inc> #define ProgHI 0x0FFF ELSE IFDEF __16F876A #include <p16f876a.inc> #define ProgHI 0x1FFF ELSE IFDEF __16F877A #include <p16f877a.inc> #define ProgHI 0x1FFF ELSE ERROR "incorrect type of microcontroller" ENDIF ENDIF ENDIF ;>>> ;>>> ADAPT #define LoaderSize 0x180 ; size of bootloader (not yet optimized) ;>>> ; #define LoaderMain UserStart+5 ; main address of bootloader #define LoaderTop ProgHI-(ICD_DEBUG*0x100) ; top address of bootloader #define LoaderStart (LoaderTop)-LoaderSize+1 ; start address of bootloader #define NumRetries 1 ; number of writing retries #define WRITE 0xE3 ; communication protocol #define WR_OK 0xE4 #define WR_BAD 0xE5 #define DATA_OK 0xE7 #define DATA_BAD 0xE8 #define IDENT 0xEA #define IDACK 0xEB #define DONE 0xED ;=============== Variables ==================================================== buff EQU 0x20 ; RAM address 0x70 reserved for MPLAB-ICD amount EQU 0x71 chk1 EQU 0x72 chk2 EQU 0x73 retry EQU 0x74 address EQU 0x75 tmpaddr EQU 0x77 temp EQU 0x79 time EQU 0x7A count EQU 0x7B ;>>> ADAPT help EQU 0x7C
Anexo B: Código Assembler 95
lcount EQU 0x7d ;>>> ;------------------------------------------------------------------------------ ORG 0x0000 ; reset vector of microcontroller nop ; for compatibility with ICD pagesel Main goto Main ;------------------------------------------------------------------------------ ORG LoaderStart TrapError pagesel TrapError goto TrapError ; trap for unintended running into Bootloader UserStart ; this instruction never gets overwritten clrf PCLATH ; set PCLATH to program page 0 ;>>> ADAPT IFDEF __16F873A nop ; for quad alignment ENDIF ;>>> ; the following 4 instructions get overwritten by user program pagesel UserStart ; set PCLATH to program page of UserStart goto UserStart ; loop for first start without a user program ;>>> ADAPT nop IFDEF __16F873A nop ENDIF ;>>> ;------------------------------------------------------------------------------ Main btfss STATUS,NOT_TO ; run user program after WatchDog-TimeOut goto UserStart start movlw 0x90 ; SPEN = 1, CREN = 1 movwf RCSTA bsf STATUS,RP0 ; bank1 IF HIGH_SPEED == 1 ; USART SYNC=0; SPEN=1; CREN=1; SREN=0; bsf TXSTA,BRGH ; TX9=0; RX9=0; TXEN=1; ELSE bcf TXSTA,BRGH ENDIF bsf TXSTA,TXEN movlw DIVIDER ; baud rate generator movwf SPBRG IFDEF PIN bsf TRIGGER ; for PIN: setting of TRIS for selected pin bcf STATUS,RP0 btfss TRIGGER goto receive ; go to bootloader goto user_restore ; run user program ELSE
Anexo B: Código Assembler 96
bcf STATUS,RP0 movlw TIMEOUT+1 ; for TIME: set timeout movwf time movlw T1SU movwf T1CON ; TIMER1 on, internal clock, prescale T1PS bsf PIR1,TMR1IF call getbyte ; wait for IDENT xorlw IDENT btfss STATUS,Z goto user_restore clrf time ; no more wait for IDENT goto inst_ident ; bootloader identified, send of IDACK ENDIF ;------------------------------------------------------------------------------ receive ; programming call getbyte ; get byte from USART movwf temp xorlw WRITE btfsc STATUS,Z goto inst_write ; write instruction movf temp,w xorlw IDENT btfsc STATUS,Z goto inst_ident ; identification instruction movf temp,w xorlw DONE btfss STATUS,Z ; done instruction ? goto receive ;------------------------------------------------------------------------------ inst_done ; very end of programming ;------------------------------------------------------------------------------ movlw WR_OK call putbyte ; send of byte movlw TIMEOUT+1 movwf time call getbyte ; has built in timeout - waits until done ;------------------------------------------------------------------------------ user_restore clrf T1CON ; shuts off TIMER1 clrf RCSTA bsf STATUS,RP0 clrf TXSTA ; restores USART to reset condition bcf STATUS,RP0 clrf PIR1 goto UserStart ; run user program ;------------------------------------------------------------------------------ inst_ident movlw IDACK ; send IDACK goto send_byte ;------------------------------------------------------------------------------ inst_write call getbyte movwf address+1 ; high byte of address
Anexo B: Código Assembler 97
call getbyte movwf address ; low byte of address call getbyte movwf amount ; number of bytes -> amount -> count movwf count call getbyte ; checksum -> chk2 movwf chk2 clrf chk1 ; chk1 = 0 ;>>> ADAPT1.2 movlw 0x21 ; if (0x2100 <= tmpaddr <= 0x21FF) .......... banksel address subwf address+1,w btfsc STATUS,Z goto adapt12_1end ; no action if data eeprom movf address,w andlw 0x03 ; Bit 0,1 der StartAddresse movwf help movwf lcount ; Zähler für späteres Lesen bcf STATUS,C rlf help ; buffer-offset: (Address & 0x03) * 2 movlw buff addwf help,w goto adapt12_2end adapt12_1end ; no action if data eeprom movlw buff adapt12_2end ; no action if data eeprom movwf FSR ;>>> ADAPT1.2 end ; FSR pointer = buff receive_data call getbyte ; receive next byte -> buff[FSR] movwf INDF addwf chk1,f ; chk1 := chk1 + buff[FSR] incf FSR,f ; FSR++ decfsz count,f goto receive_data ; repeat until (--count==0) checksum movf chk1,w xorwf chk2,w ; if (chk1 != chk2) movlw DATA_BAD btfss STATUS,Z goto send_byte ; checksum WRONG checksum_ok movlw DATA_OK ; checksum OK call putbyte write_byte call write_eeprom ; write to eeprom iorlw 0 movlw WR_OK ; writing OK btfsc STATUS,Z movlw WR_BAD ; writing WRONG ;------------------------------------------------------------------------------ send_byte
Anexo B: Código Assembler 98
call putbyte ; send of byte goto receive ; go to receive from UART ;------------------------------------------------------------------------------ ;************************* putbyte subroutine ********************************* putbyte clrwdt btfss PIR1,TXIF ; while(!TXIF) goto putbyte movwf TXREG ; TXREG = byte return ;************************* getbyte subroutine ********************************* getbyte clrwdt IFNDEF PIN ; for TIME movf time,w btfsc STATUS,Z ; check for time==0 goto getbyte3 btfss PIR1,TMR1IF ; check for TIMER1 overflow goto getbyte3 ; no overflow bcf T1CON,TMR1ON ; timeout 0.1 sec decfsz time,f ; time-- goto getbyte2 retlw 0 ; if time==0 then return getbyte2 bcf PIR1,TMR1IF movlw high TIMER movwf TMR1H ; preset TIMER1 for 0.1s timeout bsf T1CON,TMR1ON ENDIF getbyte3 btfss PIR1,RCIF ; while(!RCIF) goto getbyte movf RCREG,w ; RCREG return ;******************** write eeprom subroutine ********************************* write_eeprom ;>>> ADAPT1.2 movlw 0x21 ; if (0x2100 <= tmpaddr <= 0x21FF) .......... subwf address+1,w btfsc STATUS,Z goto adapt12_3end ; no action if data eeprom banksel EECON1 bsf EECON1,EEPGD ; EEPGD = 1 -> program memory banksel address movf address,w andlw 0xfc bsf STATUS,RP1 movwf EEADR ; EEADR = low addr bcf STATUS,RP1 movf address+1,w bsf STATUS,RP1
Anexo B: Código Assembler 99
movwf EEADRH ; EEADRH = high addr movlw buff movwf FSR ;read memory and write to buffer front adapt12_loop1 bcf STATUS,RP1 movf lcount,w btfsc STATUS,Z goto adapt12_4end ; no more read operation from Flash Memory banksel EECON1 bsf EECON1,RD nop nop bcf STATUS,RP0 movf EEDATH,w movwf INDF incf FSR,f ; FSR++ movf EEDATA,w movwf INDF incf FSR,f ; FSR++ incf EEADR bcf STATUS,RP1 decf lcount decf address incf amount incf amount goto adapt12_loop1 ;read memory and write to buffer tail adapt12_4end movf amount,w movwf help addlw buff ; SchreibAddresse in Puffer movwf FSR bcf STATUS,C rrf help ; Anzahl der Programmwoerter movf address+1,w bsf STATUS,RP1 movwf EEADRH bcf STATUS,RP1 movf address,w bsf STATUS,RP1 movwf EEADR ; EEADR/EEADRH steht auf erster zu schreibender Addresse bcf STATUS,RP1 movf help,w bsf STATUS,RP1 addwf EEADR,f btfsc STATUS,Z incf EEADRH,f adapt12_loop2 bsf STATUS,RP1 movf EEADR,w
Anexo B: Código Assembler 100
andlw 0x03 ; while (EEADR & 0x03) != 0 btfsc STATUS,Z goto adapt12_3end bsf STATUS,RP0 bsf EECON1,RD nop nop bcf STATUS,RP0 movf EEDATH,w movwf INDF incf FSR,f ; FSR++ movf EEDATA,w movwf INDF incf FSR,f ; FSR++ incf EEADR bcf STATUS,RP1 incf amount incf amount goto adapt12_loop2 adapt12_3end ;>>> ADAPT1.2 end movf address,w movwf tmpaddr ; tmpaddr = address movf address+1,w movwf tmpaddr+1 clrf count ; count=0 write_loop movlw NumRetries+1 ; retry = NumRetries+1 movwf retry w_e_l_1 movf amount,w subwf count,w ; while (count<amount) btfsc STATUS,C retlw 1 movf count,w addlw buff ; set buffer pointer movwf FSR w_e_l_2 movlw 0x21 ; if (0x2100 <= tmpaddr <= 0x21FF) .......... subwf tmpaddr+1,w bsf STATUS,RP1 bsf STATUS,RP0 ; (bank3) btfsc STATUS,Z goto data_eeprom ; goto data_eeprom program_eeprom bsf EECON1,EEPGD ; EEPGD = 1 -> program memory clrf STATUS movlw high (LoaderStart) ; if (tmpaddr >= LoaderStart) ............... subwf tmpaddr+1,w movlw low (LoaderStart) ; mask Booloader, [ICD-Debugger], btfsc STATUS,Z ; __IDLOCS & __CONFIG subwf tmpaddr,w btfsc STATUS,C goto next_adr ; next address
Anexo B: Código Assembler 101
goto w_e_l_3 data_eeprom bcf EECON1,EEPGD ; EEPGD = 0 -> data memory clrf STATUS w_e_l_3 movf tmpaddr,w bsf STATUS,RP1 movwf EEADR ; EEADR = low tmpaddr bcf STATUS,RP1 movf tmpaddr+1,w ; if (tmpaddr < 0x0004) ..................... btfss STATUS,Z goto w_e_l_4 movlw 4 subwf tmpaddr,w btfsc STATUS,C goto w_e_l_4 bsf STATUS,RP1 ; (bank3) bsf STATUS,RP0 btfss EECON1,EEPGD ; skip if (EEPGD) goto w_e_l_31 bcf STATUS,RP0 ; (bank2) ;>>> ADAPT IFDEF __16F873A movlw low UserStart+2 ; EEADRL + low UserStart+2 ELSE IFDEF __16F876A movlw low UserStart+1 ; EEADRL + low UserStart+1 ELSE IFDEF __16F877A movlw low UserStart+1 ; EEADRL + low UserStart+1 ELSE ERROR "incorrect type of microcontroller" ENDIF ENDIF ENDIF ;>>> addwf EEADR,f ; (relocated first 4 user instructions) w_e_l_31 clrf STATUS ; (bank0) movlw high UserStart ; EEADRH = high UserStart goto w_e_l_5 w_e_l_4 movf tmpaddr+1,w ; EEADRH = high tmpaddr w_e_l_5 bsf STATUS,RP1 movwf EEADRH ; set EEADRH movf INDF,w movwf EEDATH ; EEDATH = buff[count] incf FSR,f movf INDF,w movwf EEDATA ; EEDATA = buff[count+1] bsf STATUS,RP0 bsf EECON1,WREN ; WREN=1 movlw 0x55 ; EECON2 = 0x55 movwf EECON2 movlw 0xAA ; EECON2 = 0xAA
Anexo B: Código Assembler 102
movwf EECON2 bsf EECON1,WR ; WR=1 nop ; instructions are ignored nop ; microcontroller waits for a complete write clrf STATUS ;>>> ADAPT banksel EECON1 btfsc EECON1,EEPGD ; skip if (EEPGD=0 / write to EEPROM) goto ver_flash ;>>> banksel PIR2 wait_write clrwdt btfss PIR2,EEIF ; necessary for a write to data eeprom goto wait_write bcf PIR2,EEIF bsf STATUS,RP0 ; (bank3) bsf STATUS,RP1 bcf EECON1,WREN ; WREN=0 bsf EECON1,RD ; RD=1 nop nop bcf STATUS,RP0 ; (bank2) decf FSR,f movf INDF,w ; if ((EEDATH != buff[count]) || (EEDATA != buff[count+1])) xorwf EEDATH,w btfss STATUS,Z goto w_e_l_6 ; repeat write incf FSR,f movf INDF,w xorwf EEDATA,w btfsc STATUS,Z goto next_adr ; verification OK, next address w_e_l_6 clrf STATUS ; (bank0) decfsz retry,f goto w_e_l_1 ; if (--retry != 0) repeat write retlw 0 ; else return 0 (BAD) next_adr ;>>> ADAPT banksel count ; bcf STATUS,RP1 ;>>> movlw 2 ; count := count + 2 addwf count,f incf tmpaddr,f ; tmpaddr := tmpaddr + 1 btfsc STATUS,Z incf tmpaddr+1,f goto write_loop ;>>> ADAPT
Anexo B: Código Assembler 103
ver_flash banksel PIR2 bcf PIR2,EEIF banksel EECON1 bcf EECON1,WREN ; WREN=0 banksel EEADR movf EEADR,w andlw 0x03 sublw 0x03 btfss STATUS,Z goto next_adr ; if (EEADR & 0x03) = 0x03 movlw 3 subwf EEADR,f ; EEADR <- EEADR - 3 banksel help movlw 4 movwf help ; help <- 4 movlw 7 subwf FSR,f ; FSR <- FSR - 7 ver_fl_1 nop banksel EECON1 bsf EECON1,RD ; RD=1 nop nop nop nop nop nop movf INDF,w ; if ((EEDATH != buff[count]) || (EEDATA != buff[count+1])) banksel EEDATH xorwf EEDATH,w btfss STATUS,Z goto ver_fl_2 ; repeat write incf FSR,f movf INDF,w xorwf EEDATA,w btfsc STATUS,Z goto ver_fl_3 ver_fl_2 ; invalid verify banksel tmpaddr movlw 0x0fc andwf tmpaddr,f ; clear least significant two bits in [tmpaddr] movlw 6 subwf count,f ; count <- count - 6 goto w_e_l_6 ver_fl_3
Anexo B: Código Assembler 104
banksel EEADR incf EEADR,f incf FSR,f banksel help decfsz help,f goto ver_fl_1 goto next_adr ;>>> ;------------------------------------------------------------------------------ END