PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE ENGENHARIA DA COMPUTAÇÃO

Transcrição

1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE ENGENHARIA DA COMPUTAÇÃO DANILO NEGOZZECK GIOVANNI PEREIRA ZANTEDESCHI MARCELO CORRÊA DE PAULA SILVA EASY EMBEDDED CONNECTION RELATÓRIO TÉCNICO FINAL CURITIBA 2011

2

3 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE ENGENHARIA DA COMPUTAÇÃO DANILO NEGOZZECK GIOVANNI PEREIRA ZANTEDESCHI MARCELO CORRÊA DE PAULA SILVA EASY EMBEDDED CONNECTION RELATÓRIO TÉCNICO FINAL Professor Orientador: Afonso Ferreira Miguel Visto do Orientador CURITIBA 2011

4

5 RESUMO O projeto proposto vem de encontro à necessidade enfrentada por sistemas embarcados empregados em aplicações simples, onde a comunicação com dispositivos dispostos a longas distancia se faz necessária. Para tal tipo de comunicação onde o tráfego de dados não é significativamente grande, não se faz necessário o uso de um link dedicado, sendo assim necessário utilizar a Internet. O projeto proposto visa implementar um sistema embarcado que possibilite o fácil acesso a rede de dados pública (Rede).

6

7 SUMARIO 1 INTRODUÇÃO DETALHAMENTO DO PROJETO HARDWARE Placa Mãe Conexão Ethernet KIT WiFi KIT GPRS Outros KERNEL PET# Gerenciamento de Tarefas Drivers Drivers no PET# Driver de Ethernet Driver de WiFi e GPRS Outros Drivers ADAPTAÇÃO HAL Camada de Adaptação API LWIP Visão Geral LWIP Camada de emulação de Sistema Operacional Gerenciamento de buffer e memória Packet buffers Gerenciamento de memória Interface de Rede Estrutura de Dados Socket Layer Camada de Conexão APLICAÇÕES MÓDULO WI-FI Utilização Geração e transmissão do pacote Conexão com o ponto de acesso Conexão com o Kit Arm MÓDULO GPRS Utilização Conexão com a rede GPRS Conexão com o Kit Arm PROCEDIMENTOS DE TESTE E VALIDAÇÃO DO PROJETO MÓDULO PET# MÓDULO WIFI MÓDULO GPRS APLICAÇÃO TESTES CAIXA PRETA RESULTADOS IDEIA, TECNOLOGIA, MOTIVAÇÃO... 37

8 5.2. CONTATO COM AS TECNOLOGIAS LWIP PET# Módulos de GPRS e Wi-Fi DESAFIOS E PROBLEMAS Superestima Comportamento da equipe Integração TESTES CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS... 46

9 1 INTRODUÇÃO Sistemas embarcados são sistemas com o objetivo de, quando inseridos em um meio, monitorá-lo, controlá-lo ou automatizá-lo. Grande parte dos sistemas embarcados opera com restrições temporais (deadlines), sendo denominados ERTS (Embedded Real-Time System - sistema embarcado de tempo real ). As respostas produzidas por estes sistemas devem ser geradas dentro de limites de tempo bem definidos. Nos sistemas de tempo real, de forma mais enfática do que nos sistemas de computação para processamento de dados, é necessário garantir a qualidade do software embarcado. Para os ERTS, características como previsibilidade, confiabilidade, robustez e segurança são obrigatórias (Cadamuro Junior, 2007). Pensando em um projeto com foco em sistemas embarcados surgiu a idéia, por parte de um integrante da equipe que trabalha na empresa Bematech S.A, de desenvolver sobre um sistema embarcado já conhecido, o PET#. O PET# é uma versão de microkernel (como o QNX) de tempo real da família PET. A primeira versão do PET foi liberada em 1995 para uso acadêmico e no ano seguinte para uso industrial, sendo que ambas as versões foram escritas para microcontroladores Intel O PET# foi desenvolvido durante a tese de doutorado do Doutor João Cadamuro Junior. Este projeto desenvolverá uma API para o PET#, no KIT ARM9, utilizando a biblioteca LWIP, para suprir a necessidade dos sistemas embarcados atuais de ter uma comunicação com a Rede através de vários dispositivos, mantendo a possibilidade de atualizar a biblioteca LWIP sem afetar o funcionamento do sistema. Para alcançar o objetivo deste projeto, será necessário um grande conhecimento de TCP/IP, LWIP e PET#. Como a equipe não possui experiência com o PET# e com a biblioteca LWIP será necessário um estudo aprofundado sobre essas tecnologias.

