Gerenciador de aplicativos carregáveis dinamicamente em plataformas embarcadas com RTOS de pequeno porte

(1)

CURSO DE ENGENHARIA DE COMPUTAC¸ ˜AO

LEANDRO FABIAN JUNIOR

GERENCIADOR DE APLICATIVOS CARREG ´AVEIS DINAMICAMENTE EM PLATAFORMAS EMBARCADAS COM RTOS DE PEQUENO PORTE

TRABALHO DE CONCLUS ˜AO DE CURSO

PATO BRANCO 2016

(2)

GERENCIADOR DE APLICATIVOS CARREG ´AVEIS DINAMICAMENTE EM PLATAFORMAS EMBARCADAS COM RTOS DE PEQUENO PORTE

Trabalho de Conclusão de Curso apresentado ao Curso Superior de Engenharia de Computação da Universidade Tecnológica Federal do Pa-raná - UTFPR, como requisito parcial para obtenção do t´ıtulo de bacharel em Engenharia de Computação.

Orientador: Prof. Dr. Gustavo Weber Denardin

PATO BRANCO 2016

(3)

TERMO DE APROVAÇÃO

Às 10h horas e 30 minutos do dia 06 de dezembro de 2016, na sala V006, da Universidade Tecnológica Federal do Paraná, Câmpus Pato Branco, reuniu-se a banca examinadora composta pelos professores Gustavo Weber Denardin (orientador), Giovanni Alfredo Guarneri e Robison Cris Brito para avaliar o trabalho de conclusão de curso com o título Gerenciador de aplicativos carregáveis dinamicamente em plataformas embarcadas com RTOS de pequeno porte, do aluno Leandro Fabian Junior, matrícula 01376896, do curso de Engenharia de Computação. Após a apresentação o candidato foi arguido pela banca examinadora. Em seguida foi realizada a deliberação pela banca examinadora que considerou o trabalho aprovado.

______________________________

Gustavo Weber Denardin Orientador (UTFPR)

______________________________ ______________________________ Giovanni Alfredo Guarneri Robison Cris Brito

(UTFPR) (UTFPR)

______________________________ ______________________________ Beatriz Terezinha Borsoi Pablo Gauterio Cavalcanti

Coordenador de TCC Coordenador do Curso de

Engenharia de Computação

A Folha de Aprovação assinada encontra-se na Coordenação do Curso. Universidade Tecnológica Federal do Paraná

Câmpus Pato Branco

Departamento Acadêmico de Informática Curso de Engenharia de Computação

(4)

Agradeço a todos que acompanharam meus anos de graduação e que de alguma forma contribu´ıram para a minha formação, desde o simples apoio verbal até o aux´ılio técnico por horas a fio.

Agradeço em especial à professora Beatriz Terezinha Borsoi, que, como faz a muitos, me auxiliou desde o primeiro dia que entrei na universidade. Agradeço também ao meu professor orientador Gustavo Weber Denardin e aos professores da banca: Giovanni Alfredo Guarneri e Robison Cris Brito, que muito contribu´ıram no desenvolvimento deste trabalho.

Agradeço aos meus pais e minha irmã, que são os principais apoiadores de meus estudos e realizações, tanto financeira como emocionalmente, obrigado por terem me dado essa oportuni-dade. Agradeço aos muitos amigos que me acompanharam por esses anos e que, com certeza, continuarão fazendo parte das minhas realizações futuras.

Agradeço, por fim, ao Programa de Fomento às Ações da Graduação - EDITAL No_08/2016 - APOIO AOS TRABALHOS DE CONCLUS ÃO DE CURSO 2 – TCC – 2 da Universi-dade Tecnológica Federal do Paraná, pelo qual fui contemplado com uma bolsa aux´ılio para a execução desse trabalho.

(5)

FABIAN JUNIOR, Leandro. Gerenciador de Aplicativos Carregáveis Dinamicamente em Pla-taformas Embarcadas com RTOS de Pequeno Porte. 2016. 74 f. Trabalho de Conclusão de Curso – Curso de Engenharia de Computação, Universidade Tecnológica Federal do Paraná. Pato Branco, 2016.

A atualização do firmware de um sistema embarcado em funcionamento pode representar perdas graves em alguns casos, levando em conta o tempo em que sua execução precisa ser suspensa. Além do mais, se não forem tomadas as devidas precauções no carregamento do código para a máquina, a aplicação pode apresentar problemas por conta de uma atualização corrompida. Sis-temas com maiores recursos de hardware e software, contornam muitos desses problemas com a implementação de um mecanismo de gerenciamento de aplicativos. Desse modo, as aplicações podem ser desenvolvidas exteriormente ao sistema principal e, somente depois, instaladas, sem interferir nas aplicações em execução. O seguinte trabalho tem como proposta principal trazer tais facilidades às plataformas embarcadas baseadas em sistemas com menores recursos, que utilizem sistemas operacionais de tempo real.

Palavras-chave: Aplicativo dinˆamico. Recursos computacionais escassos. RTOS. Sistemas de tempo real. Sistemas embarcados.

(6)

FABIAN JUNIOR, Leandro. Dynamically Loadable Application Manager on Small RTOS Embedded Platforms. Trabalho de Conclusão de Curso – Curso de Engenharia de Computação, Universidade Tecnológica Federal do Paraná. Pato Branco, 2016.

Upgrading the firmware of a live-in system may represent serious losses in some cases, taking into account the time when its execution must be suspended. In addition, if you do not take proper precautions when loading code into the machine, the application may experience pro-blems due to a corrupted update. Systems with greater hardware and software resources bypass many of these problems by implementing an application management mechanism. Thus, the applications can be developed outside the main system and then installed without interfering with the running applications. The main goal of this text is to bring such facilities to embedded platforms based on lower-resource systems using real-time operating systems.

Keywords: Downloadable Applications. Embedded systems. Real-Time Systems. RTOS. Scarce computing resources.

(7)

Figura 1 – Diagrama representativo de um sistema de tempo real. . . 16

Figura 2 – Componentes comuns em um kernel de RTOS, incluindo objetos, o escalo-nador e alguns servic¸os . . . 18

Figura 3 – Esquema do processo de compilação e ligação de um código-fonte . . . 19

Figura 4 – Visualização da estrutura de um arquivo ELF pelo processo de ligação e pelo de execução . . . 24

Figura 5 – Exemplo de sec¸˜ao do tipo string table de um arquivo ELF. . . 26

Figura 6 – Barramento m´ınimo da SPI entre o microcontrolador e o cart˜ao SD . . . 30

Figura 7 – Posição do módulo FatFs na aplicação . . . 32

Figura 8 – Esquema da arquitetura do sistema pretendido . . . 34

Figura 9 – Acesso às funções da base pelos aplicativos através da estrutura da API . . . 37

Figura 10 – Relação das etapas de extração de programa com as partes do arquivo ELF . . 38

Figura 11 – Kit de desenvolvimento Tiva conectado a um leitor de cart˜ao SD e um po-tenciˆometro de 50 kΩ . . . 57

Figura 12 – Resposta do comando de inicialização do cartão SD . . . 58

Figura 13 – Resposta do comando de listagem de arquivos . . . 58

Figura 14 – Resposta do comando de inicialização do cartão SD . . . 59

Figura 15 – Comportamento do led na aplicac¸˜ao adcn.out . . . 59

Figura 16 – Resposta da sequˆencia de comandos: clean, cd leds e ls . . . 60

Figura 17 – Sa´ıda apresentada a partir da sequˆencia de comandos executada . . . 61

Figura 18 – Leds demonstrando a execução de duas aplicações em paralelo . . . 61

Figura 19 – Sa´ıda apresentada pelo comando de listagem de aplicativos em execuc¸˜ao . . . . 62

Figura 20 – Resposta dos comandos utilizados . . . 62

Figura 21 – Oscilação dos 3 leds, cada um em seu tempo de execução . . . 63

(8)

Quadro 1 – Tipos de dado de um arquivo ELF para arquiteturas de 32 bits . . . 24

Quadro 2 – Definic¸˜oes de tipo (sh type) de um arquivo ELF . . . 27

Quadro 3 – Principais sec¸˜oes especiais de um arquivo ELF . . . 27

Quadro 4 – Definic¸˜oes de tipo de s´ımbolo de um arquivo ELF . . . 29

(9)

Listagem 1 – Exemplo de um linker script m´ınimo · · · 20

Listagem 2 – Exemplo de uso do comando MEMORY em um linker script · · · 21

Listagem 3 – Exemplo de criação de nova seção no linker script · · · 22

Listagem 4 – Exemplo de declaração de um dado inteiro em uma seção fixa da memória 22 Listagem 5 – Estrutura de um cabeçalho ELF · · · 25

Listagem 6 – Estrutura de um cabeçalho de seção ELF · · · 26

Listagem 7 – Estrutura de uma tabela de s´ımbolos ELF · · · 28

Listagem 8 – Leitura de valor de tipo e vinculac¸˜ao · · · 28

Listagem 9 – Definição da estrutura utilizada na API com 3 atributos de acesso aos serviços do sistema base · · · 36

Listagem 10 – Camada de abstração com as redefinições dos atributos da estrutura da API · · · 36

