uma série de bibliotecas com funcionalidades de listas, funções de busca, criptografia, compactação, protocolos, funções de hash etc.

Transcrição

1 Mobile Embedded System Plataform MESP Danilo Reis, Ricardo Lino, Alberto Taborga, Viktor Saboia, Paulo Facó, Fabio Reis,David Araújo Departamento de Tecnologia Fujitec Fortaleza, Brazil Resumo O presente artigo apresenta a plataforma de hardware e software (MESP) desenvolvida pela empresa Fujitec para desenvolvimento de aplicações embarcadas com suporte a conectividade sem fio (wifi, GPRS, 3G ou 4G), tecnologia de leitura de cartões smartcard sem contato, leitura biométrica de impressão digital e interface padrão NFC (Near Field Communication) para celulares. A plataforma suporta três arquiteturas de processadores (Intel Atom E680, ARM e processador softcore NIOS II) e múltiplos sistemas operacionais, e sua utilização reduz muito o tempo de desenvolvimento de sistemas embarcados complexos. Palavras chave: Sistemas embarcados. Smartcard sem contato. RF-ID. Conectividade. NFC. I. Introdução Como consequência direta da Lei de Moore, o mundo vivencia um crescimento exponencial da capacidade de processamento das plataformas microprocessadas, assim como uma substancial redução nos respectivos preços de mercado. Nesse contexto, a cada dia que passa as aplicações embarcadas têm mais necessidade de utilizar serviços disponíveis na internet e ser sensíveis a contexto. É comum também, para aplicações embarcadas, a necessidade de suportar múltiplos protocolos de comunicação, interoperar com múltiplos dispositivos e possuir uma interface amigável. Visando obter uma plataforma de desenvolvimento de aplicações embarcadas capaz de atender a esses novos requisitos, a Fujitec projetou e desenvolveu a Mobile Embedded System Plataform (MESP). Esse sistema objetiva ser uma referência de hardware e software que ajude o desenvolvedor a criar projetos utilizando os componentes disponibilizados na plataforma, reduzindo significativamente o tempo de desenvolvimento de sistemas embarcados. A plataforma MESP compõem-se, basicamente, de seis módulos: - Módulo do núcleo microprocessado é onde se encontram a CPU, controladores de memória DDR RAM, memória flash, relógio tempo real e demais componentes de hardware que possibilitam a execução do sistema operacional e firmwares aplicativos. Esse módulo suporta diferentes arquiteturas de processador, implementando atualmente as arquiteturas Intel Atom E680 (X86), ARM e FPGA com microprocessador RISC softcore 32 bits. - Módulo de conectividade georreferenciamento compõe-se de subsistemas que possibilitam a conectividade com redes Wifi, GPRS, 3G e um módulo GPS padrão NMEA, que possibilita a localização do dispositivo. - Módulo de leitora de smartcard sem contato e NFC consiste de uma leitora ISO 14443, que possibilita a leitura de cartões inteligentes sem contato, dos tipos A, B e I-Code e interfaceamento com dispositivos com interface NFC. Fazem parte também desse módulo o controlador de módulos de segurança (SAM) que faz a interface com módulos SAM encapsulados no padrão SIM Card. - Módulo de fonte é responsável por prover uma alimentação confiável e estável para os demais módulos da plataforma. Para prover essa funcionalidade, o módulo foi dividido nos seguintes submódulos: filtros EMI, supressores de transientes, no-break e fontes chaveadas nas tensões de 5.0 V, 3.3 V, 1.2 V; - Módulo de interface com o usuário é responsável por prover as funcionalidades necessárias para interagir com o usuário, compondo-se de um display TFT gráfico (800 x 600) com 16M de cores, módulo de áudio com 16 bits DAC, teclado de funções capacitivo e câmera USB com 1.3 megapixels com resolução de 640 x Módulo de interface com dispositivos externos

