2 ano / semestre: 2011.1 n universidade regional
Propaganda
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.