Listagem 11 – Declarac¸˜ao da estrutura da API de acesso · · · 36

Listagem 12 – Estrutura de um aplicativo dinˆamico j´a instalado· · · 40

Listagem 13 – Estrutura de valores de enderec¸o dos c´odigos dos aplicativos instalados · · 40

Listagem 14 – Exemplo de declarac¸˜ao de nova string· · · 43

Listagem 15 – Cálculo da nova posição de uma string no aplicativo · · · 43

Listagem 16 – Estrutura de uma vari´avel global implementada pelo sistema · · · 44

Listagem 17 – Exemplo de definição necessária para a instalação de rotinas de interrupção em aplicativos · · · 46

Listagem 18 – Exemplo de instalação de rotinas de interrupção em aplicativos · · · 46

Listagem 19 – Código-fonte adcn - Lê da entrada analógica do microcontrolador e con-verte para a sa´ıda de PWM. Para microcontroladores Tiva TM4C1294· · · 70

Listagem 20 – C´odigo-fonte blink - Faz todos os leds oscilarem entre aceso e apagado · · 72

Listagem 21 – C´odigo-fonte ledN - Faz um dos leds oscilar entre aceso e apagado. Para microcontroladores Tiva TM4C1294 · · · 73

(10)

ADC Analog-to-Digital Converter

API Application Programming Interface ARM Advanced RISC Machine

EEPROM Electrically-Erasable Programmable Read Only Memory ELF Executable and Linkable Format

FAT File Allocation Table GCC GNU Compiler Collection GPL GNU General Public License IBM International Business Machines IDE Integrated Development Environment MS-DOS Microsoft Disk Operating System PWM Pulse Width Modulation

RAM Random-Access Memory

RTOS Real Time Operating System SD Secure Digital

SO Sistema Operacional SPI Serial Peripheral Interface TIS Tool Interface Standards

UART Universal Asynchronous Receiver/Transmitter UHS Ultra High Speed

(11)

1 INTRODUÇ ÃO . . . 12 1.1 JUSTIFICATIVA . . . 13 1.2 OBJETIVOS . . . 14 1.2.1 Objetivo Geral. . . 14 1.2.2 Objetivos Espec´ıficos . . . 14 1.3 ORGANIZAÇ ÃO DO DOCUMENTO . . . 14 2 FUNDAMENTAÇ ÃO TE ÓRICA . . . 15

2.1 SISTEMA OPERACIONAL DE TEMPO REAL. . . 15

2.1.1 RTOS em Sistemas Embarcados . . . 15

2.1.2 Estrutura de um RTOS . . . 17

2.2 LINKER . . . 18

2.2.1 Formato de um Linker Script . . . 20

2.3 PADR ÃO ELF . . . 23 2.3.1 Formato do arquivo . . . 23 2.3.2 Cabeçalho ELF . . . 25 2.3.3 Seções ELF . . . 25 2.3.4 Seções Especiais. . . 27 2.3.5 Tabela de S´ımbolos . . . 28 2.4 CART ÃO SD . . . 29

2.4.1 Sistema de Arquivos FAT . . . 30

2.4.2 FatFs. . . 31

2.5 UTILIZAC¸ ˜AO DOS CONHECIMENTOS. . . 32

3 METODOLOGIA. . . 34

3.1 VIS ˜AO GERAL . . . 34

3.2 ETAPAS DO PROJETO . . . 35

3.2.1 Etapa 1 - API de Acesso . . . 35

3.2.2 Etapa 2 - Leitura de arquivo ELF . . . 37

3.2.3 Etapa 3 - Leitura de um Cart˜ao SD. . . 39

3.2.4 Etapa 4 - Gerenciamento dos Aplicativos . . . 40

3.2.5 Etapa 5 - Problemas de referˆencia . . . 42

3.2.5.1 Utilizac¸˜ao de strings . . . 42

3.2.5.2 Criação de variáveis globais . . . 43

3.2.5.3 Restric¸˜oes de ponteiros. . . 45

3.2.5.4 Instalação de rotinas de tratamento de interrupções . . . 45

3.3 ARQUIVO DE PORT . . . 47

4 UTILIZANDO O SISTEMA . . . 51

(12)

4.4 CARREGANDO E EXECUTANDO UM APLICATIVO . . . 55 5 RESULTADOS. . . 56 5.1 RECURSOS UTILIZADOS . . . 56 5.2 IMPLEMENTAÇ ÃO E TESTES . . . 57 5.3 AN ÁLISE DA IMPLEMENTAÇ ÃO . . . 65 6 CONCLUS ÃO . . . 66 6.1 TRABALHOS FUTUROS . . . 66 REFER ÊNCIAS. . . 68 7 AP ÊNDICES. . . 70 7.1 AP ÊNDICE A. . . 70 7.2 AP ÊNDICE B. . . 72 7.3 AP ÊNDICE C. . . 73

(13)

1 INTRODUC¸ ˜AO

Um sistema embarcado é um sistema microcontrolado ou microprocessado dedicado a um propósito espec´ıfico e geralmente parte de um sistema maior. Alguns exemplos de siste-mas embarcados são: o sistema microprocessado usado no controle da mistura ar/combust´ıvel de carburadores automobil´ısticos, softwares embarcados em aviões, controle de fornos micro-ondas, equipamentos médicos e ajuste automático de foco de câmeras (MEGHANATHAN; BASKIYAR, 2005).

Sistemas embarcados são compostos por hardware, como processador, memórias, pe-riféricos e por software, podendo esse incluir ou não um sistema operacional (SO). Há várias definições para um SO. No entanto, suas funções básicas, tanto em sistemas embarcados quanto em computadores de propósito geral, podem ser descritas como o gerenciamento de recursos compartilhados em um sistema computadorizado e o fornecimento de meios de acesso a esses recursos pela aplicação programada (TANENBAUM; WOODHULL, 2009). O núcleo super-visório que provê os algoritmos base de gerenciamento de recursos, escalonamento de tarefas e lógica do SO é chamado de núcleo (ou no inglês, kernel) (LI; YAO, 2003).

Um sistema embarcado que possui metas a atingir em determinados per´ıodos r´ıgidos de tempo é chamado de sistema embarcado de tempo real (TAN; TRAN NGUYEN, 2009). Esses tipos de sistema costumam utilizar sistemas operacionais de tempo real (do inglês Real Time Operating System, RTOS) para tal propósito. Existem implementações de RTOSs de vários tamanhos e formas, dos maiores como o VxWorks (WIND RIVER, 2016), aos mais compactos como o ThreadX (EXPRESS LOGIC, 2016).

RTOSs robustos oferecem várias aplicações adaptadas dos SOs para desktop. Essas, nor-malmente não são encontradas em outros RTOSs mais compactos. Isso se deve ao fato de exe-cutarem códigos extensos e, consequentemente, ocuparem uma quantidade maior de memória, ocasionando uma resposta de tempo real mais lenta (CARBONE, 2011).

Na maioria dos casos, a arquitetura de um RTOS de pequeno porte é tal que, tanto as rotinas da aplicação quanto as dos serviços do RTOS, são compiladas individualmente e posteriormente ligadas, formando uma única imagem executável. Essa imagem é carregada na memória e executada quando o dispositivo é ligado. Essa estrutura é conhecida como monol´ıtica (MAIA; MACHADO, 2007).

O software que interage diretamente com o hardware de um sistema embarcado, também chamado de firmware, utiliza dessa abordagem monol´ıtica, pois apresenta maior eficiência quanto ao tempo de execução e o espaço de memória ocupado. Porém, o sistema perde fle-xibilidade, visto que qualquer mudança necessária na aplicação requer uma nova compilação e uma nova ligação. Além disso, o novo arquivo executável precisa ser carregado por inteiro novamente para a memória.

Sistemas operacionais para desktops, como o Windows (MICROSOFT CORPORATION, 2016); o de c´odigo aberto Linux (THE LINUX FOUNDATION, 2016) , dispon´ıvel sob a

(14)

Licença Pública Geral GNU; alguns RTOSs de maior porte, como o VxWorks, citado ante-riormente; e o QNX (QNX SOFTWARE SYSTEMS LIMITED, 2016), mantido por empresa homônima, possuem uma arquitetura, pode-se dizer, dividida em “SO/Aplicação” (CARBONE, 2011). Nesses sistemas, há um kernel residente contendo todos os serviços necessários para a inicialização e a execução do sistema. Ainda provê o acesso das aplicações aos recursos de hardware e demais serviços necessários. Tudo isso numa única imagem executável distinta. Essa imagem inicia o sistema e continua sendo executada durante o tempo em que o sistema estiver ligado, providenciando meios para que as aplicações sejam carregadas dinamicamente no sistema e executadas. Este trabalho tem como finalidade desenvolver uma estrutura baseada nessa abordagem SO/Aplicação, adaptada para sistemas de menor porte, que utilizam RTOSs mais compactos.

1.1 JUSTIFICATIVA

Apesar de uma implementação monol´ıtica ocupar um tamanho menor de memória em uma aplicação embarcada, ela carece de flexibilidade. Com aplicações carregáveis dinamicamente, o sistema é capaz de aumentar suas funcionalidades utilizando os mesmos recursos de hardware. Em um sistema já em funcionamento, essa abordagem proporciona o uso de reconfigurações sob demanda e atualizações de firmware mais seguras.

