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.