Novo satélite brasileiro e as novas possibilidades para as telecomunicações no Brasil

A notícia foi dada pelo Jornal do Brasil e interessa a todos que acompanham a área de telecomunicações no Brasil. É importante para o país que dependa cada vez menos de satélites estrangeiros para comunicação sigilosa.

Satélite vai permitir universalização da banda larga em todo o país

A presidenta Dilma Rousseff visitou nesta quarta-feira (23) as obras de construção do centro de controle do satélite que vai levar internet de alta velocidade a regiões longínquas do país, onde ainda não é possível chegar com cabos de fibra ótica. O Satélite Geoestacionário de Defesa e Comunicações Estratégicas está sendo fabricado na França desde janeiro de 2014 e o lançamento deve ocorrer entre dezembro de 2016 e fevereiro de 2017.

“Ele vai ser lançado em parceria com a França e é um patamar tecnológico que temos de alcançar. Lançar o satélite, mas, em um segundo momento, sermos capazes de produzir esse satélite no Brasil”, disse Dilma. A construção do equipamento está sendo acompanhada pela Visiona, uma empresa brasileira de cooperação entra a Telebras e a Embraer.Durante a visita às obras da antena de monitoramento do satélite, no 6º Comando Aéreo Regional em Brasília, o ministro das Comunicações, André Figueiredo, explicou que o equipamento é um grande instrumento para alcançar a universalização do acesso à internet, por meio da banda KA, dentro do novo Programa Nacional de Banda Larga.

“Queremos chegar, até o fim de 2018, com fibra ótica a 70% dos municípios brasileiros que representam 95% da população, propiciando não apenas a integração da população brasileira mas o acesso ao conhecimento”, disse Figueiredo. “No restante onde não conseguirmos chegar com fibra ótica, vamos com satélite, que vai servir como redundância para que possamos chegar em locais mais longínquos, mesmo já cobertos com fibra ótica. Por exemplo, na Região Nordeste, vamos chegar em Fernando de Noronha”, explicou.

O equipamento deve entrar em operação no primeiro trimestre de 2017. Um segundo ponto de monitoramento será montado em outro centro de operações no Rio de Janeiro.

Segurança Nacional

Além de internet, o satélite tem o objetivo de trazer mais segurança às comunicações estratégicas e militares do governo brasileiro, utilizando a banda X, faixa destinada exclusivamente ao uso militar. Segundo o comandante do Centro de Operações Espaciais, coronel Hélcio Vieira Júnior, o satélite vai cobrir todo o território brasileiro, o Atlântico Sul e grande parte da área de interesse do país, do Haiti até a Antártica.
“Militarmente falando, ele vai possibilitar que façamos comando e controle de todos os tipos de ações em que as Forças Armadas estão envolvidas, desde combate a ilícitos nas fronteiras e ajuda humanitária até, se for o caso, ações realmente militares”, disse.
O projeto do satélite geoestacionário é uma parceria entre os ministérios das Comunicações e da Defesa e tem investimento de R$ 1,7 trilhão. Hoje, segundo as pastas, as comunicações militares brasileiras são feitas por meio de aluguel da banda X em dois satélites privados, ao custo anual de R$ 13 milhões. Quando o satélite geoestacionário do Brasil entrar em operação, apenas um dos contratos será mantido, como garantia em caso de falha do novo satélite.

O satélite geoestacionário, segundo o coronel Vieira, é o primeiro do Programa Estratégico de Sistemas Espaciais, do Ministério da Defesa, que inclui vários grupos de satélites.

O primeiro visa a levar muitas informações a pontos distantes. Além do satélite geoestacionário, o grupo terá satélites de sensoriamento remoto que vão possibilitar o monitoramento de toda a fronteira seca e molhada e o controle do tráfego marítimo. “Além disso, estão previstos satélites de geoposicionamento, a exemplo do GPS americano, que vão permitir que o governo brasileiro tenha um referencial de tempo nacional. Vão melhorar muito nossos sistemas bancário, de transmissão de energia e de bolsa de valores, entre outros”, afirmou.

Dicas de implementação de IPv6 em microcontroladores.

O artigo abaixo se encontra no site do EETimes, e é muito importante em nossos dias, onde a mudança de padrões para a internet começa a ser testada. A implementação do IPv6 em sistemas embarcados poderá ser muito importante nesta mudança.

IPv6 em um microcontrolador
Robert Muchsel
Uma das forças motrizes da mudança do PIv4 para o IPv6 tem sido dispositivos embarcados de baixo custo, que estão se conectando a um passo acelerado. Mas espremer toda a suíte de protocolos IPv6 em um pequeno microcontrolador 8-bits é um esporte radical de primeira ordem. Aqui estão algumas dicas de alguém que fez isto com sucesso.

O espaço de endereços para a Internet está ficando pequeno. Enquanto alguns endereços IPv4 ainda estão por ser alocados, e hacks como o IP masqueradinge aluguel de endereços temporários atrasaram o momento, nós todavia acabaremos ficando sem endereços nos próximos anos. Para garantir que futuros dispositivos conectados à Internet tenham endereços únicos, a próxima geração do Internet Protocol, IPv6, estende o espaço de endereçamento bem acima da imaginação humana: 2¹²⁸, que é cerca de 6.67 x 10²³ endereços por metro quadrado de nosso planeta; em outras palavras, bastante.
Tendo endereços suficientes elimina a necessidade de Network Address Translation (NAT) (também conhecido como mascaramento de IP), aluguel temporário de endereço, e outras correções necessárias para conservar os bem racionados endereços IPv4. A indústria espera um grande número de dispositivos de rede clássicos como computadores desktop e servidores, mas um tremendo número de pequenos dispositivos - incluindo dispositivos sem fio e móveis "sempre conectados", como celulares e PDAs, e sensores instalados em qualquer coisa desde carros até medidores de água de refrigeradores - irá mudar a natureza do tráfego de Internet como conhecemos hoje.
Claro, o IPv6 faz mais do que simplesmente estender o espaçamento de endereço. Este upgrade do IPv4 (não há IPv5 - o ID de protocolo 5 foi usado para o Internet Stream Protocol, RFC 1819) torna a configuração de nó fácil e automática - outro ponto favorável para aplicações embarcadas. Isto também faz a rede como um todo ser mais robusta e extensível, e adiciona características de segurança e suporte para qualidade de serviço não disponíveis anteriormente. Mais importante, o IPv6 também ajuda na velocidade e simplificação de roteamento, que se tornaram um gargalo à medida que o uso da Internet aumentou.
O reestruturado e melhor IPv6 já é distribuído amplamente e configurado para gradualmente substituir o IPv4. Muitos, se não todos os roteadores já estão atualizados. Tendo progredido além do estágio de protótipo, agora forma uma parte padrão da maioria dos sistemas operacionais desktop, incluindo Windows XP, Mac OS X, Solaris e Linux. Enquanto isto stacks IPv4/IPv6 duais permitem ambientes mistos e uma migração gradual para o IPv6. (Onde o IPv6 não é suportado ainda, nós podem ainda se comunicar através de "túneis" sobre intermediários IPv4).
Este artigo introduz algumas das mudanças no IPv6 e sugere dicas práticas para adicionar rede IPv6 a dispositivos baseados em pequenos microcontroladores como o 8051. Assume-se que o leitor possua conhecimento básico de redes e uma razoável experiência com IPv4.

Visão geral do IPv6
Um aspecto importante da capacidade de auto-configuração do IPv6 é a forma que os endereços são usados. Um endereço de 128 bits IPv6 é tipicamente dividido em um prefixo de 64 bits (chamado de net bits, que define a sub-rede) e 64 bits de host. O prefixo, que também mostra o escopo de um endereço, pode ser atribuído pelo provedor de rede e enviado por broadcast por roteadores, ou ele pode ser local ao site. Geralmente, os primeiros 48 dos bits de rede são atribuídos pelo ISP; os outros 16 estão dentro dos cuidados do proprietário do site.
Na Ethernet, os 64 bits de host podem ser derivados do endereço físico único de 48 bits, também conhecidos como endereço (veja barra lateral sobre endereços EUI-64) media access control (MAC). Em outras palavras, ao contrário do IPv4 onde os endereços IP e os endereços MAC são distintos, cada nó IPv6 combina todos endereços em um só e possui um endereço IP válido assim que ele se conecta. Novamente, ao contrário do IPv4 (que requer ajuda de um servidor BOOTP/DHCP), todos os nós IPv6 podem ser auto-configuráveis, mesmo na falta de um servidor. Para comunicar globalmente, o nó deve solicitar ou escutar os broadcasts do roteador contendo o prefixo e então combinar o prefixo com o EUI-64.