Aplicações embarcadas que necessitam de atualizações de firmware são submetidas a ris-cos de integrabilidade do sistema. Como esse deve ser recarregado por completo na memória embarcada, uma parada inesperada durante o processo facilmente resultaria em uma quebra do sistema. Métodos de prevenção tomados normalmente no momento de uma atualização, como a suspensão total das tarefas e o uso de baterias na alimentação do sistema, não seriam mais necessários com o uso do sistema proposto.

Na imagem com o kernel contida no sistema, podem haver rotinas que gerenciem o car-regamento das atualizações de firmware. Se houver memória dispon´ıvel, essas atualizações podem ser carregadas em uma nova região de memória. Se ocorrida uma queda de energia du-rante o carregamento, é poss´ıvel conferir a porção de código recebida e instalar a nova aplicação ou requerer uma nova atualização. Ainda, utilizando desta abordagem é poss´ıvel manter tarefas paralelas em execução enquanto ocorre uma atualização.

(15)

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Implementar um sistema de gerenciamento de aplicações que possibilite a instalação e/ou remoção de pequenas porções do firmware de forma dinâmica em um sistema embarcado base-ado em um RTOS de pequeno porte.

1.2.2 Objetivos Espec´ıficos

• Desenvolver uma Application Programming Interface (API) que forneça métodos de comunicação entre as funções do RTOS e as aplicações carregáveis dinamicamente. • Criar um método de extração da parte executável de um arquivo Executable and Linkable

Format(ELF) e copi´a-la de uma mem´oria externa para a Random-Access Memory (RAM) do microcontrolador.

• Implementar a leitura de um arquivo execut´avel contido em um cart˜ao Secure Digital (SD).

• Implementar um método de gerenciamento de memória e execução dos aplicativos car-regáveis.

1.3 ORGANIZAC¸ ˜AO DO DOCUMENTO

O documento está organizado da seguinte forma. O Cap´ıtulo 2 introduz e revisa conceitos pertinentes ao desenvolvimento do trabalho proposto. Inicialmente é apresentado o uso de RTOSs em sistemas embarcados, abordando definições e estruturação. Em seguida, é feita uma revisão sobre as fases de um software em C e, são discutidos tópicos mais espec´ıficos como o linkere o padrão de arquivos ELF. Ao fim, são apresentadas algumas definições de cartões SD, como padrões utilizados e sua estrutura de dados.

A metodologia utilizada se encontra no Cap´ıtulo 3, em que são descritas todas as etapas para o desenvolvimento do projeto e poss´ıveis melhorias futuras. O Cap´ıtulo 4 apresenta a estruturação de arquivos do sistema e o modo como ele deve ser manuseado. Já no Cap´ıtulo 5, são listados os recursos de software e hardware utilizados e os resultados obtidos com a implementação e testes do sistema. Por fim, o Cap´ıtulo 6, apresenta a conclusão e poss´ıveis trabalhos futuros e pontos onde o sistema ainda precisa ser melhorado

(16)

2 FUNDAMENTAÇ ÃO TE ÓRICA

Neste cap´ıtulo são revisados os assuntos pertinentes ao desenvolvimento do trabalho. Inicia-se com uma introdução ao uso de RTOSs em sistemas embarcados. Logo após, são abordadas algumas fundamentações necessárias sobre o processo de ligação do código-fonte de um soft-waree uma visão sobre o formato de arquivos executáveis e ligáveis (do inglês Executable and Linkable Format, ELF). Ao fim, são comentados alguns conceitos referentes ao funcionamento de um cartão SD.

2.1 SISTEMA OPERACIONAL DE TEMPO REAL

Nos primeiros computadores programáveis a código, as aplicações eram todas desenvol-vidas a baixo n´ıvel e sem divisão alguma nos programas. Um único código abrangia desde a inicialização do sistema à qualquer outra interação com o hardware. Essa integração muito próxima entre o software e o hardware resultava em códigos nada portáveis entre arquiteturas distintas. Com isso, se fosse necessário fazer uma pequena mudança no hardware, grandes quantias do código-fonte deveriam ser alteradas. A manutenção desses sistemas era muito cus-tosa e demorada (LI; YAO, 2003).

Com o progresso da indústria de software, fez-se necessário um modo de desenvolvimento que facilitasse a manutenção dos sistemas. A partir da evolução dos métodos de implementação surge o sistema operacional, fornecendo ao desenvolvedor uma base de interfaceamento com o hardware. Tal interface permitiu uma maior portabilidade das aplicações desenvolvidas, bem como simplificação na sua manutenção. Além disso, foi poss´ıvel dar mais modularidade ao sistema, pois a aplicação agora começou a ser executada no topo do ambiente do sistema ope-racional e, pôde ser desenvolvida sem uma preocupação direta com a arquitetura utilizada.

O uso de sistemas operacionais popularizou-se sobre os computadores de propósito geral, fazendo que surgissem várias versões desses sistemas ao longo do tempo. Com o in´ıcio da época chamada “era pós-PC”(LI; YAO, 2003), o desenvolvimento de eletrônicos aumentou e, com isto, os recursos utilizados também aumentaram. Para suprir a necessidade de um melhor gerenciamento desse hardware no desenvolvimento de sistemas embarcados, surge o RTOS.

2.1.1 RTOS em Sistemas Embarcados

Comumente, autores definem sistemas embarcados como sendo dispositivos sem teclado, tela ou mouse. Tais definições utilizam de caracter´ısticas de aparência como fator de diferenciação para expressar que sistemas embarcados não são como computadores pessoais comuns. Uma definição geral pode ser simplificada como: sistemas embarcados são sistemas de computação

(17)

que possuem uma integração fortemente acoplada entre hardware e software, com o intuito de cumprir uma função dedicada (LI; YAO, 2003). Portanto, múltiplos sistemas embarcados podem coexistir em uma única aplicação.

Sendo assim, o termo sistema embarcado representa uma classe de computadores desen-volvidos para um propósito espec´ıfico. Seus recursos são inteiramente dedicados à uma, ou a um conjunto pequeno de tarefas. Esse tipo de implementação garante um maior proveito dos recursos, diminui custos, aumenta a agilidade do sistema e, por exigir um espaço menor para a aplicação, possibilita a construção de soluções de tamanho m´ınimo e até portáteis.

Um tipo especial de sistema embarcado se distingue de outros por suas exigências de res-postas à eventos externos em tempo real. Essa categoria é classificada por sistemas embarcados de tempo real (LI; YAO, 2003). Um evento externo é causado pelo meio em que o sistema embarcado está inserido. Tais eventos podem vir sozinhos ou como múltiplos eventos e em per´ıodos s´ıncronos ou ass´ıncronos. Um sistema de tempo real, como o representado no es-quema da Figura 1, deve receber esses eventos, tratá-los e devolver as ações que devem ser tomadas, tudo isso em um per´ıodo de tempo hábil e limitado, independente do evento de en-trada. O sistema deve possuir um tempo de resposta determin´ıstico.

Figura 1 – Diagrama representativo de um sistema de tempo real Fonte: Li e Yao (2003, p. 10).

Sistemas embarcados que são desenvolvidos sobre um hardware mais simples e que pos-suem um número reduzido de aplicações normalmente levam implementações que ocupam me-nos memória, com um firmware escrito de forma bem próxima à linguagem de máquina. Isso proporciona um processamento menos elevado e de resposta rápida. Porém, por exigir um fun-cionamento muito próximo ao hardware, o desenvolvimento de um sistema embarcado pode ser dif´ıcil, uma vez que é necessário que o desenvolvedor possua um considerável conhecimento sobre os recursos que estão sendo utilizados.

Um sistema operacional de tempo real é uma alternativa muito utilizada no desenvolvi-mento de aplicações embarcadas. Esse proporciona uma plataforma pronta já idealizada para

(18)

o desenvolvimento de aplicações e, na maioria das vezes, com o m´ınimo de preocupação com o hardware. Em sistemas embarcados com um número moderado de aplicações, é interessante o uso de técnicas de escalonamento de tarefas. Os RTOSs já implementam soluções para tais requisitos, portanto são de uso indispensável nesses tipos de sistema.

2.1.2 Estrutura de um RTOS

Um RTOS é o programa responsável por escalonar a execução de tarefas, gerenciando seus per´ıodos de tempo em execução e seus acessos aos recursos do sistema. Além disso, provê uma base consistente para o desenvolvimento de código de aplicações em plataformas embarcadas (LI; YAO, 2003).

As aplicações de um RTOS podem variar muito, desde um simples relógio despertador a sistemas de maior complexidade e risco, como o controle de navegação de aeronaves. Muitas boas implementações de RTOSs são escalonáveis e podem atender a diferentes tipos de requi-sitos para diferentes aplicações. Existem diversas formas de se implementar um RTOS, sendo que algumas delas podem reduzir-se a um núcleo. O núcleo provê os algoritmos m´ınimos de es-calonamento, gerenciamento de memória/recursos e de sincronização. Além do núcleo presente em todo RTOS, há também implementações que combinam diferentes módulos, como sistemas de arquivos, pilhas de protocolos e demais componentes que podem ser úteis dependendo da aplicação.