2 possibilita que a plataforma se comunique com dispositivos periféricos externos que possuam as interfaces padrão de rede RSsubmódulos do sistema, por meio de 485, CAN e USB OTP externa. A ideia geral da plataforma é que o núcleo se comunique no nível físico com os demais interfaces físicas padronizadas (conectores-padrão). No nível lógico, a comunicação entre o núcleo e submódulos se dá por meio de protocolos-padrão de mercado, tais como USB / RS-232 / I2C. Essa estratégia facilita a adição de novos módulos à plataforma, desde que sejam compatíveis com os protocolos e interfaces disponibilizados na plataforma. Outra vantagem de utilizar protocolos-padrão é a facilidade para reutilizar códigos de device drivers como base do desenvolvimento dos device drivers dos componentes da plataforma. Neste artigo, é mostrada, como estudo de caso, uma instância do projeto referência da plataforma aplicada no desenvolvimento de um validador dor embarcado para uma aplicação de pagamento eletrônico de passagens em um sistema de transporte público. O projeto utiliza a tecnologia de cartões sem contato e aparelhos celulares com interface NFC para receber os pagamentos dos usuários. Esse projeto foi escolhido por requerer um grande número de componentes da plataforma MESP, recebendo a denominação i-get. II. Arquitetura geral A. Módulos A arquitetura da plataforma MESP tem a flexibilidade como uma de suas principais ipais diretrizes de projeto. Por isso, sua arquitetura requereu que os principais componentes se comunicassem entre si por meio de interfaces padronizadas nos níveis físico (conexões elétricas) e lógico (protocolos / padrões de comunicação). Esse requisito também foi estendido ao projeto da plataforma de software. Com o intuito de prover flexibilidade e portabilidade das aplicações de firmware entre as possíveis arquiteturas da plataforma, foi criada uma camada de abstração de hardware (Hardware Abstract Layer HAL) [5], que é implementada nos diferentes sistemas operacionais suportados pela ferramenta. A junção do HAL com um conjunto de bibliotecas de software geralmente utilizadas em desenvolvimento de firmwares embarcadas recebeu a denominação DomOS. Essa biblioteca de funções aglutina uma série de bibliotecas com funcionalidades de listas, funções de busca, criptografia, compactação, protocolos, funções de hash etc. O DomOS especifica uma API abstrata padronizada de acesso a todos os componentes de hardware da plataforma. Essa API faz basicamente a adaptação entre a API especificada na plataforma MESP e a API de acesso nativo do sistema operacional aos componentes de hardware. A ideia é similar a uma máquina virtual, sendo que a abstração se dá no nível dos componentes da plataforma, e não no nível das instruções de processamento. Figura 1.0 Diagrama de blocos da plataforma MESP

3 B. Especificações Técnicas No que tange aos componentes de hardware, a plataforma MESP possui as seguintes especificações técnicas: Leitora de Cartão Sem Contato Tipo A/B (ISO 14443); Expansão com canal serial para leitora de terceiros (Inside/ASK/NFC); Criptografia DES, Triple DES, AES; Memória RAM de 128 Mbytes a 2 Gbytes DDR ou DDR2; Memória Flash de 512 Mbytes a 16 G; Módulo GPS com antena interna; Interface de comunicação com rede telefônica GPRS ou 3G; Interface WiFi Padrão b/g ; Interface de comunicação bluetooth; Display TFT colorido 800x480 pixels com backlight; Controle de intensidade do backlight e contraste; Teclado de funções com tecnologia capacitiva com cinco teclas (UP, DOWN, LEFT, RIGHT, ENTER); 1 interface USB interna; 1 interface USB externa; 1 interface Serial RS485 (externa); 1 interface sonora com usuário; Suporte para dois módulos SAM tipo m, de acordo com a norma ISO 7816; Suporte aos sistemas operacionais Linux Ubuntu e Windows Embedded 7.0; Tensão de entrada de 8-28 Volts; Fonte com proteção de sobretensão, inversão, transientes rápidos; No-break com autonomia de uma hora; Homologação Anatel; Homologação FCC parte 15; Homologação CE; Compatibilidade com a norma Restriction of Certain Hazardous Substances (RoHS); Consumo inferior a 10 Watts.

