mário alexandre dos santos marinho da...

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 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


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


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).


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.


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:


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.


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.


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


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.


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


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.


Ilustração 9, Procedimentos de instalação do Cluster Multi Hop.

Ilustração 10, Atribuição de Cluster ID 1.



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


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.


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 13, Atribição de Cluster ID 4.

Ilustração 14, Rede multi cluster e nó de fronteira.


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.


- 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.


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


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.


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

https://standards.ieee.org/regauth/oui/forms/OUT-form.shtml


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


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.


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.


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


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.


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.


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.


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.


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.

http://en.wikipedia.org/wiki/Checksum


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.


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.


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.


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.


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.


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.


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.

http://pt.wikipedia.org/wiki/Criptografia

http://pt.wikipedia.org/w/index.php?title=Cifra_de_bloco&action=edit&redlink=1

http://pt.wikipedia.org/wiki/Estados_Unidos



http://pt.wikipedia.org/wiki/Algoritmo_de_chave_sim%C3%A9trica


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.


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.


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.


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.


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.


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”


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

http://www.zigbee.org/

http://www.microchip.com/

http://www7.informatik.uni-erlangen.de/~fengchen/omnet/802154/802.15.4-2006.pdf

http://www7.informatik.uni-erlangen.de/~fengchen/omnet/802154/802.15.4-2006.pdf

http://www.ee.oulu.fi/~kk/dtsp/tutoriaalit/ZigBeeSpecification2.pdf

http://www.eetasia.com/ART_8800551784_499488_AN_dfd37dec.HTM

http://wndw.net/pdf/wndw-pt/wndw-pt-ebook.pdf

http://www.cs.uc.edu/~cordeicm/course/wirelessbroadband-text.pdf

http://wsl.stanford.edu/~andrea/Wireless/SampleChapters.pdf

https://publications.theseus.fi/bitstream/handle/10024/15812/FinalThesis_Samosuyev.pdf

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:


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


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.


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


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.


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


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


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


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


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.


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.


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.


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


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


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.


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


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).


Figura 8 – Associação gráfica de sequência de mensagens - Coordenador


Figura 9 – Associação gráfica de sequência de mensagens - Dispositivo


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


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




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"


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


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



Dim oFile As System.IO.File

Dim oRead As System.IO.StreamReader

oRead = oFile.OpenText(TextBox13.Text)


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


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


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


System.EventArgs)

Try

SerialPort1.Write(Chr(13))

Delay()


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


As System.EventArgs) Handles TextBox10.TextChanged


End Sub



End Sub

Private Sub Button4_Click_1(ByVal sender As System.Object, ByVal e As


TextBox1.Text = ""

End Sub



End Sub



End Sub



Try

SerialPort1.WriteLine(TextBox2.Text + Chr(13))


MsgBox("abre a porta ")

End Try

End Sub



Buff_escrita(0) = Asc("+")



Buff_escrita(3) = Asc("A")

Buff_escrita(4) = Asc("T")

Buff_escrita(5) = Asc("D")

Buff_escrita(6) = Asc("L")





Try

SerialPort1.Write(Buff_escrita, 0, 3)

Delay()

MsgBox("Prima_Ok")


SerialPort1.Write(TextBox3.Text + Chr(13))

MsgBox("ok para Sair Comand Modo")

SerialPort1.Write("ATCN" + Chr(13))


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: *


; - 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 * ;******************************************************************************


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 !!! ;


;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"


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


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


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


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


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


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


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


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


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


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


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


banksel EEADR incf EEADR,f incf FSR,f banksel help decfsz help,f goto ver_fl_1 goto next_adr ;>>> ;------------------------------------------------------------------------------ END

mário alexandre dos santos marinho da...

Documents