Implementações comuns de RTOSs podem ser divididas em 3 partes básicas como na Fi-gura 2. São elas (LI; YAO, 2003):

Escalonador (Scheduler) – está contido em todos os kernels e segue um conjunto de algorit-mos que determina quando e qual tarefa será executada. Exemplos comuns de algoritalgorit-mos de escalonamento são o round-robin e o escalonamento preemptivo.

Objetos (Objects) – são estruturas especiais do kernel e são úteis no desenvolvimento de aplicações de sistemas embarcados de tempo real. Alguns dos mais comuns são as tarefas, os semáforos e as filas.

Serviços (Services) – operações que o kernel aplica em um objeto ou, operações comuns como gerenciamentos de tempo, de interrupções e de recursos.

(19)

Figura 2 – Componentes comuns em um kernel de RTOS, incluindo objetos, o escalonador e alguns servic¸os

Fonte: Li e Yao (2003, p. 56).

O desenvolvimento de aplicações utilizando um RTOS é feito de modo que, o uso de recursos do sistema pelo programa é dado por chamadas de funções do kernel. Cada objeto ou serviço implementado pelo RTOS é disponibilizado em uma biblioteca que deve ser utilizada na codificação da aplicação.

2.2 LINKER

Um software em C possui um ciclo de vida que pode ser dividido em 5 est´agios bem definidos (STEVANOVIC, 2014):

1. Criação do código-fonte: desenvolvimento do software, escrito em linguagem de progra-mação em formato de texto.

2. Compilação: conversão dos arquivos de texto em binário na linguagem de máquina da arquitetura utilizada, chamados de arquivos objeto.

3. Ligação (Linking): junção dos arquivos objeto. Também é responsável pelo mapeamento e seccionamento de memória.

4. Carregamento: preparação do hardware para a execução do programa, copiando seções necessárias do arquivo executável para a memória e populando registradores.

(20)

5. Execução: funcionamento do software, mandando os comandos para o processador e gerenciando memórias de programa.

Dentre essas fases do software, é na de ligação que são organizados os códigos-objeto e as demais informações para a geração dos arquivos de sa´ıda necessários à execução. A Figura 3 apresenta um esquema da evolução de um software partindo de seu código-fonte e chegando no arquivo de sa´ıda.

Figura 3 – Esquema do processo de compilação e ligação de um código-fonte Fonte: Li e Yao (2003, p. 20).

Um programa é composto pelos códigos-fonte e pelos arquivos de cabeçalho. O modo como esse código fonte é compilado e constru´ıdo pode ser descrito em um Makefile, um script que configura os s´ımbolos e opções de compilação e invoca o compilador. A partir dos arquivos fonte, o compilador e o assembler produzem códigos-objeto contendo códigos binários em

(21)

linguagem de máquina e dados de programa. Podem ser geradas bibliotecas estáticas para o programa utilizando um arquivador (Archive utility). Ao fim da construção dos arquivos eles são ligados, e deles são retirados os arquivos necessários para o carregamento e execução do software(LI; YAO, 2003).

Essa fase de ligação é executada pelo linker e arquitetada pelo arquivo de comandos do linker(Linker Command File) ou linker script. O linker script tem como principal propósito mapear os códigos-objeto dentro do arquivo de sa´ıda e controlar o layout da memória na imagem do programa (CHAMBERLAIN; TAYLOR, 2009). O arquivo de sa´ıda gerado é um arquivo objeto e também é chamado de arquivo executável.

No processo de ligação são resolvidas as dependências dos arquivos do código-fonte, ou seja, as chamadas de funções, memórias globais e locais, arrays de caracteres e tudo o mais que possa estar sendo chamado em um arquivo do código-fonte e não possua uma ligação direta com o mesmo.

2.2.1 Formato de um Linker Script

Sendo um arquivo de texto, um linker script é escrito como uma série de comandos. Cada comando é ou uma palavra-chave, podendo conter argumentos em seguida, ou uma atribuição a algum s´ımbolo. Os comandos podem ser separados com v´ırgula e os espaços em branco são geralmente ignorados (CHAMBERLAIN; TAYLOR, 2009).

O linker script mais simples poss´ıvel, no padrão utilizado pelo GNU Compiler Collection (GCC), é mostrado na Listagem 1 e contém apenas um comando: SECTIONS. Esse é usado para descrever o layout da memória do arquivo de sa´ıda.

1 SECTIONS 2 { 3 . = 0x10000 ; 4 . text : { ∗ ( . text ) } 5 . = 0x8000000 ; 6 . data : { ∗ ( . data ) } 7 . bss : { ∗ ( . bss ) } 8 }

Listagem 1 – Exemplo de um linker script m´ınimo

Os s´ımbolos ‘.text’, ‘.data’ e ‘.bss’ representam seções especiais e contêm, res-pectivamente: códigos, dados inicializados e dados não inicializados. O s´ımbolo especial ‘.’ representa o contador da posição atual no arquivo. No in´ıcio da seção esse valor é zero. A pri-meira linha dentro do comando SECTIONS no exemplo atribui o valor hexadecimal 0x10000 ao contador. Portanto, a primeira seção iniciará nesse endereço do arquivo de sa´ıda. Tal seção é declarada na segunda linha.

A declaração da seção leva o nome da seção seguido por ‘:’ e entre as chaves o nome de todas as seções dos arquivos de entrada do linker que serão alocadas nessa seção do arquivo de

(22)

sa´ıda. O uso dos parênteses precedidos por ‘*’ em torno do nome da seção, faz com que todas as seções presentes nos arquivos de entrada que contenham esse nome sejam selecionadas. A seção de dados inicializados (.data) é criada na posição 0x8000000 do arquivo de sa´ıda, seguida pela sessão de dados não inicializados (.bss).

Por padrão, o linker pode acessar toda a memória dispon´ıvel. É poss´ıvel descrever blocos de memória, tornando-os acess´ıveis ao linker ou não, através do comando MEMORY. A Listagem 2 mostra um exemplo de uso desse comando. No exemplo, a memória acess´ıvel é dividida em dois blocos: FLASH e SRAM.

1 MEMORY

2 {

3 FLASH ( RX ) : ORIGIN = 0x00000000 , LENGTH = 0x00100000

4 SRAM ( WX ) : ORIGIN = 0x20000000 , LENGTH = 0x00040000

5 }

Listagem 2 – Exemplo de uso do comando MEMORY em um linker script

Semelhante ao comando SECTIONS, o comando MEMORY é seguido de chaves quando possui mais de um comando interno. O padrão de declaração de um bloco de memória inicia com o nome que deseja-se atribuir a esse, que pode ser qualquer palavra que não esteja reser-vada. No exemplo, ‘FLASH’ e ‘SRAM’. Em seguida, entre parênteses, encontram-se os atributos do bloco de memória. Esses não são obrigatórios. Os valores poss´ıveis para esses atributos são: R Seção apenas de leitura

W Seção de leitura e escrita X Seção executável

A Seção alocada I Seção inicializada

L O mesmo que I

! Inverte o sentido de qualquer um dos s´ımbolos anteriores

Após ‘:’, é indicada a posição de origem da região de memória, ou seja, o endereço em que se inicia o bloco de memória, através da palavra-chave ORIGIN. Separada por uma v´ırgula, a palavra-chave LENGTH indica o tamanho que o bloco de memória ocupa a partir do endereço de origem.

´

E poss´ıvel criar um pseudônimo que represente um desses blocos de memória declarados, através do comando REGION ALIAS. Assim, deixando o script mais intelig´ıvel. Para criar, por exemplo, um “apelido” nomeado ‘minha regiao’ a região FLASH, o comando fica:

REGION ALIAS("minha regiao", FLASH);

Há ainda, como definir s´ımbolos de referência com valores atribu´ıdos. Tais s´ımbolos são válidos somente internamente ao conjunto de chaves em que foram criados. A criação de tais s´ımbolos é poss´ıvel através do comando PROVIDE. Esse recebe o nome do s´ımbolo e o valor

(23)

que lhe será atribu´ıdo. Por exemplo, a declaração do s´ımbolo ‘meu simbolo’, que representa o valor hexadecimal 0x10, é feita da seguinte forma:

PROVIDE(meu simbolo = 0x10);

Um exemplo de criação de uma seção fixa em um endereço de memória é mostrado na Listagem 3. A seção .minha secao é criada na posição de memória 0x000F0000, no caso, na memória FLASH, apelidada de ‘MINHA REGIAO’.

1 MEMORY

2 {

3 FLASH ( RX ) : ORIGIN = 0x00000000 , LENGTH = 0x00100000

4 . . .

5 }

6

7 REGION_ALIAS(”MINHA REGIAO”, FLASH ) ;

8 9 SECTIONS { 10 PROVIDE ( _endereco_minha_secao = 0x000F0000 ) ; 11 12 . minha_secao : AT ( _endereco_minha_secao ) { 13 KEEP( ∗ ( . secao_qualquer ) ) 14 } > MINHA_REGIAO 15 16 . . . 17 }

Listagem 3 – Exemplo de criação de nova seção no linker script