4 III. Núcleo Processamento Na plataforma, o núcleo é o componente de hardware responsável por executar o sistema operacional e o firmware aplicativo. O núcleo pode assumir três diferentes arquiteturas: Arquitetura X86 utilizando o processador Intel Atom E680[1] Essa arquitetura é otimizada para performance e compatibilidade com o mundo PC (Personal Computers ). O processador roda com um clock de 1.6 GHertz, com o chipset EG20T tendo controlador de memória DRAM DDR2 de até 2 Gbytes, controlador do display com interfaces LVDS e RGB, relógio tempo real, controlador de memória micro SD para memória flash com até 32 Gbytes, controladores I2C, 4 portas seriais, SPI controlador com 6 portas USB e GPIO. Esse núcleo é bastante poderoso, possibilitando rodar em um ambiente embarcado aplicações que anteriormente só eram possíveis em computadores pessoais. A principal desvantagem dessa arquitetura, quando comparada com as demais arquiteturas da plataforma, é o consumo relativamente elevado (por volta de 8 Watts). A dissipação de potência, em alguns casos, pode ser um problema, pois, dependendo do ambiente, pode gerar superaquecimento do núcleo, sendo necessária a adição de coolers e dissipadores extras para resolver o problema. O custo desse núcleo também é o mais elevado entre as arquiteturas da plataforma. A Figura 2.0 mostra o diagrama de blocos do núcleo[10]. Figura 2.0 Diagrama de blocos do núcleo X86 (Atom E680) * Arquitetura ARM Cortex-A8 Essa opção de núcleo tem um bom balanceamento entre performance, custo e potência dissipada. O núcleo possui um processador DM3730[15] com controlador de memória RAM de até 256 MBytes DDR, com clock de 1 GHertz, controlador de memória flash de até 32 G, controlador de 3 portas seriais, controlador USB, até 98 portas compartilhadas de GPIO, acelerador gráfico Power VR SGX GPU, interface para câmera, I2C, SPI e consumo de até 1.5 W. A Figura 3.0 mostra o diagrama de blocos do núcleo[10].

5 Figura 3.0 Diagrama de blocos do núcleo ARM (Cortex A8) Arquitetura FPGA baseada no processador softcore NIOS II (32 bit) com 64 Mbytes DDR. O núcleo contém os seguintes componentes: controlador VGA (800x600) / RGB (24 bits) 2 MBytes de memória SRAM para vídeo, memória flash de 32 MBytes, clock de 200 MHz, 4 portas UART seriais, 6 portas USB1.1, Interface para cartão micro SD de até 32 G, interface Ethernet, interface I2C, interface RS-485, 10 portas GPIO. Esse núcleo apresenta uma boa relação custo/benefício. Contudo, se comparada com as demais arquiteturas já descritas, é a que apresenta o pior desempenho. Essa desvantagem pode ser facilmente superada, adicionando-se IPs para implementar algumas funcionalidades dedicadas por hardware, tais como CODECs filtros digitais, algoritmos criptográficos etc. Uma grande vantagem dessa arquitetura em relação às demais é a possibilidade de atualização do hardware básico do núcleo (IPs), diminuindo bastante o risco de obsolescência. A FPGA escolhida para implementar o núcleo foi a família Ciclone IV[16] da Altera. Essa família apresenta uma excelente relação custo/benefício, e tem boa disponibilidade no mercado. Visando possibilitar atualizações no hardware básico do núcleo, foi escolhida uma FPGA com um número excedente de células. Figura 4.0 Diagrama de blocos do núcleo FPGA (Ciclone IV)