10 2 DETALHAMENTO DO PROJETO O projeto está dividido em cinco partes interligadas, conforme a figura 1 em que as partes estão divididas por cores, cada uma delas pode ser desenvolvida de maneira independente das outras e, depois, integrada ao todo. Figura 1 Estrutura do Projeto 2.1. HARDWARE Placa Mãe O KIT utilizado é o modelo AT91SAM9G20-EK que conta com o microcontrolador ARM926EJ-S, este microcontrolador é baseado na família ARM (Atmel [8]). A principal característica deste KIT de desenvolvimento para o projeto é que além de possuir um microcontrolador robusto que é muito utilizado no mercado, tendo assim uma baixa possibilidade de ser descontinuado. O KIT AT91SAM9G20-EK irá integrar os outros KITs de acesso a rede ao núcleo do PET#, sendo assim denominado de Placa Mãe neste projeto.

11 O KIT AT91SAM9G20-EK disponibiliza as seguintes funcionalidades para o usuário utilizar em suas aplicações: Memória disponível no microcontrolador de 64 Kbytes para ROM e duas SRAM de 16 Kbytes; Memória disponibilizada pelo KIT de 96 MBytes para a SDRAM, 256 MBytes para a flash; Permite a entrada de cartões de memória do tipo SD. Disponibiliza as seguintes portas de comunicação: o Portas conexão Serial (RS 232); o USB; o Ethernet (RJ -45); o JTAG. Na figura 2 esta mostrando quais são os principais recursos do KIT, assim, a figura exibe uma forma simplificada do diagrama de blocos do KIT. A porta de comunicação Ethernet será utilizada para comunicação com a Internet, o detalhamento desta porta de comunicação está em um tópico dedicado. O processador que o KIT utiliza é o ARM926EJ-S, que é fabricado sobre a arquitetura ARM. O processador é RISC de 32 bits que suporta aplicações multitasking; este processador também implementa a tecnologia Jazelle, a qual permite ao processador aceleração via hardware para executar a Java Virtual Machine (JVM) para a execução de bytecodes Java. Opera com o clock de 400MHz.

12 Ethernet USB Memoria Flash ARM926EJS RS232 Memoria SDRAM Card Reader Figura 2 - Diagrama de bloco do KIT AT91SAM9G20-EK O KIT utilizado como placa mãe do projeto fornece três portas seriais, sendo uma porta exclusiva para debug e as outras duas para propósitos gerais. Está disponível no KIT dois leitores de cartões de memória SD Card, os quais poderão ser utilizados para expansão da memória de código. O KIT apresenta em relação as portas seriais duas abordagens, para as portas COM1 e debug somente foi implementado os pinos de transmissão e recepção, elas utilizam o componente ADN3202ARN para realizar o conversão dos sinais, porem esta componente somente converte os sinais dos pinos de transmissão e recepção (Atmel [8]). As figuras 3 e 4 exibem o diagrama elétrico da porta de debug e COM1. Na porta serial COM0 foi projetado o acesso a todos os recursos da porta serial, por isso, foi utilizado o componente MAX3241E, já que este permite a conversão dos sinais para todos os pinos da porta serial. A figura 5 mostra o diagrama elétrico para a porta COM0.

