2 revisão bibliográfica - Projeto Pesquisa

TURNO:
NOTURNO
VERSÃO:
2
ANO /
SEMESTRE:
2011.1
No
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO
CURSO DE CIÊNCIA DA COMPUTAÇÃO — BACHARELADO
COORDENAÇÃO DE TRABALHO DE CONCLUSÃO DE CURSO
PROPOSTA PARA O TRABALHO DE CONCLUSÃO DE CURSO
TÍTULO:
TOOLKIT PARA LINUX EMBARCADO
ÁREA: Software Embarcado.
Palavras-chave: Linux. RISC. ARM.
1 IDENTIFICAÇÃO
1.1
ALUNO
Nome: Thiago Waltrik
Código/matrícula: 101573
Endereço residencial:
Rua: General Arthur Koehler
Bairro: Vila Nova
CEP: 89012-580
Telefone fixo:
Complemento: AP203
n: 54
Cidade: Blumenau
UF: SC
Celular: (47) 9621-0094
Endereço comercial:
Empresa: Fundação Universidade Regional de Blumenau
Rua: Antônio da Veiga
CEP: 89012-900
n: 140
Cidade: Blumenau
E-Mail FURB: [email protected]
1.2
UF: SC
Telefone: (47) 3321-0509
E-Mail alternativo: [email protected]
ORIENTADOR
Nome: Miguel Alexandre Wisintainer
E-Mail FURB: [email protected]
Bairro: Victor Konder
E-Mail alternativo:
2 DECLARAÇÕES
2.1
DECLARAÇÃO DO ALUNO
Declaro que estou ciente do Regulamento do Trabalho de Conclusão de Curso de
Ciência da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada
em todas as páginas. Ainda me comprometo pela obtenção de quaisquer recursos necessários
para o desenvolvimento do trabalho, caso esses recursos não sejam disponibilizados pela
Universidade Regional de Blumenau (FURB).
Assinatura:
2.2
Local/data:
DECLARAÇÃO DO ORIENTADOR
Declaro que estou ciente do Regulamento do Trabalho de Conclusão do Curso de
Ciência da Computação e que a proposta em anexo, a qual concordo, foi por mim rubricada
em todas as páginas. Ainda me comprometo a orientar o aluno da melhor forma possível de
acordo com o plano de trabalho explícito nessa proposta.
Assinatura:
Local/data:
3 AVALIAÇÃO DA PROPOSTA
Thiago Waltrik
Orientador(a):
Miguel Alexandre Wisintainer
ASPECTOS AVALIADOS
1.
não atende
Acadêmico(a):
atende
parcialmente
AVALIAÇÃO DO(A) ORIENTADOR(A)
atende
3.1
INTRODUÇÃO
1.1. O tema de pesquisa está devidamente contextualizado/delimitado?
1.2. O problema está claramente formulado?
2.
ASPECTOS TÉCNICOS
3.
4.
5.
6.
7.
ASPECTOS
METODOLÓGICOS
8.
9.
OBJETIVOS
2.1. O objetivo geral está claramente definido e é passível de ser alcançado?
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral?
Caso não sejam apresentados objetivos específicos, deixe esse item em branco.
RELEVÂNCIA
3.1. A proposta apresenta um grau de relevância em computação que justifique o
desenvolvimento do TCC?
METODOLOGIA
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC?
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a
metodologia proposta?
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de
maneira a permitir a execução do TCC no prazo disponível?
REVISÃO BIBLIOGRÁFICA
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC?
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais
características dos mesmos?
REQUISITOS DO SISTEMA A SER DESENVOLVIDO
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram
claramente descritos?
CONSIDERAÇÕES FINAIS
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica
com a realização do TCC?
REFERÊNCIAS BIBLIOGRÁFICAS
8.1. As referências bibliográficas obedecem às normas da ABNT?
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na
proposta (são usadas obras atualizadas e/ou as mais importantes da área)?
CITAÇÕES
9.1. As citações obedecem às normas da ABNT?
9.2. As informações retiradas de outros autores estão devidamente citadas?
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada)
10.1. O texto obedece ao formato estabelecido?
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem
utilizada é clara)?
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se:

qualquer um dos itens tiver resposta NÃO ATENDE;

pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou

pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE.
PARECER:
(
Assinatura do(a) avaliador(a):
) APROVADA
(
) NECESSITA DE COMPLEMENTAÇÃO
Local/data:
CONSIDERAÇÕES DO(A) ORIENTADOR(A):
Caso o(a) orientador(a) tenha assinalado em sua avaliação algum item como “atende parcialmente”, devem ser relatos os
problemas/melhorias a serem efetuadas.
Na segunda versão, caso as alterações sugeridas pelos avaliadores não sejam efetuadas, deve-se incluir uma justificativa.
A alteração “Demonstrar a viabilidade do projeto através de um estudo de caso de uso usando mini-aplicativos”
não foi efetuada devido ao estouro do limite de páginas da proposta.
A alteração “Seção desnecessária porque estas informações já foram apresentadas anteriormente” não foi
efetuada porque toolkit para Linux embarcado é o tema da proposta.
Assinatura do(a) avaliador(a):
Local/data:
Thiago Waltrik
Avaliador(a):
José Roque Voltolini da Silva
ASPECTOS AVALIADOS
1.
não atende
Acadêmico(a):
atende
parcialmente
AVALIAÇÃO DO(A) COORDENADOR DE TCC
atende
3.2
INTRODUÇÃO
1.1. O tema de pesquisa está devidamente contextualizado/delimitado?
1.2. O problema está claramente formulado?
2.
ASPECTOS TÉCNICOS
3.
4.
5.
6.
7.
ASPECTOS
METODOLÓGICOS
8.
9.
OBJETIVOS
2.1. O objetivo geral está claramente definido e é passível de ser alcançado?
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral?
Caso não sejam apresentados objetivos específicos, deixe esse item em branco.
RELEVÂNCIA
3.1. A proposta apresenta um grau de relevância em computação que justifique o
desenvolvimento do TCC?
METODOLOGIA
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC?
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a
metodologia proposta?
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de
maneira a permitir a execução do TCC no prazo disponível?
REVISÃO BIBLIOGRÁFICA
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC?
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais
características dos mesmos?
REQUISITOS DO SISTEMA A SER DESENVOLVIDO
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram
claramente descritos?
CONSIDERAÇÕES FINAIS
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica
com a realização do TCC?
REFERÊNCIAS BIBLIOGRÁFICAS
8.1. As referências bibliográficas obedecem às normas da ABNT?
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na
proposta (são usadas obras atualizadas e/ou as mais importantes da área)?
CITAÇÕES
9.1. As citações obedecem às normas da ABNT?
9.2. As informações retiradas de outros autores estão devidamente citadas?
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada)
10.1. O texto obedece ao formato estabelecido?
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem
utilizada é clara)?
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se:

qualquer um dos itens tiver resposta NÃO ATENDE;

pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou

pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE.
PARECER:
(
) APROVADA
(
) NECESSITA DE COMPLEMENTAÇÃO
OBSERVAÇÕES:
Assinatura do(a) avaliador(a):
Local/data:
Thiago Waltrik
Avaliador(a):
Joyce Martins
ASPECTOS AVALIADOS
1.
não atende
Acadêmico(a):
atende
parcialmente
AVALIAÇÃO DO(A) PROFESSOR(A) DA DISCIPLINA DE TCCI
atende
3.3
INTRODUÇÃO
1.1. O tema de pesquisa está devidamente contextualizado/delimitado?
1.2. O problema está claramente formulado?
2.
ASPECTOS TÉCNICOS
3.
4.
5.
6.
7.
ASPECTOS
METODOLÓGICOS
8.
9.
OBJETIVOS
2.1. O objetivo geral está claramente definido e é passível de ser alcançado?
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral?
Caso não sejam apresentados objetivos específicos, deixe esse item em branco.
RELEVÂNCIA
3.1. A proposta apresenta um grau de relevância em computação que justifique o
desenvolvimento do TCC?
METODOLOGIA
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC?
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a
metodologia proposta?
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de
maneira a permitir a execução do TCC no prazo disponível?
REVISÃO BIBLIOGRÁFICA
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC?
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais
características dos mesmos?
REQUISITOS DO SISTEMA A SER DESENVOLVIDO
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram
claramente descritos?
CONSIDERAÇÕES FINAIS
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica
com a realização do TCC?
REFERÊNCIAS BIBLIOGRÁFICAS
8.1. As referências bibliográficas obedecem às normas da ABNT?
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na
proposta (são usadas obras atualizadas e/ou as mais importantes da área)?
CITAÇÕES
9.1. As citações obedecem às normas da ABNT?
9.2. As informações retiradas de outros autores estão devidamente citadas?
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada)
10.1. O texto obedece ao formato estabelecido?
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem
utilizada é clara)?
PONTUALIDADE NA ENTREGA
atraso de
_____ dias
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se:

qualquer um dos itens tiver resposta NÃO ATENDE;

pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou

pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE.
PARECER:
(
) APROVADA
(
) NECESSITA DE COMPLEMENTAÇÃO
OBSERVAÇÕES:
Assinatura do(a) avaliador(a):
Local/data:
3.4
AVALIAÇÃO DO(A) PROFESSOR(A) ESPECIALISTA NA ÁREA
Acadêmico(a):
Thiago Waltrik
1.
não atende
ASPECTOS AVALIADOS
atende
parcialmente
atende
Avaliador(a):
INTRODUÇÃO
1.1. O tema de pesquisa está devidamente contextualizado/delimitado?
1.2. O problema está claramente formulado?
2.
ASPECTOS TÉCNICOS
3.
4.
5.
6.
7.
ASPECTOS
METODOLÓGICOS
8.
9.
OBJETIVOS
2.1. O objetivo geral está claramente definido e é passível de ser alcançado?
2.2. São apresentados objetivos específicos (opcionais) coerentes com o objetivo geral?
Caso não sejam apresentados objetivos específicos, deixe esse item em branco.
RELEVÂNCIA
3.1. A proposta apresenta um grau de relevância em computação que justifique o
desenvolvimento do TCC?
METODOLOGIA
4.1. Foram relacionadas todas as etapas necessárias para o desenvolvimento do TCC?
4.2. Os métodos e recursos estão devidamente descritos e são compatíveis com a
metodologia proposta?
4.3. A proposta apresenta um cronograma físico (período de realização das etapas) de
maneira a permitir a execução do TCC no prazo disponível?
REVISÃO BIBLIOGRÁFICA
5.1. As informações apresentadas são suficientes e têm relação com o tema do TCC?
5.2. São apresentados trabalhos correlatos, bem como comentadas as principais
características dos mesmos?
REQUISITOS DO SISTEMA A SER DESENVOLVIDO
6.1. Os requisitos funcionais e não funcionais do sistema a ser desenvolvido foram
claramente descritos?
CONSIDERAÇÕES FINAIS
7.1. As considerações finais relacionam os assuntos apresentados na revisão bibliográfica
com a realização do TCC?
REFERÊNCIAS BIBLIOGRÁFICAS
8.1. As referências bibliográficas obedecem às normas da ABNT?
8.2. As referências bibliográficas contemplam adequadamente os assuntos abordados na
proposta (são usadas obras atualizadas e/ou as mais importantes da área)?
CITAÇÕES
9.1. As citações obedecem às normas da ABNT?
9.2. As informações retiradas de outros autores estão devidamente citadas?
10. AVALIAÇÃO GERAL (organização e apresentação gráfica, linguagem usada)
10.1. O texto obedece ao formato estabelecido?
10.2. A exposição do assunto é ordenada (as idéias estão bem encadeadas e a linguagem
utilizada é clara)?
A proposta de TCC deverá ser revisada, isto é, necessita de complementação, se:

qualquer um dos itens tiver resposta NÃO ATENDE;

pelo menos 4 (quatro) itens dos ASPECTOS TÉCNICOS tiverem resposta ATENDE PARCIALMENTE; ou