6 IV. Fonte de Alimentação A fonte de alimentação é um componente essencial em uma plataforma embarcada, já que muitas vezes o hardware embarcado é alimentado por uma tensão não estabilizada e geralmente sujeita a vários transientes elétricos. Dessa forma, no projeto desse módulo foram acrescentados vários circuitos de proteção, filtros EMI, supressores de transientes e um no-break para garantir que a alimentação da parte digital seja estável e confiável. Visando à boa eficiência, e para minimizar a dissipação de calor, foram escolhidas fontes chaveadas para gerar as tensões necessárias para a parte digital, sendo escolhida a família LM20123[7] de fontes chaveadas da National Semiconductor. Na plataforma MESP, o reuso do projeto ou de partes dele é um requisito importante. Desse modo, é necessário que a fonte aceite uma grande variação da tensão de entrada. Para atender a esse requisito, foi acrescentado um conversor DC/DC na entrada da fonte de alimentação. O diagrama de blocos da fonte de alimentação da plataforma MESP pode ser visto na Figura 5.0. V. Módulo de Interface com o usuário Figura 5.0 Diagrama de blocos da fonte de alimentação Visando atender ao requisito de boa usabilidade, cada dia mais presente nos sistemas embarcados, foram adicionados os seguintes subsistemas: display gráfico TFT, de 800x600, colorido, com 24 bits de resolução de cores, interface LVDS ou RGB; módulo gerador de áudio com amplificador de 2 Watts, interface USB; teclado touch capacitivo com 6 teclas (UP, DOWN, LEFT, RIGHT, ENTER, CANCEL), interface USB, com controlador SoC CY8CMBR2016 da Cypress[11]; e câmera colorida, com resolução 640 x 480 pixels, com microfone embutido e interface USB. A plataforma MESP também define um serviço especial que gerencia esses componentes com biblioteca dedicada a processamento multimídia, e provê, de maneira fácil e configurável, o acesso desses recursos ao desenvolvedor de firmware na plataforma. Por meio de um arquivo XML, o desenvolvedor define quais recursos deseja utilizar, agrupando-os por tela e associando um identificador único a cada tela. Os recursos disponíveis são: imagens, sons, entradas de dados, menus, animações etc. Quando a aplicação precisa utilizar o recurso multimídia, solicita ao serviço, passando através de uma conexão TCP/IP o identificador da tela que contém o recurso. Esse processo ativa o serviço que gerencia o recurso solicitado, simplificando, assim, o trabalho de desenvolvimento.