13 Figura 3 - diagrama elétrico para a porta serial de debug Figura 4 - diagrama elétrico para a porta serial de COM1

14 Figura 5 - diagrama elétrico para a porta serial de COM Conexão Ethernet O KIT AT91SAM9G20-EK acessa a Ethernet através de dois tipos de padrões, o RMII (Reduced Media Independent Interface) e o MII (Media Independent Interface). O padrão MII é usado para interconectar um controlador de rede MAC a um dispositivo físico. A MII pode conectar-se a um transceptor externo através de um conector ou simplesmente conectar dois chips no mesmo circuito impresso. Ser "independente de mídia" significa que qualquer um dos diferentes tipos de dispositivos físicos podem ser usados sem redesenhar ou substituir o hardware MAC. No padrão RMII há uma redução na quantidade de pinos e sinais entre o MAC e a camada física, como exemplo, o padrão MII utiliza 16 pinos para a camada física, enquanto que o padrão RMII utiliza oito pinos. No padrão RMII o clock utilizado é de 50Mhz, ou seja, o dobro do clock utilizado pelo padrão MII. O KIT vem na configuração de fabrica com o padrão RMII habilitado, pois o conector RJ-45 compartilha duas portas com o leitor de cartão SD MCDA, se o modo MII for habilitado, o leitor MCDA não poderá ser utilizado, pois poderá causar um

15 conflito de sinais e danificar tanto o controlador do Ethernet quanto o cartão SD (Atmel [8]). A conexão do processador ARM9 com o conector de Ethernet não é feita de forma direta, o KIT utiliza o componente DM9161AEP para realizar a interface entre esses dispositivos. O DM9161AEP é fabricado pela Davicom, desenhado para redes 100BASE-TX e 10BASE-T, aceitando conexões através do cabo UTP categoria 3 ou 5. Nas figuras 6 e 7 são exibidos os diagramas referentes ao funcionamento da Ethernet. A figura 6 exemplifica o diagrama elétrico mostrado na figura 7. Figura 6 - Diagrama em blocos da interface de Ethernet

16 Figura 7 Conexão Ethernet

17 KIT WiFi O acesso a rede Wireless será fornecido pelo KIT Nano Wireach, fabricado pela Connect One, este KIT permite ao usuário quatro modos de operação (Connect One [3]): LAN to WiFi Brigde: Este modo permite uma ponte transparente da LAN sobre a WiFi. Utiliza o padrão RMII para interfacear o MAC com a camada física; SerialNet Serial to WiFi Bridge: Permite realizar uma ponte entre conexões seriais sobre a rede WiFi; PPP modem emulation: Permite utilizar o KIT como um modem usando o protocolo PPP; Full Internet Controller mode: Permite a aplicação realizar operações complexas de internet como , FTP entre outros. Para o Easy Embedded Connection o modo de operação escolhido é o SerialNet, pois como a conexão entre o Kit Placa Mãe e o Nano Wireach é serial, o protocolo SerialNet apresenta melhores características para este trabalho. Os pacotes serão processados pelo LWIP e o KIT Nano Wireach somente irá realizar a conexão com a rede. Na figura 8 é exibido o diagrama exemplificando como o Nano Wireach pode ser conectado quando opera no modo SerialNet. A figura 9 mostra como será a conexão entre o processador ARM9 e o rede WiFi, veja que o PET# e o LWIP serão os responsáveis por construir os pacotes de dados, ficando para o hardware somente o envio do dado. A conexão entre o KIT AT91SAM9G20-EK e o Nano Wireach irá se realizar através da porta RS-232. Devido às dimensões reduzidas do Nano Wireach, o conector do RS-232 não pode ser conectado diretamente ao Nano Wireach, por isso, deverá ser construído um conector especialmente para o Nano Wireach.