pelo menos 4 (quatro) itens dos ASPECTOS METODOLÓGICOS tiverem resposta ATENDE PARCIALMENTE.
PARECER:
(
) APROVADA
(
) NECESSITA DE COMPLEMENTAÇÃO
OBSERVAÇÕES:
Assinatura do(a) avaliador(a):
Local/data:
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
TOOLKIT PARA LINUX EMBARCADO
THIAGO WALTRIK
BLUMENAU
2011
THIAGO WALTRIK
TOOLKIT PARA LINUX EMBARCADO
Proposta de Trabalho de Conclusão de Curso
submetida à Universidade Regional de
Blumenau para a obtenção dos créditos na
disciplina Trabalho de Conclusão de Curso I
do curso de Ciência da Computação —
Bacharelado.
Prof. Miguel Alexandre Wisintainer - Orientador
BLUMENAU
2011
2
1 INTRODUÇÃO
Segundo Weinberg (2002, p. ix), os sistemas embarcados estão emergindo como uma
indústria multibilionária. Por todo o mundo, dispositivos inteligentes estão entrando cada vez
mais na vida diária. Sloss, Symes e Wright (2004, p. 6) afirmam que sistemas embarcados
podem controlar os mais diferentes dispositivos, desde pequenos sensores encontrados em
linhas de produção a sistemas de controle de tempo-real utilizados nas sondas espaciais da
National Aeronautics and Space Administration (NASA). De acordo com Hollabaugh (2002,
p. 1), indivíduos e empresas querem dispositivos inteligentes conectados por rede para
melhorar suas vidas. Estes dispositivos devem ser simples de operar, confiáveis e pouco
dispendiosos.
O componente chave de muitos sistemas embarcados de 32 bits são os processadores
com arquitetura Advanced RISC1 Machine (ARM) (SLOSS; SYMES; WRIGHT, 2004, p. 1).
Os processadores ARM são capazes de executar Linux. Linux é a designação de uma família
de sistemas operacionais unix-like que compartilham o mesmo kernel2, sendo capaz de ser
executado em diferentes plataformas de processadores como Itanium, Power Optimization
With Enhanced RISC Performance Computing (PowerPC), x86, Scalable Processor
ARChitecture (SPARC) e Microprocessor without Interlocked Pipeline Stages (MIPS). O
Linux, quando executado em um sistema embarcado, é denominado Linux embarcado.
Ao iniciar-se o desenvolvimento de aplicativos para sistemas embarcados baseados em
Linux é necessário escolher um modelo de dispositivo embarcado (dispositivo alvo), um
compilador cruzado para este dispositivo, uma biblioteca para linguagem C e uma imagem do
kernel Linux compilada a partir de uma versão customizada do código-fonte para este
dispositivo. Estes itens, aliados a documentação e uma estação de trabalho de
desenvolvimento, formam um toolkit para Linux embarcado. Segundo Lombardo (2002, p.
65), a reunião destes itens pode gastar uma enorme quantidade de tempo antes que se possa
ter um sistema que simplesmente inicia o processo de boot.
Para preencher esta lacuna, será desenvolvido um toolkit para Linux embarcado em um
dispositivo que utiliza processador ARM. Este toolkit será desenvolvido para o dispositivo
alvo Mini2440 (FRIENDLYARM, 2010) e fornecerá uma solução para que possa se iniciar o
1
RISC é o acrônimo de Reduced Instruction Set Computer.
2
Kernel é o núcleo do sistema operacional.
3
desenvolvimento de aplicativos sem que seja necessário gastar uma enorme quantidade de
tempo inicial, proporcionando integração entre o hardware e software.
A escolha do Mini2440 dá-se devido ao seu baixo custo e a sua diversidade de
periféricos, entre eles um mostrador do tipo Liquid Crystal Display (LCD) colorido com tela
sensível ao toque, módulo WiFi e interface para cartões de memória Secure Digital (SD).
1.1
OBJETIVOS DO TRABALHO
O objetivo geral deste trabalho é desenvolver um toolkit para Linux embarcado.
Os objetivos específicos do trabalho são:
a) disponibilizar documentação passo a passo para a preparação de uma estação de
trabalho de desenvolvimento de sistemas com Linux embarcado baseada na
distribuição Linux Debian;
b) customizar, compilar e disponibilizar uma versão do kernel Linux para execução
no Mini2440;
c) disponibilizar mini-aplicativos que explorem os principais recursos de hardware do
Mini2440;
d) carregar e executar mini-aplicativos no Mini2440.
1.2
RELEVÂNCIA DO TRABALHO
Hollabaugh (2002, p. 1) presumiu que informações online sobre Linux embarcado
seriam como qualquer outra informação sobre Linux: abundantes e bem documentadas.
Rapidamente descobriu-se que sua presunção estava equivocada, pois a documentação sobre
Linux embarcado é esparsa, dispersa, incompleta e, algumas vezes, obsoleta. Além da
documentação, é necessário reunir um conjunto de ferramentas (compiladores, bibliotecas,
programas para manipulação de arquivos e imagens de disco) e imagens de sistemas de
arquivos para poder-se iniciar o desenvolvimento para o dispositivo alvo escolhido.
Segundo Lombardo (2002, p. 65), a reunião destes itens pode gastar uma enorme
quantidade de tempo antes que se possa ter um sistema que inicia o processo de boot e
4
executa aplicativo simples. Isso implica no aumento de tempo e recursos financeiros
necessários para o desenvolvimento de um software embarcado. Este Trabalho de Conclusão
de Curso (TCC) propõe a reunião de todas as ferramentas necessárias para o desenvolvimento
de softwares para dispositivo com Linux embarcado, acompanhadas de documentação em
língua portuguesa e o desenvolvimento de mini-aplicativos que demonstram como utilizar os
principais recursos de hardware do Mini2440, podendo ser adaptado a outros dispositivos que
utilizem processador da mesma família.
1.3
METODOLOGIA
O trabalho será desenvolvido observando as seguintes etapas:
a) levantamento bibliográfico: realizar levantamento de bibliografia sobre o sistema
operacional Linux, arquitetura ARM, arquitetura RISC, Mini2440, sistemas
embarcados, toolkit para Linux embarcado e trabalhos correlatos;
b) elicitação de requisitos: detalhar e reavaliar a especificação dos requisitos
considerando as necessidades observadas durante o levantamento bibliográfico;
c) análise do dispositivo alvo: estudar o funcionamento do Mini2440;
d) preparação da estação de trabalho: instalar e configurar estação de trabalho de
desenvolvimento baseada na distribuição Linux Debian;
e) geração de sistema de arquivos raiz: gerar uma imagem de sistema de arquivos raiz
com a distribuição para dispositivos embarcados Linux Emdebian;
f) documentação: documentar procedimentos realizados em forma de how-to;
g) definição: definir mini-aplicativos que explorem os principais recursos de
hardware do Mini2440 como LCD colorido com tela sensível ao toque, câmera
Complementary Metal-Oxide-Semiconductor (CMOS), módulo WiFi, interface
serial RS-232, interface Ethernet, entrada para microfone, saída de áudio estéreo,
entradas e saídas digitais de uso-geral, relógio de tempo real, interface para cartão
de memória SD e memória Electrically-Erasable Programmable Read-Only
Memory (EEPROM) Inter-Intergrated Circuit (I2C);
h) especificação: especificar mini-aplicativos com análise orientada a objetos
utilizando a Unified Modeling Language (UML). Será utilizada a ferramenta
Enterprise Architect para modelar os diagramas de classes, de caso de uso e de
5
estados;
i)
implementação: implementar os mini-aplicativos definidos e especificados. Será
utilizada a linguagem C/C++ no ambiente Eclipse3;
j)
testes: realizar a carga e efetuar testes de cada mini-aplicativo implementado.
As etapas serão realizadas nos períodos relacionados no Quadro 1.
2011
jul. ago. set. out. nov.
etapas / quinzenas 1 2 1 2 1 2 1 2 1 2
levantamento bibliográfico
elicitação dos requisitos
análise do dispositivo alvo
preparação da estação de trabalho
geração de sistema de arquivos raiz
documentação
definição
especificação
implementação
testes
Quadro 1 - Cronograma
3
Eclipse é uma IDE desenvolvida pela comunidade de software livre.
6
2 REVISÃO BIBLIOGRÁFICA
Este capítulo foi dividido em sete seções. Um breve histórico sobre o sistema
operacional Linux é apresentado na seção 2.1. A seção 2.2 demonstra alguns aspectos sobre a
arquitetura ARM. A seção 2.3 trata sobre a filosofia da arquitetura RISC. Detalhes técnicos
sobre o computador de placa única Mini2440 são abordados na seção 2.4. Na seção 2.5 é
apresentada uma definição de sistemas embarcados. A seção 2.6 define o que é um toolkit
para Linux embarcado e, por fim, a seção 2.7 apresenta trabalhos correlatos.
2.1
LINUX
Em 1991 um estudante de graduação chamado Linus Torvalds resolveu desenvolver,
por conta própria um kernel para sistema operacional compatível com a norma Portable
Operating System Interface (POSIX) para que pudesse aprender sobre a nova Central
Processing Unit (CPU) Intel 80386. A partir da versão 0.2 do kernel, Linus recrutou ajuda
através da Internet. Em três anos o kernel atingiu a versão 1.0 (MAXWELL, 2000, p. 4).
[...] o Linux não é um sistema operacional na sua totalidade. Quando instala o que
comumente é denominado Linux, você está instalando uma enorme quantidade de
ferramentas que funcionam em conjunto com um sistema verdadeiramente
funcional. O Linux, por si só, é o kernel deste sistema operacional, seu coração, sua
mente, seu sistema nervoso. (MAXWELL, 2000, p. 2).
O kernel Linux, quando distribuído com um conjunto de ferramentas (softwares), é
denominado distribuição. Alguns exemplos de distribuições Linux são Red Hat Linux,
Slackware, Ubuntu e Debian.
O Linux foi originalmente desenvolvido para computadores x86 de 32 bits (80386 ou
superiores), mas já foi portado para diversas arquiteturas como PowerPC, ARM, SPARC,
Itanium e processadores x86 de 64 bits (THE LINUX KERNEL ARCHIVES, 2011).
[...] a principal força do Linux está no processo aberto de desenvolvimento. Como o
código-fonte está gratuitamente disponível para todos, qualquer um pode criar
melhoramentos, que podem então ser gratuitamente disponibilizados para qualquer
pessoa. (MAXWELL, 2000, p. 5).
7
2.2
ARQUITETURA ARM
O processador ARM é o componente chave de muitos sistemas embarcados de 32 bits.
O primeiro protótipo, o ARM1, foi concebido em 1985. Na verdade, o núcleo do processador
ARM não é um núcleo específico, mas uma família inteira de designs que compartilham os
mesmos princípios e um conjunto comum de instruções (SLOSS; SYMES; WRIGHT, 2004,
p. 3).
O conjunto de instruções ARM é diferente da definição RISC pura para que seja
adequado para sistemas embarcados. Entre estas diferenças estão: (SLOSS; SYMES;
WRIGHT, 2004, p. 6):
a) ciclo variável de execução para certas instruções: nem toda instrução executa em
um ciclo de clock. Por exemplo, a multiplicação que pode variar o número de
ciclos de execução dependendo do número de registradores a serem transferidos à
memória seqüencial ou memória de acesso randômico;
b) barrel shifter4 de linha: barrel shifter de linha é um componente de hardware que
pré-processa um dos registradores de entrada antes de ser utilizado por uma
instrução;
c) conjunto de instruções Thumb 16 bits: o núcleo do processador ARM possui um
conjunto de instruções de 16 bits chamado Thumb que aumenta a densidade do
código em cerca de 30% comparado as instruções de 32 bits;
d) execução condicional: uma instrução somente é executada quando uma condição
específica é satisfeita. Isso melhora a performance e densidade do código,
reduzindo o número de instruções branch (jump);
e) instruções aprimoradas: instruções para Digital Signal Processor (DSP) foram
adicionadas ao conjunto de instruções ARM padrão.
Sloss, Symes e Wright (2004, p. 5) afirmam que processadores ARM tem sido
especificamente desenhados para serem pequenos e consumirem pouca energia, já que
sistemas embarcados portáteis geralmente são alimentados a bateria. Núcleos ARM não são
puramente RISC devido às restrições dos sistemas embarcados, que devem ser de baixo custo
e ter baixo consumo de energia. Para os sistemas atuais, a performance e o consumo de
energia são os fatores-chave na escolha do processador a ser usado.
4
Barrel shifter permite que bits de um registrador sejam rotacionados por um número específico de bits em um
único ciclo de clock.
8
2.3
ARQUITETURA RISC
O núcleo ARM utiliza arquitetura RISC. A filosofia do design RISC é destinada a
fornecer instruções simples que executam em um simples ciclo de clock. De acordo com
Sloss, Symes e Wright (2004, p. 4), esta filosofia concentra-se em reduzir a complexidade das
instruções executadas pelo hardware porque é mais fácil fornecer grande flexibilidade e
inteligência a um software do que a um hardware. Já a arquitetura Complex Instruction Set
Computer (CISC) possui instruções complexas que geralmente levam mais de um ciclo de
clock para serem executadas.
Sloss, Symes e Wright (2004, p. 4) afirmam que a filosofia da arquitetura RISC é
baseada em quatro regras principais:
a) instruções: processadores RISC têm um número reduzido de classes de instruções
simples que são executadas em um único ciclo de clock, sendo o programador ou
compilador que sintetizam operações mais complexas, como a divisão de um
número inteiro;
b) pipelines5: o processamento de instruções é feito em pequenas unidades que
podem ser executadas em paralelo por pipelines, não sendo necessário uma
instrução ser executada por um mini-programa (micro-código) como nos
processadores CISC;
c) registradores: processadores RISC possuem um grande conjunto de registradores
de uso-geral que permitem acesso local rápido a memória;
d) arquitetura load-store: o processador opera dados nos seus registradores enquanto
instruções separadas de load-store fazem a transferência entre o banco de
registradores e a memória externa, sendo diferente da arquitetura CISC que efetua
operações diretamente na memória.
Isso faz com que os processadores RISC sejam mais simples e possam operar a
velocidades de clock mais altas que os processadores CISC (SLOSS; SYMES; WRIGHT,
2004, p. 5).
5
Pipeline é uma técnica utilizada para acelerar a velocidade de processamento, carregando uma ou mais
instruções para a memória, ao invés de somente a próxima a ser executada.
9
2.4
MINI2440
O Mini2440 é um computador de placa única produzido pela FriendlyARM. Ele é
baseado no microprocessador RISC S3C2440A, produzido pela Samsung. Este processador
foi desenvolvido com núcleo ARM920T, da arquitetura ARMv4T e pertence a família
ARM7TDMI.
O processador S3C2440A implementa Memory Management Unit (MMU), barramento
Advanced Microcontroller Bus Architecture6 (AMBA) e arquitetura Harvard. Possui também
um conjunto completo de periféricos integrados on-chip que diminuem os custos de
desenvolvimento.
O Mini2440 possui seu processador executando a 400 MHz e incorpora 64 MB de
SDRAM7, 64 MB a 1024 MB de Not AND (NAND) Flash e várias interfaces e recursos
(Figura 1) (FRIENDLYARM, 2010, p. 7).
Fonte: Friendyarm (2010, p. 9).
Figura 1 – Visão das interfaces e recursos
6
O barramento AMBA foi introduzido em 1996 e é largamente adotado em processadores ARM. Ele permite
que designers de periféricos possam reutilizar o mesmo design em vários projetos.
7
SDRAM é o acrônimo de Sincronous Dynamic Random Access Memory.
10
2.5
SISTEMAS EMBARCADOS
Um sistema embarcado é formado por entradas e saídas e controle lógico armazenados
em um firmware de sistema. No passado, era simples distinguir um sistema embarcado de um
computador de uso-geral. Por exemplo, uma placa T1 baseada no 8051 (microcontrolador de
8 bits) era um sistema embarcado de uma estação de trabalho Sun Unix. Hoje, em termos de
funcionalidade, é difícil distinguir uma estação de trabalho Sun de uma set-top box com
Graphical User Interface (GUI) que executa um sistema operacional multitarefa capaz de
executar vários programas simultaneamente. Os avanços tecnológicos dificultam definir o que
é um sistema embarcado (HOLLABAUGH, 2002, p. 8).
Lombardo (2002, p. xv) afirma que a maneira mais fácil de diferenciar um computador
de uso-geral de um sistema embarcado é analisando a interface com o usuário. Um
computador de uso-geral geralmente possui um teclado, um mouse e um monitor. Pode ser
utilizado para navegar na Internet, editar textos e ouvir músicas. Um sistema embarcado pode
ou não possuir uma interface com o usuário. Quando possui, geralmente é limitada. As
interfaces vão desde simples botões a mostradores do tipo LCD com tela sensível ao toque.
Pode ser possível plugar um teclado ou monitor em um sistema embarcado, mas geralmente
isso é utilizado para depuração ou configuração. Estes sistemas são concebidos para realizar
operações específicas.
2.6
TOOLKIT PARA LINUX EMBARCADO
A maneira mais simples de embarcar Linux em um dispositivo é fazer download da
última versão do kernel Linux, escolher um compilador-cruzado para a plataforma escolhida,
uma biblioteca de linguagem C e alguns aplicativos. O problema é que se consome uma
grande quantidade de tempo até ter um sistema que simplesmente efetua o boot
(LOMBARDO, 2002, p. 65).
Um toolkit para Linux embarcado é um produto ou projeto de software livre que, junto
com uma estação de trabalho Linux e um dispositivo alvo, fornecem uma solução completa
para que seja possível carregar uma imagem com kernel Linux para o dispositivo alvo e este
execute, pelo menos, um aplicativo simples. Cada toolkit tem uma interface diferente com o
11
usuário e estilo próprio. Porém, todos fazem essencialmente a mesma coisa: construir um
kernel Linux que contém um aplicativo que executa como um thread do kernel ou construir
um sistema de arquivos raiz com o software desenvolvido. O toolkit deve ser capaz de instalar
novas partes do software desenvolvido em uma imagem binária a partir da qual o dispositivo
alvo executa o boot (LOMBARDO, 2002, p. 66).
2.7
TRABALHOS CORRELATOS
São encontradas várias ferramentas que auxiliam no desenvolvimento de softwares
para sistemas embarcados baseados em Linux. Entre eles está o produto MontaVista Linux
(MONTAVISTA, 2009), o framework OpenEmbedded Project (HOLGER et al., 2009) e a
distribuição Linux uClinux (UCLINUX, 2008a).
2.7.1
MontaVista Linux
O MontaVista Linux 6, desenvolvido pela MontaVista, é um produto que fornece um
ambiente de desenvolvimento para sistemas embarcados que inclui um Market Specific
Distribution (MSD), um Software Development Kit (SDK) e suporte especializado
(MONTAVISTA, 2009, p. 1).
Os MSDs são distribuições Linux otimizadas para determinados dispositivos. São
compostas de um kernel Linux e drivers apropriados (MONTAVISTA, 2010a). O SDK
oferece uma Integrated Development Environment (IDE) baseada no Eclipse, compilador
C/C++ e bibliotecas de tempo de execução (MONTAVISTA, 2010b). Um dos destaques do
MontaVista Linux é o suporte a vários dispositivos embarcados baseados nas arquiteturas
ARM, MIPS, PowerPC, x86, xScale e xTensa (MONTAVISTA, 2010c).
12
2.7.2
OpenEmbedded Project
O OpenEmbedded Project é um framework para Linux embarcado composto por um
conjunto de metadados usados para compilação cruzada, empacotamento e instalação de
pacotes de software. É utilizado para construir e manter distribuições de Linux embarcado,
como a OpenZaurus e Angstrom (HOLGER et al., 2009).
As principais capacidades do OpenEmbedded são (HOLGER et al., 2009):
a) manipular compilação cruzada;
b) manipular dependências entre os pacotes;
c) criar pacotes de software;
d) criar imagens de pacotes;
e) suportar vários dispositivos, distribuições e arquiteturas.
2.7.3
uClinux
O uCLinux, inicialmente, era um projeto derivado do kernel Linux versão 2.0 para
microcontroladores sem MMU. Hoje é um sistema operacional que inclui releases do kernel
Linux versão 2.0, 2.4 e 2.6, além de aplicativos e bibliotecas (UCLINUX, 2008a). É um
projeto designado para sistemas embarcados, tendo cobertura para uma grande variedade de
arquiteturas de processadores, entre eles estão os processadores Motorola ColdFire, Motorola
DragonBall, Atari 68k e os pertencentes a família ARM7TDMI (UCLINUX, 2008b).
Como o uClinux é desenvolvido para processadores sem MMU, a falta deste implica
em algumas limitações como a não implementação de fork()8 e a falta de proteção de
memória. Esta falta de proteção de memória permite que qualquer programa acesse a
memória de outro programa, fazendo com que o programador tenha um cuidado maior na
implementação de softwares embarcados. Embora não implemente fork(), o uClinux
implementa uma outra função chamada vfork() que permite que processadores sem MMU
forneçam suporte completo a multitarefa (UCLINUX, 2008c).
8
O fork() é uma chamada de sistema que cria um novo processo filho a partir de um processo pai.
13
3 REQUISITOS DO SISTEMA A SER DESENVOLVIDO
O toolkit para Linux embarcado deverá:
a) utilizar sistema operacional Linux Debian para a estação de trabalho de
desenvolvimento (Requisito Não-Funcional – RNF);
b) possuir documentação em língua portuguesa (RNF);
c) utilizar o dispositivo alvo Mini2440 (RNF);
d) utilizar linguagem de programação C/C++ (RNF);
e) utilizar linguagem de script Shell script (RNF);
f) criar um sistema de arquivos raiz contendo a distribuição Linux Emdebian (RNF);
g) configurar um boot-loader para carga do kernel Linux customizado (RNF);
h) carregar imagem do kernel e sistema de arquivos raiz para o Mini2440 (RNF);
i)
ter mini-aplicativos que explorem os seguintes recursos de hardware: LCD
colorido com tela sensível ao toque, câmera CMOS, módulo WiFi, interface serial
RS-232, interface Ethernet, entrada para microfone, saída de áudio estéreo,
entradas e saídas digitais de uso-geral, relógio de tempo real, interface para cartão
de memória SD e memória EEPROM I2C (Requisito Funcional – RF).
14
4 CONSIDERAÇÕES FINAIS
Após os estudos preliminares, constatou-se que os sistemas embarcados são uma
tecnologia emergente e mesmo assim há dificuldade em encontrar documentação atualizada
sobre este tema, principalmente em língua portuguesa. Diante disso, propõe-se a criação de
um toolkit que seja baseado em Linux tanto na estação de trabalho de desenvolvimento quanto
no dispositivo alvo.
A escolha do Linux deu-se pela sua estabilidade, desempenho e por ter seu código
fonte aberto, permitindo que customizações possam ser realizadas e que bugs possam ser
facilmente detectados e corrigidos. Além disso, pretende-se que todas as ferramentas
utilizadas durante a realização deste trabalho sejam baseadas em software livre.
A arquitetura ARM foi escolhida por ter baixo custo e baixo consumo de energia. Estas
características são desejáveis para sistemas embarcados. O núcleo ARM utiliza arquitetura
RISC que possui um conjunto reduzido de instruções menos complexas que o da arquitetura
CISC.
Serão abordados os passos para a criação de uma estação de trabalho de
desenvolvimento que possua as ferramentas necessárias para que se possam iniciar os
trabalhos de implementação. Após isso, serão abordados os detalhes para a criação de uma
imagem que contenha um kernel Linux apto a executar no dispositivo alvo, acompanhado de
um sistema de arquivos raiz, com uma distribuição Linux que será capaz de receber e executar
os mini-aplicativos que serão implementados.
Em relação aos trabalhos correlatos, pode-se afirmar que dentre as abordagens citadas
com este tema, todas mantém o foco em permitir que os desenvolvedores de software se
concentrem em suas atividades principais, abstraindo detalhes referentes à arquitetura do
dispositivo alvo escolhido. Este toolkit limita-se ao uso do Mini2440, mas poderá ser
adaptado a outros dispositivos baseados em arquitetura ARM. A versão do Mini2440 a ser
utilizada possui LCD colorido com tela sensível ao toque, câmera CMOS e módulo WiFi.
15
REFERÊNCIAS BIBLIOGRÁFICAS
FRIENDLYARM. FriendlyARM Mini2440. [S.l.], [2010?]. Disponível em:
<http://www.friendlyarm.net/dl.php?file=Mini2440_manual.pdf>. Acesso em: 22 mar. 2011.
HOLGER, Hans P. F. et al. OpenEmbedded user manual. [S.l.], 2009. Disponível em:
<http://docs.openembedded.org/usermanual/usermanual.html>. Acesso em: 21 mar. 2011.
HOLLABAUGH, Craig. Embedded Linux: hardware, software, and interfacing. New York:
Sams, 2002.
LOMBARDO, John. Embedded Linux. Indianapolis: New Riders, 2002.
MAXWELL, Scot. Kernel do Linux. Tradução Carlos Mink. São Paulo: Makron Books,
2000.
MONTAVISTA. Monta Vista Linux 6. Santa Clara: Monta Vista Software, 2009.
Disponível em: <http://www.mvista.com/download/fetchdoc.php?docid=427>. Acesso em: 20
mar. 2011.
_____. Monta Vista Linux 6: market especific distribution. [S.l.], 2010a. Disponível em:
<http://www.mvista.com/product_detail_msd.php>. Acesso em: 20 mar. 2011.
_____. Monta Vista Linux 6: software development kit. [S.l.], 2010b. Disponível em:
<http://www.mvista.com/product_detail_sdk.php>. Acesso em: 20 mar. 2011.
_____. Platform support for MontaVista Linux. [S.l.], 2010c. Disponível em:
<http://www.mvista.com/boards.php>. Acesso em: 20 mar. 2011.
SLOSS, Andrew N.; SYMES Dominic; WRIGHT Chris. ARM system developer’s guide:
design and optimizing system software. San Francisco: Morgan Haufmann, 2004.
THE LINUX KERNEL ARCHIVES. What is Linux? [S.l.], [2011?]. Disponível em:
<http://www.kernel.org>. Acesso em: 25 mar. 2011.
UCLINUX. What is uClinux? [S.l.], [2008a?]. Disponível em:
<http://www.uclinux.org/description/>. Acesso em: 18 mar. 2011.
_____. uClinux: ports. [S.l.], [2008b?]. Disponível em: <http://www.uclinux.org/ports/>.
Acesso em: 18 mar. 2011.
_____. uClinux: FAQ. [S.l.], [2008c?]. Disponível em:
<http://www.uclinux.org/pub/uClinux/FAQ.shtml>. Acesso em: 18 mar. 2011.
16
WEINBERG, William. Foreword. In: HOLLABAUGH, Craig. Embedded Linux: hardware,
software, and interfacing. New York: Sams, 2002. p. ix.