7 VI. Módulo de Comunicação e GPS O módulo de comunicação é responsável por prover a plataforma MESP de comunicação com o mundo externo, por meio de interfaces de rede e serviço de georreferenciamento do dispositivo embarcado. Na plataforma, são implementadas as seguintes interfaces de rede sem fio: WiFi ( b/g); GPRS; e 3G. Por se tratar de hardwares complexos e extremamente especializados, optou-se por adquirir módulos OEM que encapsulam os protocolos e complexidades de RF necessários para prover a interface. A parte de georreferenciamento seguiu a mesma lógica, sendo adquirido um módulo GPS serial que provê strings NMEA com localização, altitude e velocidade do dispositivo embarcado. Os módulos GPS[12], GPRS e 3G são fornecidos pela empresa U-blox[13], e o módulo WiFi é fornecido pela GainSpain. São disponibilizadas na plataforma as seguintes interfaces de comunicação cabeadas: Porta USB client; Porta Serial; e Interface Ethernet. VII. Leitoras de cartões inteligentes, biométrica e dispositivos NFC Este módulo é responsável basicamente por prover mecanismos de autenticação dos usuários, baseado nos princípios o que você tem (celular NFC ou smartcard sem contato), o que você é (leitor biométrico de impressões digitais) e o que você sabe (senha solicitada via teclado ou dispositivo NFC). A leitora de smartcard é baseada no chip da NXP semiconductor CLRC 632 (Multiprotocol contactless reader IC), sendo compatível com o padrão ISO tipo A, tipo B e I-Code. A leitora de smartcard sem contato tem alcance de 10 cm e se comunica com o núcleo por meio de uma interface serial, possibilitando implementar os protocolos T=CL necessários para se comunicar com dispositivos com interface NFC. O módulo de biometria é um circuito OEM da empresa Digital Persona, e se comunica com o núcleo por meio de uma interface USB. VIII. Módulo de segurança Este módulo é responsável por prover a interface elétrica e de software com smartcards com funcionalidades de SAM (Security Access Modules). Esses chips são smartcards encapsulados em formato SIM, projetados para armazenar dados de maneira segura, possuindo vários mecanismos de proteção contra ataques cibernéticos. Esses circuitos integrados têm por função armazenar chaves de segurança e realizar operações criptográficas, como autenticações, assinaturas, funções de hash, MAC, encriptação, decriptação de dados e todas as operações relacionadas com a segurança do sistema. O controlador do módulo é baseado no chip da NXP TDA 8020HL[9], que se comunica com o núcleo de processamento por meio de interface I2C e atende às normas ISO 7816 para interfaceamento de smartcard com contato e padrão EMV2000. O módulo provê dois conectores SIM para receber os smartcards com a funcionalidade de SAM, podendo ser expandido para aceitar 4 módulos SAM. IX. Módulo de controle de periféricos Em algumas aplicações, a plataforma MESP pode precisar trabalhar associada a outros dispositivos, como sensores, controladores de catracas, atuadores ou até mesmo outros dispositivos embarcados inteligentes. Visando prover essa conectividade, a plataforma disponibiliza duas interfaces com essa finalidade: uma de rede CAN e uma serial RS-485. A interface CAN (Controller Area Network) é uma rede baseada em mensagens, muito utilizada no ambiente automotivo, possibilitando taxas de comunicação de alta velocidade. A interface serial RS-485 é muito utilizada em ambiente industrial. Apesar de bastante robusta e imune a ruídos, opera com velocidade bem inferior à da rede CAN.

8 X. Arquitetura de software A plataforma de software DomOS consiste de um conjunto de bibliotecas padronizadas de acesso a componentes de hardware geralmente presentes em sistemas embarcados (LCD, portas seriais, leitoras, memórias flash, teclados, dispositivos sonoros, sinalizadores luminosos etc), juntamente com um conjunto de bibliotecas de funções geralmente utilizadas nessas aplicações, como rotinas de listas, sistemas de arquivos, entradas de dados, rotinas de criptografia, protocolos de transferência de arquivos e protocolos de redes. A plataforma DomOS tem como um dos principais conceitos ser multiplataforma, sendo que, para isso ser possível, a camada de controle do hardware foi implementada especificamente para cada plataforma-alvo (sistema operacional ou hardware embarcado). As camadas superiores da plataforma se mantêm as mesmas, pois são desenvolvidas em linguagem C padrão ANSI (disponível na grande maioria dos sistemas embarcados), e toda interface com os dispositivos físicos se dá por meio da camada de abstração de hardware (HAL), que utiliza o padrão de projeto adapter[14]. Desse modo, uma aplicação desenvolvida no framework DomOS não deve enfrentar grandes problemas ao ser migrada de uma plataforma para outra, desde que existam implementações do HAL para ambas as plataformas. Uma arquitetuta geral do framework pode ser vista na Figura 6.0. Figura 6.0 Arquitetura de camadas do DomOS Os objetos de hardware são responsáveis por prover uma interface entre as camadas superiores e os dispositivos de hardware de cada plataforma. Essas camadas têm também como função implementar, para cada plataforma de hardware disponível, as funcionalidades utilizadas na interface. Como já foi dito, cada camada se divide em duas subcamadas: a interface abstrata e a específica da plataforma. A primeira é comum a todas as plataformas, tendo como responsabilidades: - todos os tratamentos de erros genéricos (independentemente do tipo de dispositivo); e - direcionamento da interface para a plataforma específica do dispositivo. A subcamada específica tem como responsabilidades: - implementação das funcionalidades especificadas na interface, utilizando as funções específicas da API dos dispositivos ou sistemas operacionais; - fazer tratamentos de erros específicos do dispositivo; e - otimizar a execução da funcionalidade, utilizando recursos de cada sistema operacional ou hardware específico.