Ao caso de não ser referenciada nenhuma seção dos arquivos de entrada do linker para popular a seção .minha secao no arquivo de sa´ıda, é mantida uma seção padrão nomeada de .secao qualquer que sempre existirá mesmo que não seja declarada. Isso é poss´ıvel através do comando KEEP que recebe o nome da seção padrão como parâmetro.

´

E poss´ıvel atribuir um tipo de dado criado no código-fonte diretamente em uma sessão, declarando-o como um atributo dessa seção. Para tal propósito, no compilador GCC é utilizada a palavra-chave atribute antes da declaração. A criação de um dado do tipo inteiro, nomeado de meuInteiro dentro da seção .minha secao é mostrada na Listagem 4 como exemplo.

1 __attribute__( ( section (” . m i n h a s e c a o ”) ) )

2 i n t meuInteiro = 4 2 ;

Listagem 4 – Exemplo de declaração de um dado inteiro em uma seção fixa da memória

Além dessas informações, um linker script pode conter várias outras informações úteis. Para uma consulta mais ampla sobre o formato, aconselha-se a leitura dos documento de especifi-cação, que podem ser encontrados em Chamberlain e Taylor (2009).

(24)

2.3 PADR ˜AO ELF

O arquivo objeto gerado após o processo de ligação do programa precisa seguir um mo-delo espec´ıfico. Um padrão fortemente utilizado, tanto pelo GCC como também por outros compiladores, é o padrão ELF. Originalmente desenvolvido e publicado pela UNIX System Laboratories(USL), o padrão ELF foi selecionado pela Tool Interface Standards (TIS) como um formato de arquivo de objetos portável e hoje trabalha em várias arquiteturas para vários sistemas operacionais (TIS COMMITTEE, 1995).

Por ser gerado como formato de sa´ıda no desenvolvimento do firmware de várias arquite-turas e, possuir uma estrutura de organização que possibilita que a parte executável do código seja extra´ıda separadamente, o padrão ELF adapta-se muito bem à proposta desse trabalho e, portanto, será utilizado como formato do aplicativo dinâmico.

O padrão ELF foi desenvolvido para simplificar o desenvolvimento de software. Sua es-trutura e conteúdo proporcionam uma interface binária que se estende por vários ambientes operacionais, diminuindo a necessidade de diferentes implementações para diferentes sistemas e ainda reduzindo o processo de reformulação e recompilação do código.

2.3.1 Formato do arquivo

Por ser um arquivo objeto, o arquivo ELF tem envolvimento tanto com a ligação do pro-grama quanto com sua execução. Portanto, convém adotar duas visões paralelas sobre seu conteúdo, como mostrado na Figura 4, uma para cada diferente necessidade desses processos envolvidos. Pelo uso do arquivo ELF ser amplo no processo de geração de um software, ele possui várias informações que são desnecessárias para este trabalho. Por esse motivo, serão focados aqui somente os dados pertinentes ao trabalho em questão. Para mais informações é recomendada a leitura dos documentos de especificação que podem ser encontrados em TIS Committee (1995).

(25)

_ _____________________ _ ______________________ _ _____________________ _ ______________________ _ _____________________ _ ______________________ _ _____________________ _ _____________________ _ ______________________ _ _____________________ _ _____________________ _ ______________________ . . . . . . _ _____________________ _ ______________________ _ _____________________ _ ______________________                                                        

Cabeçalhos de Programa Cabeçalhos de Programa opcional

Seção 1

Seção n

Cabeçalhos de Seção Cabeçalhos de Seção Segmento 2 Segmento 1 Cabeçalho ELF Cabeçalho ELF

Visão de Ligação Visão de Execução

opcional

Figura 4 – Visualização da estrutura de um arquivo ELF pelo processo de ligação e pelo de execução

Fonte: TIS Committee (1995, p. 1).

O cabeçalho ELF (ELF header) situa-se no in´ıcio do arquivo e contém informações que descrevem o mapeamento das partes do arquivo. As seções (sections) carregam os arquivos objeto gerados no processo de ligação. Podem conter instruções, dados, tabelas de s´ımbolos e outras informações necessárias para o funcionamento do software. Os segmentos (segments) são compostos por uma ou mais seções que são agrupadas na forma em que devem ser copiadas para a memória na hora da execução do programa. Se dispon´ıvel, a tabela de cabeçalho de programa (program header table) contém a descrição dos segmentos e auxilia na criação da imagem de processo na execução do programa. Por fim, a tabela de cabeçalho de seção (section header table) descreve as seções do arquivo e é utilizada em tempo de ligação dos objetos.

Para arquiteturas de 32 bits os dados de um arquivo ELF s˜ao representados como no Qua-dro 1. S˜ao utilizados somente esses tipos de dado em todo o contexto do arquivo.

Nome Bytes Tipo standard Prop´osito

Elf32 Addr 4 unsigned long Enderec¸o de programa Elf32 Half 2 unsigned short Inteiro m´edio sem sinal Elf32 Off 4 unsigned long Deslocamento no arquivo Elf32 Sword 4 signed long Inteiro grande com sinal Elf32 Word 4 unsigned long Inteiro grande sem sinal unsigned char 1 unsigned char Inteiro pequeno sem sinal

Quadro 1 – Tipos de dado de um arquivo ELF para arquiteturas de 32 bits Fonte: TIS Committee (1995, p. 2)

Por ser idealizado para ser um arquivo portável e único tanto em tempo de ligação como de execução, um arquivo ELF possui várias informações que podem não ser relevantes dependendo da aplicação proposta. Para este trabalho, somente algumas partes do arquivo são úteis. Tais partes são descritas a seguir.

(26)

2.3.2 Cabec¸alho ELF

O cabeçalho de um arquivo ELF 32 bits possui tamanho e estrutura fixos, sendo assim, pode ser lido como uma struct em C. A declaração de tal estrutura pode ser vista na Listagem 5.

1 # d e f i n e EI NIDENT 16

2

3 t y p e d e f s t r u c t {

4 u n s i g n e d c h a r e_ident [ EI_NIDENT ] ; / ∗ Magic number and o t h e r i n f o ∗ / 5 Elf32_Half e_type; / ∗ O b j e c t f i l e t y p e ∗ / 6 Elf32_Half e_machine; / ∗ A r c h i t e c t u r e ∗ / 7 Elf32_Word e_version; / ∗ O b j e c t f i l e v e r s i o n ∗ / 8 Elf32_Addr e_entry; / ∗ E n t r y p o i n t v i r t u a l a d d r e s s ∗ / 9 Elf32_Off e_phoff; / ∗ P r o g r a m h e a d e r t a b l e f i l e o f f s e t ∗ / 10 Elf32_Off e_shoff; / ∗ S e c t i o n h e a d e r t a b l e f i l e o f f s e t ∗ / 11 Elf32_Word e_flags; / ∗ P r o c e s s o r − s p e c i f i c f l a g s ∗ /

12 Elf32_Half e_ehsize; / ∗ ELF h e a d e r s i z e i n b y t e s ∗ /

13 Elf32_Half e_phentsize; / ∗ P r o g r a m h e a d e r t a b l e e n t r y s i z e ∗ / 14 Elf32_Half e_phnum; / ∗ P r o g r a m h e a d e r t a b l e e n t r y c o u n t ∗ / 15 Elf32_Half e_shentsize; / ∗ S e c t i o n h e a d e r t a b l e e n t r y s i z e ∗ / 16 Elf32_Half e_shnum; / ∗ S e c t i o n h e a d e r t a b l e e n t r y c o u n t ∗ / 17 Elf32_Half e_shstrndx; / ∗ S e c t i o n h e a d e r s t r i n g t a b l e i n d e x ∗ / 18 } Elf32_Ehdr ;

Listagem 5 – Estrutura de um cabec¸alho ELF

A estrutura do cabeçalho possui algumas informações sobre o tipo do arquivo como flags de versão e arquitetura para qual o arquivo fora compilado. Além disso, informa posições de endereço de in´ıcio de algumas partes do arquivo, bem como os tamanhos que ocupam na memória. Ainda é informado o endereço em que o programa deve ser iniciado em sua execução. As partes do cabeçalho que serão úteis para este trabalho são aquelas que descrevem a tabela de cabeçalhos de seção do arquivo. São elas:

e shoff endereço de in´ıcio da tabela de cabeçalhos de seção no arquivo ELF. e shentsize tamanho em bytes de cada cabeçalho de seção na tabela. e shnum quantidade de cabeçalhos de seção na tabela do arquivo ELF.

e shstrndx número da seção que contém a tabela com os nomes de cada seção.

2.3.3 Sec¸˜oes ELF

Uma seção ELF é um arquivo objeto ou de texto que contém partes ou informações impor-tantes à ligação ou execução do programa. Funções declaradas no código-fonte do programa são compiladas para arquivos objeto e alocadas cada uma em uma seção diferente do arquivo ELF.

(27)

Por possu´ırem informações variadas, as seções podem ter diferentes tamanhos e tipos. Para o controle delas ser poss´ıvel, um arquivo ELF possui uma tabela composta por estruturas chamadas de cabeçalhos de seção. Essa tabela na verdade é um vetor de estruturas como as descritas na Listagem 6. A posição de endereço inicial dessa tabela é dada por e shoff. Ela é formada por e shnum estruturas de tamanho e shentsize bytes. O primeiro cabeçalho de seção da tabela é sempre nulo.

