UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA – UEFS
Linton Thiago Costa Esteves
PROJETO DE REDE SEM FIO DE SENSORIAMENTO BASEADA NO
PROTOCOLO MiWi
FEIRA DE SANTANA 2011
Linton Thiago Costa Esteves
PROJETO DE REDE SEM FIO DE SENSORIAMENTO BASEADA NO
PROTOCOLO MiWi
Trabalho de Conclusão de Curso apresentado ao Departamento de Tecnologia, Curso de Engenharia de Computação da Universidade Estadual de Feira de Santana, como requisito parcial para a obtenção do título de Engenheiro de Computação.
Orientador: Prof. Dr. Anfranserai Morais Dias
Feira de Santana 2011
Dedico esse trabalho aos meus pais que sempre me apoiaram quando precisei e que são um grande exemplo de garra, caráter e respeito, uma prova que o esforço e a disciplina são a base para superar qualquer fronteira, a minha irmã amada que me trouxe muitos
momentos bons, a meus avós que sempre me apoiaram e contribuíram com a minha formação e a minha namorada que sempre esteve ao meu
lado, me compreendendo e apoiando nos momentos mais difíceis, sempre trazendo alegria e paz com o seu sorriso encantador.
AGRADECIMENTOS
Ao professor Doutor Paulo César Machado de Abreu Farias, pelo compromisso e orientação durante o processo de construção desse trabalho.
Ao professor Doutor Anfranserai Morais Dias, que sempre se mostrou disposto a ajudar.
Ao professor Doutor Germano Pinto Guedes pelo apoio e orientação;
A Victor Araújo Ferraz, pelo auxílio no processo de revisão da versão anterior do projeto.
RESUMO
Este projeto propôs o estudo da arquitetura de uma rede de sensores para monitoramento remoto de parâmetros ambientais (temperatura, umidade, insolação, pressão). O sistema possui um nó coordenador ligado a um computador pessoal via protocolo serial, que monitora as unidades remotas através de comunicação por rádio. Visando aumentar a autonomia dos módulos, foram incluídos dispositivos auxiliares de memória, que podem ser de dois tipos: EEPROM, utilizada nas estações remotas, ou cartões SD, utilizado no coordenador da rede. Nas estações, a coleta dos dados sensoriais é realizada a intervalos constantes que podem ser configurados remotamente pelo usuário. A partir do software de monitoramento instalado no computador pessoal, é possível realizar diversas operações de monitoramento e configuração dos módulos da base e da estação remota. Esse software foi desenvolvido com base em técnicas de projeto de interface para o usuário e apresenta uma interface amigável e intuitiva, o que facilita o processo de adaptação e controle do sistema. O projeto foi concebido objetivando fornecer uma alternativa configurável pelo usuário e de baixo custo.
Palavras chave: Automação. Instrumentação. Microcontroladores. Redes de Sensores. Sensoriamento remoto.
ABSTRACT
This project proposed to study the architecture of a sensor network for remote monitoring of environmental parameters (temperature, humidity, solar radiation, pressure). The system has a coordinating node connected to a central computer through a serial protocol that monitors the remote units via radio communication. In order to increase the autonomy of the modules were included extra memory devices to the system that may be of two types: EEPROM, for use in remote stations, or SD cards, for use in the network coordinator. In remote stations, the collection of sensor data is performed at constant intervals that can be remotely configured by the user. From the monitoring software installed on personal computer, it is possible to perform various monitoring and configuration operations of the modules. This software was developed based on user interface design techniques and it offers a friendly and intuitive interface which facilitates the system adaptation process and control. The project was planned to provide an user´s configurable and low cost alternative.
Keywords: Microcontrollers. Instrumentation. Sensor Network. Automation. Remote Sensing.
LISTA DE FIGURAS
Figura 1 - Barramento de comunicação I2C. ... 15
Figura 2 - Configuração de start e stop de uma comunicação I2C. ... 16
Figura 3 - Tipo de barramento SPI por conexão independente. ... 18
Figura 4 - Topologia estrela... 22
Figura 5 - Topologia P2P... 22
Figura 6 - Ambiente de desenvolvimento com o MiMAC e MiApp (MiWi DE). ... 24
Figura 7 - Formato do pacote do MiWi P2P. ... 27
Figura 8 - Frame Control do pacote do MiWi P2P. ... 27
Figura 9 - Handshaking padrão do IEEE 802.15.4... 30
Figura 10 - Processo de handshaking do MiWi P2P. ... 30
Figura 11 - Módulo transmissor MRF24J40MA. ... 31
Figura 12 - Interface do MRF24J40MA com um microcontrolador ... 32
Figura 13 - Diagrama de blocos da arquitetura da primeira versão do módulo remoto ... 34
Figura 14 - Lógica TTL de entrada e saída ... 37
Figura 15 - Arquitetura da estação remota ... 39
Figura 16 - Arquitetura da base ... 39
Figura 17 - Processo de configuração do hardware e do protocolo MiWi no coordenador. .... 41
Figura 18 - Processo de configuração do hardware e do protocolo MiWi na Estação. ... 41
Figura 19 - Struct RECEIVED_MESSAGE. ... 44
Figura 20 - Fluxograma da estação remota ... 46
Figura 21 - Estrutura de uma amostra ... 47
Figura 22 - Processo de escrita: antes do início do processo (a); início do processo (b); fim do processo (c) ... 48
Figura 23 - Processo de leitura: antes do início da leitura (a); início da leitura (b); fim da leitura (c) ... 48
Figura 24 - Fluxograma da base ... 52
Figura 25 - Diagrama com as principais classes do software de gerenciamento. ... 54
Figura 26 - Tela principal do software supervisório... 55
Figura 27 - Tela de configuração da comunicação serial ... 56
Figura 28 - Painel de Visualização da Rede ... 57
Figura 29 - Abas “Estação” e “Base” da tela principal ... 58
Figura 30 - Tela de configuração do intervalo de aquisição ... 58
Figura 31 - Protótipo da estação e da base em matriz de contatos ... 61
Figura 32 - Esquema de ligação da base ... 63
Figura 33 - Projeto da placa da base ... 63
Figura 34 - Prótotipo da base ... 64
Figura 35 - Esquema de ligação da estação remota ... 65
Figura 36 - Projeto da placa da estação ... 65
Figura 37 - Protótipo da estação remota ... 66
Figura 38 - Interface da base com uma porta RS-232 ... 66
Figura 39 - Cenário do teste de consistência ... 67
Figura 40 - Superposição amostras em 24 de março ... 68
Figura 41 - Histograma do erro absoluto em 24 de março ... 68
Figura 42 - Superposição amostras em 25 de março ... 69
Figura 44 - Fluxo de dados durante o teste ... 71 Figura 45 - Gráfico da porcentagem de retorno de pacotes sem verificar período de
aquisição ... 72 Figura 46 - Gráfico da porcentagem de retorno de pacotes verificando período de
aquisição apenas na estação ... 73 Figura 47 - Gráfico da porcentagem de retorno de pacotes verificando o período de
aquisição em ambos os módulos ... 74 Figura 48 - Gráfico gerado com a porcentagem de pacotes enviados para a base que foram
identificados ... 74 Figura 49 - Gráfico com a porcentagem do sucesso de retorno com variação da distância
entre os módulos ... 76
LISTA DE TABELAS
Tabela 1 - Possíveis configurações do clock no protocolo SPI. ... 18
Tabela 2 - Principais comandos do HDBS. ... 20
Tabela 3 - Especificações do Frame Control. ... 28
Tabela 4 - Lista dos comandos de controle. ... 49
Tabela 5 - Comandos de controle da base ... 53
SIGLAS
ACK – Acknowledgement
EEPROM - Electrically-Erasable Programmable Read-Only Memory EUI - Extended Organization Unique Identifier
FAT - File Allocation Table FFD - Full-Function Device I2C - Inter-Integrated Circuit
ISO - International Standards Organization MiMAC - Microchip Media Access Controller MiWi - Microchip Wireless
MMC - MultiMediaCard
OSI - Open Systems Interconnection PAN - Personal Area Network QoS - Qualidade de Serviço RFD - Reduced-Function Device RS-232 - Recommended Standard 232 RTC - Real-Time Clock
RTOS – Real-Time Operating System SD - Secure Digital
SPI - Serial Peripheral Interface TAD - Tempo de Aquisição por Bit
USART - Universal Synchronous Asynchronous Receiver Transmitter WDT - Watch Dog Timer
SUMÁRIO
1 INTRODUÇÃO ... 12
2 FUNDAMENTAÇÃO TEÓRICA ... 14
2.1 Protocolo RS-232 ... 14
2.2 Protocolo Inter-Integrated Circuit ... 15
2.3 Serial Peripheral Interface ... 17
2.4 Cartões de Memória e Módulo HDBS ... 19
2.5 Microchip Wireless (MiWi) ... 20
2.5.1 Características Gerais do MiWi/IEEE 802.15.4 ... 21
2.5.2 MiWi Development Environment (MiWi DE) ... 23
2.5.2.1 Microchip Media Access Controller ... 24
2.5.2.2 MiWi Application Programming Interface ... 25
2.5.3 Protocolo MiWiTM P2P ... 25
2.5.3.1 Formato da Mensagem ... 26
2.5.3.2 Enviando e Recebendo uma Mensagem ... 28
2.5.3.3 Variação do Handshaking ... 29 2.6 Módulo MRF24J40MA ... 31 3 DESENVOLVIMENTO ... 33 3.1 Histórico ... 33 3.1.1 Primeira Fase ... 33 3.1.2 Segunda Fase ... 35 3.2 Projeto de Hardware ... 36
3.2.1 Arquitetura da Estação Remota ... 38
3.2.2 Arquitetura da Base ... 39
3.3 Projeto de Software ... 40
3.3.1 Configurações Gerais dos Módulos e Funções do Protocolo MiWi ... 40
3.3.2 Firmware da Estação Remota ... 45
3.3.3 Firmware da Base ... 50
3.3.4 Programa do Computador Pessoal ... 53
4 RESULTADOS ... 60
4.1 Projeto e Confecção da Placa de Circuito Impresso ... 60
4.2 Teste de Consistência dos Dados no Dia 24 de Março ... 67
4.3 Teste de Consistência dos Dados no Dia 25 de Março ... 69
4.4 Teste de Eficácia na Transmissão sem Algoritmo de Aquisição ... 70
4.5 Teste de eficácia na Transmissão com Algoritmo de Aquisição na Estação ... 72
4.6 Teste de Eficácia na Transmissão com Algoritmo de Aquisição Total ... 73
4.7 Teste do Alcance de Transmissão ... 75
5 DISCUSSÕES ... 77
6 CONSIDERAÇÕES FINAIS ... 79
1 INTRODUÇÃO
O avanço tecnológico atinge todos os setores da atividade humana, trazendo muitas alterações na forma como as tarefas são realizadas pelo Homem. Essas modificações surgem no sentido de facilitar o trabalho das pessoas, transformando tarefas complicadas em simples, o que, consequentemente, aumenta a produtividade e a qualidade do trabalho.
Nesse contexto, o setor de sensoriamento remoto está em franco avanço, onde novas tecnologias estão sempre surgindo. Dentre esses avanços, o que vem causando maior impacto é a utilização de protocolos sem fio para controle e monitoramento das estações de aquisição.
Esse modelo possui uma grande mobilidade e versatilidade causada principalmente, pela ausência de conexões físicas entre seus nós, o que torna mais fáceis e baratas tarefas como o deslocamento das estações de aquisição e implantação inicial do sistema uma vez que não há a necessidade de se preocupar com manuseio e acomodação de fiações elétricas.
A exigência de um modelo de implantação e manutenção simples e rápido muitas vezes se torna um fator crucial na escolha de determinada tecnologia. Regiões de difícil acesso, por exemplo, tendem a valorizar soluções que privilegiem esses fatores.
Por esses motivos, a escolha de uma rede de sensores sem fio é uma alternativa interessante para sistemas que utilizem algum tipo de sensoriamento como em monitoramento ambiental, aplicações militares, vigilância, automação de serviços públicos, monitoramento hospitalar, dentre outros.
Assim, este projeto propôs o desenvolvimento de uma arquitetura de rede sensorial para monitoramento remoto de parâmetros ambientais (temperatura, umidade, insolação, pressão). A arquitetura é composta de dois tipos de unidades: Remota e Base.
A unidade remota se conecta aos sensores calibrados coletando amostras a intervalos constantes, cujo valor pode ser alterado remotamente através de um comando enviado pela base, os dados são armazenados em uma memória Electrically-Erasable Programmable
Read-Only Memory (EEPROM) externa, juntamente com um rótulo temporal obtido de um Real-Time Clock (RTC). Quando solicitado, os dados são enviados via rádio para a base, onde
são armazenados em um cartão de memória e transmitidos via o protocolo Universal
Synchronous Asynchronous Receiver Transmitter (USART) para uma interface externa com
um computador pessoal. Ao receber uma mensagem com uma amostra, o computador automaticamente a identifica, exibe seu valor em um gráfico e a armazena em um arquivo.
A base, por outro, lado funciona como uma central de coleta e gerenciamento das estações. Ela envia comandos de verificação, configuração e coleta de dados para as estações remotas, seja de forma automática ou através de solicitações provenientes do computador ao qual está conectada.
No capitulo 2 é apresentada uma fundamentação teórica onde são discutidas as tecnologias utilizadas no desenvolvimento da aplicação, juntamente com uma descrição de alguns dos componentes utilizados no projeto.
O capitulo 3 aborda o desenvolvimento do projeto, onde são apresentadas as etapas necessárias para a sua conclusão como a definição das arquiteturas dos módulos, concepção dos firmwares da base e estação e do software de monitoramento a ser instalado em um computador pessoal.
Sequencialmente, no capitulo 4, são abordados os resultados obtidos no projeto, como o processo de confecção da placa de circuito impresso e os testes realizados.
Por fim, no capitulo 5, é feita uma discussão acerca dos resultados obtidos, seguida da conclusão no capitulo 6 e das referências utilizadas.
2 FUNDAMENTAÇÃO TEÓRICA
Nesta sessão será feita uma descrição das tecnologias utilizadas no desenvolvimento do projeto, abrangendo as características tanto dos componentes e periféricos utilizados quanto dos protocolos de comunicação empregados.
2.1 Protocolo RS-232
O protocolo RS-232 foi criado pela Electronic Industries Association (EIA) para a comunicação entre um terminal de dados e um comunicador de dados. O pacote é constituído de 10 ou 11 bits sendo 8 bits para a mensagem, 1 bit de inicio (start bit), 1 bit de parada (stop bit) e 1 bit de paridade, sendo o último opcional (MIYADAIRA, 2009).
Durante o estado inativo, o canal de transmissão é mantido em nível lógico ‘1’; ao iniciar o processo de transmissão, primeiramente o canal é colocado em nível ‘0’, indicando ao receptor que uma mensagem será enviada. O receptor então começa a contar o clock para receber os dados. Sequencialmente, é enviado um byte iniciado pelo bit menos significativo seguido pelo bit de paridade e de um Stop bit (MIYADAIRA, 2009).
O bit de paridade é responsável pela verificação de erro na mensagem, podendo ser utilizada uma paridade par ou ímpar. Na paridade par seu valor é igual a ‘0’ para número par de bits ‘1’ na mensagem e ‘1’ para um número ímpar de bits ‘1’ (MIYADAIRA, 2009).
O padrão não segue os níveis de tensão CMOS/TTL, apresentando os seguintes valores:
• 0: tensão entre +3V e +25V • 1: tensão entre -3V e -25V • Indefinido: -3V a +3V
Como o microcontrolador opera em um nível de tensão diferente do padrão RS-232, é necessária a existência de um circuito que realize a tradução entre os dois níveis viabilizando a comunicação. No projeto, o circuito integrado responsável por realizar essa tradução é o MAX232 (TEXAS INSTRUMENTS, 2008). Ele funciona como um amplificador/redutor,
amplificando o sinal do PIC para o padrão RS-232 e reduzindo o sinal recebido pelo computador para o nível utilizado pelo PIC.
2.2 Protocolo Inter-Integrated Circuit
O protocolo Inter-Integrated Circuit (I2C) foi desenvolvido pela Philips objetivando simplificar a comunicação entre dispositivos eletrônicos. Ele é um protocolo síncrono do tipo mestre-escravo (master-slave) (SANCHEZ; CANTON, 2007).
Esse protocolo se utiliza de um barramento composto por duas linhas, uma para envio do sinal de clock (Serial Clock Line - SCL) e outra para tráfego dos dados a serem transmitidos (Serial Data Line - SDA). Sua linha de transmissão de dados é bidirecional enquanto a de clock é unidirecional, sendo essa última transmitida por um único mestre de cada vez (SANCHEZ; CANTON, 2007).
O barramento apresenta uma topologia multi-mestre, o que permite a existência de vários mestres em um mesmo barramento, no entanto, no momento em que um dos dispositivos assume o papel de mestre, todos os outros devem entrar em modo escravo, evitando interferências no processo de transmissão. Por necessitar de uma arquitetura mais complexa, o mestre normalmente é um microcontrolador ou microprocessador (MIYADAIRA, 2009).
Figura 1 - Barramento de comunicação I2C. Fonte: Próprio Autor
Como em um mesmo barramento podem coexistir vários dispositivos, é necessário um sistema de endereçamento que possa identificar a origem e destino das mensagens. Para tanto, o I2C prevê que cada dispositivo conectado deve possuir um endereço único, podendo ser de 7 ou 10 bits (SANCHEZ; CANTON, 2007).
A comunicação é iniciada (start bit) quando a linha de dado passa do nível lógico ‘1’ para ‘0’, enquanto a linha de clock está em 1. O término de uma transmissão (stop bit) ocorre quando a linha de dado passa do nível ‘0’ para o nível ‘1’ enquanto a linha de clock está em nível ‘1’ (MIYADAIRA, 2009), como pode ser visto na Figura 2.
Figura 2 - Configuração de start e stop de uma comunicação I2C. Fonte: Próprio Autor
Após o envio do start bit, caso o dispositivo possua um endereçamento de 7 bits, o mestre envia 1 byte pela linha SDA contendo os 7 bits do endereço da memória e um bit para informar o tipo da operação que será realizada (bit R/W), sendo ‘1’ para leitura e ‘0’ escrita. Para um endereçamento de 10 bits, são enviados dois bytes, os 5 bits mais significativos do primeiro byte são constantes e servem para informar que o endereçamento é de 10 bits, os 3 bits restantes representam os bits mais significativos do endereço do dispositivo, já o segundo byte, apresenta 1 bit para identificar o tipo de operação e os 7 bits restantes do endereçamento (SANCHEZ; CANTON, 2007; MIYADAIRA, 2009).
Após o envio da mensagem contendo o endereço do dispositivo, aquele que apresenta o endereço especificado responde ao mestre com um sinal de acknowledgement, forçando a linha de dados para o nível ‘0’ antes do nono pulso de clock. Se, por algum motivo, não existir um dispositivo com o endereço enviado ou o dispositivo endereçado não conseguiu identificar a mensagem, nenhum sinal é enviado ao mestre, tornando possível identificar que ocorreu algum erro na transmissão. Ao identificar esse erro o mestre envia um stop bit (MIYADAIRA, 2009).
Os passos seguintes dependerão de qual valor foi atribuído ao bit R/W:
Caso 1 (operação de leitura), o mestre envia 8 pulsos de clock e realiza a leitura simultânea de 8 bits no barramento DAS. Ao receber o oitavo bit o mestre responde com um ACK, informando o sucesso da operação de leitura;
Caso 0 (operação de escrita) o mestre envia 8 pulsos de clock juntamente com os 8 bits que se deseja enviar. Ao receber todos os bits o escravo responde ao mestre através de um ACK na linha de dados. Após a leitura/escrita da quantidade de dados desejada a comunicação é encerrada com um stop bit. Um fato simples, mas essencial, é a necessidade da utilização dos resistores de pull-up (Figura 1). Como os dispositivos conectados ao barramento operam apenas baixando a tensão do mesmo, esses resistores são essenciais para fixar a tensão em nível alto, evitando que as duas linhas fiquem flutuando, além de possibilitar identificar de forma eficaz que o barramento está livre (MIYADAIRA, 2009).
Atualmente muitas famílias de microcontroladores já são fabricados com uma arquitetura que implementa via hardware o protocolo I2C. Para algumas exceções que não possuem essa solução via hardware, já existem bibliotecas disponíveis que implementam o protocolo via software.
2.3 Serial Peripheral Interface
A interface Serial Peripheral Interface (SPI) surgiu como uma solução simples e eficiente para a conexão de periféricos. Ela opera de forma síncrona no modo full-duplex suportando um único mestre e diversos escravos conectados ao barramento. Sua velocidade máxima de transmissão pode alcançar até 70 MHz, a depender dos dispositivos conectados (IBRAHIM, 2008; MIYADAIRA, 2009).
Diferente do protocolo I2C em que cada dispositivo conectado possui um endereço específico, nesse padrão, a seleção do dispositivo que o mestre deseja comunicar é realizada pelo pino de seleção SS/CS (Figura 3). Como o protocolo não padroniza essa seleção, ela pode ser realizada tanto em nível lógico alto como em baixo, a depender do dispositivo. Vale ressaltar que o protocolo possibilita dois tipos de conexão, a conexão independente (Figura 3), e a conexão em cascata (IBRAHIM, 2008; MIYADAIRA, 2009).
Figura 3 - Tipo de barramento SPI por conexão independente. Fonte: Próprio Autor
O barramento é formado por 3 linhas:
1. SCK – utilizada pelo mestre para envio do pulso de clock; 2. MOSI – master output, slave input;
3. MISO – master input, slave output.
Quanto ao sinal de clock, o protocolo suporta quatro formas distintas, resultantes da combinação da polaridade e da fase do clock, como pode ser visto na Tabela 1 (IBRAHIM, 2008; MIYADAIRA, 2009).
Tabela 1 - Possíveis configurações do clock no protocolo SPI. Modo Polaridade Fase Característica
0 0 0 Polaridade do clock ‘0’, pulso gerado no inicio do período. 1 0 1 Polaridade do clock ‘0’, pulso gerado no final do período. 2 1 0 Polaridade do clock ‘1’, pulso gerado no inicio do período. 0 1 1 Polaridade do clock ‘1’, pulso gerado no final do período.
Fonte: IBRAHIM, 2008.
Normalmente, os dados são transferidos em pacotes de oito bits, podendo variar a depender da aplicação. Assim que o dispositivo é selecionado pela linha SS a comunicação é iniciada. Como a comunicação é full-duplex, ao mesmo tempo em que o mestre envia um comando o escravo também pode enviar. Para finalizar a conexão, o mestre para o sinal de
2.4 Cartões de Memória e Módulo HDBS
Os cartões de memória são dispositivos de armazenamento que utilizam a tecnologia
flash, para armazenamento dos dados. Suas características principais são permitir a
leitura/escrita dos dados por uma grande quantidade de vezes de forma rápida e sem a necessidade constante de alimentação para manter o armazenamento. Ele é muito utilizado como unidade de armazenamento em diversos equipamentos eletrônicos como as câmeras digitais, celulares, videogames e computadores pessoais. Atualmente, a maioria dos computadores já vem com um leitor de cartão de memória acoplado, o que torna a sua utilização ainda mais atrativa.
Com o objetivo de atender a demanda crescente por alternativas de armazenamento de dados, a Tato Equipamentos Eletrônicos desenvolveu o módulo HDBS. Ele é utilizado para leitura e escrita de cartões de memória nos padrões Secure Digital (SD) e MultiMediaCard (MMC). Esse módulo possui um microcontrolador embarcado e pode implementar um sistema de partição dos tipos FAT16 ou FAT32, permitindo que os dados armazenados nos cartões possam ser lidos também por um computador pessoal (TATO EQUIPAMENTOS ELETRÔNICOS, 2008).
O HDBS disponibiliza o controle por comandos pré-definidos. Esses comandos abrangem diversos modos de abertura de arquivos, operações de leitura ou escrita, manipulação de diretórios, inicialização da interface, gerenciamento dos sistemas de arquivos, dentre outros. É importante salientar que a quantidade de comandos existentes é suficiente para o manuseio adequado dos cartões.
Para realizar uma operação, o usuário envia a string do comando correspondente através de uma comunicação serial , em grupos de 8 bits, seguido do comando “\r\n” o que identifica o fim da mensagem. Na Tabela 2 é possível visualizar uma lista dos principais comandos utilizados no projeto (TATO EQUIPAMENTOS ELETRÔNICOS, 2008).
Tabela 2 - Principais comandos do HDBS.
Comando Funcionalidade Exemplo
HDRESET Reinicia o módulo printf("hdreset\r\n"); HDINIT Inicia o módulo printf("hdinit\r\n");
FS Inicia o sistema de
arquivos
printf("fs\r\n"); FOA <filename>,
[<file#r>]
Abre um arquivo printf("\r\nfoa nomeArquivo.txt, 1\r\n");
WL <file#>, <text> Escreve uma linha no arquivo
printf("wl 1, %d\r\n", informação); CLOSE <file#> Fecha um arquivo printf("\r\nclose 1\r\n");
Fonte: TATO EQUIPAMENTOS ELETRÔNICOS, 2008.
2.5 Microchip Wireless (MiWi)
Atualmente, existe no mercado uma forte demanda por aplicações de monitoramento ou controle sem fio que apresentem uma arquitetura simples, baixo custo de desenvolvimento e baixo consumo, sem deixar de lado uma boa consistência no processo de envio e recepção de pacotes.
Dentre os protocolos existentes nesse segmento destaca-se o Microchip Wireless (MiWi) (MICROCHIP TECHNOLOGY INC., 2010b). Ele é baseado nas especificações do padrão IEEE 802.15.4 que definem as camadas físicas e MAC, fornecendo uma base para o desenvolvimento de protocolos sem fio (IEEE COMPUTER SOCIETY, 2003).
Como as características e funcionalidade gerais do MiWi em sua maioria são semelhantes as do IEEE 802.15.4, na seção 2.5.1 serão abordadas funcionalidades compartilhadas pelo padrão IEEE 802.15.4 e pelo protocolo MiWi. Na seção 2.5.2, será apresentado o framework desenvolvido pela Microchip para construção de projetos sem fio, o MiWi Development Environment (MICROCHIP TECHNOLOGY INC., 2010b). Por fim, na seção 2.5.3, serão abordadas características específicas do MiWi P2P (YANG, 2010), variação do MiWi utilizada no projeto.
2.5.1 Características Gerais do MiWi/IEEE 802.15.4
Normalmente, os módulos para transmissão de dados sem fio possuem dois estados de funcionamento: ativo e dormindo. No modo ativo o dispositivo se encontra em pleno funcionamento apresentando um elevado consumo energético, sendo apenas nesse estado que uma comunicação é possível. Já no modo dormir, grande parte dos periféricos e funcionalidades são desabilitadas permitindo uma redução significativa no consumo (IEEE COMPUTER SOCIETY, 2003).
Com essa base, o modelo IEEE 802.15.4 propõe um protocolo de comunicação com um baixo ciclo de trabalho, mantendo o sistema a maior parte do tempo em modo dormir, o que diminui o consumo (IEEE COMPUTER SOCIETY, 2003).
O modelo suporta apenas comunicação digital de dados, não suportando serviços analógicos, o que permite a adoção de um algoritmo de modulação eficiente produzindo uma redução do consumo energético (IEEE COMPUTER SOCIETY, 2003).
Além disso, possui um eficaz controle de erros assegurando uma transferência de dados confiável e uma boa qualidade de serviço (QoS). Em cada pacote transmitido é realizado um cálculo sobre os bits transmitidos, gerando um valor de paridade o qual é transmitido juntamente com o cabeçalho da mensagem. Ao chegar ao destino, a mesma operação é realizada e o valor obtido é comparado com o valor de paridade da mensagem. Caso os dois valores sejam iguais é possível afirmar que os dados foram recebidos corretamente (IEEE COMPUTER SOCIETY, 2003).
Dentro de uma rede Wireless Personal Area Network (WPAN) existem basicamente dois tipos de dispositivos: o Reduced-Function Device (RFD) e o Full-Function Device (FFD). Os FFD são mais complexos e podem operar em dois modos, coordenador ou dispositivo final. Eles podem se comunicar com outros FFD ou com RFD. Toda rede WPAN tem que ter obrigatoriamente um FFD funcionando como um Personal Area Network (PAN)
Coordinator. Já os RFD são mais simples por serem construídos com recursos minimizados e
podem se comunicar apenas com FFD (ver figuras 4 e 5). Quando uma rede é criada o PAN
coordinator deve ser iniciado primeiro, seguido dos outros FFD e dos RFD (IEEE
COMPUTER SOCIETY, 2003).
Esse padrão possibilita a utilização de duas topologias de rede: star (estrela) (Figura 4) e peer-to-peer (ponto a ponto ou P2P) (Figura 5). Basicamente, a topologia estrela possui um
único dispositivo coordenador no centro que gerencia as transferências da rede fornecendo as rotas, iniciando e terminando uma comunicação (IEEE COMPUTER SOCIETY, 2003). A topologia P2P, assim como a estrela possui um dispositivo controlador, no entanto, os outros dispositivos podem comunicar entre si, não sendo necessário que toda comunicação seja intermediada pelo coordenador. Essa característica permite a construção de redes mais complexas (IEEE COMPUTER SOCIETY, 2003).
Figura 4 - Topologia estrela. Fonte: YANG, 2010.
Figura 5 - Topologia P2P. Fonte: YANG, 2010.
O IEEE 802.15.4 define dois tipos de controle de transmissão: beacon e non-beacon. Em uma rede beacon cada dispositivo possui um intervalo de tempo determinado pelo coordenador para realizar uma comunicação e assim transmitir dados. Esse processo aperfeiçoa a economia de energia de todos os dispositivos da rede, pois os rádios são ligados apenas durante os períodos de transmissão, ficando, então, desligados a maior parte do tempo (IEEE COMPUTER SOCIETY, 2003).
Já em uma rede non-beacon os dispositivos podem transmitir a qualquer momento, o que aumenta o consumo de energia do PAN coordinator, mas ainda assim possibilita que os RFD diminuam o seu consumo por não necessitar de uma sincronização frequente (IEEE COMPUTER SOCIETY, 2003).
Existem dois tipos de endereços nessa especificação: Extended Address, composto de oito bytes e único, e o Short Address, composto de dois bytes cujo valor é atribuído ao dispositivo quando ele se conecta a rede.
2.5.2 MiWi Development Environment (MiWi DE)
Visando facilitar e incentivar o uso do MiWi, a Microchip criou o MiWi Development
Environment (MICROCHIP TECHNOLOGY INC., 2010b), um framework que possibilita a
construção de projetos com arquitetura MiWi de forma simples e eficaz.
Com o MiWi DE é possível que alterações antes complexas, como mudança de protocolo ou de módulo de rádio frequência utilizado, sejam bem menos custosas, tornando possível a construção de projetos mais flexíveis.
A simplicidade na realização dessas tarefas se dá principalmente pela utilização de dois frameworks: o MiMAC (YANG, 2009b) e o MiApp (YANG, 2009a). Eles possibilitam a abstração e generalização de muitas das funcionalidades necessárias nesses tipos de redes.
O MiWi DE é subdividido em três camadas: camada de aplicação, camada de protocolo e camada de configuração do transmissor (Figura 6).
O papel do MiMAC e do MiApp é justamente fazer a ligações entre essas camadas. A camada de aplicação utiliza o MiApp para se comunicar com a camada de protocolo enquanto a camada de protocolo se comunica com os módulos RF através do MiMAC (Figura 6).
Figura 6 - Ambiente de desenvolvimento com o MiMAC e MiApp (MiWi DE). Fonte: YANG, 2009a.
2.5.2.1 Microchip Media Access Controller
A Microchip desenvolveu o Microchip Media Acess Controller (MiMAC) com o intuito de padronizar a camada MAC para protocolos de comunicação que utilizam transmissores sem fio de curto alcance e baixo consumo de energia. O MiMAC propõe uma pilha protocolar simples e de fácil uso, quando comparado aos outros protocolos sem fio existentes voltados para redes Wireless Personal Area Network (WPAN), o que facilita a sua implementação e utilização. Consequentemente, essas características reduzem o custo de implantação do mesmo (YANG, 2009b).
Devido a possibilidade de ser aplicado a todos os transmissores fabricados pela Microchip, é possível ao usuário final a mudança de transmissor em qualquer estágio de desenvolvimento, sem que isso cause grandes custos ao projeto. Esse processo pode ser realizado com a mudança de um parâmetro de configuração no firmware (YANG, 2009b).
2.5.2.2 MiWi Application Programming Interface
O MiWi Application Programming Interface (MiApp) é o responsável por fazer a ligação entre a camada de aplicação e a camada do protocolo sem fio utilizado. Ele é dividido em duas partes: arquivos de configurações e conjunto de funções.
Nos arquivos de configurações é possível ao usuário configurar o hardware utilizado no projeto, definindo as especificações de cada porta, o tipo de dispositivo RF adotado bem como a seleção do protocolo que será utilizado na aplicação (YANG, 2009a).
Já o conjunto de funções possibilita ao usuário realizar diversas operações como envio e recepção de dados sem fio, inicialização do módulo RF, operações de handshaking além de outras funcionalidades especiais (YANG, 2009a).
A partir do conjunto de configurações presentes nos arquivos de configurações o MiApp possibilita a realização de operações específicas, aumentando assim a flexibilidade do projeto, uma vez que, para a mudança de protocolo ou de algum hardware, não são necessárias grandes mudanças no código da aplicação apenas nos arquivos de configuração (YANG, 2009a).
Com esse framework, o processo de configuração e operação de protocolos sem fio se torna uma tarefa muito mais simples, pois, nesse ponto, não é necessário ao desenvolvedor se preocupar com detalhes mais específicos de cada processo, diminuindo, assim, o tempo necessário para a construção de projetos sem fio.
Para maiores detalhes sobre o framework favor consultar o documento 1284 da Microchip (YANG, 2009a), o qual contém o conjunto de funções e configurações possíveis do MiApp.
2.5.3 Protocolo MiWiTM P2P
O protocolo MiWi P2P (YANG, 2010) é fundamentado nas especificações do IEEE 802.15.4. No entanto, ele apresenta uma camada MAC diferente do padrão, que simplifica o processo de handshaking, diminuindo as operações de conexão.
Suporte a diversas famílias de microcontroladores fabricados pela Microchip como os PIC18, PIC24, dsPIC32 e dsPIC33;
Compiladores C18, C32 e C40;
Funciona como uma máquina de estados, o que o torna independente de um
Real-Time Operating System (RTOS);
Possibilita a utilização do estado sleep ao final de uma comunicação;
Permite a utilização da função de detecção de energia, para operar com o sinal que apresenta o menor ruído e a troca de canal;
Topologias P2P e estrela;
Suporta apenas redes do tipo non-beacon.
Com relação ao tipo de endereçamento. as regras são as mesmas do IEEE 802.15.4, existindo o short address e o extended address. No entanto, o short address é utilizado apenas para mensagens broadcasts. Além disso, o extended address ou Extended Organization
Unique Identifier (EUI) pode variar de 2 a 8 bytes, a depender das necessidades da aplicação
(YANG, 2010).
2.5.3.1 Formato da Mensagem
O formato do pacote enviado pelo protocolo MiWi P2P (Figura 7) é subdividido em 8 campos:
1. Frame Control; 2. Sequence Number;
3. Destination PAN ID;
4. Destination address;
5. Source PAN ID;
6. Source Address; 7. Pay Load; e
Figura 7 - Formato do pacote do MiWi P2P. Fonte: YANG, 2010.
O Frame Control é composto por 2 bytes onde são armazenadas informações de controle do pacote (Figura 8). A Tabela 3 apresenta as suas funcionalidades e os possíveis valores dos seus campos.
Figura 8 - Frame Control do pacote do MiWi P2P. Fonte: YANG, 2010.
O Sequence Number é formado por um byte, cujo valor é incrementado a cada pacote enviado. Ele é utilizado pelo pacote de ACK para identificar o pacote.
O Source e Destination PAN Identifier definem o PAN Identifier de origem e de
destino respectivamente. Como a versão atual do protocolo MiWi P2P possibilita apenas mensagens em uma mesma rede, o Source PAN Identifier não é utilizado e o Destination PAN Identifier é definido com o valor 0xFFFF (broadcast PAN Identifier) (YANG, 2010).
O campo de endereço de destino (Destination Address) pode ser do tipo short ou
extended address. Seu tipo deve ser compatível com o configurado no Destination Address Mode. O short address é utilizado apenas para mensagens broadcast e apresenta por padrão o
valor 0xFFFF. O Source Address pode ser apenas do tipo extended address e armazena o endereço do dispositivo que enviou o pacote (YANG, 2010).
Tabela 3 - Especificações do Frame Control.
Nome do campo Bits Valores Funcionalidade
Frame Type 3 001 – Data Frame
010 - Acknowledgement 011 – Command Frame
Define o tipo do pacote
Security Enable 1 1 – segurança habilitada 0 – segurança desabilitada
Identifica se a mensagem é criptografada
Frame pending 1 1 – existe pacote adicional 0 – não há pacote adicional
Indica se um pacote adicional é esperado após um ACK.
Acknowledgement Request
1 1 – requisição de ACK 0 – não necessita ACK
Indica a necessidade de um
acknowledgement Intra PAN 1 1 – Source PAN ID é omitido
0 – Source PAN ID é exibido
Determina se a mensagem apresentará o Source PAN ID. Destination Address Mode 2 10 – Short address 11 – Extended address Tipo de endereço do dispositivo destino Source Address Mode
2 11 - Só pode ser do tipo
extended address no
protocolo MiWi P2P
Tipo de endereço da fonte
Fonte: YANG, 2010.
2.5.3.2 Enviando e Recebendo uma Mensagem
O protocolo MiWi P2P suporta apenas dois modos de envio de uma mensagem:
broadcast ou unicast.
Mensagem do tipo broadcast tem como destino final todos os dispositivos ao alcance daquele que estiver enviando. O padrão IEEE 802.15.4 tem por definição um short address específico que identifica mensagens do tipo broadcast. Como não existe um endereço com essa mesma funcionalidade do tipo extended address, todas as mensagens de broadcast utilizam um short address. Além disso, essas mensagens não necessitam de um ACK (YANG, 2010).
As mensagens unicast tem apenas um único destino, por isso, é necessário informar na mensagem o endereço do destino, sendo então obrigatória a utilização de um extended
address. Diferente das mensagens broadcast, todas as mensagens unicast são seguidas de um Acknowledgement, identificando o sucesso da transmissão.
Uma funcionalidade bastante interessante no envio de mensagens unicast é a utilização de indirect message. Quando o dispositivo de destino está com o seu rádio
desligado ele fica incapaz de receber ou transmitir uma mensagem, tornando inviável uma comunicação durante esse período. O indirect message permite que, mesmo nesse tipo de situação, uma mensagem possa ser enviada. Ao detectar que o rádio do destino está desligado, o emissor automaticamente armazena aquela informação em memória até que o dispositivo “acorde” e torne-se apto para receber o pacote (YANG, 2010).
No entanto, seria muito custoso armazenar para sempre mensagens nessas situações, o que poderia causar uma sobrecarga na memória. Uma forma de evitar essa situação foi a criação do indirect message time-out. Ele armazena o tempo máximo que as mensagens podem ficar em espera até que o dispositivo “acorde”. Caso o tempo nele estipulado seja “estourado”, a mensagem é então descartada (YANG, 2010).
O padrão define que apenas aquele dispositivo de destino da mensagem será notificado. Quando ele estiver com o rádio em estado “dormindo” e quiser mudar para o estado “ativo” é necessário que, após essa operação, seja enviada uma mensagem de data
request para informar aos outros que seu rádio está novamente ativo e que estará apto a
realizar uma comunicação (YANG, 2010).
2.5.3.3 Variação do Handshaking
A maior diferença do protocolo MiWi P2P para as especificações do IEEE 802.15.4 está no processo de handshaking.
Para a realização do handshaking seguindo as especificações do IEEE, é necessário seguir cinco procedimentos, conforme apresentado na Figura 9(YANG, 2010):
1. O dispositivo que deseja se comunicar envia uma beacon request;
2. Todos os dispositivos capazes de realizar uma comunicação respondem com uma mensagem beacon;
3. O dispositivo inicial coleta todas as respostas e seleciona uma para estabelecer a conexão enviando uma requisição de associação;
4. Após um período de tempo o dispositivo inicial envia uma requisição de dados para solicitar a resposta da requisição de associação;
5. O outro dispositivo envia a resposta de associação.
Figura 9 - Handshaking padrão do IEEE 802.15.4. Fonte: YANG, 2010.
Com esses passos, cada dispositivo pode estabelecer apenas uma conexão, o que inviabiliza a ideia de múltiplas conexões proposta em uma conexão P2P.
O processo de handshaking desenvolvido pelo IEEE, por apresentar um funcionamento robusto, necessita de uma arquitetura mais trabalhada, o que inviabiliza sua utilização em aplicações que dispõem de poucos recursos.
Visando resolver essas duas barreiras, o MiWi P2P desenvolveu um processo de
handshaking mais simples com apenas dois passos (YANG, 2010):
1. O dispositivo inicial envia uma requisição de conexão P2P;
2. Qualquer dispositivo ao alcance responde com um comando P2P connection responde finalizando a conexão.
Figura 10 - Processo de handshaking do MiWi P2P. Fonte: YANG, 2010.
Com esse modelo, torna-se possível a realização de conexões múltiplas permitindo a construção de uma rede P2P. No entanto, essa funcionalidade será possível apenas para FFD que estabelecerão múltiplas conexões com outros FFD ou RFD. Enquanto isso, no RFD
existirá apenas uma única conexão que será estabelecida com o dispositivo que primeiro enviar o comando de P2P Connection Request (YANG, 2010).
2.6 Módulo MRF24J40MA
O MRF24J40MA (Figura 11) é um módulo de emissão e recepção de sinais via rádio, desenvolvido pela Microchip para atender a demanda das aplicações que utilizam o padrão IEEE 802.15.4. Ele implementa em hardware as camadas físicas e MAC do modelo OSI, sendo a última baseada no padrão IEEE 802.15.4, o que facilita a interação com os protocolos ZigBee®, MiWi™, MiWi™ P2P, dentre outros (MICROCHIP TECHNOLOGY INC., 2008b).
Figura 11 - Módulo transmissor MRF24J40MA. Fonte: MICROCHIP TECHNOLOGY INC., 2008b.
Algumas de suas características gerais são: Faixa de operação entre 2,4V e 3,6V
Compatível com as famílias de microcontroladores PIC16F, PIC18F, PIC24F/H, dsPIC33 e PIC32;
Alcance do rádio de até 400 metros (em local aberto); Cristal interno;
Módulo de segurança implementado em hardware; Baixo consumo:
o Modo RX: 19 mA; o Modo TX: 23 mA; o Modo Sleep: 2 μA.
Sua interface externa com um microcontrolador é realizada por um barramento SPI de quatro vias, e mais 3 pinos: interrupção, wake e reset (Figura 12) (MICROCHIP TECHNOLOGY INC., 2008b).
Figura 12 - Interface do MRF24J40MA com um microcontrolador Fonte: MICROCHIP TECHNOLOGY INC., 2008b.
3 DESENVOLVIMENTO
Como dito anteriormente, o objetivo principal do projeto é construir uma rede de sensores sem fio para aquisição de dados remotamente. A rede é composta de dois tipos de módulos: a estação remota e a base.
A estação remota opera como um ponto de coleta de informações, onde os sensores estão acoplados. Suas principais tarefas são a coleta dos dados provenientes dos sensores, seu armazenamento juntamente com os respectivos rótulos temporais e envio via rádio dessas informações para a estação base.
Já a estação base trabalha como coordenador da rede e concentrador de informações. Ela solicita constantemente que as estações remotas enviem os dados coletados, armazenando-os em memória e/ou os enviando para um computador pessoal ao qual está conectada.
Nos subtópicos a seguir, serão apresentados com detalhes o histórico de desenvolvimento do projeto, o projeto em hardware da base e da estação e, por fim, os softwares construídos.
3.1 Histórico
A concepção do projeto nos moldes atuais foi possível graças à realização de diversas tarefas e à superação de algumas barreiras. Esse processo pode ser subdividido em duas fases: a primeira realizada pelo aluno Victor Ferraz (FERRAZ, 2008) e a segunda concebida pelo aluno Linton Thiago. Ambas as fases serão explicadas respectivamente nas seções 3.1.1 e 3.1.2 dessa monografia.
3.1.1 Primeira Fase
Na primeira fase, um dos principais desafios foi a identificação dos componentes necessários ao sistema. Optou-se por utilizar um microcontrolador PIC18F4550 como
dispositivo controlador das estações remotas e da base. Essa escolha foi orientada principalmente pelas características de desempenho, facilidade de desenvolvimento e baixo custo destes dispositivos (MICROCHIP TECHNOLOGY INC., 2010d; FERRAZ, 2008).
Nessa etapa verificou-se a necessidade de expansão da memória, já que as estações devem ter um bom período de autonomia. Nesse momento, foram incluídas memórias EEPROM extras através de um 24FC512 (MICROCHIP TECHNOLOGY INC., 2010c; FERRAZ, 2008).
Devido a aplicação, os dados coletados devem ser rotulados com data e hora. Para isso, utilizou-se um RTC como fornecedor dessas informações. Dentre os circuitos pesquisados, escolheu-se o DS1302 (FERRAZ, 2008).
Apesar da existência de uma grande variedade de formas de comunicação que poderiam ser utilizadas no projeto para a comunicação entre a base local e a estação remota, um fator decisivo na escolha foi a facilidade de operação. Pensando nisso, a equipe optou por utilizar uma comunicação via rádio frequência entre a base e a estação utilizando o circuito integrado TRF2.4G (LAIPAC TECHNOLOGY INC., 2008). Já a comunicação da base local com o computador central foi inicialmente estabelecida via uma interface serial
Recommended Standard 232 (RS-232) (FERRAZ, 2008).
Dessa forma, esse primeiro protótipo da estação seria composto por um microcontrolador como unidade central controladora e nele estariam ligados o RTC, a memória EEPROM, o TRF2.4G e os sensores, como pode ser visualizado na figura 13.
Figura 13 - Diagrama de blocos da arquitetura da primeira versão do módulo remoto Fonte: FERRAZ, 2008.
Já a base apresentava uma arquitetura mais simples, contendo apenas o microcontrolador, o módulo para transmissão via rádio e uma comunicação serial com o computador. Como não existia um sistema de armazenamento próprio da base, era necessária uma conexão constante com um computador pessoal para coleta dos dados recebidos.
3.1.2 Segunda Fase
Na segunda fase, a primeira tarefa realizada foi a migração do compilador utilizado, do CCS C Compiler (CCS, 2010) para o C18 (MICROCHIP TECHNOLOGY INC., 2010a). Uma das principais razões para essa alteração foi a necessidade de um compilador que apresentasse uma documentação mais detalhada e, consequentemente, um melhor suporte. Nesse quesito, a Microchip, fabricante do C18, apresenta uma proposta muito mais atraente que a fornecida pela CCS, por oferecer uma série de exemplos, frameworks e notas de aplicações, o que facilita o processo de estudo de novas tecnologias e, consequentemente, proporciona um aumento na eficiência do desenvolvimento das aplicações.
No entanto, essa alteração invalidou o código do projeto construído no CCS até então, uma vez que, com a utilização de um compilador diferente, as funções, estrutura do projeto e parâmetros utilizados não seriam mais os mesmos.
Visando aumentar a capacidade de armazenamento de dados, o módulo HDBS foi acoplado ao sistema possibilitando, assim, a escrita em cartões de memória do tipo SD/MMC.
Apesar de já existir uma alternativa para a transmissão dos dados via rádio, a equipe optou pela substituição do protocolo existente por um que apresentasse uma maior robustez e que já estivesse mais consolidado no mercado, o que possibilitaria a construção de redes mais complexas de uma forma mais simples e eficiente.
Após um levantamento dos protocolos existentes no mercado, optou-se pela utilização do protocolo MiWi, cujas características principais (versatilidade, baixo consumo e confiabilidade na transmissão dos dados) condiziam com a proposta do projeto.
O MiWi é um protocolo desenvolvido pela Microchip que surgiu a partir das especificações do IEEE 802.15.4. Atualmente, existem duas versões desse protocolo, o MiWi P2P e o MiWi Mesh. A rede P2P, por apresentar uma topologia mais simples que as redes
limitados, sendo esse o principal motivo da sua utilização no projeto (MICROCHIP TECHNOLOGY INC., 2010b).
Por ser um protocolo sem fio mais complexo que o utilizado anteriormente, o MiWi P2P produz um firmware que ocupa uma quantidade de memória maior. E, apesar do MiWi DE possibilitar uma minimização da quantidade de memória ocupada no microcontrolador, tal prática se torna inviável de ser utilizada com o PIC18F4550. Como o firmware gerado com apenas o protocolo ocupa aproximadamente 20 kbytes de sua memória, restariam 12 Kbytes para a inserção das outras funcionalidades do módulo, o que é insuficiente.
Sendo assim, foi necessária a migração de microcontrolador, de um PIC18F4550, com 32 kbytes de memória, para um PIC18F4620 (MICROCHIP TECHNOLOGY INC., 2008a) com 64 kbytes. Com essa mudança, passou a existir memória suficiente para a incorporação de todas as funcionalidades pretendidas, além de possibilitar a inserção de funcionalidades futuras, caso necessário.
Com a escolha do protocolo de comunicação sem fio, a próxima etapa foi selecionar um módulo RF que suportasse o MiWi e apresentasse características compatíveis com as necessidades do projeto. Dentre os módulos pesquisados, o que mais se destacou foi o MRF24J40MA (MICROCHIP TECHNOLOGY INC., 2008b). Esse módulo possui uma vasta documentação e já está em uma versão bastante estável, o que levou a equipe a acreditar que sua utilização traria benefícios para o projeto, fornecendo uma alternativa confiável para a transmissão/recepção de informações.
3.2 Projeto de Hardware
Como dito anteriormente, a rede construída é composta de dois módulos: a estação remota e a base. Esses módulos, apesar de apresentarem funcionalidades distintas, possuem algumas características em comum:
1. Envio e recepção de dados via rádio; 2. Análise do tempo; e
3. Interface de comunicação com um computador pessoal.
Para atender ao primeiro requisito, em ambos os módulos foi inserido um transmissor via rádio frequência, o MRF24J40MA (MICROCHIP TECHNOLOGY INC., 2008b). No
entanto, esse transmissor apresenta uma tensão de operação de 3,3V, inferior a faixa de operação do HDBS que é de 5V . Sendo assim, na base foi necessária a utilização de dois reguladores de tensão: um LM7805 para regular em 5V a alimentação do HDBS, e um LM1117 para ajustar em 3,3V a alimentação dos demais componentes do módulo. Por não possuir essa necessidade, na estação remota não foi necessária a utilização de dois reguladores, bastando apenas o LM1117.
Tal prática foi possível devido ao HDBS apresentar lógica TTL, o que torna viável a identificação de sinais com níveis menores do que 3,3V, como pode ser observado na figura14. Caso a tensão de operação do rádio transmissor fosse inferior a 2V, tal prática não seria possível.
Figura 14 - Lógica TTL de entrada e saída Fonte: Próprio Autor
Tanto a base, como a estação, necessitam constantemente de informações temporais, uma vez que, boa parte de suas ações são realizadas a partir de intervalos de tempos pré-determinados. Pensando nisso, em ambos os módulos foram inseridos um DS1302.
A interface com um computador pessoal, na segunda fase, inicialmente foi obtida através do protocolo de comunicação USB. No entanto, com a mudança de microcontrolador do PIC18F4550 para o PIC18F4620 essa funcionalidade teve que ser removida uma vez que, diferente do PIC18F4550, o PIC18F4620 não possui suporte a USB. Por outro lado, no mercado existem diversos módulos que possibilitam a conversão de sinal para o USB, como o
Future Tecnology Devices International (FTDI) (FUTURE TECNOLOGY DEVICES
INTERNATIONAL LTDA., 2011) e o cabo serial/USB desenvolvido pela Tato (TATO EQUIPAMENTOS ELETRÔNICOS, 2011).
Dessa forma, objetivando fornecer uma alternativa flexível, no projeto da placa desenvolvida foram colocados 3 pinos para interface externa. Eles são ligados aos pinos RX e TX do microcontrolador e à referência do módulo. Com essa interface, é possível ao usuário realizar uma comunicação no padrão RS-232 com o computador através do MAX232 (TEXAS INSTRUMENTS, 2008) ou uma comunicação USB através do FTDI ou cabo serial/USB.
Nos subtópicos a seguir serão apresentadas as arquiteturas específicas da estação remota e da base.
3.2.1 Arquitetura da Estação Remota
Pela necessidade constante de coletar e armazenar os dados dos sensores, a memória interna do microcontrolador não seria suficiente para receber esses dados por um grande período de tempo, o que tornaria o tempo de autonomia das estações relativamente pequeno. Pensando nisso, foi necessário inserir nesse módulo um dispositivo que fornecesse uma memória extra, aumentando assim o período de autonomia das estações. O circuito integrado utilizado com esse fim foi um 24FC512 cuja interface de comunicação para leitura e escrita de dados é a I2C.
O microcontrolador utilizado dispõe dos periféricos I2C, SPI e USART utilizados no projeto. No entanto, os pinos para a comunicação I2C são os mesmos para a SPI. Como no projeto os dois tipos de comunicação são utilizadas foi necessário definir qual dos componentes se beneficiaria pela utilização do protocolo embutido no microcontrolador. Sendo assim, a equipe optou por ceder essas portas para o módulo RF, visto que ele realiza uma quantidade maior de operações. Por esse motivo, o protocolo I2C para interface com a memória EEPROM foi construído em software e o 24FC512 conectado aos pinos RB2 e RB3 do microcontrolador.
Figura 15 - Arquitetura da estação remota Fonte: Próprio Autor
3.2.2 Arquitetura da Base
Por ser a concentradora de informações, a base necessita de uma quantidade de memória maior que a requisitada pelas estações. Dentre as possibilidades pesquisadas, a solução mais adequada, pela sua versatilidade e grande capacidade de armazenamento, foi o emprego de cartões de memória SD/MMC. Seu uso foi viabilizado através do módulo HDBS que permite a gravação nesses tipos de cartões via USART. Na figura 16 é possível visualizar a arquitetura da base.
Figura 16 - Arquitetura da base Fonte: Próprio Autor
3.3 Projeto de Software
Nesse projeto, foi necessária a construção de três softwares diferentes: o firmware da estação remota, o firmware da base e um programa para gerenciamento através de um computador pessoal.
A programação da estação remota, assim como a da base, foi feita em linguagem C, através da plataforma MPLAB IDE v8.63 usando o compilador C18 . Vale ressaltar, que, em ambos módulos, o projeto foi desenvolvido a partir do “Simple Example - PIC18 - C18” disponibilizado juntamente com o framework MiWi DE (MICROCHIP TECHNOLOGY INC., 2010b), o que facilitou o processo de aprendizagem e desenvolvimento do protocolo.
O software do computador pessoal foi construído em JAVA na plataforma NetBeans 6.7.1. Nesse projeto foram utilizadas as bibliotecas javax.comm , para realizar a comunicação serial com o módulo base, e a jfreechart, para construção do gráfico na interface principal.
3.3.1 Configurações Gerais dos Módulos e Funções do Protocolo MiWi
Como ambos os módulos possuem uma arquitetura semelhante, existem algumas configurações que são compartilhadas. Dentre elas podemos destacar as funções de configuração do hardware do microcontrolador e do protocolo MiWi. As figuras 17 e 18 ilustram o fluxograma desse processo de configuração dos módulos da base e da estação, respectivamente.
Início
BoardInit() ConsoleInit() ConfigurarHardwareModulo()
MiApp_ProtocolInit (FALSE); MiApp_SetChannel (myChannel) MiApp_ConnectionMode (ENABLE_ALL_CONN) i=MiApp_EstablishConnection (0xFF, CONN_MODE_DIRECT) MiApp_StartConnection( START_CONN_DIRECT, 10, 0) i == 0xFF sim Fim Configuração não
Figura 17 - Processo de configuração do hardware e do protocolo MiWi no coordenador. Fonte: Próprio Autor
Início
BoardInit() ConsoleInit() ConfigurarHardwareModulo()
MiApp_ProtocolInit (FALSE); MiApp_ConnectionMode (ENABLE_ALL_CONN) sim i=MiApp_EstablishConnectio n(0xFF, CONN_MODE_DIRECT) i == 0xFF sim nao Fim Configuração MiApp_SetChannel (myChannel) não Fim do programa
Figura 18 - Processo de configuração do hardware e do protocolo MiWi na Estação. Fonte: Próprio Autor
A primeira função executada após a inicialização dos módulos é a “BoardInit()” que é a encarregada de configurar as portas de entrada e saída do microcontrolador, comunicação SPI com o módulo RF e o Watch Dog Timer (WDT). Logo após sua execução a função “ConsoleInit()” é acionada, e as configurações da comunicação USART são selecionadas:
1. Baud Rate – 9600; 2. Bits de dados – 8; 3. Sem paridade; 4. Bit de parada – 1; e 5. Sem controle de fluxo.
Em seguida é iniciado o processo de configuração do protocolo MiWi. Um fator decisivo para o cumprimento de forma eficiente desse processo, foi a utilização das rotinas presentes no MiApp (YANG, 2009a). Esse framework disponibiliza diversas funções que facilitam o processo de configuração e manipulação do protocolo.
A primeira executada entre elas é a “BOOL MiApp_ProtocolInit(BOOL
bNetworkFreezer)”, responsável por inicializar a pilha do protocolo. Essa função possui um
único parâmetro de entrada que define se configurações prévias serão carregadas (TRUE) ou se a pilha será iniciada do zero (FALSE) (YANG, 2009a). Nesse projeto, a função foi chamada com o parâmetro FALSE.
Logo após, é feita uma chamada à função “BOOL MiApp_SetChannel(BYTE
Channel)”, que configura o canal de comunicação a ser utilizado (YANG, 2009a). Como no
projeto não foi utilizado a funcionalidade de detecção automática de canal, seu valor foi configurado para o canal 25, que é o canal padrão do MiWi DE. Caso durante o processo de configuração do canal ocorra um erro, uma mensagem é exibida e a execução do programa interrompida. Caso a seleção do canal tenha sido realizada com sucesso, é feita uma chamada à função “void MiApp_ConnectionMode(BYTE Mode)” (YANG, 2009a) que configura o modo de conexão a ser utilizado. Essa função pode receber quatro tipos de parâmetros:
ENABLE_ALL_CONN
o Habilita qualquer tentativa de conexão; ENABLE_PREV_CONN
o Habilita apenas conexões que já existiram; ENABLE_ACTIVE_SCAN_RSP
o Configura o módulo para responder a qualquer active scan recebido; DISABLE_ALL_CONN
o Desabilita todas as requisições de conexão.
No projeto, por apresentar uma alternativa mais simples, o parâmetro escolhido foi o ENABLE_ALL_CONN.
A próxima função executada é a “BYTE EstablishConnection(BYTE
ActiveScanIndex, BYTE Mode)”. Ela recebe como parâmetros de entrada o índice na tabela
resultante do active scan para o nó que se deve estabelecer uma conexão, se seu valor for “0xFF” ela tentará estabelecer uma conexão com qualquer dispositivo. O parâmetro “mode” especifica o modo de conexão: “MODE_DIRECT”, usado quando o dispositivo destino está no alcance do rádio, ou “MODE_INDIRECT”, para estabelecer a conexão indiretamente através de outros nós. Após ser chamada, essa função retorna um byte indicando o índice da nova conexão na tabela de conexões, quando seu valor é 0xFF significa que não foi possível estabelecer uma conexão (YANG, 2009a).
No projeto, como a rede foi construída com apenas um nó, foram utilizados os parâmetros 0xFF e “MODE_DIRECT” (YANG, 2009a). No entanto, existe uma pequena diferença entre a chamada dessa função entre o coordenador e a estação remota. No coordenador, ela é chamada apenas uma vez, e caso o valor de retorno seja 0xFF a função “StartConnection()” é acionada (Figura 17). Já na estação, enquanto o valor de retorno não for diferente de 0xFF ela é chamada constantemente (Figura 18). Em ambos os módulos, quando se tem uma chamada bem sucedida da função “EstablishConnection()”, o processo de configuração dos módulos é finalizado.
A função “BOOL StartConnection(BYTE Mode, BYTE ScanDuration, DWORD
ChannelMap)”, acionada pela base, recebe três parâmetros de entrada (YANG, 2009a):
Mode
o Identifica o modo de iniciar a PAN; ScanDuration
o Define o tempo máximo de execução da avaliação do canal; ChannelMap
o Identifica os canais a serem escaneados no processo.
Na base, o campo “Mode” é definido como “START_CONN_DIRECT”, para que a conexão seja estabelecida sem a detecção de ruído. O campo “ScanDuration” foi colocado em 10, o que equivale a um tempo de 1 segundo de acordo com a equação: ScanTime(us) =
configurado como “START_CONN_DIRECT”, o parâmetro “ChannelMap” é automaticamente descartado (YANG, 2009a).
Com a realização dessas funções, o processo de configuração do hardware e do protocolo MiWi nos módulos está finalizado. A partir desse ponto, ambos os módulos entram em um laço para execução de suas rotinas especificas. No entanto, as operações de envio e recepção de dados via rádio realizadas durante esse laço não mudam entre os módulos. Sendo assim, não existe motivo para essas operações serem abordadas de forma separada.
A cada iteração do laço principal do programa, é acionada a função “MiApp_MessageAvailable()”. Essa função retorna verdadeiro sempre que for recebida uma nova mensagem de um dos nós da rede.
Toda vez que uma nova mensagem é recebida, o MiApp automaticamente organiza o seu conteúdo em um struct do tipo “RECEIVED_MESSAGE” (Figura 19). Nessa estrutura, estão contidas informações importantes como os bytes de configuração da mensagem, o endereço de origem e o payload da mensagem. Por padrão, o MiApp já cria a variável “rxMessage” do tipo “RECEIVED_MESSAGE”.
Figura 19 - Struct RECEIVED_MESSAGE. Fonte: Próprio Autor
Dessa forma, após a detecção de uma nova mensagem, é possível acessar a todas as informações recebidas através da variável “rxMessage”. Caso se deseje acessar, por exemplo, o conteúdo do primeiro byte recebido, basta apenas fazer a seguinte chamada: “rxMessage.PayLoad[0]”.
Após a recepção da mensagem e realização das operações adequadas com os dados coletados, a mensagem recebida é então descartada ao se chamar a função “MiApp_DiscardMessage()”.
Por outro lado, o processo de envio de dados pode ser realizado de duas formas:
broadcast - a mensagem é enviada para todos os nós da rede, ou unicast - a mensagem é
enviada apenas para um dispositivo. Como nesse projeto foi definida a utilização de mensagens do tipo broadcast, apenas esse tipo será abordado aqui.
Para cada byte que se deseja enviar através do protocolo, a função “void
MiApp_WriteData(BYTE OneByteTxData)” é acionada. Sendo assim, caso o usuário
necessite enviar “n” bytes, essa função deve ser chamada “n” vezes, contanto que o valor de “n” não ultrapasse o tamanho máximo configurado do buffer TX, no projeto esse valor foi configurado para enviar até 100 bytes por vez.
Com toda a informação que se deseja enviar carregada no buffer TX a função “BOOL
MiApp_BroadcastMessage(BOOL SecEn)” é acionada. Seu parâmetro de entrada indica se o payload da mensagem deve ou não ser criptografado. Caso a operação tenha sido realizada
com sucesso essa função retornará “verdadeiro”. Como não foi utilizado criptografia dos dados no projeto, “SecEn” é configurado como FALSE.
3.3.2 Firmware da Estação Remota
Ao ligar o módulo da estação remota, inicialmente são realizadas as rotinas de configuração do hardware do microcontrolador, inicialização do módulo RF e criação de uma conexão com a base.
Após essas operações de configuração, a estação remota entra em um laço onde são executadas suas funcionalidades específicas. Na figura 20, é possível visualizar um fluxograma das operações realizadas por esse módulo e dos caminhos tomados, a depender do evento ocorrido.
Figura 20 - Fluxograma da estação remota Fonte: Próprio Autor