9 XI. Serviços de software A plataforma MESP foi projetada tendo como um dos objetivos o reuso de código, razão pela qual algumas funcionalidades que apresentavam grande potencial de reuso foram implementadas na forma de serviços. Os serviços seguem uma arquitetura clienteservidor, comunicando-se por meio de uma conexão TCP/IP local. Nessa arquitetura, a aplicação implementa a parte cliente, enviando comandos ao servidor, enquanto o serviço faz o papel de servidor, executando os comandos solicitados e devolvendo a resposta ao cliente. Dentre os serviços atualmente implementados na plataforma MESP, destacam-se: o serviço de interface com o usuário e o serviço de autenticação biométrica. O serviço de interface com o usuário é responsável por gerenciar todos os recursos de hardware e software da plataforma que interagem com o usuário. Por esse motivo, os componentes de hardware controlador de video, controlador de áudio, controlador de teclado e câmera são controlados por esse serviço. Na parte de software, o serviço utilizou como base as bibliotecas da Nokia Qt e opencv da Intel. A biblioteca Qt provê os objetos de interfaces gráficas com o usuário, como botões, listas, imagens, animações e sons. A biblioteca opencv provê o controle da câmera e funções relacionadas com processamento de imagens por ela capturadas. Visando facilitar o desenvolvimento de aplicação na plataforma MESP, o serviço de interface com o usuário foi projetado de maneira tal que, para utilizar os recursos controlados pelo serviço, o desenvolvedor de aplicação não precisa conhecer detalhes da implementação das bibliotecas Qt e opencv. O serviço de interface com o usuário funciona da seguinte forma: - inicialmente, o serviço lê um arquivo XML e define quais recursos da interface com o usuário devem ser utilizados; - dentro do arquivo XML, os recursos são organizados por telas que possuem um identificador único (ID); - o cliente do serviço solicita o ID da tela com os recursos desejados e parâmetros associados à tela; - o serviço implementa e provê o recurso com base no ID da tela solicitada e em recursos definidos dentro do arquivo XML e associados à tela; - os recursos gráficos associados à tela solicitada são implementados pelo serviço, interpretando os recursos definidos no arquivo XML e utilizando a API das bibliotecas Qt e opencv para prover o recurso solicitado; - o serviço devolve ao cliente o resultado da operação. No caso da operação de entrada de dados, são enviados os dados capturados na tela. Dessa forma, o trabalho do desenvolvedor de aplicações resume-se a criar e configurar o arquivo XML, especificando na aplicação de que tela ele necessita no momento. Essa funcionalidade provê uma grande flexibilidade e produtividade para o desenvolvedor, com significativa redução do tempo de desenvolvimento de aplicações, possibilitando, assim, que o desenvolvedor se concentre nas regras de negócio do firmware, sem se preocupar com o desenvolvimento de código para interagir com o usuário, que geralmente é demorado e complexo. O serviço de biometria segue a mesma filosofia, abstraindo do desenvolvedor detalhes da API de tratamento do scanner de impressão digital e reconhecimento de imagens. O serviço provê funções de alto nível, dos tipos capture uma impressão digital de boa qualidade, identifique a impressão digital lida e outros comandos que possibilitem ao desenvolvedor utilizar o recurso de reconhecimento biométrico sem precisar se preocupar com os detalhes da API. XII. Estudo de caso i-get Visando validar o projeto da plataforma MESP, a Fujitec desenvolveu o hardware embarcado i-get, que consiste de um validador de cartões inteligentes sem contato aplicado ao ambiente de transporte coletivo público. O hardware teve como base o projeto de referência da plataforma, sendo customizado o projeto da placa de circuito impresso, para se adaptar à engenharia de produto já previamente definida. O firmware do validador foi portado de um código existente na plataforma Windows, criado em cima do DomOS. Para essa versão do validador, foi escolhido o núcleo baseado na arquitetura X86, visando basicamente projetar um equipamento com o máximo de capacidade de processamento e com alta compatibilidade de bibliotecas de software disponíveis no mercado. O principal ponto negativo da escolha desse núcleo diz respeito a alguns problemas de superaquecimento, quando colocado dentro da caixa do validador. A solução para esse problema foi a adição de um cooler sobre o dissipador do processador Atom 680 e uma modificação do projeto da caixa, de forma que o ar quente retirado pelo cooler pudesse ser expelido para o ambiente externo. Essa ação possibilitou uma estabilização da temperatura de operação do processador, que se manteve por volta de 58 ºC, mesmo em condições de alta carga de processamento. O validador utiliza vários componentes da plataforma, a saber: leitora de cartões inteligentes sem contato, leitora de impressão digital, teclado capacitivo, display gráfico, som, câmera, módulo GPS, modulo WiFi, módulo GPRS, módulo de segurança, fonte de alimentação e rede RS-485 para controle de catraca externa. A figura 7.0 mostra um protótipo do equipamento montado.