2 Elf32_Word sh_name; / ∗ S e c t i o n name ( s t r i n g t b l i n d e x ) ∗ / 3 Elf32_Word sh_type; / ∗ S e c t i o n t y p e ∗ / 4 Elf32_Word sh_flags; / ∗ S e c t i o n f l a g s ∗ / 5 Elf32_Addr sh_addr; / ∗ S e c t i o n v i r t u a l a d d r a t e x e c u t i o n ∗ / 6 Elf32_Off sh_offset; / ∗ S e c t i o n f i l e o f f s e t ∗ / 7 Elf32_Word sh_size; / ∗ S e c t i o n s i z e i n b y t e s ∗ / 8 Elf32_Word sh_link; / ∗ L i n k t o a n o t h e r s e c t i o n ∗ / 9 Elf32_Word sh_info; / ∗ A d d i t i o n a l s e c t i o n i n f o r m a t i o n ∗ / 10 Elf32_Word sh_addralign; / ∗ S e c t i o n a l i g n m e n t ∗ / 11 Elf32_Word sh_entsize; / ∗ E n t r y s i z e i f s e c t i o n h o l d s t a b l e ∗ / 12 } Elf32_Shdr ;

Listagem 6 – Estrutura de um cabeçalho de seção ELF

Uma das seções existentes em um arquivo ELF é dedicada à guardar o nome das seções em modo de texto (strings) e organizada em formato de string table. A posição dessa seção na tabela de seções é dada pelo valor e shstrndx. Uma string table é composta por um conjunto de nomes separados pelo byte ’\0’ de fim de string e também possui esse s´ımbolo em seu in´ıcio. Um exemplo de string table pode ser visto na Figura 5 ao lado de uma tabela representando cada string nela contida.

+ 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 ______________________________________________________ 0 _{______________________________________________________}\0 n a m e . \0 V a r 10 _{______________________________________________________}i a b l e \0 a b l e 20 __{______________________________________________________}\0 \0 x x \0                                            String _ _________________ 0 none 1 name. 7 Variable 11 able 16 able 24 null string _ _________________        Índice Índice

Figura 5 – Exemplo de sec¸˜ao do tipo string table de um arquivo ELF Fonte: TIS Committee (1995, p. 16).

Uma estrutura de cabeçalho de seção descreve, basicamente, como uma seção está alocada no arquivo ELF e quais e que tipos de informação ela contém. Dentre os vários dados existentes num cabeçalho de seção, os pertinentes a este trabalho são destacados a seguir:

sh name posição na string table de cabeçalhos de seção em que inicia a string que contém o nome da seção.

sh type constante que representa o tipo da seção. Os principais valores e suas definições são descritos no Quadro 2. Além destes, há outros valores padrão que podem ser usados e ainda há um conjunto de valores reservados para assinalar uma seção como de um tipo espec´ıfico de processador ou arquitetura.

(28)

sh offset endereço de in´ıcio da seção no arquivo ELF. sh size tamanho da seção em bytes.

Definição Valor Descrição

SHT NULL 0 Seção inativa. Contém valores indefinidos

SHT PROGBITS 1 Seção com informações com sentido definido pelo programa SHT SYMTAB 2 Seção contendo uma tabela de s´ımbolos

SHT STRTAB 3 Sec¸˜ao contendo uma string table

SHT DYNAMIC 6 Seção contendo informações de ligação dinâmica

SHT NOTE 7 Seção com informações de algum tipo de marcação do arquivo SHT NOBITS 8 Seção não ocupa espaço

Quadro 2 – Definic¸˜oes de tipo (sh type) de um arquivo ELF Fonte: TIS Committee (1995, p. 2)

2.3.4 Sec¸˜oes Especiais

As seções de um arquivo ELF podem levar nomes variados dependendo do compilador, da arquitetura ou até mesmo da aplicação. Alguns nomes de seção são padronizados e indicam que a seção possui fins espec´ıficos na montagem da imagem de memória constru´ıda na execução. As seções especiais mais comuns são listadas no Quadro 3.

Nome Tipo Descric¸˜ao

.bss SHT NOBITS Marca dados não inicializados do programa .comment SHT PROGBITS Contém informações de controle de versão .data SHT PROGBITS Contém dados inicializados do programa .data1 SHT PROGBITS Complemento de .data

.debug SHT PROGBITS Contém informações de debug

.dynamic SHT DYNAMIC Contém informações de ligação dinâmica

.fini SHT PROGBITS Códigos executados ao fim da execução do programa .init SHT PROGBITS Códigos executados na inicialização do programa .note SHT NOTE Informações de compatibilidade e checagem .rodata SHT PROGBITS Contém dados do tipo somente leitura (constantes) .rodata1 SHT PROGBITS Complemento de .rodata

.shstrtab SHT STRTAB Contém string table com o nome das seções .strtab SHT STRTAB Contém string table com o nome dos s´ımbolos .symtab SHT SYMTAB Contém a tabela de s´ımbolos do programa .text SHT PROGBITS Contém o ”texto”executável do programa

Quadro 3 – Principais sec¸˜oes especiais de um arquivo ELF Fonte: TIS Committee (1995, p. 2)

(29)

2.3.5 Tabela de S´ımbolos

Uma tabela de s´ımbolos ELF é uma seção que guarda informações necessárias para a alocação e realocação de definições e referências simbólicas do programa. Tal tabela é formada por estruturas tais como a mostrada na Listagem 7. A primeira estrutura da tabela é sempre nula. Cada valor da tabela é descrito a seguir.

2 Elf32_Word st_name; / ∗ Symbol name ( s t r i n g t b l i n d e x ) ∗ / 3 Elf32_Addr st_value; / ∗ Symbol v a l u e ∗ /

4 Elf32_Word st_size; / ∗ Symbol s i z e ∗ /

5 u n s i g n e d c h a r st_info ; / ∗ Symbol t y p e and b i n d i n g ∗ / 6 u n s i g n e d c h a r st_other ; / ∗ Symbol v i s i b i l i t y ∗ /

7 Elf32_Half st_shndx; / ∗ S e c t i o n i n d e x ∗ / 8 } Elf32_Sym ;

Listagem 7 – Estrutura de uma tabela de s´ımbolos ELF

st name _{posição na string table de s´ımbolos em que inicia a string que contém o nome do} s´ımbolo. Se o valor for nulo o s´ımbolo não possui nome.

sh value valor associado ao s´ımbolo. Dependendo do tipo de s´ımbolo, esse valor pode ser um valor absoluto, um endereço ou outro tipo de informação.

st size valor associado ao tamanho do s´ımbolo. Se o valor for nulo o s´ımbolo possui tama-nho nulo ou desconhecido.

st info especifica atributos de tipo (type) ou vinculação (binding) do s´ımbolo. Os valores são manipulados da forma mostrada na Listagem 8. As definições de tipo são mostradas no Quadro 4 e as de vinculação no Quadro 5

st other normalmente contém valor nulo e não possui significado definido. st shndx número da seção ao qual o s´ımbolo está relacionado.

1 / ∗ How t o e x t r a c t and i n s e r t i n f o r m a t i o n h e l d i n t h e s t i n f o f i e l d . ∗ / 2 # d e f i n e ELF32 ST BIND ( v a l ) ( ( ( u n s i g n e d c h a r ) ( v a l ) ) >> 4 )

3 # d e f i n e ELF32 ST TYPE ( v a l ) ( ( v a l ) & 0 x f )

4 # d e f i n e ELF32 ST INFO ( b i n d , t y p e ) ( ( ( b i n d ) << 4 ) + ( ( t y p e ) & 0 x f ) )

(30)

Definição Valor Descrição STT NOTYPE 0 Tipo não especificado

STT OBJECT 1 Objeto de dados, como uma variável, um vetor, etc. STT FUNC 2 Associado à uma função ou outro código executável

STT SECTION 3 S´ımbolo associado com uma seção. Normalmente usado em realocações.

STT FILE 4 Nome do arquivo associado ao arquivo objeto

STT LOPROC 13 In´ıcio de intervalo reservado para definic¸˜oes espec´ıficas de pro-cessador

STT HIPROC 15 Fim de intervalo reservado para definic¸˜oes espec´ıficas de proces-sador

Quadro 4 – Definic¸˜oes de tipo de s´ımbolo de um arquivo ELF Fonte: TIS Committee (1995, p. 19)

Definição Valor Descrição

STB LOCAL 0 S´ımbolo vis´ıvel somente no arquivo objeto em que ´e criado STB GLOBAL 1 S´ımbolo vis´ıvel em todo os arquivos objetos

STB WEAK 2 Semelhante ao STB GLOBAL mas com definições de menor pre-cedência

STB LOPROC 13 In´ıcio de intervalo reservado para definic¸˜oes espec´ıficas de proces-sador

STB HIPROC 15 Fim de intervalo reservado para definic¸˜oes espec´ıficas de proces-sador

Quadro 5 – Definições de vinculação (bind) de s´ımbolo de um arquivo ELF Fonte: TIS Committee (1995, p. 18)