18 Figura 8 - Diagrama de operação Arm9 Porta Serial Nano wireach Rede WiFi Figura 9 - Diagrama de blocos da operação da rede WiFi KIT GPRS A comunicação via GPRS será realizada através do KIT de desenvolvimento EVK2 da fabricante Telit. O KIT de desenvolvimento EVK2 é composto pela placa mãe CS1139B e por uma placa adaptadora que pode agregar funcionalidades extras ao KIT de desenvolvimento, o fabricante disponibiliza vários modelos destas placas, cada uma com funcionalidades diferentes, como acesso a sinal de GPS, acesso a rede GSM, acesso a GPRS (Telit Communications [7]). A comunicação entre o KIT e a aplicação é feita através da porta serial. O KIT permite o suporte ao áudio, possibilitando que sejam conectados alto-falantes e microfones, porem a utilização da funcionalidade de áudio não esta no escopo do projeto. O KIT exige para o seu funcionamento um SIM card com acesso valido a rede GSM. A figura 10 demonstra o diagrama de blocos da conexão do KIT EVK2 ao processador ARM9. Para utilizar a rede GPRS será necessária a contratação de um serviço de acesso à rede GPRS. Os pacotes de dados iram ser processados pela camada do LWIP, e o KIT EVK2 irá se portar como uma ponte entre a rede GPRS e a aplicação, pois o objetivo é deixar transparente para a aplicação qual é a rede escolhida para a transmissão dos dados. Arm9 Porta Serial EVK2 Rede GPRS Figura 10 - Diagrama de blocos para o KIT GPRS

19 Outros Além dos KITs de desenvolvimento já descritos, um computador também será conectado ao KIT AT91SAM9G20-EK para auxiliar durante as etapas de testes e visualização dos dados. O KIT Placa Mãe disponibiliza portas para conexão de periféricos, como a conexão de display LCD, alto-falante, push-buttons. Os dispositivos conectados podem se comunicar com o processador ARM9, permitindo criar interfaces de teste e entrada de dados KERNEL PET# Gerenciamento de Tarefas O gerenciamento de tarefas no PET# é feito através de preempção, já que todas as tarefas são criadas como Threads e executam paralelamente Drivers No contexto da informática, a função de um driver de dispositivo é aceitar requerimentos abstratos do software independente do dispositivo acima dele e cuidar para que a solicitação seja executada, permitindo que o software interaja com o dispositivo. Um driver não é um processo ou tarefa (programa) gerido independentemente pelo sistema, mas sim um conjunto de tabelas contendo informações sobre cada periférico, bem como os fluxos de informação circulante entre o sistema operacional e o periférico. Pode ser visto em alguns casos como parte do processo que está em execução (código). Um driver de dispositivo simplifica a tarefa da aplicação atuando como um tradutor entre o dispositivo e as aplicações ou o sistema operacional. O código de alto nível das aplicações pode ser escrito independentemente do dispositivo que será utilizado. Qualquer versão de um dispositivo, como uma impressora, requer os seus próprios comandos. Entretanto, a maioria das aplicações acessam os dispositivos usando comandos genéricos de alto-nível, como println, que imprime um texto. O driver converte esses comandos genéricos em um código de baixo-nível interpretado pelo dispositivo. Em uma melhor tradução: um driver opera ou controla um hardware, ou seja, é o meio de comunicação do hardware.