10 Figura 7.0 Validador i-get criado com base na plataforma MESP Os sistemas operacionais escolhidos para a validador foram o Linux Ubuntu e o Windows Embedded 7.0. Dessa forma, foi necessária a construção de um HAL (Hardware Abstract Layer) para cada sistema operacional. Como o núcleo escolhido é baseado na arquitetura X86, não foi necessária a utilização de um cross compiler para compilar a plataforma de software. Para compilação do firmware nos sistemas operacionais Linux Ubuntu e Windows Embedded 7.0, foram escolhidas as IDEs Eclipse CDT e Visual Studio 2008, respectivamente. Portado o HAL para cada plataforma, a migração do firmware foi relativamente simples, apresentando apenas alguns problemas de performance, quando foi utilizada a biblioteca opencv no gerenciamento do vídeo gerado pela câmera. Nesse caso, a utilização da CPU chegava a 90% na inicialização da câmera de vídeo. Esse problema foi contornado inicializando a câmera apenas nos momentos em que ela era necessária para o firmware, o que reduziu a utilização da CPU para algo em torno de 10%. O serviço de gerenciamento de interface também apresentou alguns problemas de performance na apresentação de animações com muitas imagens. As animações apresentavam uma baixa taxa de quadros, quando as imagens eram carregadas diretamente do sistema de arquivos. Esse problema foi contornado criando-se um RAM disk, no qual foram previamente armazenadas as imagens que seriam utilizadas nas animações, e utilizando-se um cache interno de memória no serviço de interfaces, para acelerar o acesso às imagens. XIII. Conclusões e trabalhos futuros O validador i-get foi o primeiro teste efetivo da plataforma MESP, ficando claros, no processo de desenvolvimento, os pontos fortes e os pontos fracos da proposta da plataforma MESP. No projeto de hardware, observou-se uma grande economia de tempo na elaboração dos circuitos esquemáticos do validador, pois o trabalho de engenharia resumiu-se a escolher os módulos necessários e eventualmente projetar alguns circuitos de compatibilização na sua interconexão. Por outro lado, quando da análise do projeto da placa de circuito impresso, não se verificou uma redução significativa de tempo na elaboração dessa etapa do projeto, embora o trabalho de posicionar os componentes tenha sido facilitado, pois, em muitos casos, era possível, com pequenas adaptações, utilizar o mesmo posicionamento original relativo dos componentes dos módulos. Um ponto forte da utilização da plataforma na etapa de projeto da placa de circuito impresso foi a redução do risco no projeto, já que todos os leiautes críticos, como partes de RF (rádiofrequência) e circuitos de chaveamento de alta velocidade, se basearam em leiautes que já previamente testados. Do ponto de vista de software, a abordagem utilizando a plataforma MESP mostrou-se bastante eficaz, pois o trabalho de migração do software reduziu-se a implementar a camada de abstração de hardware em cada sistema operacional e fazer alguns ajustes no firmware, para resolver algumas questões de performance. O reuso de código foi considerável, pois, o código da plataforma Windows foi quase todo utilizado, sendo necessárias apenas pequenas modificações.