Conhecendo a estruturação do arquivo ELF é poss´ıvel encontrar os blocos de byte que guardam os comandos de cada função, inclusive a main. Com isso, utilizando da mesma arquitetura, é poss´ıvel instalar novas funções em um sistema já em execução extraindo esses blocos do arquivo e carregando para a memória.

2.4 CART ˜AO SD

O Secure Digital (SD) é um formato de cartão de memória não volátil desenvolvido pela Associação SD Card (SD CARD ASSOCIATION, 2016) e que é amplamente usado em aplica-ções que demandem o uso de memórias portáteis por ser um método seguro, de implementação simples e proporcionar considerável capacidade de armazenamento e desempenho. Um cartão SD é um dispositivo Flash, uma variação da Electrically-Erasable Programmable Read Only

(31)

Memory(EEPROM) tradicional. A principal diferença, além da taxa de escrita e leitura, é que na EEPROM é poss´ıvel apagar 1 byte em espec´ıfico e na Flash deve-se apagar um bloco de memória. A gravação e eliminação de dados é feita eletricamente e não é necessário o uso de fontes externas de energia para garantir o armazenamento dos dados (SD GROUP; SD CARD ASSOCIATION, 2013).

O padrão utilizado no cartão SD oferece três métodos poss´ıveis de acesso. Os protocolos SD Bus e Ultra High Speed (UHS) Bus, criados exclusivamente para o padrão SD, prometem maior desempenho no acesso aos dados na memória do cartão. Porém, muitos microcontro-ladores/processadores não possuem o periférico que possibilite o uso desses padrões e, ainda, ocupam um número maior de pinos. Como um modo secundário, o protocolo Serial Peripheral Interface(SPI) pode ser usado para a comunicação f´ısica com o cartão.

Há uma queda de desempenho na troca do protocolo padrão de acesso ao cartão SD, que possui 4 vias paralelas de dados, pelo SPI, que possui somente uma. Porém, destaca-se a vanta-gem de que, utilizando ele, é poss´ıvel criar uma comunicação a partir da maioria dos microcon-troladores existentes, com menor esforço por parte do programador e menos memória utilizada. Isso é poss´ıvel pois, atualmente, o barramento SPI é encontrado por padrão em praticamente todas as plataformas microcontroladas. A Figura 6 ilustra a configuração m´ınima necessária de barramento para a conexão do microcntrolador ao cartão SD.

MCU

SD

CS SCLK DI DO SCLK GPIO MOSI MISO SPI RPU

Figura 6 – Barramento m´ınimo da SPI entre o micro-controlador e o cart˜ao SD

Fonte: Chan (2016).

2.4.1 Sistema de Arquivos FAT

Os dados do cartão SD, fazem uso da estrutura de um sistema de arquivos para o controle de armazenamento, leitura e gravação de seus dados. Um padrão comumente utilizado é o File Allocation Table(FAT), por ser acess´ıvel e oferecer simplicidade e relativa robustez. O sistema de arquivos FAT utiliza de um método de organização dos dados bem como especifica o seu nome: uma tabela de alocação de arquivos. Os dados são paginados em blocos de mesmo ta-manho, chamados de clusters, e no in´ıcio do volume de memória encontra-se uma tabela que contém a localização de todos os dados contidos dentro desse volume (MICROSOFT CORPO-RATION, 2000).

(32)

O padrão FAT teve origem no fim da década de 1970 e foi originalmente desenvolvido para arquiteturas de computadores pessoais International Business Machines (IBM) atuando como o sistema de arquivos padrão do sistema operacional Microsoft Disk Operating System (MS-DOS). Inicialmente suportava discos de memória menores que 500 KB e, com o passar do tempo, fora aprimorado para suportar m´ıdias de tamanhos cada vez maiores e com menores desperd´ıcios.

Os três formatos mais conhecidos de FAT são o FAT12, FAT16 e o FAT32. São padrões que foram sendo desenvolvidos sobre o FAT padrão ao passar do tempo, conforme as necessidades de armazenamento. Basicamente, a diferença entre cada um está no tamanho da representação do endereço dos clusters na tabela FAT. Assim, utilizam endereços de 12, 16 e 32 bits respecti-vamente (MICROSOFT CORPORATION, 2000).

A gravação de um arquivo no sistema FAT é feita de forma que o arquivo é dividido em um número de clusters que possibilite seu armazenamento. Por exemplo, em um sistema FAT com clusters de 32 KB, um arquivo de 34 KB ocuparia dois desses para ser armazenado. Um com 32 KB e outro com os 2 KB restantes. Levando ao desperd´ıcio de 30 KB do volume.

Um volume de memória FATn (sendo n a versão do sistema de arquivos) pode possuir no máximo 2n_{clusters. Se esse volume for de um tamanho relativamente grande, é necessário que} os clusters tenham também um tamanho relativamente grande para poder cobrir toda sua ex-tensão de memória. Porém, quanto maior o tamanho dos clusters, maior é a perda de memória. Por esse motivo, o padrão comumente utilizado em sistemas FAT é o FAT32, que possibilita um número maior de clusters, fazendo que esses sejam de tamanhos menores e ainda cubram todo o volume necessário, com menos desperd´ıcio (MICROSOFT CORPORATION, 2007).

2.4.2 FatFs

Apesar da simplicidade do sistema de arquivos FAT, a implementação do controle de tal formato pode ser extensa e um tanto complicada, por conta do número de informações envol-vidas. Por esse motivo, várias aplicações utilizam de módulos de sistemas de arquivos FAT dispon´ıveis tanto comercialmente, quanto de forma gratuita e com código aberto. Um desses é o FatFs (CHAN, 2016).

(33)

Figura 7 – Posição do módulo FatFs na aplicação

Fonte: Chan (2016).

Com manutenção constante, até a atual data deste trabalho, o módulo FatFs é um soft-warelivre de código aberto para o gerenciamento de volumes FAT voltado ao uso em sistemas embarcados com recursos reduzidos. É escrito em ANSI C (C89) e completamente separado da camada de controle de entrada e sa´ıda f´ısica com os dispositivos de armazenamento, como mostrado na Figura 7. Portanto, independe de plataforma (CHAN, 2016).

Em conjunto com a comunicação SPI, a biblioteca FatFs possibilita a leitura, escrita, criação e remoção de arquivos no cartão SD. Bem como a navegação e gerenciamento de seus diretórios internos.

2.5 UTILIZAC¸ ˜AO DOS CONHECIMENTOS

A partir dos conhecimentos adquiridos no decorrer dessa seção, as etapas necessárias para a elaboração do gerenciador de aplicativos dinâmicos podem ser iniciadas. Utilizando a descrição do arquivo ELF, apresentada na Seção 2.3, torna-se poss´ıvel encontrar sua parte que refere-se ao código executável da aplicação. Ela é necessária para a instalação dos aplicativos, como será visto no cap´ıtulo seguinte.

A API responsável pela comunicação dos aplicativos com o sistema, pode ser armazenada em uma porção reservada da memória Flash fazendo uso das descrições do arquivo Linker, apresentadas na Subseção 2.2.1.

O arquivo ELF será carregado para o sistema através da comunicação com um cartão SD. Esse cartão utiliza o protocolo SPI e o sistema de arquivos Fat32, como apresentado ao longo da Seção 2.4. Os aplicativos carregados serão instalados como tarefas do RTOS presente no sistema, introduzido na Seção 2.1, .

Com as informações até aqui levantadas, dá-se in´ıcio às etapas de implementação do sis-tema. O próximo cap´ıtulo, traz as implementações necessárias para a construção do sistema de gerenciamento de aplicativos proposto.

(34)

3 METODOLOGIA

Neste cap´ıtulo são descritas as etapas do trabalho e o modo com que elas são executadas. A seguir, é exposta uma visão geral sobre a arquitetura proposta. Logo após, são listadas e expla-nadas as etapas da construção do sistema e alguns problemas enfrentados e suas soluções. São apresentadas também as definições contidas no arquivo de port, para a adaptação do sistema. Ao fim, são introduzidos alguns poss´ıveis trabalhos futuros.

3.1 VIS ˜AO GERAL

O sistema proposto é dividido em dois grandes núcleos: os aplicativos carregáveis e a imagem contida na memória do microcontrolador, a qual será chamada de base, e que contém o kernel, o gerenciador dos aplicativos e a API de acesso ao kernel e drivers de sistema. Um esquema simplificado da arquitetura proposta é apresentado na Figura 8.

Cartão SD Aplicativos carregáveis Gerenciamento de aplicativos em módulos Chamadas de funções do RTOS do RTOS Imagem executável na memória do embarcado hardware Kernel

Figura 8 – Esquema da arquitetura do sistema pretendido

Pela leitura de um cartão SD, o microcontrolador recebe o aplicativo carregável em formato ELF. Esse aplicativo é desenvolvido normalmente no ambiente de desenvolvimento padrão, da mesma forma que uma aplicação normal para a arquitetura em uso. Porém, com a diferença da necessidade da inclusão de um arquivo de cabeçalho contendo a API de acesso às funções e s´ımbolos dispon´ıveis no RTOS e na base, e, algumas poucas mudanças, citadas no decorrer deste cap´ıtulo. Além disso, o aplicativo deve ser obrigatoriamente carregado para a base.

(35)