20 Drivers no PET# O sistema embarcado de tempo real PET# utiliza uma filosofia de drivers onde a ideia central é a de que todos os drivers tenham a mesma estrutura, composta de apenas algumas funções: Rotina de Criação int dev_create ( const char * path, DEV_CONFIG * cfg ); Rotinas de Inspeção int dev_findfirst ( DEVBLK * devblk ); int dev_findnext ( DEVBLK * devblk ); int dev_search ( const char * path, DEVBLK * devblk ); Rotinas para abrir e fechar os Devices int dev_open ( const char * path, unsigned int access ); int dev_close ( int handle ); Rotinas de Manipulação int dev_read ( int handle, void * buf, UINT32 len, UINT32 offset ); int dev_write(int handle, const void * buf,uint32 len, UINT32 offset); int dev_ioctl ( int handle, int request, void * arg, int arg_size ); Ao invocar o comando de criação de um Device driver usando o PET#, uma mensagem é enviada para uma Thread que gerencia os Device Drivers, a DeviceManager, esta mensagem é então interpretada e uma nova Thread é criada com o Device requisitado Driver de Ethernet O driver de Ethernet usado pelo PET# foi desenvolvido junto com o sistema operacional e é considerado robusto pelo seu desenvolvedor. O drive utiliza uma estrutura um pouco diferente dos padrões do PET# pela dificuldade de gerenciar o envio e recebimento de pacotes.

21 Driver de WiFi e GPRS Os drivers de GPRS e WiFi não serão desenvolvidos, pois como os KITs utilizados são conectados via serial na placa mãe, será utilizado o drive serial tty para estes KITs. A utilização destas interfaces será descrita na camada de ADAPTAÇÃO Outros Drivers O PET# possui outros drives implementados, dentre eles: Drivers de Serial TTY, FLASH e EEPROM; Driver RTC; Drivers de Impressão para impressora térmica; E outros ADAPTAÇÃO HAL Para que os dispositivo de rede, como o WiFi e o GPRS, funcionem corretamente no PET# eles precisam possuir um Driver e um HAL. O Drive tem a funcionalidade de conectar o SO ao hardware, fornecendo configurações e abstração de dispositivos, já o HAL tem como objetivo implementar as funcionalidades que o dispositivo fornece, pois como cada dispositivo possui suas particularidades, como de configuração ou tratamento de retornos, se faz necessário uma serie de especializações. Será desenvolvido um HAL para cada Interface de rede, permitindo a máxima utilização dos recursos específicos de cada dispositivo. Assim como já existem diversos Driver desenvolvidos no PET# também existem diversos HALs que já estão consolidados Camada de Adaptação Ao utilizar o LWIP com o PET# será necessário implementar mais uma camada, esta camada de adaptação fará a comunicação entre a camada HAL e o LWIP.

22 O objetivo desta camada é permitir que as funções implementadas no HAL possam ser usadas pelo LWIP sem a necessidade de altera-lo, pois assim ele pode ser atualizado com o mínimo ou nenhuma alteração. Para que a camada de adaptação funcione conforme o esperado, deverão ser definidos dois ponteiros dentro da estrutura da interface de rede do LWIP, além da implementação das funções desta camada, são eles input e output (que serão melhor explicados na sessão de interface de rede) a fim de realizar a comunicação com o HAL. Portanto o ponteiro de input deverá apontar para a função, dentro da camada de adaptação, que vai trabalhar os dados para serem executados pelo HAL do dispositivo desejado quando um pacote for recebido. O ponteiro output aponta para a função dentro da camada de adaptação que é chamada quando um pacote está para ser enviado na rede física, fazendo a conexão entre o LWIP e o HAL API LWIP O interesse em conectar computadores com dispositivos por eles suportados em redes cresceu muito nos últimos anos, dispositivos como sensores podem ser conectados a uma rede já existente como, por exemplo, a internet e então podem ser monitorados de qualquer lugar (LWIP [2]). Se os sensores estiverem embarcados será necessário que eles sejam fisicamente pequenos e baratos devido às limitações de espaço que o hardware embarcado geralmente possui, também será necessário uma implementação do protocolo de internet que funcione com limitações computacionais e de memória. Então temos a implementação de uma pilha TCP/IP que é pequena o suficiente para ser usada em sistemas menores, o LWIP Visão Geral LWIP O LWIP contém diversos módulos de suporte, sendo eles, a camada de emulação do sistema operacional, os subsistemas de gerenciamento de buffer e memória, funções de interface de rede e funções de checksum, incluindo uma API abstrata (na maioria das vezes um processo do usuário).