11 É importante ressaltar que a utilização da plataforma MESP reduziu de maneira significativa o tempo de validação e homologação do firmware na plataforma embarcada, pois, como o código já havia sido validado na plataforma Windows, logo, não foi observado nenhum bug de lógica introduzido no processo de migração. Um ponto importante na utilização da plataforma MESP é a escolha do núcleo de processamento. Visando facilitar o processo de escolha da arquitetura disponível (X86, ARM Cortex A9 e FPGA) na plataforma MESP, foi elaborada uma tabela que leva em conta os seguintes pontos de análise: Performance, flexibilidade, aquecimento, custo, consumo de energia, capacidade de armazenamento, portabilidade e memória. Tabela 1.0 Elementos de comparação entre as arquiteturas dos núcleos de processamento Item Núcleo Atom (E680) ARM Cortex-A8 FPGA (Ciclone IV) Performance Alta Alta Média Flexibilidade Baixa Baixa Alta Aquecimento Alto Baixo Baixo Custo Alto Médio Médio Consumo de energia Alto Baixo Baixo Capacidade de armazenamento Alta Média Média Portabilidade Alta Média Baixa Memória Alta Média Média Diferentemente de outras abordagens de desenvolvimento de sistema embarcados, a plataforma MESP não se propõe a desenvolver um código apenas uma vez e rodar em qualquer plataforma-alvo sem modificação. A proposta consiste em gerar um código que seja bastante reutilizável e cujo processo de migração para outras plataformas embarcadas seja relativamente simples, embora o desenvolvedor pague um preço no processo de migração que deve ser feito para cada plataforma-alvo. Este ganha o benefício de, finalizado o processo, ter um código que executa na plataforma embarcada de modo eficiente e leve, e utilizando de maneira otimizada os recursos computacionais (memória e processamento) da plataforma embarcada. O custo em processamento da camada HAL é significativamente menor que a utilização de máquinas virtuais. Futuramente, pretende-se desenvolver instâncias de equipamentos com todas as arquiteturas disponíveis na plataforma MESP, e desenvolver componentes de software que possibilitem uma execução de uma camada de abstração de hardware de maneira remota por meio de uma conexão serial ou de rede TCP/IP, funcionalidade esta que vai facilitar bastante o processo de debug do firmware na plataforma-alvo.

12 XIV. Referências [1] Intel Atom Processor E680 (512K Cache, 1.60 GHz), [2] Richards, D. Linux Thin Client Networks Design and Deployment, Packt Publishing, August 2007 [3] Johnson, H.,Graham, Martin., A Handbook of Black Magic, Pretince Hall, 1993 [4] Douglas Brooks, Signal Integrity Issues and Printed Circuit Board Design, Third printing, Pretince Hall, [5] Modern Operating Systems, Tanenbaum, A. Prentice Hall,3rd. Edition, December 2007 [6] Intel Low Pin Count (LPC) Interface Specification, 2002, Revision 1.1, document number [7]National LM A 1.5 MHz Power wise Synchronous Buck Regulator, [8] USB 2.0 Specification, April 27, 2000 [9]NXP TDA8020HL Dual IC card interface, [10] Compulab CM-iTC Computer-On-Module, [11]Cypress CY8CMBR2016, [12] Ublox, LEON G100/G200 GSM/GPRS Data and Voice Module, LEON-G100_G200_DataSheet%28GSM.G1-HW-10004%29.pdf. [13]LEA-6 u-blox 6 GPS Modules, 28GSM.G1-HW-10004%29.pdf [14] Helm, R.,Gamma, E.,Vlissides,J,Johnson- Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley,Nov 10, 1994 [15]Texa Instruments,Digital Media Processor, [16] Altera, Cyclone IV Handbook,