Ao ser recebido na base, o aplicativo é instalado na memória de acesso randômico (do inglês Random-Access Memory, RAM) em forma de tarefa do RTOS. A implementação das chamadas do RTOS estarão contidas em uma seção reservada da memória Flash do microcon-trolador. O acesso a elas é dado através de uma API de estruturas de ponteiros que apontam aos endereços de cada função.

3.2 ETAPAS DO PROJETO

O projeto do sistema est´a dividido nas seguintes etapas:

Etapa 1 Desenvolvimento de uma API que possibilite às aplicações carregáveis o acesso às chamadas do RTOS e funções dispon´ıveis no sistema base.

Etapa 2 Implementação de um algoritmo de extração da parte executável do arquivo binário gerado pela compilação dos aplicativos carregáveis constru´ıdos.

Etapa 3 Implementação da leitura de um arquivo contido em um cartão SD.

Etapa 4 Implementação do sistema de carregamento, execução e gerenciamento dos aplicati-vos carregáveis.

Etapa 5 Desenvolvimento de métodos de resolução de perdas de referência, encontrados na execução dos aplicativos.

3.2.1 Etapa 1 - API de Acesso

Como o RTOS e outras funções importantes ao funcionamento dos aplicativos estarão contidas na base do sistema, e esses aplicativos serão desenvolvidos em outro ambiente no qual não há o RTOS instalado ou as funções dispon´ıveis, é necessário um meio de acesso a seus objetos e serviços. Para tal propósito é desenvolvida uma API de acesso.

As APIs implementadas são formadas por uma única estrutura de dados contendo ponteiros de memória para a localização de cada s´ımbolo acess´ıvel na base, seja esse de chamadas do RTOS ou outras implementações dispon´ıveis. Por exemplo, funções de acesso a drivers de algum hardware espec´ıfico.

Essa estrutura da API possui uma declaração padrão, sendo seu nome “System struct”e o nome de cada um de seus atributos como “attr n”, cada um com seu tipo “type n”. Em que n é um número que varia de 0 ao número de atributos contidos na estrutura menos 1. O modelo de uma estrutura da API com 3 atributos pode ser visto na Listagem 9.

(36)

1 t y p e d e f i n t ( ∗ type_0 ) ( v o i d ) ; 2 t y p e d e f v o i d ( ∗ type_1 ) ( i n t ) ; 3 t y p e d e f c h a r ( ∗ type_2 ) ( i n t , c h a r ) ; 4 5 t y p e d e f s t r u c t { 6 type_0 atr_0; 7 type_1 atr_1; 8 type_2 atr_2; 9 } System_struct ;

Listagem 9 – Definição da estrutura utilizada na API com 3 atributos de acesso aos serviços do sistema base

Visando a fácil adaptação de um código desenvolvido para ser executado de modo habitual em uma arquitetura, para um aplicativo dinâmico dessa mesma arquitetura, é criada uma camada de abstração entre as chamadas do código-fonte da aplicação e a estrutura da API. Essa camada nada mais é que um amontoado de definições que “apelidam”os nomes padrões dos atributos das estruturas da API para os das funções e objetos chamados no código.

Se um determinado aplicativo utiliza as funções RTOS func A(), RTOS func B() e Driver func A(), a estrutura da API terá 3 atributos, cada um com um tipo próprio que receberão os ponteiros dessas funções. Cada um desses atributos será redefinido pelo nome original das funções de modo com que essas possam ser chamadas no código do aplicativo da mesma maneira em que são no código de um programa normal. As redefinições são feitas como mostrado na Listagem 10. Além das redefinições dos atributos, a camada de abstração define uma chamada para a posição em que a estrutura da API se encontra na memória da base (no exemplo, 0x000F0000).

1 # d e f i n e SYSTEM ( ( S y s t e m s t r u c t ∗ ) 0 x000F0000 )

2

3 # d e f i n e RTOS func A SYSTEM−>a t r 0 0 0

4 # d e f i n e RTOS func B SYSTEM−>a t r 0 0 1

5 # d e f i n e D r i v e r f u n c A SYSTEM−>a t r 0 0 2

Listagem 10 – Camada de abstração com as redefinições dos atributos da estrutura da API

1 __attribute__ ( ( section (” . a p i S e c t i o n ”) ) ) 2 c o n s t System_struct system = { 3 RTOS_func_A, 4 RTOS_func_B, 5 Driver_func_A 6 } ;

Listagem 11 – Declarac¸˜ao da estrutura da API de acesso

Após todas as declarações de tipos e s´ımbolos serem feitas, as estruturas podem ser decla-radas, como no modelo da Listagem 11. Como a API será chamada no código do aplicativo, ele deve saber onde encontrá-la na memória do microcontrolador, podendo assim executá-la. Por esse motivo, a API é gravada em uma seção fixa da memória, que deve ser criada no linker scriptdo projeto, como mostrado na Listagem 3. No modelo de exemplo, essa seção é nomeada

(37)

“.apiSection”. A atribuição da estrutura a essa seção fixa é poss´ıvel fazendo uso da palavra chave atribute , apresentada na Seção 2.2.1.

A API é constitu´ıda por 3 arquivos e um esquema de seu funcionamento básico pode ser visto na Figura 9. Os arquivos API.c e API.h encontram-se no sistema base. Cada um contém, respectivamente, a declaração que atribui as chamadas de função na estrutura da API e as definições da estrutura, dos tipos de seus atributos e da posição em que a estrutura encontra-se na memória. O último arquivo é o API include.h e deve estar em todos os aplicativos. Esencontra-se contém as mesmas definições do API.h mais a camada de abstração com as redefinições dos atributos da estrutura da API para os nomes originais das funções atribu´ıdas a cada atributo.

Aplicativo carregável Kernel do RTOS (API.c e API.h) Base Estruturas de ponteiros (API_include.h) Chamadas de funções do sistema base

Figura 9 – Acesso às funções da base pelos aplicativos através da estrutura da API

Como os arquivos da API devem ser modificados sempre que novas funções da base são disponibilizadas às aplicações, foi criado uma rotina em linguagem C, nomeada API Generator.c, que recebendo um arquivo nomeado API.txt monta os 3 arquivos necessários ao funcionamento da API, bastando apenas copiá-los para seus devidos diretórios de projeto. Tal arquivo deve encontrar-se no mesmo diretório que a rotina compilada e conter, estritamente nesta ordem, as inclusões de arquivos de cabeçalho, as declarações das funções e os s´ımbolos definidos que podem ser utilizados pelos aplicativos.

3.2.2 Etapa 2 - Leitura de arquivo ELF

O aplicativo carregado no microcontrolador é lido em formato ELF. Logo, para que seu carregamento e execução sejam poss´ıveis, é necessário que sua imagem de execução seja mon-tada na memória da base. Isso se dá pela implementação de uma rotina que, a partir do arquivo ELF recebido, extrai o conteúdo executável e o carrega para uma nova tarefa do RTOS. Usando as tarefas do RTOS, há a vantagem do escalonamento entre as aplicações, e ainda o gerencia-mento dos recursos por elas utilizados.

A partir da descrição da estrutura do arquivo ELF, apresentada na Seção 2.3, é constru´ıda uma rotina que encontre o código objeto que contém a função principal (main()) do aplicativo

(38)

e demais func¸˜oes que ela utiliza, dentro do arquivo recebido. Um esquema representativo das etapas e cada parte do arquivo que elas utilizam pode ser visto na Figura 10.

Cabeçalho ELF Seção 1 Seção 2 Seção com string

table de seções

Cabeçalho de Seção 1

...

Seção com string

table de símbolos Cabeçalho de Seção 2 ... Tabela de símbolos Arquivo ELF Leitura do cabeçalho ELF Carregamento da .shstrtab Procura das seções .symtab, .strtab e .rodata Procura do símbolo main Procura do símbolo de função após o símbolo main Procura de símbolo informado como nal Carregamento do código executável Carregamento da .rodata 5 4 3 2 A B 6 7 1

Figura 10 – Relação das etapas de extração de programa com as partes do arquivo ELF

O sistema implementa dois modos de carregamento da parte execut´avel:

Modo A: mais simples, carrega apenas a função main() para a base, sendo que desse modo o aplicativo deve ser desenvolvido sem funções extras, toda a execução acontece dentro da função main().

Modo B: carrega também as funções extras criadas na aplicação, para isso é necessário que as funções sejam criadas após a main() e apenas declaradas antes dela no código-fonte do aplicativo. Isso é necessário, pois o sistema implementado parte do princ´ıpio que o código das funções extras está mapeado após o código da main(), e o modo como o mapeamento do arquivo ELF é feito depende da posição dessas funções. Além disso, é necessário também informar no arquivo de port, pela definição END SYMBOL NAME, o nome da função que é mapeada após as funções extras no arquivo ELF na fase de ligação do projeto. É poss´ıvel descobri-la consultando o arquivo de mapeamento (.map) gerado após a compilação.

Inicia-se a leitura do arquivo pelo cabeçalho, extrai-se as informações dos cabeçalhos de seção e da posição da string table .shstrtab, que guarda os nomes das seções ELF. Percor-rendo os cabeçalhos de seção e consultando a string table, são procurados três cabeçalhos: o