23 O LWIP usa um modelo em que todos os protocolos ficam em um único processo separado do kernel (LWIP [2]). Aplicações podem tanto ficar no mesmo processo do LWIP ou em vários processos separados com a comunicação entre a pilha TCP/IP e as aplicações sendo feita por chamadas de função, quando uma aplicação divide um processo com o LWIP ou através de uma API abstrata Camada de emulação de Sistema Operacional A fim de tornar o LWIP portável, chamadas de funções e estruturas de dados não são utilizadas diretamente no código, esta camada provê uma interface uniforme para os serviços de Sistemas Operacionais (SO). Geralmente ao portar o LWIP para outro sistema operacional apenas esta camada será alterada. A camada de emulação de sistema operacional fornece uma funcionalidade de timer que é usada pela TCP estes timers tem uma granularidade de 200ms e chamam a função registrada quando o time-out acontece possuindo um único mecanismo de sincronização fornecido (semáforo), que pode ser emulado por outras primitivas de sincronização, por exemplo, como variáveis condicionais. A transferência de mensagem é feita através de um mecanismo simples que usa uma abstração chamada mailbox que tem duas operações post e fetch. A operação post não vai bloquear o processo, as mensagens postadas na mailbox são colocadas em uma fila pela camada de emulação de SO até que outro processo as pegue utilizando o fetch, a mailbox pode ser implementada com a utilização de semáforos Gerenciamento de buffer e memória O gerenciamento de buffer e memória deve ser preparado para acomodar buffers de tamanhos variáveis, que possam conter desde grandes segmentos de TCP com várias centenas de bytes até pequenas respostas de echo com apenas alguns poucos bytes, os dados do buffer devem ficar em uma memória que não seja gerenciada pelo subsistema de rede, como uma ROM ou a memória da aplicação Packet buffers Um packet buffer, ou pbuff, é a representação interna de um pacote no LWIP e foi desenvolvido tendo em mente o pequeno tamanho da stack. A estrutura pbuf suporta tanto a alocação dinâmica de memória para segurar o conteúdo dos pacotes

24 quanto o uso de memória estática. Pbufs podem ser agrupados em uma lista, chamada de pbuf chain. Existem 3 tipos de pbuffs, são eles: PBUFF_RAM os dados do pacote são armazenados em memória e gerenciados pelo subsistema pbuf. PBUFF_ROM os dados são armazenados em memória porém não gerenciados pelo subsistema pbuf. PBUFF_POOL Consiste em pbufs de tamanho fixo alocados de uma pool de pbufs com tamanho fixo. Os três tipos de pbuf têm diferentes usos. Pbufs do tipo PBUF_POOL são geralmente utilizados por drivers de dispositivos de rede já que a operação realizada para alocar um pbuf é rápida e, portanto, adequado para gerenciamento de interrupções. PBUF_ROM são usados quando uma aplicação envia dados que é armazenado em memória e gerenciado pela aplicação. Estes dados não devem ser alterados depois que o pbuf for enviado para a pilha TCP/IP, por isso sua principal utilização é quando os dados estão armazenados na ROM. Pbufs do tipo PBUF_RAM também são usados quando uma aplicação envia dados gerados dinamicamente. Neste caso, o sistema pbuf aloca memória não apenas para os dados da aplicação, mas também para os headers que irão preceder os dados e assume o pior caso. O tamanho dos headers é configurável em tempo de compilação. Em essência, pbufs de entrada são do tipo PBUF_POOL e os de saída são do tipo PBUF_ROM ou PBUF_RAM. A estrutura de um pbuf consiste em dois ponteiros, dois campos de tamanho, o campo de flags e um contador de referência. O campo next é um ponteiro para o próximo pbuf quando este se encontra em uma pbuf chain. O ponteiro de payload aponta para o início dos dados no pbuf. O campo len contêm o tamanho dos dados do pbuf. O campo tot_len contém o sum do pbuf e de todos os pbufs em uma pbuf chain. O campo flags indica o tipo de pbuf e o campo ref contém um contador de referência.

