Mobile Embedded System Plataform MESP

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
[email protected],[email protected],[email protected];[email protected],paulo.faco
@fujitec.com.br,[email protected],[email protected]
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 480.- Módulo de interface com dispositivos externos –
possibilita que a plataforma se comunique com dispositivos periféricos externos que possuam as interfaces padrão de rede RS485, CAN e USB OTP externa.
A ideia geral da plataforma é que o núcleo se comunique no nível físico com os demais submódulos do sistema, por meio de
interfaces físicas padronizadas (conectores-padrão).
(conectores
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
eto 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.
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.
possí
arquiteturas da plataforma,
Com o intuito de prover flexibilidade e portabilidade das aplicações de firmware entre as possíveis
foi criada uma camada de abstração de hardware (Hardware Abstract Layer – HAL) [5], que é implementada nos diferentes
sistemas operacionais suportados pela ferramenta.
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
espe
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
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 802.11 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 2.6.38 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.
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].
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)
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.
Figura 5.0 – Diagrama de blocos da fonte de alimentação
V. Módulo de Interface com o usuário
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.
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 (802.11 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 14443 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.
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.
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.
Figura 7.0 – Validador i-get criado com base na plataforma MESP
Os sistemas operacionais escolhidos para a validador foram o Linux Ubuntu 2.6.38 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 2.6.38 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.
É 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
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
Item
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.
XIV.
Referências
[1] Intel® Atom™ Processor E680 (512K Cache, 1.60 GHz), http://ark.intel.com/products/52497?wapkw=Atom%20E680
[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, 2003.
[5] Modern Operating Systems, Tanenbaum, A. Prentice Hall,3rd. Edition, December 2007
[6] Intel Low Pin Count (LPC) Interface Specification,http://www.intel.com/design/chipsets/industry/lpc.html,August 2002,
Revision 1.1, document number 251289-001
[7]National LM20123 3A 1.5 MHz Power wise Synchronous Buck Regulator,
http://www.national.com/pf/LM/LM20123.html#Overview
[8] USB 2.0 Specification,http://www.usb.org/developers/docs/, April 27, 2000
[9]NXP TDA8020HL Dual IC card interface,http://www.nxp.com/documents/data_sheet/TDA8020HL.pdf.
[10] Compulab CM-iTC Computer-On-Module,http://compulab.co.il/products/computer-on-modules/cm-itc/.
[11]Cypress CY8CMBR2016,http://www.cypress.com/?id=3650.
[12] Ublox , LEON G100/G200 GSM/GPRS Data and Voice Module, http://www.u-blox.com/images/downloads/Product_Docs/
LEON-G100_G200_DataSheet%28GSM.G1-HW-10004%29.pdf.
[13]LEA-6 u-blox 6 GPS Modules, http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100_G200_DataSheet%
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,http://www.ti.com/product/dm3730.
[16] Altera , Cyclone IV Handbook, http://www.altera.com/literature/hb/cyclone-iv/cyclone4-handbook.pdf