Endereços EUI-64
O identificador único extendido de 64 bits, ou EUI-64, foi definido em antecipação à possível sobrecarga do espaço de endereçamento único de 48 bits (EUI-48). Tanto o EUI-48 quanto o EUI-64 definem os primeiros 24 bits como o Company_ID, que é administrado pela IEEE Registration Authority Committee (http://standards.ieee.org/regauth). A organização proprietária do respectivo Company_ID atribui e administra os bits restantes.
A RFC 2373 descreve como inserir um par de valores de 8 bits (FF e FE) depois do terceiro octeto no meio do MAC de 48 bits para derivar o EUI-64.
Por exemplo, se 00-60-35 é o Company_ID e o endereço MAC de 48 bits de um nó é 00-60-35-23-45-67, o EUI-64 deste nó será 00-60-35-FF-FE-23-45-67.
Para gerar um endereço IPv6 que especifique aquele nó suficientemente para a rede local, o prefixo FE80:0000:0000:0000 é inserido e, seguindo as regras da RFC 2373, o bit 1 no primeiro octeto do EUI-64 é setado: FE80:0000:0000:0000:0260:35FF:FE23:4567.

Endereços IPv6 são escritos em notação hexadecimal e em grupos de 16 bits. Por exemplo:

3FFE:AAAA:BBBB:CCCC:0260:35FF:FE8D:6EE9

é um endereço de escopo global. A mesma máquina teria o endereço de "link local" FE80::0260:35FF:FE8D:6EE9, onde o FE80::/64 é o prefixo para endereços de link local, (o número depois da barra mostra o comprimento do prefixo, neste caso 64, e :: representa zeros). O host de loopback (127.0.0.1 na linguagem IPv4) é simplesmente ::1. Endereços locais de site possuem um prefixo de FEC0::/10, mas já que não há equivalente direto de endereços locais de site no IPv4, estes endereços são raramente usados hoje.
Já que longos endereços hexadecimais de 128 bits são difíceis para humanos entenderem, eles são normalmente escondidos por trás de nomes domain name system (DNS) como www.embedded.com. Um servidor DNS capaz de usar IPv6 (por exemplo, BIND9) é necessário para servir endereços de IPv6. A tradução de endereços IPv6 não incorpora fundamentalmente novos conceitos, então uma entrada de endereço IPv6 no DNS seria criada, por exemplo, como:

IN AAAA 3FFE:AAAA:BBBB:CCCC:0260:35FF:FE8D:6EE9

ao invés do similarmente formatado registro IN A usado no IPv4. O uso do DNS é fortemente encorajado, já que se espera mudanças mais frequentes nos prefixos de IPv6 do que de endereços IPv4. Renumeração de rede é muito mais fácil com o IPv6 e pode até mesmo ser automatizado.
O IPv6 inclui tanto endereços de unicast quanto multicast. Além disto, ele define um novo destino de anycast. Um pacote endereçado para um IP de anycast é entregue ao mais próximo ou melhor de vários hosts disponíveis. O anycast ajuda a balancear cargas através do roteamento e é um avanço considerável sobre o round-robin DNS (usado no IPv4), que não leva em conta detalhes de roteamento.

Camadas superiores
O IPv6 mantém as camadas superiores de protocolo, UDP e TCP, sem mudanças. Contudo, o cabeçalho de pacote IP é modificado para acomodar os endereços maiores. O cabeçalho de pacote IP é também limpo e simplificado para ser alinhado em 64 bits, para o benefício de roteadores, para que sempre tenham um comprimento fixo.
O checksum do cabeçalho IP não é mais usado porque o UDP e TCP possuem checksums que incluem partes daquele cabeçalho. Roteadores podem rotear pacotes mais rapidamente se eles não tiverem que primeiro recalcular o checksum do cabeçalho em cada pacote. Para compensar a potencial corrupção de cabeçalho de pacote IP, o checksum de camada mais alta é feito mandatório no UDP. Era opcional em sistemas IPv4, apesar de muitos hosts usarem ele.
Uma modificação interessante é a substituição do Address Resolution Protocol (ARP) do IPv4 com o novo Neighbor Discovery Protocol (NDP), que é parte do Internet Control Message Protocol versão 6 (ICMPv6). Ao invés de mandar broadcasts de requisição de resolução de endereços para todos os hosts, o IPv6 mapeia grupos de multicasts e endereços de IPv6 de uma forma que elimina broadcasts e assegura que um dado nó receba (quase) somente o trafego que é de interesse dele (veja a barra lateral sobre grupos de multicast).

Grupos Multicast
Um endereço multicast que é computado como função do endereço do nó é chamado um endereço de multicast de nó solicidado. O algoritmo completo é definido na RFC 2373. Em resumo, o endereço multicast de nó solicitado é formado tomando-se os 24 bits de ordem menor do endereço e anexando aqueles bits ao prefixo FF02:0:0:0:0:1:FF00::/104.
Por exemplo, o endereço de nó FE80::260:35FF:FE23:4567 se torna FF02::1:FF23:4567.

Os detalhes do ICMPv6, multicasting e NDP estão além do escopo deste artigo. Mais informação sobre estes e outros tópicos está disponível em www.ipv6.org.

IPv6 embarcado
O novo mundo de dispositivos embarcados traz o TCP/IP para as menores ferramentas e as conecta à rede. Enquanto a visão da torradeira em rede de forma justa morreu com o desaparecimento de certas companhias de startup, a conectividade é uma característica desejável para outros dispositivos do dia a dia, tais como medidores de energia, gravadores de vídeo pessoais e máquinas de respostas.
Há várias abordagens para se adicionar redes TCP/IP a dispositivos embarcados. Uma prática comum é usar um sistema operacional, tais quais VxWorks, Windows CE, ou Linux, com uma suíte de protocolo TCP/IP incluída. Se estas soluções não se adequam à sua plataforma, você pode adicionar um de um grande número de implementações de terceiros do stack TCP/IP para quase qualquer um sistema operacional real-time.

Micro IPv6
Se hardware muito potente (processador e memória) está fora de questão em seu sistema, parecerá difícil implementar o IPv6. Muitos sistemas embarcados, por exemplo, possuem menos de 64KB para código e 128KB para dados, incluindo toda a memória disponível para o OS, stack TCP/IP com suporte ao IPv6 e a própria aplicação.
Felizmente, a implementação completa de todas as funções do IPv6 não é tecnicamente necessária em várias áreas. Estas áreas são esclarecidas no documento InternetNode "Requerimentos mínimos de ferramentas IPv6 para redes de baixo custo" (este documento, juntamente com outros, está disponível em http://www.taca.jp/docs.html). Em particular, muitas funções de roteamento são opcionais. Por exemplo, a segurança é frequentemente também disponível no nível de aplicação (especialmente se a aplicação tem que dar suporte ao IPv4). O IPv6 pode ser canalizado sobre redes IPv4 existentes ("6over4", no jargão), mas esta é outra área onde o código pode ser removido de end nodes.
Na Dallas Semiconductor, nós modificamos uma suíte de protocolo IPv4 mínima para compatibilidade com IPv6. Nós tínhamos como alvo um microcontrolador baseado em 8051, o DS80C400, com 64KB de ROM^[1].
Quando nós começamos a implementar o IPv6 juntamente com o IPv4, nós fomos tentados a simplesmente duplicar o código, por exemplo ao criar um módulo TCP6 próximo de um TCP4. Isto foi eliminado, no entanto, por nosso apertado "orçamento" de memória. Ao invés de criar um segundo set de rotinas, nós modificamos implementações existentes de protocolo de alto nível (TCP, UDP, e outros) para trabalhar tanto com IPv4 quanto com IPv6.
A realidade é que aplicações existentes hoje suportam IPv4 e a vasta maioria das novas aplicações irão ainda operar sob o IPv4, não IPv6. Para justificar o suporte ao IPv6 do lado da aplicação, o stack de rede tem que tornar o menos doloroso possível adicionar suporte IPv6 a uma aplicação. Por exemplo, uma implementação que tem uma função socket() para IPv4 e uma função separada socket6() para IPv6 não será provavelmente bem recebida pelos desenvolvedores. Mantendo as implementações de protocolos de alto nível e a API os mesmos para ambas versões tornará mais fácil para o programador de aplicação adaptar-se às mudanças.
Nós rapidamente descobrimos que um número de otimizações eram necessárias para espremer o IPv6 em nossa pequena ROM. Além de estabelecer limites óbvios como o tamanho máximo de pacote suportado, uma idéia que nos salvou de muita dor de cabeça foi sempre usar endereços de 128 bits de tamanho, mesmo com o IPv4. Já que o prefixo ::0/96 (12 bytes de zeros no início) não é atualmente usado pelo IPv6 com exceção do localhost ::1, nós declaramos todos os endereços começando com ::0/96 como sendo endereços IPv4 e colocamos os endereços IPv4 de fato nos restantes 32 bits. Isto eliminou um grande número de construções if-then-else, tornou desnecessários flags de endereço de protocolo, e simplificou enormemente a passagem de parâmetros. É verdade que não há mais localhost IPv6 mais, mas o localhost IPv4 (127.0.0.1) ainda funciona e, quando se fala consigo mesmo, ninguém realmente importa muito com qual o protocolo usado.

Tabela 1: O tamanho do código TCP/IP na ROM do DS80C400
Módulo	Tamanho de código	IPv4	IPv6	Compartilhado
ARP	1111	X
DHCP	2366	X
ICMP	1949	X
IGMP	1346	X
IP	2487	X
ICMP6/Ping6	3346		X
IP 6	6999		X
NDP6	7962		X
Driver Ethernet	2677			X
TCP	10494			X
TFTP	584			X
UDP	1225			X
Tamanho total	42546	9259	18307	14980

Tabela 1 mostra o tamanho de código para cada módulo na suíte revisada de protocolo TCP/IP. O código foi escrito em assembler para 8051.

Preparar, apontar, fogo!
IPv6 está se tornando mais importante. Suporte a esta tecnologia será crucial para o sucesso de muitos dispositivos embarcados vindouros. Além de melhorar o protocolo IP, IPv6 fornece auto-configuração, um número virtualmente ilimitado de endereços IP e alguns alinhamentos do protocolo IP e do processo de roteamento.
A implementação do IPv6 em um dispositivo embarcado pode ser cheio de manhas, e você terá que fazer compromissos. Os benefícios, contudo, valem a pena, e não é de forma alguma impossível - mesmo em um microcontrolador de 8 bits com 64KB de ROM.

Robert Muchsel é um engenheiro de software senior na Dallas Semiconductor. Ele possui um diploma em ciências da computação do Instituto Federal Suíço de Tecnologia em Zurique e tem desenvolvido software por 12 anos. Seu endereço de e-mail é robert.muchsel@dalsemi.com.

Notas finais
1. A porção IPv6 do software do DS80C400 foi desenvolvido em colaboração com InternetNode, um empreendimento conjunto de Yokogawa e Wide Research Institute.

BodyCom: nova tecnologia de Personal Area Network

Se alguém já jogou alguma vez Metal Gear Solid no Playstation, vai se lembrar dos PAN cards, que Snake tinha que conseguir para abrir as várias portas do complexo de Shadow Moses. Talvez muitos não saibam, mas as tecnologias de rede utilizando o corpo humano estão se desenvolvendo, e uma adição a este campo foi feita estes dias pela Microchip, com a publicação em seu site de uma introdução à tecnologia batizada por eles de BodyCom.
A tecnologia foi criada para ser uma rede de curto alcance, onde o principal meio de comunicação é o corpo humano. A comunicação é iniciada quando os dispositivos estão há poucos centímetros do corpo humano, ou quando o sensor de toque for acionado.
Qual a vantagem de uma rede que só se comunica quando há uma grande proximidade? É fácil entender como uma rede wireless pode ser útil. As vantagens do BodyCom ficam por conta da segurança, em primeiro lugar. A aplicação não precisará se preocupar bastante com segurança, pois não há tanta facilidade em se "sniffar" os pacotes de uma pessoa. Por outro lado, como a comunicação é iniciada quando o usuário tocar o dispositivo específico, ele não precisa de usar as mãos para ativar um controle ou algo do gênero (bom quando você chegar em casa debaixo de chuva e com as mãos cheias de compras, não?).
Por causa da alta permissividade do corpo humano a baixas frequências, a comunicação é realizada entre 60KHz e 30MHz. O sinal é acoplado capacitivamente pelo corpo humano usando um Amplitude Shift Key (ASK) de baixa frequência.
Segundo a Microchip, o BodyCom foi desenvolvido visando os seguintes objetivos:

1. Consumo muito baixo, principalmente do dispositivo móvel.
2. Resposta rápida do sistema.
3. Comunicação estável e robusta, com detecção de falha.
4. Campo de ação limitada (para permitir a comunicação apenas quando houver o toque da pessoa no dispositivo).
5. Custo e complexidade baixos.

Por usar acoplamento capacitivo, sinais de frequência mais baixa possuem amplitude menor, requerendo que sinais de frequência baixa possuam amplitude maior. Além disto, o dispositivo móvel, operando a bateria, deve ter o consumo bem reduzido. Isto influenciou nas escolhas de frequências de comunicação. Assim, o dispositivo móvel recebe a uma frequência de 128KHz, enquanto transmite a 8MHz.
A Microchip detalha então como podemos implementar seu sistema de comunicações em seu datasheet de 26 páginas. É um arquivo bem completo, com todos os esquemáticos e cálculos necessários. O sistema obviamente é feito para ser usado com os microcontroladores PIC.

MiWi: Criando redes MiWi com PIC18F4550

Depois de nossa série sobre o protocolo MiWi, chega a hora de colocar tudo em prática. Assim, vamos criar aqui um projeto de redes MiWi com o PIC. Vou selecionar o PIC18F4550, pois depois poderemos atualizar o projeto, adicionando o controle através da porta USB.
Se vocês perderam algum dos posts anteriores, podem acessá-los pela lista abaixo:
1- MiWi: Dispositivos e topologias de rede;
2- MiWi: Endereçamento;
3- MiWi: Relatórios de protocolo;
4- MiWi: Mensagens de Stack e Serviços
5- MiWi: Segurança
Como a biblioteca da Microchip para o MiWi foi desenvolvida recentemente, há ainda alguns bugs e também muitas atualizações. Ela é fornecida com o Microchip Application Libraries, e a última versão disponível agora, enquanto escrevo este artigo, é a versão de junho de 2011 (Stack MiWi 4.2). Quem estiver com sua versão desatualizada, é bom atualizar.

Hardware do projeto

Desenhamos o circuito do projeto no KiCad, que pode ser visto abaixo:

Criamos o componente MRF24J40MA, já que o KiCad não o possui. Você poderá obter todos os datasheets relacionados a este módulo no site da Microchip.
O módulo MRF24J40MA é o módulo que fará todo o trabalho de transmissão e recepção de pacotes. Você o controla via barramento SPI. Ele na verdade é um transceiver feito pela Microchip para os protocolos ZigBee ou MiWi... Mas como um transceiver, você poderá criar qualquer protocolo de comunicação com ele. O Stack MiWi não está no módulo, mas é implementado pelas bibliotecas da Microchip.
Para você ter uma visão geral dos registradores disponíveis deste módulo, procure pelo datasheet do circuito integrado principal dele, o MRF24J40. Há ainda uma versão deste módulo de maior alcance, chamado de MRF24J40MB.
A alimentação do módulo é de 3.3V. Para simplificar o desenho acima, não incluímos a fonte. Portanto, quando você for implementar este projeto, lembre-se de incluí-la.

Incluindo os arquivos do projeto

Vamos agora ao PCAD, e vamos criar um novo projeto com PICF4550. Os arquivos que devemos incluir são os arquivos abaixo:

Arquivo	Pasta
Console.c	\Microchip Solutions\Microchip\WirelessProtocols\
MSPI.c	\Microchip Solutions\Microchip\WirelessProtocols\
SymbolTime.c	\Microchip Solutions\Microchip\WirelessProtocols\
MiWi.c	\Microchip Solutions\Microchip\WirelessProtocols\MiWi\
MRF24J40.c	\Microchip Solutions\Microchip\Transceivers\MRF24J40\
MiWi.c	\Microchip Solutions\Microchip\WirelessProtocols\MiWi\

Os cabeçalhos relacionados com estes arquivos podem ser adicionados para facilitar a visualização. Por fim, devemos copiar três arquivos que serão necessários para o projeto: ConfigApp.h, HardwareProfile.h, SystemProfile.h. Para o projeto de um dispositivo End Device, nós vamos copiar estes arquivos do diretório Microchip Solutions\MiWi DE Demos\Node 2. Para Coordinators, devemos copiar estes arquivos do diretório Microchip Solutions\MiWi DE Demos\Node 1. São eles que conterão as configurações de rede do projeto, bem como o esquema de ligação deste projeto.
Assim que copiar estes arquivos para a pasta do projeto, inclua-os. Fazendo isto, vamos editar o arquivo HardwareProfile.h, para que ele reflita o nosso esquemático:

#ifndef _HARDWARE_PROFILE_H
    #define _HARDWARE_PROFILE_H
    
    #include "GenericTypeDefs.h"
    #include "ConfigApp.h"
    #include <p18cxxx.h>
    
    #define CLOCK_FREQ          48000000
    
    #define RFIF                INTCON3bits.INT2IF
    #define RFIE                INTCON3bits.INT2IE
    
    #define PHY_CS              LATCbits.LATC2
    #define PHY_CS_TRIS         TRISCbits.TRISC2
    #define RF_INT_PIN          PORTBbits.RB2
    #define RF_INT_TRIS         TRISBbits.TRISB2
    
    #define SPI_SDI             PORTBbits.RB0               
    #define SDI_TRIS            TRISBbits.TRISB0
    #define SPI_SDO             LATCbits.LATC7
    #define SDO_TRIS            TRISCbits.TRISC7
    #define SPI_SCK             LATBbits.LATB1
    #define SCK_TRIS            TRICBbits.TRISB1

    #define PHY_RESETn          LATCbits.LATC0
    #define PHY_RESETn_TRIS     TRISCbits.TRISC0
    #define PHY_WAKE            LATCbits.LATC1
    #define PHY_WAKE_TRIS       TRISCbits.TRISC1
    
    #define LED_1               PORTEbits.RE0
    #define LED_1_TRIS          TRISEbits.TRISE0
    #define LED_2               PORTEbits.RE1
    #define LED_2_TRIS          TRISEbits.TRISE1
    #define LED_3               PORTEbits.RE2
    #define LED_3_TRIS          TRISEbits.TRISE2

    #define TMRL                TMR0L
    
    #define TOOGLE(c)           c = ~c

#endif

Aqui nós definimos todas as ligações feitas com o módulo MRF24J40MA. Se alguma destas definições faltar, o compilador gerará erros. O clock e o registrador do timer usado também devem ser definidos aqui, para que o Stack MiWi possa fazer as temporizações corretamente. Portanto, você não poderá usar este timer.

Configurando o projeto

A configuração do projeto é feita no arquivo ConfigApp.h. Veja quais opções você poderá selecionar neste arquivo:

Configuração	Descrição
ENABLE_CONSOLE	Habilita a impressão de mensagens pela serial do microcontrolador. Comente esta definição, para desabilitá-la.
SIMPLE_EXAMPLE	Desabilita todas as funções mais avançadas do Stack. Insira esta definição no projeto, para habilitá-la.
ENABLE_NETWORK_FREEZER	Grava todos os dados mais importantes de uma conexão em memória não volátil, para rápido restabelecimento da rede. É necessário ter esta memória no projeto.
HARDWARE_SPI	Utiliza o módulo SPI nativo do microcontrolador para comunicação. Comentando-se esta definição, o Stack tentará emular uma SPI. Recomendável usar o SPI nativo.
PROTOCOL_P2P	Habilita a rede P2P. Não pode ser definido juntamente com PROTOCOL_MIWI
PROTOCOL_MIWI	Habilita a rede MiWi Mesh. Não pode ser definido juntamente com PROTOCOL_P2P
NWK_ROLE_COORDINATOR	Define o dispositivo como Coordinator. Não pode ser definido juntamente com NWK_ROLE_END_DEVICE.
NWK_ROLE_END_DEVICE	Define o dispositivo como End Device. Não pode ser definido juntamente com NWK_ROLE_COORDINATOR.
MRF24J40	Define que o módulo MRF24J40MA de 2.4GHz será usado. Não pode ser definido junto com outros transceivers.
MRF49XA	Define que o módulo subGHz MRF49XA da Microchip será usado. Não pode ser definido junto com outros transceivers.
MRF89XA	Define que o módulo subGHz MRF89XA da Microchip será usado. Não pode ser definido junto com outros transceivers.
MY_ADDRESS_LENGTH	Define o tamanho do endereço permanente do nó, em bytes.
EUI_0 - EUI_7	Esta é a definição do endereço EUI do módulo. Cada dígito é um byte do endereço.
TX_BUFFER_SIZE	Define o tamanho do buffer de transmissão.
RX_BUFFER_SIZE	Define o tamanho do buffer de recepção.
MY_PAN_ID	Define o PANID do dispositivo.
ADDITIONAL_NODE_ID_SIZE	Define o tamanho dos dados adicionais que serão anexados à requisição P2P. Estas são informações que os dispositivos querem compartilhar com outros pontos na conexão. Estes dados serão definidos pela aplicação.
CONNECTION_SIZE	Define o máximo de conexões P2P que este dispositivo permite ao mesmo tempo.
TARGET_SMALL	Remove algumas funcionalidades para diminuir o código gerado.
ENABLE_PA_LNA	Habilita o amplificador de potência em transceivers que o possuem.
ENABLE_HAND_SHAKE	Habilita o hand-shake antes da comunicação. Sem isto, os transceivers RF só poderão fazer broadcast, ou possuir o endereço de destino programado no firmware para comunicação com um dispositivo.
ENABLE_SLEEP	Permite que o dispositivo vá para o modo sleep e volte dele.
ENABLE_ED_SCAN	Habilita a detecção de energia, para descobrir qual o canal que possui menos ruído.
ENABLE_ACTIVE_SCAN	Habilita o Active Scan, para detectar as conexões atualmente existentes.
ENABLE_SECURITY	Habilita a encriptação de dados na transmissão.
ENABLE_INDIRECT_MESSAGE	Fará com que o dispositivo guarde mensagens para dispositivos que estão em modo sleep, até que eles retornem ao funcionamento normal.
ENABLE_BROADCAST	Fará com que o dispositivo envie broadcasts aos dispositivos em modo sleep, até que eles retornem ao funcionamento normal.
RFD_WAKEUP_INTERVAL	Define o intervalo de wakeup para dispositivos RFD em segundos. Esta definição no entanto não é utilizada pelos dispositivos RFD, mas pelos dispositivos FFD, para calcular seus vários timeouts.
ENABLE_FREQUENCY_AGILITY	Faz com que o dispositivo possa mudar de canal, quando houver uma súbita mudança no ruído.

Alterando o valor destas definições, você poderá configurar seu projeto de acordo com suas necessidades. É sempre bom dar uma olhada nestas configurações depois de copiar os arquivos.

Arquivo principal do projeto

No arquivo principal, você precisará definir algumas coisas também. Vamos ao esqueleto básico deste arquivo:

#include <stdio.h>
#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "WirelessProtocols/MSPI.h"
#include "WirelessProtocols/MCHP_API.h"

#include "HardwareProfile.h"

#if ADDITIONAL_NODE_ID_SIZE > 0
 BYTE AdditionalNodeID[ADDITIONAL_NODE_ID_SIZE] = {0x01};
#endif

BYTE myChannel = 11;

#pragma config FOSC=HSPLL_HS
#pragma config CPUDIV=OSC1_PLL2
#pragma config PLLDIV=5
#pragma config USBDIV=2
#pragma config CCP2MX=ON
#pragma config WDT=OFF
#pragma config WDTPS=32768
#pragma config MCLRE=ON
#pragma config LVP=OFF
#pragma config VREGEN=ON
#pragma config IESO=OFF
#pragma config PWRT=ON
#pragma config BOR=OFF
#pragma config CP0=OFF
#pragma config CP1=OFF
#pragma config CP2=OFF
#pragma config CP3=OFF
#pragma config CPB=OFF
#pragma config CPD=OFF
#pragma config WRT0=OFF
#pragma config WRT1=OFF
#pragma config WRT2=OFF
#pragma config WRT3=OFF
#pragma config WRTB=OFF
#pragma config WRTC=OFF
#pragma config WRTD=OFF
#pragma config EBTR0=OFF
#pragma config EBTR1=OFF
#pragma config EBTR2=OFF
#pragma config EBTR3=OFF
#pragma config EBTRB=OFF
#pragma config DEBUG=ON
#pragma config XINST=ON

void UserInterruptHandler(void)
{
}              

void main(void)
{
 BYTE i=0xFF;
 
 RCON = 0x80;           // Habilita prioridades para interrupções
 ADCON0 = 0x00;
 ADCON1 = 0x0F;       // PORTA só como entradas e saídas digitais.
 CMCON = 0x07;        // Comparadores desligados.
 TRISA = 0xFF;
 TRISB = 0x05;
 TRISC = 0x00;
 PORTC = 0x06;
 TRISD = 0x00;
 PORTD = 0x00;
 TRISE = 0x07;
 PORTE = 0xFF;
 INTCON = 0x00;
 INTCON2 = 0x00;
 INTCON3 = 0x00;
 // Configura o módulo SPI
 SSPSTAT = 0xC0;
 SSPCON1 = 0x20;
 
 INTCONbits.GIEH = 1;
 RFIF = 0;               // Limpa o interrupt flag do chip.
 RFIE = 1;
 INTCON2bits.INTEDG2 = 0;

 MiApp_ProtocolInit(FALSE);
 if(MiApp_SetChannel(myChannel) == FALSE)
 {
  return;
 }
 MiApp_ConnectionMode(ENABLE_ALL_CONN);
 while((i = MiApp_EstablishConnection(0xFF, CONN_MODE_DIRECT)) == 0xFF);
 #ifdef ENABLE_DUMP
        DumpConnection(0xFF);
 #endif
 LED_2 = 1;
 for(;;)
 {
  if(MiApp_MessageAvailable())
  {
   // Aqui tratamos a mensagem recebida.
   MiApp_DiscardMessage();
  }
 }
}

O código acima é de um arquivo prinpipal para o projeto de dispositivo End Device. A diferença entre o End Device e o Coordinator é apenas a função main. Duas definições devem ser feitas no arquivo principal. A primeira é a definição da variável AdditionalNodeID, conforme pode ser visto acima. Os arquivos do Stack MiWi usam esta variável, portanto é necessário pelo menos definí-la. A segunda definição é a da função UserInterruptHandler. Esta função é chamada depois que a interrupção do MiWi for executada, e precisa também ser declarada, mesmo que nada seja feito ali.
Além destas declarações, você deverá ainda configurar o módulo SPI e habilitar a interrupção que você definiu para o módulo MRF24J40MA (o Stack não faz isto como acontece em outras bibliotecas Microchip). Feito isto, seu projeto está pronto para funcionar.
As diferenças existentes neste arquivo acima, para o projeto do Coordinator são poucas. Compare com o código abaixo (do Coordinator):

MiApp_ProtocolInit(FALSE);
 if(MiApp_SetChannel(myChannel) == FALSE)
 {
  return;
 }
 MiApp_ConnectionMode(ENABLE_ALL_CONN);
 MiApp_StartConnection(START_CONN_DIRECT, 10, 0);
 #ifdef ENABLE_DUMP
        DumpConnection(0xFF);
 #endif
 LED_2 = 1;
 for(;;)
 {
  if(MiApp_MessageAvailable())
  {
   MiApp_DiscardMessage();
  }
 }

Pode-se observar que o End Device usa a função MiApp_EstablishConnection, enquanto o Coordinator usa a função MiApp_StartConnection. Esta função inicializa a rede MiWi, e somente com uma rede estabelecida, é que os dispositivos End Device podem estabelecer conexões.

Conclusão

Terminamos aqui com a criação de um projeto MiWi. No nosso próximo post, iremos desvendar um pouco mais as rotinas usadas pelo Stack, para implementar a comunicação via protocolo MiWi, comparando com o que já foi escrito sobre o protocolo, aqui.

MiWi: Segurança

Continuando nossa série de posts sobre o protocolo MiWi, nós terminaremos nossa descrição do protocolo, tratando agora da questão da Segurança de rede. Estou aqui traduzindo parte do datasheet, Application Note AN1066 - MiWi Wireless Networking Protocol Stack. Para quem não viu os outros tópicos, aqui está uma pequena lista de referência:
1- MiWi: Dispositivos e topologias de rede;
2- MiWi: Endereçamento;
3- MiWi: Relatórios de protocolo;
4- MiWi: Mensagens de Stack e Serviços
O protocolo MiWi segue a definição de segurança MAC especificada no IEEE 802.15.4. Todos os 7 modos de segurança definidos na especificação são suportados no protocolo MiWi. Estes podem ser divididos em três grupos:

• O modo AES-CTR encripta os dados do protocolo MiWi. Quem estiver atacando não irá entender o conteúdo do pacote MiWi sem uma chave. Este modo de segurança não pode verificar a integridade do pacote ou o conteúdo do cabeçalho MiWi, e mais importante, o endereço fonte original do pacote.
• Os modos AES-CBC-MAC garantem a qualidade do pacote MiWi. O Message Integrity Code (Código de integridade de mensagem - MIC) inserido no pacote garante que o pacote, incluindo o cabeçalho e os dados, não foram modificados de qualquer forma durante a transmissão. O tamanho do MIC é determinado pelo modo em particular; MICs maiores fornecem uma proteção maior. Os dados do pacote MiWi não são encriptados nestes modos.
• Os modos AES-CCM combinam os dois modos anteriores para garantir tanto a integridade do pacote quanto os dados encriptados.

Modo de segurança 00h, que especifica nenhuma segurança, é essencialmente o procoloco MiWi com o modo de segurança desligado. A capacidade de cada um dos modos de segurança pode ser visto na tabela abaixo:

Modo de segurança		Serviços de segurança				MIC (Bytes)
Identificador	Nome	Controle de Acesso	Encriptação de dados	Integridade de dados	Pureza sequencial
01h	AES-CTR	X	X		X	0
02h	AES-CCM-128	X	X	X	X	16
03h	AES-CCM-64	X	X	X	X	8
04h	AES-CCM-32	X	X	X	X	4
05h	AES-CBC-MAC-128	X		X		16
06h	AES-CBC-MAC-64	X		X		8
07h	AES-CBC-MAC-32	X		X		4

O stack fornece suporte de segurança na camada de protocolo MiWi. Quando segurança é ligada, o bit de segurança (bit 0) do byte Frame Control é setado. Assim que a segurança é ligada, o stack a utiliza em todos os pacotes do protocolo MiWi. O cabeçalho do protocolo MiWi (exceto hops, tipo de relatório e Report ID) são usados como dados de autenticação para todos os modos de segurança, exceto modo 01h. O tipo de relatório e o Report ID são assegurados, assim como os dados do relatório. Dados adicionais da suíte de segurança do IEEE 802.15.4 podem ser encontradas na seção 7.6 do padrão.
Quando a segurança é habilitada, o stack adiciona três novos items ao cabeçalho do pacote, imediatamente antes dos dados:

• o contador de frame
• o endereço longo da fonte
• a número da chave de sequência

O formato do cabeçalho de protocolo MiWi, com a segurança habilitada, é mostrado abaixo:

Quando a segurança é usada, entre 13 e 29 bytes adicionais são requeridos para o cabeçalho de segurança auxiliar e o MIC, dependendo da combinação do modo de segurança e da camada assegurada. Usuários precisarão balancear as necessidades de segurança e o impacto no tamanho dos dados (e a performance associada), associado com a combinação de definições de segurança.
A segurança no protocolo MiWi checa o contador de frames para evitar ataques repetidos. Somente pacotes MiWi de um membro da família de nós (como nós pais ou filhos) são checados para o contador de pureza. A razão é que somente tais nós são capazes de saber se outros membros da família de nós deixaram ou se uniram à rede. Qualquer pacote dos membros da família são obrigados a ter o contador de frame não menor que o contador de frame armazenado, do contrário, o pacote é descartado. Qualquer pai irá resetar o contador correspondente do pacote recebido assim que o filho correspondente se unir ou reunir à rede.
A segurança de protocolo assume que todas as informações de segurança, incluindo a chave de 16 bytes de segurança, número de chave de sequência e modo de segurança estejam preconfiguradas no stack. a forma recomendada de se fazer isto é programar tais chaves diretamente no software embarcado do sistema, de forma que nenhuma chave de segurança seja transferida durante o funcionamento da rede.

Conclusão

Aqui terminamos a descrição do protocolo MiWi, tratando dos modos de segurança disponíveis. Em breve, trataremos da criação de projetos MiWi, usando os microcontroladores da família Microchip.

Google Wallet: pagamento por celular

A Google parece reunir uma grande quantidade de pessoas criativas nestes dias. A última idéia é a do Google Wallet, uma carteira eletrônica pelo celular: todas transações comerciais serão feitas através de um aplicativo no celular.
Segundo o site EETimes India, é a NXP quem está auxiliando a Google com a parte de NFC (near-field communication), empresa esta que já atua na área de pagamento móvel, controle de acesso, infraestrutura de trânsito, autenticação de dispositivos e soluções eGovernment, tais como ePassport, carteiras de motoristas, carteiras de identidade e cartões de planos de saúde.
A aplicação da Google vai utilizar a solução de transação móvel da NXP, o NXP PN65 NFC, que inclui o controlador de rádio NFC, o elemento embarcado seguro e o software NFC em um simples dispositivo. O elemento embarcado seguro permite o pagamento pelo Google Wallet, e usa criptografia avançada para aumentar a segurança em tais transações.
Como é uma aplicação NFC, como o RFID, tudo que o usuário fará é aproximar seu celular de superfícies preparadas para a transação, e o pagamento poderá ser realizado. Não só pagamento, mas também cartões de desconto, pontos de fidelidade, etc. Se esta tecnologia pegar mesmo, não demorará muito para dados de carteira de identidade, carteira de motorista, CPF e outros também serem disponibilizados nesta forma...
O NFC de fato foi inventado pela NXP em 2002, a partir de uma combinação do RFID com tecnologias de interconexão. Em 2004 a NXP fundou o fórum NFC, para tornar a tecnologia mais conhecida e também torná-la padrão. Com a adoção da tecnologia pela Google, provavelmente a solução da NXP se tornará muito mais difundida.

MiWi: Mensagens de Stack e Serviços

Continuando nossa série sobre o protocolo MiWi, vamos hoje falar sobre mensagens de stack e serviços. O texto que trago aqui é uma tradução de parte do datasheet, Application Note AN1066 - MiWi Wireless Networking Protocol Stack.
Para quem não acompanhou nossa série deste o começo, ela se divide já em 3 partes:
1- MiWi: Dispositivos e topologias de rede;
2- MiWi: Endereçamento;
3- MiWi: Relatórios de protocolo

Fornecer alocação de endereços e serviços de roteamento são apenas o começo de uma solução de rede wireless. Além destes, o protocolo MiWi fornece outros serviços opcionais que ajudam os desenvolvedores a alcançar uma solução mais rapidamente. Estes serviços incluem criar conexões dinamicamente entre dois dispositivos sem precisar conhecer qualquer informação sobre o dispositivo antes do tempo (por exemplo, sockets), e a habilidade de procurar a rede por um endereço longo de um dispositivo específico.

Descobrindo nós na rede através do EUI

Quando dois nós comunicam por uma rede MiWi, eles usam seus endereços curtos. Se a topologia de rede mudar, seria útil encontrar aquele dispositivo novamente. Já que o endereço curto do dispositivo é atribuído a ele pelo seu dispositivo pai, o endereço curto curto do destino pode ter mudado. Se este é o caso, então o novo endereço curto deve ser descoberto antes que a comunicação possa ser restabelecida. Diferentemente do endereço curto, o EUI do dispositivo nunca muda e é globalmente único. Se um dispositivo conhece o EUI do outro dispositivo, ele será capaz de distinguir este dispositivo de qualquer outro. Assim, procurar pelo EUI de um dispositivo se torna importante para restabelecer comunicação entre dois dispositivos que se movem. Esta busca é possível no protocolo MiWi.
Como vimos no último post, há dois pacotes de stack que são definidos para ajudar com a busca de determinado EUI: EUI_ADDRESS_SEARCH_REQUEST e EUI_ADDRESS_SEARCH_RESPONSE. O pacote de requisição é transmitido para o primeiro Coordinator, que se encarrega de fazer um broadcast para todos os outros Coordinators. Este pacote é repetido até que o contador de hops chegue a 0.
Se algum dos Coordinators encontrar o dispositivo entre seus dispositivos filho, ele enviará a resposta de volta, de nó em nó, até o dispositivo que gerou a requisição.
Abaixo temos um diagrama do que foi descrito aqui:

Abrindo uma conexão com um dispositivo

Outra funcionalidade que pode ser importante para algumas redes é a capacidade de dinamicamente estabelecer conexões na rede. Isto é útil em redes onde a preconfiguração de nós precisa ser mínima.
Como um exemplo, um usuário pode desejar adicionar um novo interruptor de luz a um sistema de controle de iluminação. Como este interruptor sabe qual luz ele deve enviar seus pacotes? Uma forma é ter algum tipo de interface onde o dispositivo instalador manualmente programa os endereços do controlador e do alvo nos dispositivos.

Cluster Socket

Um método mais dinâmico seria ter um push button tanto na luz quanto no interruptor. Você pressiona primeiro o push button na luz, e então o do interruptor, dentro do período de tempo especificado. Isto permite os dois dispositivos saberem que eles precisam se comunicar um com o outro. Isto permite mudança dinâmica em tempo real no comportamento da rede de uma forma simples e mais simples ao usuário.
O protocolo MiWi define esta conexão dinâmica como um cluster socket. Um cluster socket existe entre dois nós que são membros da rede e são formados com base no endereço curto.
No exemplo anterior, apertar o push button do interruptor envia um OPEN_CLUSTER_SOCKET_REQUEST ao PAN Coordinator com a informação daquele dispositivo (veja também nosso post sobre Relatórios de Protocolo). Isto notifica o PAN Coordinator que o dispositivo está procurando por alguém para se comunicar. O PAN Coordinator mantém a requisição aberta pelo tempo especificicado pela aplicação. Se uma requisição similar vier da luz, o PAN Coordinator combina o a informação de endereço curto de ambos dispositivos em um OPEN_CLUSTER_SOCKET_RESPONSE e o envia para o interruptor e a luz. Finalmente, o PAN Coordinator remove a requisição de abertura de socket. Se o PAN Coordinator não receber uma segunda requisição de abertura de socket dentro do tempo especificado, então ele irá finalizar a requisição sem enviar uma resposta ao nó que a requisitou.
Se os dispositivos em F e G receberem o OPEN_CLUSTER_SOCKET_RESPONSE, eles podem examinar os dados daquele pacote e determinar se aquele dispositivo é, de fato, o dispositivo que eles querem comunicar. Esta é uma decisão do nível de aplicação, não é fornecida pelo stack.
Abaixo temos um diagrama de abertura de cluster socket:

P2P Socket

Apesar de dispositivos P2P somente se comunicar com um dispositivo e eles não se comunicam através da rede, eles ainda podem requerer uma conexão dinâmica. Dispositivos P2P devem ter um algoritmo diferente dos cluster sockets já que eles não são membros da rede.
Quando um dispositivo P2P quer se comunicar com um diferente nó, ele primeiro faz um broadcast de um pacote OPEN_P2P_SOCKET_REQUEST que contém o EUI completo do dispositivo. Qualquer dispositivo que receber esta requisição e deseja se comunicar com aquele dispositivo envia um pacote OPEN_P2P_SOCKET_RESPONSE que contém seu próprio EUI, informando o primeiro dispositivo que ele quer se comunicar. Na implementação atual, somente coordinators são capazes de receber o OPEN_P2P_SOCKET_REQUEST.
Aqui podemos ver como este procedimento acontece:

Conclusão

Hoje vimos a descrição dos serviços e como o protocolo utiliza os relatórios descritos no último post para implementá-los. No próximo post da série, terminamos de fazer a descrição do protocolo, comentando sobre a questão da segurança na rede MiWi.

MIWi: Relatórios de Protocolo

Continuando nossa série sobre o MiWi, vamos agora falar dos relatórios de protocolo. Mais uma vez, estarei traduzindo parte da documentação fornecida pela Microchip: Application Note AN1066 - MiWi Wireless Networking Protocol Stack.

MiWi Protocol Reports

O protocolo MiWi transporta pacotes entre dispositivos usando pacotes especiais chamados de relatórios (reports). O protocolo permite a implementação de até 256 tipos de relatórios, cada um com um ID diferente.
O relatório tipo 00h é reservado para pacotes de protocolo da rede MiWi, onde os dados do pacote (payload) são direcionados para o stack. Por exemplo, um ACK possui o tipo de relatório 00h (por ser um pacote de stack).
O tipo de relatório e o Report ID são definidos no cabeçalho do pacote, como já foi descrito no post MiWi: Endereçamento. O tamanho e conteúdo dos dados de um relatório depende do Report ID. Na implementação atual do MiWi, o tamanho do payload varia de 0 bytes (há alguns pacotes que não precisam de enviar dados, o próprio Report ID já é a informação) até 10 bytes, com o byte menos significativo sendo enviado primeiro.
Vejamos então a lista de relatórios deste protocolo.

Tipo de Relatório	Report ID	Nome
00h	10h	OPEN_CLUSTER_SOCKET_REQUEST
	11h	OPEN_CLUSTER_SOCKET_RESPONSE
	12h	OPEN_P2P_SOCKET_REQUEST
	13h	OPEN_P2P_SOCKET_RESPONSE
	20h	EUI_ADDRESS_SEARCH_REQUEST
	21h	EUI_ADDRESS_SEARCH_RESPONSE
	30h	ACK_REPORT_TYPE
01h-FFh	00h-FFh	Disponível para o usuário

Vamos agora fazer uma descrição de cada um destes relatórios:

OPEN_CLUSTER_SOCKET_REQUEST

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Requesting EUI Address (8 bytes)
00h	10h	O EUI do dispositivo que inicia a requisição

O endereço de destino do cabeçalho de protocolo MiWi deve ser o do PAN Coordinator (0000h). O endereço fonte do cabeçalho de protocolo MiWi deve ser o do dispositivo que está iniciando a requisição. O campo Requesting EUI Address especifica o EUI do dispositivo que inicia a requisição, com o byte menos significativo primeiro.

OPEN_CLUSTER_SOCKET_RESPONSE

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Resulting EUI Address (8 bytes)	Resulting Short EUI Address (2 bytes)
00h	11h	O EUI do dispositivo final	O endereço curto do dispositivo final

O endereço de destino do cabeçalho de protocolo MiWi deve ser o dispositivo que requisitou originalmente esta resposta. O endereço fonte deve ser do PAN Coordinator, já que este pacote específico se origina ali. O campo Resulting EUI Address especifica o EUI do dispositivo que respondeu à requisição (LSB primeiro). Note que este é um endereço diferente daquele especificado no endereço de destino do protocolo MiWi.
O campo Resulting Short Address é o endereço curto do dispositivo que respondeu à requisição. Com a combinação do EUI e do endereço curto enviado para ambos nós requisitantes, eles serão capazes de comunicar na rede e encontrar um ao outro se algum deles se mover na rede. Assim que o OPEN_CLUSTER_SOCKET_RESPONSE é enviado, o PAN Coordinator não mais manterá qualquer informação do socket.

OPEN_P2P_SOCKET_REQUEST

Tipo de Relatório (1 Byte)	Report ID (1 byte)
00h	12h

As informações tanto da fonte quanto do destino no cabeçalho de protocolo MiWi deve ser FFFFh. O campo de Hops do cabeçalho de protocolo MiWi deve ser 00h para prevenir rebroadcast do pacote. O PANID de fonte e de destino de nível MAC deve ser FFFFh. O endereço curto MAC de destino deve ser FFFFh. O endereço de fonte de nível MAC deve ser modo Long Address.

OPEN_P2P_SOCKET_RESPONSE

Tipo de Relatório (1 Byte)	Report ID (1 byte)
00h	13h

As informações tanto da fonte quanto do destino no cabeçalho de protocolo MiWi deve ser FFFFh. O campo de Hops do cabeçalho de protocolo MiWi deve ser 00h. O PANID de fonte e de destino de nível MAC deve ser FFFFh. Os endereços MAC de destino e fonte devem ser ambos endereços longos (EUIs).

EUI_ADDRESS_SEARCH_REQUEST

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Search EUI Address (8 bytes)
00h	20h	O EUI do dispositivo que está sendo procurado

O endereço curto e PANID de destino do cabeçalho de protocolo MiWi dever ser o endereço de broadcast, FFFFh.O endereço e PANID de fonte do cabeçalho de protocolo MiWi deve ser a informação de endereço que está requisitando a busca. Na recepção deste pacote, um coordinator na rede irá retransmitir este pacote como broadcast se o número de hops for maior que 00h. O coordinator irá decrementar o contador de hops antes de retransmitir o pacote. O coordinator não irá mudar o valor do número de sequência do protocolo MiWi quando transmitir o pacote.

EUI_ADDRESS_SEARCH_RESPONSE

Tipo de Relatório (1 Byte)	Report ID (1 byte)	Search EUI Address (8 bytes)	Search Results PANID (2 bytes)	Search Results Short Address (2 bytes)
00h	21h	O EUI do dispositivo que está sendo procurado	O PANID do dispositivo resultante	O endereço curto do dispositivo resultante

O pacote EUI_ADDRESS_SEARCH_RESPONSE deve ser enviado de volta para o endereço do dispositivo que originalmente enviou a requisição (o dispositivo mencionado nos campos de fonte do protocolo MiWi do pacote de requisição).

ACK_REPORT_TYPE

Tipo de Relatório (1 Byte)	Report ID (1 byte)
00h	30h

O endereço fonte do ACK de protocolo MiWi deve ser igual ao endereço de destino do protocolo MiWi que fez a requisição do Acknoledgement. O endereço de destino do pacote de ACK deve ser igual ao endereço de fonte do protocolo MiWi do pacote que requer um Acknoledgement.

Conclusão

Aqui nós tratamos dos vários tipos de pacotes usados pelo protocolo MiWi, para transportar dados. Já tratei aqui de uma introdução ao protocolo MiWi, bem como da forma que este protocolo faz o endereçamento de dispositivos. No próximo post da série, iremos ver mais sobre mensagens de stack e serviços.

MiWi: Endereçamento

Continuando nossa série de posts sobre o protocolo MiWi, vamos falar um pouco mais sobre a forma de endereçamento.

Atribuição de endereços

O protocolo MiWi usa os endereços fornecidos pela especificação IEEE 802.15.4. Ela defina três tipos de endereços:

1. Extended Organizationally Unique Identifier (EUI): Este endereço é um número de 8 bytes que é único em todo o mundo. Todo dispositivo usando esta especificação tem que ter um EUI único. Os 3 bytes superiores do EUI são comprados da IEEE, enquanto que os outros 5 bytes do EUI estão disponíveis para o usuário da forma que lhe for conveniente, desde que eles permaneçam globalmente únicos.
2. PAN Identifier (PANID): O PANID é um endereço de 16 bits que define um grupo de nós. Todos os nós no PAN compartilham um PANID comum. O dispositivo assume o PANID assim que ele escolhe se juntar àquela PAN.
3. Short Address: Também conhecido como endereço do dispositivo, este endereço é um endereço de 16 bits atribuído ao dispositivo pelo seu Coordinator. Ele deve ser único na PAN. O PAN Coordinator sempre possui este endereço como 0000h.

O protocolo MiWi usa os 16 bits disponíveis no Short Address para ajudar com o roteamento e troca de informações nos nós. O significado de cada bit é mostrado abaixo.

O campo Parent's Number (bits 10 a 8) é único para cada coordinator da rede, incluindo o PAN Coordinator. Como este campo só possui 3 bits, temos no máximo 8 coordinators em uma rede.
O campo RxOffWhenIdle (bit 7) é o inverso da propriedade definida pela IEEE 802.15.4 de RxOnWhenIdle. Quando o bit está setado, ele indica que este dispositivo vai desligar seu transceptor quando estiver desocupado e ficará incapacitado de receber pacotes. Qualquer dispositivo deverá rotear qualquer pacote que tenha este bit setado ao dispositivo pai deste dispositivo. O dispositivo pai por sua vez vai guardar estes pacotes até que ele volte a habilitar seu transceptor e requeira os dados. Se este bit não for setado no endereço do dispositivo, então o dispositivo é sempre capaz de receber pacotes.
O campo Child's Number (bits 6 a 0) de cada coordinator da rede é 00h. Isto indica que eles estão operando como coordinators. Outros valores para este campo são determinados pelo tipo de dispositivo (FFD ou RFD), assim como sua função na PAN. Abaixo temos uma idéia geral de como endereços são determinados.

Como pode-se ver, o PAN Coordinator possui endereço 0000h. Outros Coordinators assumem um endereço específico para os grupos, enquanto os dispositivos ligados a estes Coordinators, assumem um endereço ligado a eles.

Mensagens no protocolo MiWi

Assim que uma rede é formada, o próximo passo é definir como serão transferidos os pacotes pela rede MiWi. Se por acaso uma conexão P2P foi formada, então o endereço usado será o endereço longo, e não o endereçamento curto (Short Address) usado no item anterior.

Formato do pacote

O protocolo MiWi usa a camada MAC da especificação IEEE 802.15.4 para seus pacotes. Nós que se uniram à rede usarão o modo Short Address fornecido por esta especificação. Nós P2P, como dissemos há pouco, usarão o modo Long Address para a fonte e destino.
Acima desta camada reside o cabeçalho do protocolo MiWi que contém informação necessária para roteamento e processamento de pacotes. A figura abaixo mostra o formato do cabeçalho:

Hops: Quantidade de vezes que o pacote pode ser retransmitido, onde o valor 0 significa que este pacote não pode ser retransmitido. Tamanho de 1 byte.
Frame Control: Conjunto de bits que definem o comportamento deste pacote. Tamanho de 1 byte.
Dest PANID: O PANID do destino, tamanho de 2 bytes no protocolo MiWi.
Dest Short Address: Endereço final do destino, com 2 bytes de tamanho.
Source PANID: O PANID da fonte, com 2 bytes.
Source Short Address: Endereço da fonte do pacote, com 2 bytes.
Sequence number: Número de sequência que serve para monitorar o status de um pacote enquanto trafega pela rede, com 1 byte de tamanho.
Report Type: O agrupamento da mensagem contida neste pacote. Todos os pacotes gerados pelo stack possuem valor 00h, enquanto que os pacotes gerados pelo usuário podem variar de 01h a FFh. Tamanho de 1 byte.
Report ID: Tipo de mensagem contida neste pacote, com 1 byte.

Abaixo uma descrição dos bits do Frame Control:

Bit	Nome do campo	Descrição
7-3	Reservados	Mantidos como '0' nesta implementação.
2	ACKREQ	Acknoledge Request bit, que quando setado, requere de uma camada superior um Acknoledgement de recepção do dispositivo de destino.
1	INTRCLST	Intra Cluster bit, reservado nesta implementação, usar como '1'.
0	ENCRYPT	Encrypt bit, que quando setado, indica que o pacote é encriptado no nível de aplicação.

Roteamento

Roteamento em uma rede wireless pode ser muito difícil e uma tarefa que consome muito recurso. O protocolo MiWi resolve este problema usando a alocação de endereços para indicar o pai do dispositivo a receber o pacote, e também usando os serviços IEEE já existentes para ajudar a trocar e chavear informações na rede.

Descobrindo Coordinators vizinhos

Uma das tarefas do algoritmo de roteamento é determinar o próximo passo para qualquer pacote. O protocolo MiWi usa o mecanismo de união da rede IEEE, adicionado ao tráfego normal de rede, para descobrir estes caminhos. Quando qualquer dispositivo se une à rede, ele primeiro envia um pacote beacon de requisição. Todos os Coordinators que recebem o pacote de requisição enviam um pacote beacon informando dispositivos próximos de suas informações de rede.
No protocolo MiWi, três bytes de informação adicional são inseridas no payload do pacote beacon para ajudar com o roteamento:
Protocol ID (1 byte): Isto ajuda a distinguir protocolos de rede MiWi de outros protocolos IEEE 802.15.4, que possam estar operando na mesma região. O Protocol ID deve ser sempre 4Dh.
Version Number (1 byte): O número de versão desta especificação. Stacks baseados nesta especificação deverão ser sempre 10h.
Local Coordinators (1 byte): Este campo é um campo de bits que indica quais coordinators são atualmente visíveis pelos coordinator que está enviando o pacote beacon. Cada posição no campo de bits representa diretamente um de 8 possíveis coordinators. O bit 0 é o endereço 0000h (o Pan Coordinator). O bit 1 indica que este coordinator pode falar diretamente com o 0100h. Como dissemos antes, temos no máximo 8 coordinators, e cada bit aqui especifica um deles. A Microchip dá um exemplo de como este campo ficaria em um coordinator de endereço 200h, que possui o PAN Coordinator e o coordinator 500h. Seu campo de bits ficaria b00100101. Observem que neste exemplo, o próprio coordinator se coloca como visível, o que não deixa de fazer sentido.

Através do campo Local Coordinators, todos os coordinators da rede poderão saber quais as possíveis rotas para todos os nós sem precisar enviar requisições específicas.

Roteando para outros dispositivos

Roteando em uma rede MiWi se torna fácil assim que se tem conhecimento dos coordinators mais próximos, assim como o que aqueles coordinators podem ver. O algoritmo de roteamento segue o fluxograma abaixo:

Mensagens de Broadcast

Quando um coordinator de rede MiWi recebe um pacote de broadcast, ele irá retransmitir o broadcast contanto que o contador de hops (o primeiro byte do cabeçalho) não for igual a zero. Pacotes de broadcast não são repassados para end devices.
Pacotes de broadcast devem ter sempre seu ACK request bit (tanto no cabeçalho MiWi quanto no cabeçalho MAC) definidos como '0'. Coordinators que recebem o pacote devem processar o pacote depois de recebê-lo.

Conclusão

Aqui vimos como os endereços deste protocolo funcionam, bem como funciona o esquema de roteamento de mensagens. Esperamos ter esclarecido esta parte do protocolo, e já nos preparando para a próxima parte.

MiWi: Dispositivos e Topologias de rede

Recentemente iniciei um trabalho onde eu teria que desenvolver um equipamento que pudesse se comunicar através de algum tipo de protocolo wireless. Meu cliente então me trouxe uma placa de desenvolvimento que usa o módulo MRF24J40MA da Microchip. Devo confessar que não tinha qualquer experiência com protocolos wireless, e vi uma ótima oportunidade de dar inicio aos meus estudos nesta área. O que vou escrever aqui está baseado no Application Note AN1066 - MiWi Wireless Networking Protocol Stack, da Microchip.
Por enquanto, fiquemos com a introdução à este protocolo, baseado nas camadas MAC (Medium Access Layer) e PHY (Physical Layer) da especificação do IEEE 802.15.4. Esta especificação é a mesma especificação básica para o protocolo ZigBee, portanto para aqueles que já estão familiarizados com este protocolo, muita coisa por aqui será apenas repetição do que já viram. No caso, o ZigBee e o MiWi desenvolvem as camadas superiores que não são definidas por esta especificação.
Vejamos então o que a especificação IEEE 802.15.4 define, ao mesmo tempo que tratarmos do que o MiWi adiciona. Em primeiro lugar, ela define três frequências de operação: 2.4GHz, 915MHz e 868MHz. Cada frequência oferece um número fixo de canais, e possui uma taxa máxima de transmissão, que para facilitar, disponho no quadro abaixo:

Frequência	Canais (Número do canal)	Máximo Throughput de dados (kbps)
868 MHz	1 (0)	20
915 MHz	10 (1-10)	40
2.4 GHz	16 (11-26)	250

Um pacote MAC do IEEE 802.15.4 tem tamanho máximo de 127 bytes, incluindo um CRC de 16 bits. Além disto, o IEEE 802.15.4 opcionalmente usa um mecanismo de transferência com Acknoledge no MAC. Isto significa que há um flag especial ACK no cabeçalho do pacote. Quando este flag está setado, um Acknoledgement é requerido. Isto vai garantir que o pacote foi recebido, embora isto não garanta que o pacote chegue a camadas superiores dentro do stack (o pacote pode ser descartado por alguma camada intermediária do stack). Se o flag ACK for setado e o ACK não for recebido dentro de certo tempo, o transmissor fará uma nova transmissão. Ele repetirá isto uma certa quantidade de vezes até gerar um erro.

Tipos de dispositivos

O IEEE 802.15.4 também define dispositivos baseados em sua funcionalidades, que são basicamente duas. Disponibilizo aqui também uma tabela com a descrição de cada dispositivo.

Tipo de Dispositivo	Serviços oferecidos	Fonte de Tensão típica	Configuração típica para o Receptor oscioso
Full Function Device (FFD)	Todos ou a maior parte	Rede de alimentação	Ligado
Reduced Function Device (RFD)	Limitado	Bateria	Desligado

Já o MiWi define três tipos de dispositivos, desta vez em relação ao seu status na rede. Aqui temos o PAN Coordinator, o Coordinator e o End Device.

Tipo de Dispositivo	Tipo de dispositivo IEEE	Função típica
PAN Coordinator	FFD	Um por rede. Forma a rede, aloca os endereços de rede, mantém a tabela de conexões.
Coordinator	FFD	Opcional. Estende o alcance físico da rede. Permite que mais nós se unam à rede. Pode também executar funções de monitoramento ou controle.
End Device	FFD ou RFD	Executa funções de monitoramento e controle.

Topologias de rede

Dos três dispositivos definidos pelo protocolo MiWi, o mais importante para a a rede é o PAN Coordinator. É ele quem inicializa a rede, seleciona o canal e o PAN ID da rede. Todos os outros dispositivos devem obedecer as instruções dadas pelo PAN Coordinator, para se unir à rede. Esta rede pode ter quatro configurações possíveis, que vamos mostrar aqui. As imagens foram retiradas do já mencionado Application Note.

Configuração em Estrela

A configuração em estrela consiste de um PAN Coordinator e um ou mais End Devices. Na rede em estrela, todos os dispositivos se comunicam unicamente com o PAN Coordinator. Se algum dispositivo precisa enviar dados para outro dispositivo, ele enviará primeiro para o PAN Coordinator, que por sua vez encaminhará o pacote para o outro dispositivo.

Configuração Cluster-Tree

Na configuração Cluster-Tree, continuamos a ter apenas um PAN Coordinator. Contudo, outros Coordinators podem se unir à rede, formando uma estrutura de rede em árvore: o PAN Coordinator seria a raiz, os Coordinators seriam os ramos, e os End Devices seriam as folhas. Neste tipo de rede, todas as mensagens enviadas pela rede seguem o caminho da estrutura em árvore. Já que as mensagens podem ser roteadas através de mais de um nó para que elas cheguem a seu destino, este tipo de rede algumas vezes é referido como redes multi-hop (salto múltiplo).

Configuração Mesh

A rede Mesh é parecida com a rede Cluster-Tree, exceto pelo fato de que dispositivos FFD podem rotear mensagens diretamente a outros dispositivos FFD, ao invés de seguir a estrutura de árvore da rede. No entanto, mensagens de dispositivos RFD ainda precisam passar pelo elemento pai deste dispositivo.
Uma grande vantagem nesta topologia é a diminuição no tempo de latência das mensagens, além da confiabilidade ser aumentada. Como as redes cluster-tree, a rede mesh é também uma rede multi-hop.

Configuração Ponto a ponto (P2P)

O tipo mais simples de configuração, aqui não há distinção entre pai ou filho, pois a comunicação é direta.

Redes Multi-acesso

Uma rede IEEE 802.15.4 é uma rede multi-acesso, significando que todos os nós em uma rede possuem igual acesso ao meio de comunicação. Há dois tipos de mecanismos multi-acesso: beacon (farol) e non-beacon.
Em uma rede beacon, os nós podem transmitir em fatias de tempo predefinidas. O PAN Coordinator periodicamente inicia com um superframe, identificado como um beacon frame, e todos os nós na rede devem sincronizar com este frame. A cada nó é atribuída uma fatia específica no superframe, durante a qual, é permitida a transmissão e recepção. Um superframe pode também conter um slot comum durante a qual todos os nós competem pelo acesso do canal.
Em uma rede non-beacon, todos os nós em uma rede podem transmitir a qualquer hora desde que o canal esteja desocupado. A versão atual do MiWi suporta apenas redes non-beacon.

Primeiras conclusões

Temos aqui uma pequena descrição deste protocolo wireless da Microchip. Hoje em dia, os protocolos wireless estão cada vez mais fáceis de ser implementados, já que muitos fabricantes desenvolvem módulos completos.
Este protocolo tem como vantagem o custo, além de seus módulos possuírem tamanhos reduzidos.
Posteriormente falarei mais sobre o endereçamento neste protocolo, bem como o sistema de mensagens.

Páginas dinâmicas e AJAX no PIC.

Como eu havia dito em outro post, vou continuar nossa matéria sobre servidores Web no PIC. Nesta última parte, estarei descrevendo como você poderá inserir variáveis dinâmicas em suas páginas, bem como usar AJAX para atualizá-las.
Uma coisa que critico muito na plataforma da Microchip é a falta de documentação sobre este assunto. No entanto, se formos observar, há uma falta de documentação em toda nossa área. Espero assim preencher uma lacuna existente em nossa área.
Bem, se vocês acompanharam nossa última postagem, estarão com um servidor Web pronto para usar. Devemos agora criar nossas variáveis dinâmicas.

Criando variáveis dinâmicas na página Web

A Microchip definiu uma forma para a criação de variáveis dinâmicas em páginas Web. O padrão adotado é colocar o nome da variável entre dois '~'. Assim, poderíamos criar uma página web com o seguinte código HTML:

<html>
<head>
<title>Contagem de itens</title>
</head>
<body>
<p>Até o momento foram produzidos ~varItens~ itens.</p>
</body>
</html>

Criamos então aqui, uma página que irá mostrar o valor de uma variável chamada varItens. Esta página faz parte de um projeto que irá contar a quantidade de certos itens produzidos em uma indústria. Você deverá salvar esta página em seu diretório de páginas HTML, e então através do programa MPFS.exe (localizado na pasta [Raiz]\Microchip Solutions\Microchip\TCPIP Stack\Utilities), você irá gerar o código para ser incluído em seu programa. Se tudo ocorrer bem, o programa gerará o arquivo HTTPPrint.h com um novo protótipo de função:

void HTTPPrint_varItens(void);

Esta é a função que você deverá implementar para que sua variável dinâmica seja corretamente impressa no browser.
 
Implementando a função de impressão de variáveis dinâmicas
 
Vamos então criar uma função que imprime o valor de uma variável inteira chamada de quantItens. O nome da variável que escolhemos no código HTML não nos obriga a adotá-lo em parte alguma do código,pois escolhemos ali o nome da nossa função de impressão.
Assim, nossa função se chamará HTTPPrint_varItens. Eis o código-fonte desta função:

void HTTPPrint_varItens(void) 
{
   char tmpBuff[6];
   sprintf(tmpBuff, "%d", quantItens);
   TCPPutString(sktHTTP, (BYTE*)tmpBuff);
}

O que fiz foi basicamente converter o valor inteiro contido na variável quantItens para uma string, e usando a função TCPPutString, enviamos os dados para o browser que estiver visualizando a página. Tudo que for enviado através da função TCPPutString será exibido na posição que definimos no código HTML pela variável ~varItens~. Assim, não imprimimos apenas valores inteiros, mas também strings com mensagens para nossos usuários, códigos HTML para formatação de mensagens, etc...
 
Usando AJAX
 
Como implementar o AJAX em um servidor com PIC? A tarefa não é tão complexa assim. Imaginemos então que nosso projeto tenha que monitorar em tempo real a quantidade de itens na linha de produção, e que o browser deverá atualizar esta leitura sempre. Como implementar isto?
O primeiro passo será criar um arquivo que a página Web que criamos deverá buscar sempre com novas leituras. Este arquivo deverá ser um arquivo XML, e seu código pode ser visto abaixo:

<leitura> 
<contagem>~varItens~</contagem>
</leitura>

Observem que o elemento raiz é chamado de leitura, e os itens estão dentro de uma tag que chamamos de contagem.
Aqui neste arquivo, que vamos chamar de leitura.xml, nós colocamos novamente a impressão da variável varItens, que irá chamar a função que definimos acima. Novamente usamos o arquivo MPSF.exe para converter estes arquivos para um formato que possa ser utilizado pelo compilador.
Precisamos agora de algum mecanismo para buscar este arquivo no servidor e atualizar nossa página. Quem trabalha com Web poderia muito bem criar algumas funções em Javascript para usar o AJAX. No entanto, a Microchip já disponibiliza um arquivo Javascript que implementa o AJAX, e já faz o trabalho de atualizar periodicamente uma área de sua página Web.
O grande detalhe aqui é que a Microchip não divulgou muito isto. Não é um arquivo que está separado em uma pasta, somente esperando para ser usado. Este arquivo na verdade faz parte de um de seus exemplos, e pode ser encontrado na pasta [Raiz]\Microchip Solutions\TCPIP Demo App\WebPages2. O nome deste arquivo é mchp.js. Você deverá copiar este arquivo para sua pasta de páginas Web, e fazer algumas modificações no arquivo HTML que apresentamos acima:

<html>
<head>
<title>Contagem de itens</title>
<script type="text/javascript" src="mchp.js"></script>
<script type="text/javascript">
/* <![CDATA[ */
function displayItens(r)
{
  document.getElementById('leitura').innerHTML = getXMLValue(r, 'contagem');
}
function init()
{
  newAJAXCommand('leitura.xml', displayItens, true);
}
/* ]]> */
</script>
</head>
<body onload="init();">
<p>Até o momento foram produzidos <span id="leitura">~varItens~</span> itens.</p>
</body>
</html>

Em primeiro lugar, usamos um elemento SPAN para conter o valor a ser atualizado. Desta forma, limitamos a área onde será atualizada. É importante definir um ID para este SPAN, pois através deste localizaremos este elemento.
Definimos também a propriedade onload do elemento BODY. Quando a página carregar, ela irá invocar a função nesta propriedade. Vemos também que o código agora inclui dois scripts javascript: um é nosso arquivo mhcp.js, o outro é o nosso código.
Este nosso código simplesmente invoca a função newAJAXCommand, que faz todo o trabalho. O primeiro parâmetro desta função é o nome do arquivo que ela irá buscar no servidor. No nosso caso, é o arquivo leitura.xml que criamos anteriormente. O segundo parâmetro é o nome da função que será chamada, quando o arquivo for recebido. Criamos a função displayItens para este propósito, e por isto fornecemos este nome para a função. O terceiro parâmetro indica se você deseja repetir este chamado periodicamente, ou se este será um chamado apenas. No nosso caso, como desejamos uma leitura em tempo real, deixamos o valor como true. Esta função permite ainda um quarto parâmetro, que não vamos usar. Este parâmetro te permite enviar outras variáveis via POST para seu servidor.
Enviando o comando, o seu servidor responderá, enviando o arquivo leitura.xml. Quando recebermos o arquivo, ele será processado pela função que você passou como parâmetro para a função newAJAXCommand. Ela deve ter um parâmetro, que é o objeto XML que recebemos. Assim, para obtermos um item deste objeto, usamos a função getXMLValue. Ela recebe dois parâmetros. O primeiro, é o objeto XML que desejamos processar. Passe o objeto que recebemos como resposta. O segundo parâmetro é a tag no arquivo XML, que desejamos obter do arquivo. Como vocês podem se lembrar, colocamos a leitura dentro de uma tag contagem. Assim, passamos isto como parâmetro. Atribuímos então este valor à propriedade innerHTML do nosso SPAN, e pronto! Nosso valor estará sendo atualizado o tempo inteiro.
 
Conclusão
 
Temos então nosso servidor Web no PIC, utilizando variáveis dinâmicas e AJAX. A partir deste exemplo muitas outras adaptações poderão ser feitas, para atender aos requerimentos de cada projeto.