25 Gerenciamento de memória O gerenciamento de memória faz alocações e desalocações de regiões contíguas de memória e pode encolher o tamanho de um bloco de memória alocado anteriormente. O gerenciador de memória usa uma porção dedicada da memória total no sistema, isso garante que o sistema de rede não use toda a memória disponível. Internamente o gerenciador de memória mantém um registro de toda a memória alocada, utilizando uma pequena estrutura acima de cada bloco alocado de memória, esta estrutura usa dois ponteiros next e previous e uma flag para indicar se o bloco de alocação está alocado ou não. Ele procura na memória um bloco de alocação que seja grande o suficiente para realizar a alocação necessária. O primeiro bloco que for grande o suficiente será usado (first-fit). A fim de evitar a fragmentação, a flag utilizada dos blocos anterior e posterior são verificadas. Se qualquer uma delas não estiver sendo utilizada, os blocos são combinados em um único grande bloco não utilizado Interface de Rede No LWIP os drivers de dispositivo para o hardware de rede são representados por uma estrutura de interface de rede similar à do BSD. As interfaces de rede são mantidas conectadas em uma lista global, que é referenciada pelo ponteiro next na estrutura. Cada interface de rede tem um nome, este nome de duas letras identifica o tipo de driver de dispositivo utilizado nesta interface de rede e só é utilizado quando a interface é configurada por um operador humano em tempo de execução. O nome é setado pelo driver de dispositivo e deveria refletir o tipo de hardware que é representado pela interface de rede, como esses nomes não necessariamente são únicos, o campo num é usado para distinguir interfaces de rede diferentes que sejam do mesmo tipo Estrutura de Dados As estruturas de dados usadas na implementação do TCP são pequenas devido às restrições de memória dos sistemas para os quais o LWIP foi desenvolvido, há uma troca entre complexidade da estrutura de dados e a

26 complexidade do código que usa essas estruturas, e neste caso a complexidade do código foi sacrificada a fim de manter as estruturas de dados pequenas Socket Layer Por causa do alto nível de abstração dado pelo socket BSD ele não serve para uso com o LWIP. Particularmente o socket BSD precisa copiar os dados da aplicação que serão enviados para buffers internos para a pilha TCP/IP. Na maioria dos casos a API é um processo do usuário e o TCP/IP fica no kernel do sistema operacional evitando assim a cópia extra no buffer e melhorando muito o desempenho da API. A API não precisa que os dados sejam copiados entre aplicação e a pilha TCP/IP, já que a aplicação pode manipular os buffers internos diretamente Camada de Conexão Ao utilizar o LWIP com o PET# será necessário implementar uma camada a mais que será criada pela equipe, esta camada de conexão fará a comunicação entre a camada HAL e o LWIP APLICAÇÕES Verificar a atuação dos comandos disponibilizados ao usuário. Verificar se o sistema embarcado se comunica com a aplicação no computador MÓDULO WI-FI Wi-Fi é a denominação para o acesso a internet onde não são utilizados cabos para a conexão de equipamentos eletrônicos com o ponto de acesso a internet. O nome Wi-Fi vem do termo em inglês Wireless Fidelity, um trocadilho com os equipamentos de áudio da década de 50 que utilizavam o termo Hi-Fi para alta fidelidade de áudio. O IEEE é o responsável por publicar os padrões para desenvolvimento de equipamentos Wi-Fi, a norma IEEE é o padrão para os dispositivos wireless.

27 Utilização O módulo de acesso a rede Wi-Fi deve ser configurado antes de entrar em operação, para isso, os comandos de configuração são transmitidos ao módulo através de comandos AT. Os comandos AT foram desenvolvidos pela Hayes Communications em 1981 para a configuração de seus modens, estes comandos permitiam que aos usuários modificar a configuração original e acessar a memória. O AT do nome significa atenção, pois antes do desenvolvimento desta serie de comandos havia dificuldades em interpretar o que era dado e o que era fim de comando. Os comandos utilizados pelo módulo são uma extensão dos comandos AT originais, no módulo são comandos AT+i, o camando é composto por uma prefixo, corpo e o caractere de fim de comando, que é o carriage return <cr> (Connect One [4]). Os comandos não são sensíveis ao tamanho, assim, podem ser inserida tanto em caixa alta como em caixa baixa. Primeiramente o módulo precisa se conectar ao ponto de acesso Wi-Fi, depois de estabelecida a conexão com a ponto de acesso é necessário configurar a interface serial do módulo para se comunicar com o Kit Arm9. Com esta configuração inicial concluída o módulo Wi-Fi está pronto para transmitir os dados do Kit Arm9 para uma rede Wi-Fi Geração e transmissão do pacote O pacote de dados será gerado pela camada LWIP, responsável por formar um pacote de dados de acordo com a rede e o protocolo de transporte escolhidos, assim, todo processamento para o pacote a ser transmitido ou para o pacote recebido é feito pelo Kit Arm9. Ao sair do Kit Arm9 o pacote está pronto para ser transmitido à internet. O módulo Wi-Fi quando configurado para trabalhar no modo serial simplesmente forma uma ponte entre o Kit Arm9 e a rede Wi-Fi, assim, o módulo não causa nenhuma interferência no pacote, como a inclusão de um cabeçalho extra Conexão com o ponto de acesso Para utilizar a rede Wi-Fi é necessário realizar algumas configurações no módulo (Connect One [5]). Os comandos são executados na ordem exibida abaixo.

28 AT+IFD FACTORY DEFAULTS: Apaga as configurações atuais e aplica as configurações de fábrica; AT+IHIF = 1 HOST INTERFACE: Especifica a interface de comunicação, neste caso será utilizada a interface USART0; AT+IBDRF = 9 BAUD RATE FIXED: Fixa a taxa da baud rate no módulo para a taxa 9, que é igual a bps; AT+IRP20 REPORT STATUS: Informa uma lista dos pontos de acesso encontrados; AT+IWLSI = X WIRELESS LAN SERVICE SET IDENTIFIER: Indica que o ponto de acesso X deverá ser o utilizado; AT+IWSTN WIRELESS LAN SECURITY TYPE ARRAY: Indica qual o tipo o segurança o ponto de acesso utiliza. Este item deverá ser configurado após se conhecer o tipo de segurança que o ponto de acesso utiliza; AT+DOWN TERMINATE INTERNET SESSION: Executa um reset no módulo e aplica as configurações realizadas Conexão com o Kit Arm9 A conexão com o kit Arm9 é feita através da porta serial, no módulo Wi-Fi a porta serial deve ser configurada antes de seu uso (Connect One [6]), os comandos abaixo configuram o módulo Wi-Fi a utilizar a porta serial como entrada de dados. AT+ILPRT = 5100 DEVICE LISTENING PORT: Define uma porta no módulo onde este escuta o Kit Arm9; AT+IFCHR = \X0D FLUSH CHARACTER: Indica que o caractere de fim de transmissão de dados; AT+ISNSI = 9 DEVICE SERIAL INTERFACE: Indica que a taxa de baud rate será de bps; AT+ISNMD ACTIVATE SERIALNET MODE: Ativa o modo ponto serial para Wi-Fi. Após o módulo entrar no modo de conexão serial não são mais aceitos comandos AT, todos os dados transmitidos do Kit Arm9 serão interpretados dados a serem transmitidos. Para entrar novamente no modo de comandos AT é necessário