Main

Universidade Estadual de Campinas
Faculdade de Engenharia Mecnica
Uma Metodologia de Porte de Sistema

Operacional de Tempo Real para
Plataformas de Hardware
Autor: Tiago Noboru Ukei

Orientador: Prof. Dr. Denis Loubach
Campinas
2016
Universidade Estadual de Campinas

Faculdade de Engenharia Mecnica
Uma Metodologia de Porte de Sistema

Operacional de Tempo Real para
Plataformas de Hardware
Trabalho de Concluso de Curso apresentado

Comisso de Graduao da Faculdade de
Engenharia Mecnica, como requisito para a
obteno de ttulo de Engenheiro de Controle
e Automao.
Autor: Tiago Noboru Ukei

Orientador: Prof. Dr. Denis Loubach
Campinas
2016
Dedico este trabalho minha famlia,

que tanto me ajudou e incentivou no decorrer deste curso.
Agradecimentos
Reconheo que, sem a ajuda de diversas pessoas, este trabalho e a concluso deste
curso no seriam possveis. Portanto, gostaria de expressar meus mais ternos agradecimentos:
Primeiramente a Deus e a Jesus Cristo, por terem sempre me ajudado, concedendo
a mim graa, fora e sabedoria ao longo de minha vida.
Ao Prof. Dr. Denis Loubach, pelas notveis contribuies durante minha vida
acadmica e, em especial, para a realizao deste trabalho.
Aos meus queridos pais, que nunca mediram esforos para me ajudar durante toda
a minha vida, dando-me sempre do melhor e fornecendo-me um grande suporte por todos
esses anos de faculdade.
minha valiosa esposa, por tudo o que tem feito por mim e por ser minha fiel
companheira, demonstrando amor, carinho e dedicao em todos os momentos.
minha querida irm, por estar sempre presente em minha vida e por todo carinho
expressado.
toda minha famlia, pelo suporte que tenho recebido, pelo amor sempre demonstrado a mim e pela compreenso durante essa etapa da minha vida.
minha amiga Rita, sempre pronta para me ajudar e pela valiosa reviso deste
trabalho.
Ao meu amigo Lucas, por me auxiliar em diversos projetos durante a graduao.
Aos meus pastores, ministros e amigos do Ministrio Evanglico Comunidade Rhema
e do Word of Faith Fellowship, por todo ensinamento que recebi, pelo amor e carinho
demonstrado, por estarem sempre disponveis para me ajudar e por, de uma forma ou de
outra, terem participado de minha trajetria na faculdade.
Aos meus colegas de turma, pelo companheirismo, pela amizade e pelas grandes
contribuies durante os anos da graduao.
A todos os professores da Unicamp, em especial os da FEM, pela pacincia e por
todo ensinamento, sem o qual no poderia concluir este curso.
Aos supervisores da Sulzer, Srgio e Edson, pela compreenso e pelo suporte
prestado durante o estgio.
E a todos que, de alguma forma, contriburam para que a concluso deste curso
fosse possvel.
Se algum de vocs deficiente em sabedoria,

que pea ao Deus doador [que d] a todos
liberalmente e generosamente, sem
reprovao ou censura, e ela lhe ser dada.
(Amplified Bible (traduzida), Tiago 1:5)
Resumo
Sistemas embarcados de tempo real tm fundamental importncia em diversas aplicaes
nos dias de hoje, tais como na indstria, em automveis, aeronaves, celulares, eletrodomsticos, automao predial e centros de pesquisa avanada. Ao se tornarem cada vez mais
complexas, essas aplicaes passam a exigir o desenvolvimento de cdigos mais confiveis
e eficientes. Embora a fase de testes desses sistemas venha sendo aprimorada nos ltimos
anos, ela no capaz de reproduzir exaustivamente todas as condies a que o sistema
estar exposto durante seu funcionamento, tornando-se necessrio o desenvolvimento
de tcnicas e metodologias para aumentar a qualidade e confiabilidade de tais sistemas.
Apesar do grande nmero de pesquisas nessa rea, ainda no se encontra na literatura um
mtodo nico e sistemtico para realizar o porte de um sistema operacional de tempo real
para uma determinada plataforma de hardware. Neste contexto, este trabalho de pesquisa
visa apresentar uma metodologia contendo uma sequncia bem definida das atividades a
serem executadas para que um processo de porte seja realizado com sucesso. Para alcanar
esse objetivo, foram analisados, por meio de reviso da literatura, os principais mtodos
utilizados por diferentes autores em portes especficos e foi realizado um estudo de um
Board Support Package existente e funcional, que serviu de base para o desenvolvimento
deste trabalho. A metodologia proposta foi ento testada e validada ao se realizar um
porte do FreeRTOS em uma plataforma ARM, mostrando-se adequada para aplicao em
sistemas hard real-time.
Palavras-chave: sistemas embarcados de tempo real, porte, metodologia, RTOS.
Abstract
Nowadays, real-time embedded systems play a fundamental role in different application
domains, such as in the industry segment, in automobiles, aircrafts, cell phones, home
appliances, building automation and advanced research centers. As they become increasingly
complex, these applications require the development of more reliable and efficient codes.
Although the testing stage of these systems has been enhanced in the past few years, it
is not able to simulate all the possible conditions on which the system will be exposed
during its lifecycle, making it necessary to develop techniques and methodologies in order
to improve quality and reliability of such systems. Despite the research performed on
this subject, a unified and systematic method for porting a real-time operating system
on a hardware platform is hardly found in the literature. Considering this scenario, this
research work aims to introduce a methodology with a well-defined sequence of activities
required for a successful porting process. In order to achieve this goal, we analyzed, through
literature review, the main methods used by different authors in specific ports, and we also
performed a study of an existing and functional board support package, which comprised
the basis for the development of this work. The methodology proposed here was tested
and validated through porting FreeRTOS to an ARM-based hardware platform, being
suitable for hard real-time applications.
Keywords: real-time embedded systems, porting, methodology, RTOS.
Lista de ilustraes
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Exemplos de sistemas embarcados . . . . . . . . . . . . . . . . . . . . .

Diagrama de blocos de um sistema de controle genrico . . . . . . . . .
Sistemas embarcados de tempo real . . . . . . . . . . . . . . . . . . . .
Classificao dos sistemas de tempo real . . . . . . . . . . . . . . . . .
Diagrama alto nvel de um RTOS, mostrando o kernel e outros componentes encontrados em sistemas embarcados . . . . . . . . . . . . . . .
Diagrama de sequncia de uma execuo preemptiva . . . . . . . . . .
Troca de contexto entre tarefas . . . . . . . . . . . . . . . . . . . . . .
Escalonamento preemptivo por prioridade . . . . . . . . . . . . . . . .
Round-robin e escalonamento preemptivo . . . . . . . . . . . . . . . . .
Estrutura de uma tarefa . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de transio dos estados mnimos de um kernel de tempo real
Estrutura de um semforo . . . . . . . . . . . . . . . . . . . . . . . . .
Estrutura de uma fila de mensagens . . . . . . . . . . . . . . . . . . . .
Ambiente tpico de desenvolvimento cross-platform . . . . . . . . . . .
Processo de gerao da imagem executvel . . . . . . . . . . . . . . . .
Combinao das sees em imagem executvel . . . . . . . . . . . . . .
Mapeamento da imagem executvel no target . . . . . . . . . . . . . .
Componentes de software de uma imagem executvel . . . . . . . . . .
O BSP na estrutura de um sistema embarcado . . . . . . . . . . . . . .
Processo de inicializao do software . . . . . . . . . . . . . . . . . . .
Grafo da metodologia em cinco passos . . . . . . . . . . . . . . . . . .
Um modelo de tomada de deciso para sistemas embarcados . . . . . .
Componentes de um projeto criado com o KSDK . . . . . . . . . . . .
Estrutura do kernel em estudo . . . . . . . . . . . . . . . . . . . . . .
Diagrama de sequncia ilustrando a inicializao do FreeRTOS . . . . .
Drivers do dispositivo sensvel ao toque includo no projeto . . . . . . .
Fluxograma do processo de porte segundo a metodologia proposta . . .
Desdobramento do processo ID 6 da metodologia apresentada . . . . .
Desdobramento do processo ID 7 da metodologia apresentada . . . . .
Plataforma FRDM-KL25Z . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de requisitos do sistema . . . . . . . . . . . . . . . . . . . .
Diagrama de pacotes implementados . . . . . . . . . . . . . . . . . . .
Estrutura do projeto inicial . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama esquemtico de ligao do LED RGB . . . . . . . . . . . . .
Diagrama de atividades da tarefa Task1 . . . . . . . . . . . . . . . . .
18
24
24
25
31
31
33
34
35
36
37
37
38
39
40
41
41
42
42
44
50
52
54
57
64
65
66
68
70
74
75
76
77
81
81
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
36
37
38
39
40
41
42
43
44
45
46
47
Diagrama de atividades da tarefa Task2 . . . . . . . . . . . .

Diagrama de definio de blocos . . . . . . . . . . . . . . . . .
Sistema em funcionamento . . . . . . . . . . . . . . . . . . . .
Fotografia do sistema em movimento, com exposio durante 10
Sada nos pinos dos LEDs durante a execuo de cada tarefa .
Temporizao medida com o osciloscpio . . . . . . . . . . . .
Janela New Kinetis Project . . . . . . . . . . . . . . . . . . .
Selecionando o KSDK . . . . . . . . . . . . . . . . . . . . . .
Selecionando o FreeRTOS, na perspectiva Processor Expert .
Adicionando uma tarefa, na perspectiva Processor Expert . .
Perspectiva Hardware . . . . . . . . . . . . . . . . . . . . . .
Perspectiva C/C++ . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
segundos
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
82
82
84
85
86
86
93
95
96
96
97
97
Lista de tabelas
Tabela 1 Valores das principais constates definidas em FreeRTOSConfig.h . . 60
Tabela 2 Funes que compem a OSA . . . . . . . . . . . . . . . . . . . . . . . 62
Tabela 3 Matriz de rastreabilidade das etapas versus implementaes . . . . . . 83
Lista de quadros
Quadro 1 Constantes definidas no arquivo system_MKL25Z4.h . . . . . . . . 78
Quadro 2 Constantes definidas no arquivo portmacro.h . . . . . . . . . . . . 78
Quadro 3 Constantes definidas no arquivo FreeRTOSConfig.h . . . . . . . . 79
Siglas
A/D analgico-digital
ABS Anti-lock Braking System
ADC Analog-to-Digital Converter
API Application Programming Interface
ARM Advanced RISC Machine
BSP Board Support Package
CLP Controlador Lgico Programvel
CMP comparador de alta velocidade
CMSIS Cortex Microcontroller Software Interface Standard
COP Computer Operating Properly
CPU Central Processing Unit
D/A digital-analgico
DAC Digital-to-Analog Converter
DMA Direct Memory Access
DSP Digital Signal Processor
EABI Embedded-Application Binary Interface
EDF Earliest-Deadline-First
EEPROM Electrically-Erasable Programmable Read-Only Memory
FIFO first-in/first-out
FLL Frequency-Locked Loop
FPGA Field-Programmable Gate Array
GCC GNU Compiler Collection
GPIO General-Purpose Input/Output
GPOS General-Purpose Operating System

HAL Hardware Abstraction Layer
HARETICK Hard Real-Time Compact Kernel
I2 C Inter-Integrated Circuit Bus
I/O Input/Output
IDE Integrated Development Environment
IoT Internet of Things
IPC Inter-Process Communication
ISR Interrupt Service Routine
JTAG Join Test Action Group
KDS Kinetis Design Studio
KSDK Kinetis Software Development Kit
LED Light Emitting Diode
LPT Low-Power Timer
LQFP Low-profile Quad Flat Package
LR Link Register
LTIB Linux Target Image Builder
MCG Multipurpose Clock Generator
MSP Main Stack Pointer
NMI Non-Maskable Interrupt
NVIC Nested Vectored Interrupt Controller
OpenSDA Open-standard Serial and Debug Adapter
OS Operating System
OSA OS Abstraction layer
OXF Object eXecution Framework
PC Personal Computer
PC Program Counter
PCS Procedure Call Standard
PEE PLL Engaged External
PEx Processor Expert
PIT Periodic Interrupt Timer
PLL Phase-Locked Loop
PSR Program Status Register
QCB Queue Control Block
RAM Random Access Memory
RGB Red-Green-Blue
RISC Reduced Instruction Set Computer
RMS Rate-Monotonic Scheduling
ROM Read Only Memory
RTC Real-Time Clock
RTOS Real-Time Operating System
SBA Sociedade Brasileira de Automtica
SCB Semaphore Control Block
SDRAM Synchronous Dynamic Random Access Memory
SoC System-on-Chip
SPI Serial Peripheral Interface
SRAM Static Random Access Memory
SVC Supervisor Call
SWD Serial-Wire Debug
TCB Task Control Block
TCP/IP Transmission Control Protocol / Internet Protocol
TPM Timer/PWM Module
TSI Touch Sensing Input

UART Universal Asynchronous Receiver/Transmitter
UML Unified Modeling Language
USB Universal Serial Bus
Sumrio
1
1.1
1.2
1.3
INTRODUO . . . . .
Motivao . . . . . . . . .
Objetivos . . . . . . . . .
Estrutura do documento .
. . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
20
20
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
REVISO DA LITERATURA . . . . . . . . . . . . . . . . . .
Sistemas embarcados de tempo real . . . . . . . . . . . . . . .
Conceitos e Definies . . . . . . . . . . . . . . . . . . . . . . . .
Classificao dos sistemas de tempo real . . . . . . . . . . . . . . .
Propriedades fundamentais dos sistemas de tempo real . . . . . . .
Fatores que influenciam a previsibilidade . . . . . . . . . . . . . . .
DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interrupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chamadas de sistema (system calls) . . . . . . . . . . . . . . . . . . . .
Semforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gerenciamento de memria . . . . . . . . . . . . . . . . . . . . . . . .
Linguagem de programao . . . . . . . . . . . . . . . . . . . . . . . .
Sistemas operacionais de tempo real . . . . . . . . . . . . . .
Principais caractersticas de um RTOS . . . . . . . . . . . . . . . .
Kernel: o ncleo de um RTOS . . . . . . . . . . . . . . . . . . . .
Escalonador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Algoritmos de escalonamento . . . . . . . . . . . . . . . . . . . . . . . . .
Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Semforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Filas de mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tool-chain e gerao da imagem executvel . . . . . . . . . .
BSP e drivers de dispositivos . . . . . . . . . . . . . . . . . . .
Sequncia de inicializao do target . . . . . . . . . . . . . . .
Inicializao do hardware . . . . . . . . . . . . . . . . . . . . . . .
Inicializao do RTOS . . . . . . . . . . . . . . . . . . . . . . . .
Inicializao da aplicao . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
25
25
26
2.1.4.1
2.1.4.2
2.1.4.3
2.1.4.4
2.1.4.5
2.1.4.6
2.1.4.7
2.2
2.2.1
2.2.2
2.2.2.1
2.2.2.1.1
2.2.2.1.2
2.2.2.2
2.2.2.2.1
2.2.2.2.2
2.2.2.2.3
2.2.2.3
2.3
2.4
2.5
2.5.1
2.5.2
2.5.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
27
27
28
28
28
28
29
30
30
32
32
33
35
35
37
38
38
39
41
43
43
45
45
2.6
2.6.1
2.6.2
Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
BSP e porte do sistema operacional . . . . . . . . . . . . . . . . . . . . . 46
Algoritmos de escalonamento e RTOS . . . . . . . . . . . . . . . . . . . . 51
3
3.1
3.1.1
3.1.2
DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . .
Estudo do BSP para porte do FreeRTOS em uma plataforma ARM
Estrutura de um projeto FreeRTOS bsico . . . . . . . . . . . . . . . . . .
Anlise dos arquivos responsveis pelo porte . . . . . . . . . . . . . . . . .
port.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
portmacro.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FreeRTOSConfig.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vetor de interrupo: startup_MKL25Z4.S . . . . . . . . . . . . . . . . . . .
system_MKL25Z4.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MKL25Z4.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OSA: fsl_os_abstraction_free_rtos.c . . . . . . . . . . . . . . . . . .
Outros arquivos fonte comuns . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequncia de inicializao do FreeRTOS . . . . . . . . . . . . . . . . . . .
Drivers de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metodologia para porte de um RTOS em uma plataforma de hardware
3.1.2.1
3.1.2.2
3.1.2.3
3.1.2.4
3.1.2.5
3.1.2.6
3.1.2.7
3.1.2.8
3.1.3
3.1.4
3.2
4
4.1
4.2
4.3
EXPERIMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Critrios para a definio do RTOS utilizado . . . . . . . . . . . . . .
Critrios para a definio da plataforma de hardware utilizada . . .
Aplicao da metodologia desenvolvida na plataforma de hardware
escolhida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
54
55
56
56
59
59
60
61
61
61
61
63
64
65
71
71
72
74
RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6
6.1
6.2
CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Submisso de artigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
REFERNCIAS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
APNDICES
92
APNDICE A DETALHES DE INSTALAO DO AMBIENTE

DE DESENVOLVIMENTO . . . . . . . . . . . . . 93
APNDICE B CDIGOS . . . . . . . . . . . . . . . . . . . . . . 98
B.1
B.2
B.3
port.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
led_driver.c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
led_driver.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
C.1
APNDICE C ARTIGOS . . . . . . . . . . . . . . . . . . . . . . . 106

CBA 2016 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
18
1 Introduo
Este captulo apresenta a motivao, os objetivos e a estrutura deste trabalho de
pesquisa.
1.1 Motivao
Dispositivos que utilizam sistemas embarcados esto presentes em praticamente
todos os lugares: automveis, aeronaves, maquinrio agrcola, eletrodomsticos, televises,
celulares, MP3, porteiros eletrnicos, roteadores e dispositivos de rede, entre muitos outros
(Figura 1). A tendncia para os prximos anos, com a evoluo do conceito de IoT (Internet
of Things), ou Internet das Coisas, que todas as coisas sejam interconectadas, graas
ao desenvolvimento na rea de sistemas embarcados.
Figura 1 Exemplos de sistemas embarcados. Fonte: Veerabahu (2011).
Em muitas dessas aplicaes, o tempo que os dispositivos de controle levam para

produzir a resposta a estmulos externos criticamente importante. Um controlador
de voo de um caa supersnico, por exemplo, deve atuar em fraes de segundo para
evitar que ocorra uma catstrofe. Em outros casos, o tempo de resposta no precisa ser
Captulo 1. Introduo
19
necessariamente pequeno, mas o resultado deve ser produzido dentro de um intervalo de

tempo previsvel.
Com as aplicaes tornando-se cada vez mais complexas, surge a necessidade
de um gerenciamento confivel e eficiente das tarefas executadas por um dispositivo.
Por conseguinte, os desenvolvedores de software tm se apoiado cada mais em sistemas
operacionais para desempenhar suas funes. Apesar do constante avano em tecnologia de
hardware, ainda constitui um desafio manter a alta qualidade e confiabilidade de sistemas
cada vez mais complexos (ABADIE, 2008, p. 12).
Torna-se necessrio adotar abordagens criteriosas e mtodos sistemticos para a
implementao do sistema a fim de garantir sua previsibilidade. Deseja-se evitar, portanto,
que o sistema funcione aparentemente bem por um tempo, porm venha a falhar em
determinadas circunstncias. Uma falha no sistema de controle de alguns dispositivos,
como uma planta nuclear ou uma nave espacial, pode ter consequncias catastrficas,
envolvendo uma grande perda financeira ou, at mesmo, de vidas humanas, a exemplo do
que ocorreu com o radar anti-mssil da Arbia Saudita durante a Guerra do Golfo, que
falhou devido a um erro no software de controle, causando grandes danos (BUTTAZZO,
2011, p. 3-4):
Em 25 de fevereiro de 1991, o radar avistou um mssil Scud direcionado
para a Arbia Saudita e o computador de bordo calculou sua trajetria,
realizou a verificao, porm classificou o evento como um alarme falso.
Poucos minutos depois, o Scud caiu na cidade de Dhahran, causando
prejuzos e um enorme dano econmico. Mais tarde, foi descoberto que,
devido a uma longa rotina de tratamento de interrupo executando
com as interrupes desabilitadas, o clock de tempo real do computador de bordo estava perdendo algumas interrupes de clock e, dessa
forma, acumulando um delay de aproximadamente 57 microssegundos
por minuto. No dia do acidente, o computador havia trabalhado por cerca
de 100 horas (uma situao excepcional, nunca experimentada antes),
acumulando, assim, um atraso total de 343 milissegundos. Esse delay
causou um erro de predio na fase de verificao de 687 metros! O erro
foi corrigido em 26 de fevereiro, no dia subsequente ao acidente, inserindo
poucos pontos de preempo dentro da longa rotina de tratamento da
interrupo.
A partir do exemplo mencionado anteriormente, pode-se inferir que, durante a

fase de testes, no possvel replicar todas as condies a que o sistema estar exposto
quando colocado em funcionamento, ou seja, o teste de software no representa, por
si s, uma soluo para alcanar a previsibilidade nos sistemas de tempo real. Para se
obter um desempenho mais robusto sob vrias condies de operao, necessrio utilizar
metodologias de projeto avanadas, como a Scrum e a Extreme Programming (SOARES,
2004), alm de uma anlise aprofundada do cdigo fonte e mecanismos especficos do sistema
operacional, projetados para suportar aplicaes com restries temporais (BUTTAZZO,
2011).
Captulo 1. Introduo
20
Para que um sistema satisfaa tais restries, o software precisa estar adequadamente acoplado ao hardware, sendo necessrio um conjunto de macros e funes que
forneam um suporte mnimo, de forma que o sistema se conforme plataforma especfica
em que ser portado. Em outras palavras, realizar o porte de um sistema operacional
consiste em inicializar adequadamente os componentes bsicos do hardware para sua
correta utilizao.
Apesar do grande nmero de pesquisas e estudos relacionados aos sistemas computacionais de tempo real na atualidade, no se encontra na literatura um mtodo sistemtico
e nico, que possa ser aplicado para realizar o porte de qualquer sistema operacional de
tempo real - RTOS (Real-Time Operating System) - em uma nova plataforma de hardware.
Devido complexidade envolvida nesse processo, importante que haja uma sequncia
bem definida das atividades necessrias para que o porte do sistema seja efetuado com
xito. Tal necessidade explica o motivo da escolha deste tema para o trabalho de graduao,
dada a importncia e a aplicabilidade desses sistemas no mundo atual.
1.2 Objetivos
O objetivo da presente pesquisa apresentar uma metodologia de porte de um
RTOS em uma plataforma de hardware.
O trabalho de pesquisa tambm visa validar a metodologia apresentada por meio
da implementao de um porte especfico.
Pretende-se ainda fornecer a fundamentao terica para uma futura dissertao de
mestrado, cujo objetivo ser apresentar uma metodologia para a adaptao de um sistema
operacional para sistema operacional de tempo real, visando modificar seu escalonador
para atender s restries das tarefas de tempo real.
1.3 Estrutura do documento

O Captulo 1 apresenta a motivao e os objetivos da pesquisa, bem como uma
introduo ao tema abordado neste trabalho, onde citam-se algumas aplicaes dos sistemas
embarcados de tempo real e demonstra-se a importncia dos sistemas operacionais de
tempo real.
No Captulo 2 so apresentados, por meio de reviso da literatura, os principais
conceitos envolvendo sistemas embarcados de tempo real e sistemas operacionais de tempo
real. Tais conceitos fornecem a fundamentao terica para a metodologia desenvolvida.
No Captulo 3 realizado um estudo da estrutura e das principais caractersticas
de um BSP (Board Support Package) existente e funcional, fornecido pelo KSDK (Kinetis
Captulo 1. Introduo
21
Software Development Kit) para o porte do FreeRTOS em uma plataforma de desenvolvimento FRDM-KL25Z, a qual utiliza um processador ARM1 Cortex M0+. Com base
nesse estudo, desenvolvida uma metodologia geral para realizar o porte de um sistema
operacional de tempo real em uma plataforma de hardware.
No Captulo 4 apresentado o porte do FreeRTOS em uma plataforma FRDMKL25Z para teste e validao da metodologia desenvolvida. Os detalhes de implementao
do porte so apresentados nesse captulo, bem como os critrios de seleo do RTOS e da
plataforma utilizados.
No Captulo 5 so apresentados os resultados obtidos.
Por fim, no Captulo 6, so discutidos os resultados e so apresentadas as concluses
e propostas para os trabalhos futuros.
ARM (Advanced RISC Machine) uma arquitetura de processador RISC (Reduced Instruction Set
Computer) muito utilizada em sistemas embarcados.
22
2 Reviso da literatura
Neste captulo so apresentados os principais conceitos que embasaram esta pesquisa,
bem como o trabalho de outros autores que descrevem os passos seguidos para a realizao
de portes especficos.
2.1 Sistemas embarcados de tempo real

2.1.1 Conceitos e Definies
Li e Yao (2003, p. 14) definem sistemas embarcados como sistemas computacionais com integrao de hardware e software fortemente acoplados, projetados para
executar uma funo especfica. Os principais componentes de um sistema embarcado so:
Unidade de processamento microcontrolador, microprocessador;

Memria de programa ROM (Read Only Memory), EEPROM (Electrically-Erasable
Programmable Read-Only Memory), FLASH;
Memria de dados RAM (Random Access Memory), SDRAM (Synchronous Dynamic Random Access Memory);
Dispositivos de entrada sensores, botes;
Dispositivos de sada atuadores, LEDs (Light Emitting Diodes), displays.
A unidade de processamento o crebro do sistema computacional, pois responsvel por executar as instrues do programa, incluindo a manipulao de dados e o clculo
lgico e aritmtico. H diversas unidades de processamento que podem ser utilizadas
na construo de um sistema embarcado, tais como o microprocessador, microcontrolador, DSP (Digital Signal Processor), FPGA (Field-Programmable Gate Array), SoC
(System-on-Chip), entre outros.
Valvano (2007) cita quatro caractersticas essenciais dos sistemas embarcados, que
os diferem dos computadores de uso geral:
a) Sistemas embarcados tipicamente realizam uma funo especfica, sendo projetados para resolverem um nmero limitado de problemas e, consequentemente,
possuem poucos recursos;
Captulo 2. Reviso da literatura
23
b) Apresentam fortes restries de projeto, tais como custo reduzido, baixo consumo
de energia, limitao de tamanho, e muitas vezes, operao em ambientes
agressivos;
c) Em muitas aplicaes, devem operar dentro de restries de tempo real; e
d) A maioria dos sistemas embarcados requer unidades de memria reduzidas.
Do ponto de vista de programao, os sistemas embarcados diferem dos PCs
(Personal Computers) no sentido em que estes lidam com um conjunto bastante previsvel de
dispositivos de entrada/sada, como unidade de disco, vdeo, teclado, mouse, som e interface
de rede, e existe um bom suporte do sistema operacional para esses dispositivos. Por outro
lado, os sistemas embarcados incorporam uma enorme variedade de perifricos, incluindo
botes, switches, sensores, atuadores, portas seriais assncronas e de rede, conversores
A/D (analgico-digital) e D/A (digital-analgico), etc, os quais raramente possuem algum
suporte do sistema operacional - OS (Operating System), fazendo com que o programador
tenha que lidar diretamente com o hardware (ABBOTT, 2006).
Sistemas de tempo real podem ser definidos como sistemas que respondem a
eventos externos e assncronos dentro de restries de tempo bem definidas (FURHT et al.,
1991). Duas caractersticas intrnsecas aos sistemas de tempo real so que esses sistemas
devem produzir resultados computacionalmente corretos e esses resultados devem ser concludos dentro de um perodo de tempo predefinido. Em outras palavras, o comportamento
de tais sistemas depende igualmente da corretude de sua lgica de computao e do tempo
em que o resultado produzido (LI; YAO, 2003). Por exemplo, quando um motorista
aciona o pedal do freio, o controlador do sistema ABS (Anti-lock Braking System) analisa
o ambiente (velocidade do carro, aderncia ao solo, direo do veculo) e aciona o freio na
frequncia adequada em fraes de segundo. Tanto o resultado produzido, quanto o tempo
em que o freio acionado, so igualmente importantes para a segurana dos ocupantes do
veculo (CHENG, 2002).
Alguns outros exemplos de sistemas de tempo real so (BUTTAZZO, 2011):
controle de plantas qumicas e nucleares;
diversos dispositivos de controle em automveis;
controladores de voo;
monitoramento ambiental;
sistemas de telecomunicao;
sistemas de monitoramento de sinais vitais;
automao industrial;
24
robtica.
Um conceito que no deve ser confundido que, se um sistema de tempo real, no

significa necessariamente que ele atua em fraes de segundo. De fato, enquanto o objetivo
da computao rpida minimizar o tempo mdio de resposta de um determinado conjunto
de tarefas, o objetivo da computao de tempo real satisfazer o requisito de temporizao
de cada tarefa (STANKOVIC, 1988 apud BUTTAZZO, 2011, p. 8). Portanto, muito mais
importante que a velocidade de processamento a previsibilidade do sistema.
A maioria das aplicaes de controle e aquisio de dados se enquadram na categoria
dos sistemas de tempo real (BARABANOV, 1997). Um diagrama simplificado de um
sistema de controle de tempo real apresentado na Figura 2.
Sistema de
controle
Atuadores
Sensores
AMBIENTE
Figura 2 Diagrama de blocos de um sistema de controle genrico. Fonte: Buttazzo (2011, p. 8).
Sistemas embarcados de tempo real so sistemas embarcados que exibem

comportamentos de tempo real. A Figura 3 ilustra de forma simples o relacionamento
entre sistemas de tempo real e sistemas embarcados.
Sistemas
embarcados
Sistemas
embarcados
de tempo real
Sistemas de
tempo real
Figura 3 Sistemas embarcados de tempo real. Fonte: Li e Yao (2003, p. 19).
25
2.1.2 Classificao dos sistemas de tempo real

Os sistemas de tempo real podem ser classificados como crticos (hard real-time)
ou no-crticos (soft real-time), dependendo do grau de tolerncia s falhas em cumprir
os requisitos temporais e da severidade dos prejuzos decorridos dessas falhas (LI; YAO,
2003).
Um sistema crtico de tempo real deve cumprir as restries de tempo sem
praticamente nenhuma flexibilidade e uma falha temporal pode causar consequncias
catastrficas, at mesmo envolvendo vidas humanas. Resultados obtidos aps o limite
de tempo (deadline) previsto para determinada tarefa so geralmente inteis ou
apresentam alto grau de depreciao.
Um sistema no-crtico de tempo real possui um certo grau de tolerncia s
falhas temporais, as quais normalmente no resultam em um colapso do sistema,
porm podem causar prejuzos financeiros e degradao do desempenho.
Enquanto em um sistema crtico de tempo real, o deadline um valor determinstico,
este pode ser estimado estatisticamente para um sistema no-crtico (LI; YAO, 2003). A
Figura 4 mostra alguns exemplos de sistemas de tempo real e sua classificao.
Sistemas de
propsito geral
Simulao
Inferface com
computacional
usurio
Sistemas no-crticos
de tempo real
Video da
internet
Cruise
control
Telecomunicao
Sistemas crticos
de tempo real
Motor
eletrnico
Controlador
de voo
Figura 4 Classificao dos sistemas de tempo real. Fonte: Adaptado de Barr e Massa (2006).
2.1.3 Propriedades fundamentais dos sistemas de tempo real

Para poderem ser utilizados em aplicaes crticas, os sistemas de tempo real
necessitam de algumas propriedades fundamentais, tais como (BUTTAZZO, 2011):
Temporizao. Como j descrito anteriormente, o tempo em que o resultado
produzido to importante quanto sua exatido, o que significa que o sistema
operacional deve prover mecanismos de kernel especficos para o gerenciamento do
tempo e das tarefas com restries temporais e diferentes criticidades.
Previsibilidade. Para que se obtenha o desempenho desejado, o sistema deve ser
capaz de prever a evoluo das tarefas e garantir que todos os requisitos temporais
crticos sejam atendidos, antes do sistema ser colocado em operao.
26
Eficincia. O sistema operacional deve possuir um gerenciamento eficiente dos

recursos disponveis nos sistemas de tempo real, uma vez que estes so, geralmente,
embarcados em dispositivos pequenos, com severas limitaes de espao, peso, energia,
memria e poder computacional.
Robustez. Sistemas de tempo real devem ser projetados para suportar todos os
cenrios de carga previstos, a fim de no colapsarem quando sujeitos a uma condio
de sobrecarga.
Tolerncia a falhas. Componentes crticos de um sistema de tempo real devem
ser projetados para serem tolerantes a falhas, pois o sistema no pode entrar em
colapso, caso haja alguma falha simples de hardware ou de software.
Manutenibilidade. O sistema de tempo real deve ser projetado com uma estrutura
modular a fim de possibilitar modificaes no sistema.
2.1.4 Fatores que influenciam a previsibilidade

A previsibilidade , sem dvida, uma das principais caractersticas que um sistema
de tempo real deve ter. Contudo, garantir que todas as restries temporais sejam atendidas
depende de inmeros fatores, incluindo desde as caractersticas da arquitetura do hardware,
at a linguagem de programao utilizada para implementar o aplicativo (BUTTAZZO,
2011). Os principais elementos que afetam o determinismo e, portanto, a previsibilidade
do sistema, so discutidos a seguir.
2.1.4.1 DMA
O acesso direto memria - DMA (Direct Memory Access) - uma tcnica utilizada
por perifricos para transferir dados diretamente entre o dispositivo e a memria, livrando a
unidade central de processamento - CPU (Central Processing Unit) - da tarefa de controlar
a transferncia de dados, de modo a permitir que o acesso memria e o programa sejam
executados em paralelo. Como a CPU e o perifrico de entrada/sada - I/O (Input/Output)
- compartilham o mesmo barramento, a CPU fica bloqueada enquanto o dispositivo realiza
a transferncia de dados, caso ambos requeiram um ciclo de memria ao mesmo tempo.
Dessa forma, impossvel prever quantas vezes a CPU ter de esperar o DMA finalizar
a tarefa para ter acesso memria, impedindo a determinao do tempo de resposta de
forma precisa (BUTTAZZO, 2011).
Uma soluo alternativa seria utilizar um outro mtodo em que os ciclos de memria
sejam divididos em dois espaos de tempo: um reservado para a CPU e o outro para o
DMA. Essa soluo mais cara, porm mais previsvel, uma vez que no h conflito entre a
CPU e o DMA e, portanto, o tempo de resposta pode ser determinado com maior preciso
(BUTTAZZO, 2011).
27
2.1.4.2 Cache
Cache uma memria de rpido acesso que funciona como um buffer entre a
CPU e a memria RAM. Quando o programa requer um dado da memria, o hardware
verifica se a informao solicitada encontra-se na cache. Caso no esteja (cache miss), o
dado, bem como o contedo adjacente, copiado da RAM para a cache. Foi observado
estatisticamente que, para uma memria de 1 MB e uma cache de 8 kB, a taxa de acerto
(cache hit) de 80%, de forma que a utilizao da cache, em geral, diminui o tempo mdio
de execuo do programa (BUTTAZZO, 2011).
Nos sistemas de tempo real, no entanto, a utilizao da cache pode prejudicar
o determinismo do sistema, uma vez que, nos casos em que ocorre cache miss, h uma
degradao do desempenho, devido transferncia adicional de dados da RAM para a
cache. Ademais, durante operaes de escrita, o uso da cache aumenta o custo operacional,
visto que a escrita na cache deve ser propagada para todos os nveis at a memria, a fim de
evitar inconsistncia dos dados. Embora observaes estatsticas mostrem que apenas 10%
dos acessos memria so para operaes de escrita, essas observaes somente trazem
uma estimativa do comportamento mdio de um aplicativo e no podem determinar os
limites do pior caso (BUTTAZZO, 2011).
Em sistemas preemptivos, o efeito da utilizao de cache sobre a previsibilidade do
sistema ainda maior, porque depende do nmero de preempes e do ponto especfico
onde elas ocorrem, posto que a preempo destri o conceito de localidade de programa e
aumenta o nmero de cache misses (BUTTAZZO, 2011).
2.1.4.3 Interrupes
Um dos maiores problemas para a previsibilidade de um sistema de tempo real so
as interrupes geradas por dispositivos de I/O, pois podem introduzir atrasos significativos
durante a execuo da tarefa. Na maioria dos sistemas operacionais h rotinas especficas
para o tratamento dessas interrupes (drivers) que gerenciam os dispositivos a elas
relacionados e encapsulam dentro delas todo o detalhe de hardware dos perifricos. Os
servios de interrupo obedecem a um esquema de prioridades, as quais so, geralmente,
mais altas para os drivers que para as tarefas.
Entretanto, tratando-se de sistemas de tempo real, essa concepo no vlida,
visto que as tarefas de controle podem ser muito mais crticos que as interrupes de
perifricos. Como, em geral, muito difcil limitar a priori o nmero de interrupes que
uma tarefa poder experimentar, o atraso introduzido pelo mecanismo de interrupo na
execuo das tarefas se torna imprevisvel (BUTTAZZO, 2011, p. 16).
Trs abordagens que podem ser usadas para reduzir a interferncia dos drivers nas
tarefas do programa e ainda realizar operaes de entrada/sada so apresentadas a seguir
28
(BUTTAZZO, 2011):
a) Desabilitar todas as interrupes externas, exceto a do timer, e gerenciar os
perifricos dentro das tarefas do programa, por meio de polling;
b) Desabilitar todas as interrupes externas, exceto a do timer, e gerenciar os
dispositivos em rotinas dedicadas do kernel, ativadas periodicamente pelo timer;
c) Manter as interrupes habilitadas, porm reduzir os drivers para executarem
o mnimo de tarefas possvel, apenas ativando a tarefa apropriada para tratar o
evento disparado pelo dispositivo.
2.1.4.4 Chamadas de sistema (system calls)
Para que haja previsibilidade do sistema, todas as chamadas de kernel devem ser
caracterizadas por um tempo de execuo limitado e desejvel que sejam preemptivas. De
fato, qualquer seo no-preemptiva pode atrasar a ativao ou a execuo de atividades
crticas, causando uma falha temporal a deadlines crticos (BUTTAZZO, 2011, p. 18).
2.1.4.5 Semforos
Nos semforos normalmente utilizados em sistemas operacionais, tarefas de baixa
prioridade podem bloquear a execuo de tarefas com maior prioridade por intervalos
de tempo no-limitados, introduzindo atrasos no-determinsticos na execuo de tarefas
crticas, fenmeno conhecido como inverso de prioridades. Para minimizar esse problema,
inadmissvel em aplicaes de tempo real, devem ser usados protocolos que modificam a
prioridade das tarefas com base no uso de recursos e controlam a atribuio desses recursos
por meio de um teste executado toda vez que a tarefa entra em uma seo crtica, de forma
a limitar o tempo mximo que tarefas que compartilham sees crticas ficam bloqueadas
(BUTTAZZO, 2011).
2.1.4.6 Gerenciamento de memria
Alguns mecanismos de gerenciamento de memria podem introduzir atrasos nodeterminsticos na execuo dos programas, tais como os baseados em paginao, o que
no recomendado para aplicaes de tempo real. Para esses sistemas, comum adotar
mecanismos de particionamento esttico, que aumentam a previsibilidade do sistema, em
detrimento da flexibilidade (BUTTAZZO, 2011).
2.1.4.7 Linguagem de programao
Alm das caractersticas do hardware e dos mecanismos implementados no kernel,
a escolha da linguagem de programao exerce considervel influncia na determinao da
previsibilidade de um sistema de tempo real. Novas linguagens tm sido propostas para
29
suportar o desenvolvimento de aplicaes de tempo real, a exemplo da Real-Time Euclid,

que fora o programador a especificar limites de tempo especficos e excees de timeout
em todos os loops, esperas e declaraes de acesso a perifricos, alm de impor restries,
como ausncia de estruturas de dados dinmicas, ausncia de recurso e nmero mximo
de iteraes para cada loop (BUTTAZZO, 2011).
Qualquer mecanismo introduzido nas linguagens de programao para atender aos
requisitos de tempo real deve ser suportado pelo sistema operacional, por meio de servios
de kernel especficos, dos quais, o escalonamento o que mais influencia a previsibilidade
(BUTTAZZO, 2011).
2.2 Sistemas operacionais de tempo real

Os sistemas embarcados com hardware relativamente simples ou software com
poucas linhas de cdigo (e.g., relgio digital) so geralmente implementados com base em
uma arquitetura bare metal, ou seja, sem a utilizao de um sistema operacional, a exemplo
do padro de projeto (design-pattern) chamado executivo cclico cooperativo. No entanto,
algumas aplicaes na atualidade so complexas e requerem um gerenciamento elaborado
do escalonamento das tarefas. Os sistemas operacionais de tempo real so, portanto, a
chave para muitos sistemas embarcados hoje e proveem uma plataforma de software sobre
a qual podem ser construdos os aplicativos (LI; YAO, 2003).
Um sistema operacional de tempo real um sistema operacional capaz de garantir
os requisitos de tempo dos processos sob seu controle (BARABANOV, 1997, p. 1). Ele
deve escalonar a execuo dos programas de maneira temporizada, gerenciar os recursos
do sistema e prover suporte bsico para sincronizao, comunicao, temporizao precisa,
I/O e uma fundao consistente para o desenvolvimento do cdigo de aplicativo (LI; YAO,
2003; STANKOVIC; RAJKUMAR, 2004).
Em geral, no h uma definio rigorosa dos critrios para a utilizao de um RTOS
em uma aplicao, visto que tanto o executivo cclico cooperativo quanto os algoritmos
preemptivos possuem vantagens e desvantagens. Como mencionado anteriormente, em
aplicaes mais simples, no se justifica a utilizao de um RTOS devido ao overhead
introduzido pelas trocas de contexto e tarefas do kernel, alm de um aumento do volume de
memria decorrente do fato de cada tarefa possuir um espao reservado para sua prpria
pilha. Por outro lado, um RTOS permite uma utilizao mais eficiente da CPU (DAVIS;
MERRIAM; TRACEY, 2000) e, segundo Locke (1992), recomendado para praticamente
todas as aplicaes de tempo real, uma vez que possui as seguintes vantagens sobre os
sistemas cclicos simples: maior previsibilidade da capacidade de satisfazer os requisitos de
reposta da aplicao, a eficincia do sistema resultante do uso de periodicidade natural
(no-harmnica), a habilidade de se separar as questes de temporizao e funcionalidade
30
e uma estrutura robusta quando alguma alterao necessria durante a manuteno do

sistema.
2.2.1 Principais caractersticas de um RTOS

Os atributos que um RTOS precisa ter dependem do aplicativo que ser utilizado,
mas os mais comuns so: confiabilidade, previsibilidade, desempenho, volume de memria
reduzido e escalabilidade (LI; YAO, 2003).
a) Confiabilidade. Um sistema confivel se ele prov servio contnuo, sem
falhas. Embora o nvel de confiabilidade que um sistema requer dependa de sua
criticidade, uma caracterstica essencial que os sistemas embarcados devem
ter e determinado no s pelo RTOS, mas tambm pelo hardware, BSP e
software aplicativo.
b) Previsibilidade. Cumprir os requisitos temporais fundamental para o correto
funcionamento dos sistemas de tempo real, o que exige que o RTOS tenha
um nvel adequado de previsibilidade. Um RTOS determinstico aquele que
apresenta comportamento previsvel, isto , em que as chamadas de sistema
operacional completam-se dentro de perodos de tempo conhecidos.
c) Desempenho. Um sistema deve ser rpido o suficiente para satisfazer os requisitos de tempo pr-estabelecidos. Seu desempenho depende tanto do hardware,
como do software, e pode ser medido pela quantidade de dados transferidos em
um determinado tempo (throughput), ou mesmo pelo tempo de computao de
um algoritmo.
d) Volume de memria reduzido. Sistemas embarcados tm, em geral, limitaes de tamanho e custo, e, portanto, possuem memria limitada. Logo, o RTOS
deve ser customizvel, e a maneira com que ele gerencia a memria torna-se um
fator determinante que deve ser levado em conta pelos engenheiros do sistema
operacional.
e) Escalabilidade. Um RTOS deve ser capaz de crescer ou diminuir para atender
a requisitos especficos, o que gera economia de tempo e dinheiro quando
reutilizado em diferentes aplicaes. Para que um sistema seja escalvel, ele
deve ser capaz de adicionar ou remover componentes modulares, incluindo
sistemas de arquivos e pilhas de protocolos.
2.2.2 Kernel: o ncleo de um RTOS

Todo RTOS possui um kernel e pode possuir outros mdulos, como sistema de
arquivos, pilhas de protocolos de rede, entre outros elementos. O diagrama apresentado na
Figura 5 ilustra, em alto nvel, os componentes de um sistema embarcado.
320
CHAPTER 6 Processes and Operating Systems
Captulo 2. Reviso
dareal-time
literatura
up a basic
operating system. We will use as our example operating system
FreeRTOS [Bar07]. This operating system runs on many different platforms.
6.4.1 Two basic concepts
31
Aplica0vo
To make our operating system work, weRTOS

need to simultaneously introduce two basic
concepts. First, we introduce
preemption
asdan
Protocolos
Sistema
e alternative
Outros to the C function call as a
rede
componentes
way to control execution. de
Second,
we arquivos
introduce priority-based
scheduling as a way
for the programmer to control the order in which processes run. We will explain these
Bibliotecas de
Suporte
Kernel go on in the
ideas one at a time as general
concepts, then
next sections to see how they
suporte C/C++
POSIX
are implemented in FreeRTOS.org.
To be able to take full Drivers
advantage
ofMecanismos
the timer, wePerifricos
must change our notion of a proPreemption
de
disposi=vos
de debug
I/O
cess. We must, in fact, break
the assumptions
of our high-level
programming language.
We will create new routines that allow us to jump from one subroutine to another at
any point in the program. That, together with
BSP the timer, will allow us to move between
functions whenever necessary based upon the systems timing constraints.
Hardware execution of an operating system. We
Figure 6.7 shows an example of preemptive
want to share the CPU across two processes. The kernel is the part of the operating
system thatalto
determines
what
is running.
The kernel
is activated
Figura 5 Diagrama
nvel de
umprocess
RTOS,
mostrando
o kernel
e outrosperiodically
componentes enconby
the
timer.
The
length
of
the
timer
period
is
known
as
the
time
trados em sistemas embarcados. Fonte: Li e Yao (2003, quantum
p. 67). because it
is the smallest increment in which we can control CPU activity. The kernel determines
what process will run next and causes that process to run. On the next timer interrupt,
the kernel may pick the same process or another process to run.
O kernel
o ncleo
sistema
e aour
parte
por
Notethat
this use do
of the
timer is operacional
very different from
use ofresponsvel
the timer in the
lastdeterminar
Before, we
the timer Ele
to control
loop iterations,
with one loop
iteration
qual tarefa section.
deve entrar
emused
execuo.
ativado
periodicamente
pelo
timer e ento
including the execution of several complete processes. Here, the time quantum is in
chama a prxima
tarefa than
a ser
A ofFigura
6 apresenta
general smaller
theexecutada.
execution time
any of the
processes. um diagrama de sequncia
que mostra um exemplo de execuo preemptiva do sistema operacional (WOLF, 2012).

Timer
Kernel
Task 1
Task 2
FIGURE 6.7
Figura 6 Sequence
Diagrama
de sequncia
de execution.
uma execuo preemptiva. Fonte: Wolf (2012, p. 320).
diagram
for preemptive
Os principais componentes do kernel de um RTOS so (LI; YAO, 2003):

Escalonador - segue um conjunto de algoritmos que determinam as tarefas a serem
executadas em cada momento. Alguns dos algoritmos de escalonamento incluem o
round-robin e o escalonamento preemptivo.
Objetos - so estruturas especiais do kernel que auxiliam os desenvolvedores a
criarem aplicativos para sistemas embarcados de tempo real. Alguns objetos comuns
do kernel so as tarefas, semforos e filas de mensagem.
Servios - so operaes que o kernel realiza sobre um objeto ou operaes gerais,
como temporizao, tratamento de interrupes e gerenciamento de recursos.
32
2.2.2.1 Escalonador
O escalonador, principal ferramenta do kernel, prov os algoritmos responsveis
por determinar qual tarefa deve ser executada em cada momento (LI; YAO, 2003).
2.2.2.1.1 Definies
Li e Yao (2003, p. 69) definem entidade escalonvel como um objeto do kernel
que compete pelo tempo de execuo em um sistema, baseado em um algoritmo de
escalonamento pr-definido. Exemplos de entidades escalonveis so as tarefas e os
processos.
Tarefas so funes independentes, cuja execuo consiste em uma sequncia de
instrues independentemente escalonveis. Processos tambm so entidades escalonveis,
contudo, diferem das tarefas no sentido em que fornecem melhores caractersticas de
proteo memria, em detrimento de desempenho e overhead de memria (LI; YAO,
2003).
O conceito de multitarefa permite um escalonador gerenciar vrias entidades
escalonveis que precisam ser executadas simultaneamente, dentro de seus respectivos
deadlines. Em um ambiente multitarefa, o kernel intercala a execuo das tarefas baseado no
algoritmo de escalonamento, de forma que todas aparentam ser executadas simultaneamente
(LI; YAO, 2003).
Rotinas de interrupes - ISR (Interrupt Service Routine), diferentemente das
tarefas, no seguem os algoritmos de escalonamento, mas so executadas a partir de
interrupes de hardware, obedecendo poltica de prioridades (MARTINS, 2009).
Cada tarefa possui seu prprio contexto, que, segundo Lamie (2009 apud MARTINS, 2009), inclui o estado dos registradores da CPU, o contador de programa - PC
(Program Counter) - e informaes crticas relacionadas tarefa. Quando outra tarefa
entra em execuo, realizada uma troca de contexto, que consiste nos seguintes passos
(LI; YAO, 2003), ilustrados na Figura 7:
1. O kernel salva o contexto da tarefa 1 em seu TCB (Task Control Block)1 ;
2. O kernel carrega o contexto da tarefa 2 do seu TCB, que se torna a thread atual em
execuo;
3. O contexto da tarefa 1 congelado enquanto a tarefa 2 executa. Se o escalonador
precisar executar a tarefa 1 novamente, esta ir continuar sua execuo a partir do
ponto onde parou, imediatamente antes da troca de contexto.
1
TCB ou bloco de controle da tarefa uma estrutura de dados do sistema que o kernel utiliza para
guardar informaes especficas de cada tarefa. (LI; YAO, 2003, p. 70)
33
1
Salva contexto
Tarefa 1
Contexto da
Tarefa 2
Troca de
contexto
Execuo
atual
Contexto atual
2
Carrega contexto
Tarefa 2
Contexto da
Tarefa 1
Lista de
tarefas
Tarefa 2
Tarefa 1
Tempo de troca de
contexto
Tempo
Figura 7 Troca de contexto entre tarefas. Fonte: Li e Yao (2003, p. 70).
Em qualquer momento durante a execuo do RTOS, o fluxo de controle passa

por uma das trs reas: uma tarefa do programa, uma ISR ou pelo kernel. Quando uma
chamada de sistema ocorre, o escalonador verifica se necessria uma troca de contexto.
Em caso positivo, ele depende de um mdulo associado, denominado dispatcher, para
realizar a troca e alterar o fluxo de execuo, que desviado para o kernel para executar
uma das rotinas de sistema fornecidas por ele. Aps terminar a execuo dessa rotina,
o dispatcher responsvel por passar o controle para uma das tarefas do aplicativo do
usurio.
2.2.2.1.2 Algoritmos de escalonamento
Os algoritmos de escalonamento mais comuns utilizados pelos kernels atualmente
so o escalonamento preemptivo por prioridade e o round-robin.
Escalonamento preemptivo por prioridade
O escalonamento preemptivo por prioridade o mais utilizado nos sistemas de
tempo real. O conceito desse algoritmo consiste em que cada tarefa possui uma prioridade
e aquela de maior prioridade a que ser executada primeiro. Portanto, como mostra a
Figura 8, se uma tarefa estiver executando e outra de maior prioridade tornar-se pronta
para ser executada, o kernel imediatamente salva o contexto da tarefa atual em seu TCB
e passa a executar a outra tarefa (LI; YAO, 2003).
ALTA
34
Preempo
Trmino da tarefa
Tarefa 3
Prioridade
da tarefa
Tarefa 2
Tarefa 2
Tarefa 1
Tarefa 1
BAIXA
Tempo
Figura 8 Escalonamento preemptivo por prioridade. Fonte: Li e Yao (2003, p. 72).
A prioridade atribuda s tarefas no momento em que so criadas, mas podem

ser alteradas dinamicamente por meio de funes do kernel, conferindo ao sistema a
flexibilidade de se adaptar a eventos externos. No entanto, como apontam Li e Yao (2003),
essa capacidade, se no for utilizada corretamente, pode gerar problemas, tais como
inverso de prioridades, deadlock 2 e, at mesmo, a falha do sistema.
Wolf (2012) apresenta duas diferentes abordagens do escalonamento preemptivo
por prioridade: o RMS (Rate-Monotonic Scheduling) e o EDF (Earliest-Deadline-First).
O RMS uma poltica de escalonamento esttica, atribuindo prioridades fixas
para cada tarefa, baseada na ordem dos perodos, ou seja, tarefas com perodo mais curto
recebem maior prioridade. O RMS utiliza um modelo de sistema bastante simples, para o
qual as seguintes hipteses devem ser verdadeiras (WOLF, 2012, p. 326-327):
todas as tarefas so executadas periodicamente em um nico processador;
o overhead da troca de contexto desprezvel;
no h dependncia de dados entre tarefas;
o tempo de execuo de uma tarefa constante;
todos os deadlines coincidem com o final de seus perodos; e
a tarefa de maior prioridade no estado pronto sempre selecionada para execuo.
O escalonamento EDF um esquema de prioridade dinmico que atribui as prioridades, durante a execuo, por ordem de deadline, ou seja, as tarefas cujo deadline
encerra-se antes recebem as maiores prioridades. Obviamente, deve-se recalcular as prioridades ao trmino de cada tarefa. A implementao desse algoritmo mais complexa que a
do RMS, porm capaz de atingir maiores utilizaes de CPU. Por outro lado, executar o
escalonador com utilizao de CPU muito alta pode ser problemtico, devido sobrecarga,
o que torna mais fcil garantir o cumprimento dos deadlines com o RMS (WOLF, 2012).
2
Deadlocks ocorrem quando dois ou mais processos interagindo chegam a uma situao de impasse,
geralmente ocasionado por compartilharem recursos simultaneamente, causando travamento do sistema
(TANENBAUM, 2001).
35
Round-robin
O escalonamento round-robin mais comum em GPOSs (General-Purpose Operating
Systems), dado que fornece para cada tarefa uma poro igual do tempo de execuo e,
portanto, no satisfaz os requisitos de tempo real, uma vez que no considera a ordem
de prioridades. Esse algoritmo baseia-se no princpio de igualdade, em que as tarefas so
colocadas em uma fila e escalonadas uma aps a outra, de forma que todas possuem a
mesma chance de executar (LI; YAO, 2003; WOLF, 2012).
De acordo com Li e Yao (2003), quando uma tarefa colocada em execuo,
um contador de tempo de execuo iniciado e incrementado a cada ciclo de clock at
completar uma fatia de tempo (time slice). A tarefa em execuo , ento, colocada no
final da fila e seu contador zerado.
O round-robin pode ser associado a um escalonamento preemptivo baseado em
prioridade, em que as tarefas de mesma prioridade recebem igual alocao de tempo de
CPU. Um ciclo de round-robin executado at ser interrompido por uma tarefa de maior
prioridade. Nesse momento, o contador de tempo de execuo salvo e restaurado quando
a tarefa interrompida colocada novamente em execuo (LI; YAO, 2003). A Figura 9
ilustra essa ideia.
ALTA
Trmino da tarefa
Preempo
Prioridade
da tarefa
Tarefa 4
Fatia de tempo
Tarefa 1
Tarefa 2
Tarefa 3
T1
T1
Tarefa 2
BAIXA
Tempo
Figura 9 Round-robin e escalonamento preemptivo. Fonte: Li e Yao (2003, p. 72).
2.2.2.2 Objetos
Objetos de kernel so estruturas especiais fundamentais para o desenvolvimento
de aplicativos para sistemas embarcados de tempo real. Os objetos mais comuns de um
RTOS so as tarefas, os semforos e as filas de mensagem.
2.2.2.2.1 Tarefas
Como j definido anteriormente, tarefas so linhas de execuo paralelas e independentes, que podem competir por tempo de CPU, ou seja, so entidades escalonveis.
Segundo Li e Yao (2003), uma tarefa, quando criada, possui um nome, um ID nico, uma
36
prioridade (quando aplicvel), um bloco de controle de tarefa (TCB), uma pilha e uma
rotina, como ilustrado na Figura 10.
Bloco de Controle da Tarefa
Pilha da tarefa
TCB
PILHA
Nome da tarefa / ID
Rotina da
tarefa
int tMyTask()
{
while(1) {
printf(Hello world!);
:
}
}
Maior
prioridade
130
Prioridade
da tarefa
Menor
prioridade
Figura 10 Estrutura de uma tarefa. Fonte: Li e Yao (2003, p. 81).
Na inicializao do kernel, so criadas as tarefas de sistema e alocadas as prioridades

para cada tarefa a partir de um conjunto de nveis de prioridade reservados. As tarefas de
sistema incluem (LI; YAO, 2003):
Tarefa de inicializao: inicializa o sistema e cria as tarefas de sistema;
Tarefa idle (ocioso): consome os ciclos ociosos do processador, quando no h
outras atividades em execuo;
Tarefa de logging: registra as mensagens de sistema;
Tarefa de tratamento de exceo: trata as excees; e
Tarefa de debug: permite a depurao do sistema.
Em qualquer kernel que suporte a execuo paralela em um processador, h pelo
menos trs estados bsicos que uma tarefa pode estar durante sua execuo, ilustrados na
mquina de estados da Figura 11 (BUTTAZZO, 2011):
Executando. Uma tarefa entra nesse estado quando comea a ser executada no
processador. Se o escalonamento for preemptivo por prioridade, a tarefa com maior
prioridade ser a que estar executando.
Pronto. Tarefas nesse estado esto prontas para executar, porm o processador est
ocupado executando outra tarefa. Todas as tarefas nesse estado so mantidas em
uma fila.
37
Espera ou bloqueado. Uma tarefa entra nesse estado quando solicita um recurso
indisponvel, precisa esperar at que algum evento ocorra ou possui um delay de
certa durao.
ESPERA
sinal
espera
dispatch
ativa
PRONTO
EXECUTANDO
termina
preempo
continua
IDLE
fim do ciclo
TIMER
Figura 11 Diagrama de transio dos estados mnimos de um kernel de tempo real. Fonte:
Buttazzo (2011, p. 352).
2.2.2.2.2 Semforos
Li e Yao (2003) definem semforo como um objeto de kernel que uma ou mais
entidades escalonveis podem adquirir ou liberar com o objetivo de sincronizar a execuo
de mltiplas tarefas ou coordenar o acesso a um recurso compartilhado (excluso mtua).
Quando um semforo criado, o kernel lhe atribui um bloco de controle de semforo SCB (Semaphore Control Block), um ID nico, um valor (binrio ou uma contagem) e
uma lista de espera para tarefas, como ilustra a Figura 12.
Bloco de Controle do Semforo
SCB
Nome do
semforo / ID
Lista de espera
das tarefas
Tarefa 1
Valor
Binrio ou
uma contagem
Tarefa 2
...
Determina quantos tokens de

semforo esto disponveis
Figura 12 Estrutura de um semforo. Fonte: Li e Yao (2003, p. 96).
O kernel controla o nmero de vezes que um semforo pode ser adquirido por meio
de um contador, que inicializado no momento em que o semforo criado. Quando
uma tarefa adquire o semforo, ela permitida a executar uma dada operao ou acessar
38
um recurso e o contador decrementado. Este volta a ser incrementado medida que as

tarefas liberam os semforos (LI; YAO, 2003).
Quando o contador atinge o valor 0, o semforo no possui mais tokens para serem
adquiridos e a tarefa , ento, bloqueada e colocada na fila de espera, a qual pode ser
ordenada por prioridade ou seguir uma ordem FIFO (first-in/first-out). Quando o semforo
torna-se disponvel novamente, a tarefa desbloqueada e movida para o estado de espera
ou de execuo, dependendo de sua prioridade (LI; YAO, 2003).
2.2.2.2.3 Filas de mensagens
Uma fila de mensagens , segundo Li e Yao (2003, p. 111), um objeto similar
a um buffer, por meio do qual as tarefas e ISRs enviam e recebem mensagens para se
comunicarem e sincronizarem dados. A vantagem da fila de mensagens que as tarefas
no precisam enviar e receber as mensagens simultaneamente, pois o buffer armazena a
mensagem do emissor temporariamente, at que o receptor esteja pronto para receb-la.
Ao criar uma fila de mensagens, o kernel lhe atribui um bloco de controle de fila - QCB
(Queue Control Block), um nome, um ID nico, buffers de memria, o tamanho da fila, o
comprimento mximo da mensagem e uma ou mais listas de espera para as tarefas, como
mostra a Figura 13.
Bloco de Controle
da Fila
Memria
QCB
Nome da
fila / ID
...
Tarefa
Lista de espera
das tarefas receptoras
Mximo comprimento
da mensagem
Lista de espera
das tarefas emissoras
Tarefa
Tarefa
Tarefa
...
Elemento da fila
Tail
Comprimento da fila
Head
Figura 13 Estrutura de uma fila de mensagens. Fonte: Li e Yao (2003, p. 111).
2.2.2.3 Servios
Para auxiliar no desenvolvimento dos aplicativos para sistemas embarcados de
tempo real, o kernel fornece servios que compreendem um conjunto de mtodos da API
(Application Programming Interface), os quais so usados para realizar operaes sobre os
objetos do kernel e para facilitar o gerenciamento dos timers, tratamento de interrupes,
perifricos de I/O e gerenciamento de memria.
39
2.3 Tool-chain e gerao da imagem executvel

Uma caracterstica intrnseca aos sistemas embarcados a especificidade do software com relao ao hardware no qual ser executado. Logo, uma parte do esforo de
desenvolvimento focado em ferramentas para transformao dos cdigos fonte para
serem executados na plataforma de hardware escolhida. Esse mtodo de desenvolvimento
utiliza uma cross-platform, uma vez que o software desenvolvido e compilado em uma
plataforma (host) para rodar em outra (target). Nesse contexto, a plataforma host a
combinao do hardware, do sistema operacional e das ferramentas de desenvolvimento de
software utilizadas (LI; YAO, 2003).
A Figura 14 ilustra um ambiente tpico de desenvolvimento cross-platform.
Host system
Target system
Connections
Host
resident
software
Target
resident
software
Serial
BDM/JTAG
Ethernet
Figura 14 Ambiente tpico de desenvolvimento cross-platform. Fonte: Li e Yao (2003, p. 27).
O conjunto de ferramentas tpicas para o desenvolvimento de software embarcado

denominado tool-chain e contm, entre outras, as seguintes ferramentas:
Cross compiler - Compilador que roda em uma arquitetura de processador, mas
produz cdigo objeto para outra arquitetura de processador, a partir de cdigo fonte
em alto nvel (C/C++). utilizado porque o target geralmente no concebido
para hospedar um compilador.
Assembler - A partir de cdigo fonte em linguagem assembly, gera cdigo objeto,
que contm cdigo de mquina em binrio e dados do programa.
Linker - Liga os cdigos objeto produzidos pelo cross compiler ou assembler. Neste
passo, decide-se como os cdigos objeto sero combinados e onde (FLASH, ROM,
RAM) sero colocados o cdigo binrio e os dados no target.
40
Debugger - Ferramenta que executada no host e que permite rodar o software

embarcado a partir do target, visando observar seu comportamento em tempo de
execuo. Como o debugger interrompe a execuo do software, os requisitos de
tempo real no so mais satisfeitos.
A Figura 15 ilustra a viso geral do processo de gerao do cdigo executvel por
meio da utilizao da tool-chain.
User-created files
Makefile
(Makefile)
C/C++ Source and

Header Files
(*.c, *.cpp, *.h,
*.hpp)
Make Utility
Assembly Source
and Header Files
(*.s, *.h)
Preprocessor
Compiler
Archive Utility
Library Files
(*.a, *.lib)
Relocatable
File
(*.o, *.a)
Linker
Command File
(*.link)
Assembler
Object Files
(*.o)
Linker and Locator
Shared Object
File
(*.o, *.a)
Executable
Image
(*.elf, *.coff,
*.hex, *.out)
Link Map
(*.map)
Linker generated output files
Figura 15 Processo de gerao da imagem executvel. Fonte: Li e Yao (2003, p. 29).
Os cdigos objeto gerados pelo compilador ou pelo assembler contm geralmente

trs sees padro, quais sejam:
.text - cdigo de programa e constantes, geralmente armazenados na ROM ou na
Flash;
.data - variveis inicializadas, com espao de memria alocado na RAM, porm o
valor de inicializao normalmente armazenado na ROM/Flash;
.bss - variveis no inicializadas, com espao reservado na RAM.
41
O linker responsvel por combinar essas sees para formar a imagem executvel
e o loader carrega, na memria fsica do target, o cdigo executvel criado. Esse processo
exemplificado nas Figuras 16 e 17.
Executable image
file1.o
loader section
code/data (file1.o)
file2.o
loader section
code/data
.text section
.text (file1.o)
.text section
code
.text section
code
.text (file2.o)
my_section (file2.o)
my_section
code
.data section
data
.data section
.data (file1.o)
.data section
data
.bss section
data
.data (file2.o)
.bss section
data
.bss section
.bss (file1.o)
.bss (file2.o)
Figura 16 Combinao das sees em imagem executvel. Fonte: Li e Yao (2003, p. 38).
Executable image
Target memory
loader section
code/data (file1.o)
ROM
.text section
.text (file1.o)
Flash
0x0103Fh
0x10000h
my_section (file2.o)
.data (file2.o)
0x0001Fh
0x00040h
.text (file2.o)
.data section
.data (file1.o)
0x00000h
RAM
0x1FFFFh
.bss section
.bss (file1.o)
.bss (file2.o)
Figura 17 Mapeamento da imagem executvel no target. Fonte: Li e Yao (2003, p. 38).
2.4 BSP e drivers de dispositivos

Para que o RTOS comunique-se de forma adequada com o hardware, necessrio
um conjunto de drivers especficos para os componentes de hardware do sistema, conhecido
como BSP (LI; YAO, 2003). O BSP um componente de software que pode fazer parte
da imagem executvel, juntamente com uma srie de outros mdulos, como mostra a
Figura 18.
Kumar, Kamaraju e Yadav (2013, p. 36) definem BSP como uma implementao
do cdigo de suporte especfico para uma dada placa que se conforma a um dado sistema
42
Aplicativo
Software
Outros componentes/mdulos embarcados

Pilhas de protocolos (i.e. TCP/IP)
Sistema operacional de tempo real (RTOS)
Board Support Package (BSP)
MICROPROCESSADOR
ETHERNET
PORTA SERIAL
Hardware
BDM / JTAG
RAM / ROM / FLASH
TIMER
Figura 18 Componentes de software de uma imagem executvel. Fonte: Li e Yao (2003, p. 57).
operacional, ou seja, o BSP fornece o suporte mnimo para carregar o sistema operacional e contm os device drivers para todos os dispositivos no sistema target. Segundo
Corbet, Rubini e Kroah-Hartman (2005), os drivers de dipositivos funcionam como uma
caixa preta, fazendo com que um dispositivo de hardware particular responda a uma
interface de programao interna bem definida, sem que a aplicao conhea os detalhes
de implementao do dispositivo.
No entanto, encontram-se na literatura algumas divergncias quanto ao escopo do
BSP, se pertinente ou no incluir os drivers de perifricos em sua definio. Diferentemente
de Kumar, Kamaraju e Yadav (2013), Fredericks (2001) afirma que o BSP no acessa
diretamente o hardware dos dispositivos, porm funciona como uma interface entre o
kernel e os drivers dos perifricos.
Uma vez que a definio exata do BSP no faz parte do escopo deste trabalho,
adotou-se a perspectiva apresentada na dissertao de Hedlund e Aronson (2002), em
que dividem o BSP em um conjunto mnimo de cdigo de inicializao e drivers para o
funcionamento do sistema operacional (OS BSP), e um conjunto de drivers especficos
para a aplicao e que no so utilizados pelo RTOS (BSP), como ilustra a Figura 19.
Software aplicativo
Pilhas
Kernel
Cdigo de inicializao
Controlador de interrupo
Canal de debug
Timer do escalonador
OS BSP
BSP
Drivers especficos
aplicao (UART, GPIO,
PWM, Ethernet, etc.)
Hardware
Figura 19 O BSP na estrutura de um sistema embarcado. Fonte: Hedlund e Aronson (2002,

p. 35).
43
Como afirmam Hedlund e Aronson (2002), o desenvolvimento de um BSP uma

tarefa bastante rdua e pode demandar vrios meses, dependendo do nvel de complexidade
do hardware. Para escrever um BSP, necessrio conhecer a arquitetura de hardware do
target, o fluxo de dados, o mapa de memria, o mapa de interrupes, alm da linguagem de
montagem especfica para o microprocessador, j que boa parte do cdigo de inicializao
escrito em linguagem de baixo nvel. Boa parte dos desenvolvedores, no entanto, utiliza
o BSP de um porte anteriormente realizado para a plataforma de hardware ou para o
RTOS sendo utilizado e faz as devidas adaptaes no cdigo para a aplicao especfica.
Em geral, os registradores necessrios para o porte so listados nesses BSPs, juntamente
com uma sequncia para inicializar corretamente o hardware do target (LI; YAO, 2003).
2.5 Sequncia de inicializao do target

O BSP participa ativamente da inicializao do sistema, realizada pelos componentes
de software aps receberem do loader o controle de execuo. Os principais passos da
inicializao de um sistema embarcado, como ilustrados na Figura 20, podem ser divididos
em (LI; YAO, 2003):
inicializao do hardware;
inicializao do RTOS;
inicializao da aplicao.
2.5.1 Inicializao do hardware

A etapa de inicializao do hardware compreende os estgios 1, 2 e 3 da Figura 20
e corresponde fase de inicializao do BSP. Essa etapa inicial, em que a maior parte do
cdigo escrita em linguagem assembly, inclui as seguintes atividades (LI; YAO, 2003;
HEDLUND; ARONSON, 2002):
a) Iniciar a execuo a partir do vetor de inicializao
b) Configurar os registradores apropriados para o correto funcionamento do processador:
Identificar o tipo do processador
Obter ou estabelecer a velocidade de clock da CPU
c) Desabilitar interrupes e caches
d) Inicializar o controlador de memria, os chips de memria e as unidades de
cache:
44
Sequncia
de inicializao
do target
Inicializao
do hardware
Inicializao
do software
(RTOS)
Inicializao
do software
(aplicativo)
Vetor de inicializao
Inicializao de
hardware mnimo
Inicializao do
hardware remanescente
Inicializao
do RTOS
Inicializao
dos componentes
do RTOS
Incio da execuo
do RTOS
Transfere controle
ao programa de
usurio
Imagem de boot
mnima
BSP
RTOS
Aplicativo
Figura 20 Processo de inicializao do software. Fonte: Li e Yao (2003, p. 59).
Identificar a localizao das diferentes partes da memria, como a pilha,

dados, etc
Obter o tamanho da memria
Executar testes preliminares de memria, se necessrio
e) Configurar e inicializar os tratadores de interrupes e excees:
O BSP configura o controlador de interrupo para realizar o tratamento das
interrupes do OS e de I/O
f) Configurar o timer do escalonador do sistema operacional
g) Configurar os drivers de comunicao para o canal de debug do OS
h) Inicializar as interfaces de barramento
i) Inicializar os perifricos da placa
Ao se completar a fase de inicializao do BSP, estaro inicializados todos os
componentes de hardware do target e um conjunto de chamadas de funo disponibilizado
para as camadas mais altas do software (por exemplo, o RTOS) comunicarem com esses
componentes (LI; YAO, 2003).
45
2.5.2 Inicializao do RTOS

Os principais passos da inicializao do RTOS, que correspondem s etapas 4 a 6
da Figura 20, incluem (LI; YAO, 2003, p. 60):
a) Inicializar o RTOS
b) Inicializar objetos e servios do RTOS, quando presentes:
tarefas
semforos
filas de mensagens
servios de timer
servios de interrupo
servios de gerenciamento de memria
c) Criar as pilhas necessrias para o RTOS
d) Inicializar extenses adicionais do RTOS, tais como:
pilha TCP/IP (Transmission Control Protocol / Internet Protocol)
sistema de arquivos
e) Iniciar a execuo do RTOS e das tarefas iniciais
2.5.3 Inicializao da aplicao

Aps a inicializao do RTOS, este faz uma chamada a uma funo predefinida,
implementada pelo usurio, transferindo o controle para o software aplicativo. Esse
aplicativo tambm passa por uma fase de inicializao, quando so criados todos os
objetos, servios, estrutura de dados e variveis. O controle transferido ento para o
escalonador, o qual passa a gerenciar a execuo das tarefas criadas pelo programa de
usurio.
Nos sistemas embarcados de tempo real mais crticos, muito comum a implementao de um algoritmo de teste de integridade de hardware e software em tempo de
execuo, o qual deve ser inicializado na etapa de inicializao da aplicao. Geralmente
suportados por um componente de hardware especfico, esses testes incluem: teste de
conformidade do usurio, integridade de cdigo e de dados, monitoramento de recursos,
restries de tempo real e defeitos residuais, como ponteiros invlidos, erros de alocao de
memria, estruturas de dados corrompidas, erros de temporizao, otimizao, converso
de tipos, entre outros (VINCENT et al., 2002).
46
2.6 Trabalhos relacionados

Diversos artigos cientficos e trabalhos acadmicos tm sido realizados com o
objetivo de analisar o desempenho de sistemas operacionais de tempo real, bem como
executar, de forma eficiente, o porte desses RTOSs em plataformas de hardware especficas,
adaptando ou desenvolvendo o BSP necessrio. Como base para o presente trabalho, e
tambm para fins de comparao, alguns dos trabalhos mais relevantes utilizados na
pesquisa so apresentados a seguir, resumidamente.
2.6.1 BSP e porte do sistema operacional

Young (2015) realiza um estudo a fim de adaptar o FreeRTOS para ser executado
em uma plataforma de desenvolvimento FRDM-KL25Z, utilizando-se da API fornecida
pelo KSDK. Primeiramente, efetuou-se a configurao do IDE (Integrated Development
Environment) KDS (Kinetis Design Studio), que inclui tambm uma interface de depurao,
e ento foi realizado o porte do FreeRTOS para o hardware, modificando-se alguns arquivos
utilizados na implementao do kernel e desenvolvendo-se um BSP mnimo para suportar
a utilizao do LED RGB (Red-Green-Blue)3 . As principais alteraes foram realizadas
nos seguintes arquivos:
port.c: contm as funes que interagem com o hardware e permitem a execuo
de outras funes do OS, tais como semforo, excluso mtua (mutex), tarefas, etc.
portmacro.h e FreeRTOSConfig.h: contm uma lista de constantes para configurao do hardware e do RTOS para correta utilizao pelo software aplicativo.
A metodologia empregada por Young (2015) resume-se nos seguintes passos
(YOUNG, 2015, p. 6):
1. Pesquisar sobre a arquitetura do processador e o esquema de gerenciamento de
memria. Definir as constantes e macros apropriadas nos arquivos de cabealho,
necessrias para a configurao do clock, tamanho do heap e da pilha, nveis de
prioridade, entre outras definies;
2. Utilizando o cdigo de um porte anterior para uma plataforma semelhante, realizar as
modificaes necessrias no arquivo port.c, implementando inicialmente a funo
de inicializao da pilha (pxPortInitialiseStack());
3. Determinar quais funes so dependentes de pxPortInitialiseStack() e
implement-las de forma incremental at que seja possvel compilar o FreeRTOS;
3
RGB a abreviatura do sistema de cores aditivas, formado por vermelho (Red), verde (Green) e azul
(Blue)
47
4. Implementar um BSP mnimo para suportar a utilizao do LED RGB, utilizado

nos testes de temporizao.
No artigo apresentado por Kumar, Kamaraju e Yadav (2013) feito o porte do
sistema operacional Linux em uma plataforma ARM, utilizando-se a ferramenta LTIB
(Linux Target Image Builder) para customizar o BSP para a aplicao especfica do sistema.
O artigo explica como preparar o ambiente de desenvolvimento e instalar e executar o
LTIB a fim de se obter as imagens inicializveis, alm de port-las para o target, por meio
de um carto SD. No estudo, realizada uma comparao do consumo de memria e do
tempo de inicializao de diferentes configuraes do sistema operacional - mnima, padro,
mxima e customizada. Verifica-se a vantagem de se customizar o BSP e o OS, uma vez
que se obtm o melhor desempenho nos quesitos de memria e tempo de inicializao,
bem como se obtm suporte para todos os dispositivos contidos no target. Outra vantagem
tambm apontada no artigo o fato de o tempo de desenvolvimento ser muito menor
quando se utiliza um BSP existente e funcional e se adapta para a aplicao em vez de se
escrever todo o cdigo.
Joshi et al. (2014) tambm fazem a customizao do BSP e o porte do Linux em
um processador ARM Cortex, porm utilizam o ambiente de desenvolvimento baseado no
projeto Yocto4 em vez do mtodo tradicional que utiliza o LTIB, considerado antiquado
pelos autores.
Em sua dissertao, Schfer (2007) apresenta um estudo aprofundado sobre o carregamento e a linkagem dinmica de cdigo nativo no sistema operacional RTEMS5 em uma
plataforma Blackfin. O estudo partiu da necessidade de se programar CLPs (Controladores
Lgicos Programveis) em qualquer uma das linguagens abordadas no padro internacional
IEC 61131-3 e traduzir o cdigo para a linguagem C, para ser posteriormente compilada
em cdigo nativo pelo compilador GCC (GNU Compiler Collection), melhorando, dessa
maneira, o desempenho do sistema em relao ao mtodo tradicional de cdigo interpretado.
Outro objetivo da pesquisa era desenvolver um loader para realizar o carregamento e a
linkagem dinmica do cdigo nativo, a fim de permitir a atualizao de software rpida
em links de comunicao lentos. Para atingir os objetivos, foi necessrio realizar o porte
do RTEMS para a plataforma Blackfin, adotando-se a seguinte metodologia:
Preparar a tool-chain e o ambiente de desenvolvimento;
Criar uma cpia de no_cpu e no_bsp (diretrios que contm os prottipos e
descries das funes dependentes da CPU e da placa, respectivamente), que
4
O Yocto Project um projeto de colaborao open source que fornece templates, ferramentas e mtodos
que auxiliam na criao de sistemas baseados em Linux customizados para aplicaes embarcadas
independentemente da arquitetura de hardware utilizada (YOCTO PROJECT, 2013)
RTEMS um sistema operacional de tempo real open source, muito utilizado em aplicaes espaciais
(SCHFER, 2007).
48
compilam com a tool-chain;

Criar um porte bsico do SuperCore e do BSP contendo o driver do console;
Testar o programa Hello World, que imprime uma string no console, pois requer
que o sistema operacional seja inicializado com sucesso e faa uma troca de contexto
para a tarefa do aplicativo;
Implementar o tratamento de interrupo e testar o programa Ticker, que utiliza
muitos subsistemas do RTEMS e exige o funcionamento do driver de clock e da
rotina de tratamento de interrupo, para interromper uma tarefa em execuo e
despertar outra que est em espera.
Testar e depurar o sistema utilizando aplicativos maiores.
Segundo Schfer (2007), o kernel do RTEMS composto por dois subsistemas
fundamentais: o SuperCore e o BSP, os quais interagem diretamente com o hardware,
apesar de possuir um cdigo enorme. O autor destaca os arquivos contidos no diretrio
cpukit/score/cpu, que so associados ao porte do RTEMS em uma famlia particular
de processadores. Para o porte em uma plataforma Blackfin, esses arquivos compreendem
alguns headers, um arquivo em linguagem assembly (cpu_asm.S) e dois arquivos de
cdigo fonte em C. Os headers so usados para definir macros do RTEMS, enquanto
o arquivo em assembly relativamente pequeno, com aproximadamente 100 linhas de
cdigo, e consiste em apenas trs funes para o gerenciamento das tarefas e duas para o
gerenciamento das interrupes.
Gerenciar as tarefas consiste basicamente em salvar o contexto de uma tarefa em
execuo e restaurar o contexto de outra tarefa, alm de lidar com pilhas de tarefas e
requisitos de alinhamento de pilha. Para essa implementao, foi criada uma estrutura de
dados para armazenar o contexto das tarefas, que contm todos os registradores da CPU
do Blackfin necessrios. importante ressaltar que algumas macros devem ser devidamente
configuradas para a correta utilizao da pilha, tais como as macros que definem a direo
de crescimento, o tamanho mnimo e o alinhamento da pilha.
Implementar o gerenciamento de interrupes consiste basicamente em implementar
algumas macros para habilitar/desabilitar interrupes e algumas funes para realizar o
tratamento destas. A rotina de tratamento de interrupo implementada em assembly
e chamada por uma ISR genrica, que instalada por meio da funo _CPU_ISR_install_vector.
Schfer (2007) tambm implementa o BSP para o ADI EzKit533, que suporta
comunicao serial via UART (Universal Asynchronous Receiver/Transmitter)/SPI (Serial
Peripheral Interface) e utiliza o clock do processador para o driver de clock. O arquivo
start.S, parte do BSP responsvel pela inicializao do hardware, inicializa o stack
49
pointer e ento chama a funo boot_card, que inicializa o RTEMS. Em sua execuo,
chamada outra funo (bsp_start) onde so inicializados o hardware e os perifricos
sem um driver dedicado. No driver do console, o autor implementa dois modos diferentes
para a comunicao serial via UART: por polling e por interrupo. O driver do clock
fornece uma base de tempo confivel para o kernel e sua implementao bastante simples,
contendo apenas duas funes: Clock_driver_support_initialize_hardware,
que programa o clock do ncleo do Blackfin, e Clock_driver_support_install_isr, que instala o tratador de interrupo para esse driver. O driver do timer implementado
por Schfer (2007) usado apenas para benchmarking e consiste em ler os ciclos do clock
do registrador CYCLES.
Schfer (2007) realiza, ainda, um benchmarking, por meio do qual constata que
a melhora de desempenho do cdigo nativo sobre o interpretado de quatro vezes. No
tocante ao tempo de desenvolvimento, o autor conclui que implementar o sistema com base
em um RTOS existente muito mais eficiente do que escrever todo o cdigo de interface
entre o software e o hardware.
O trabalho de Abadie (2008) apresenta uma metodologia de model-driven engineering, que permite a gerao automtica de cdigo a partir da criao de modelos
(abstraes) do sistema, utilizados para validao das funcionalidades e restries do projeto em suas fases iniciais. O autor pretende, com essa abordagem, aumentar a qualidade
e confiabilidade dos cdigos, prejudicadas pela crescente complexidade das aplicaes dos
sistemas embarcados atuais. Para alcanar seu objetivo, Abadie (2008) utiliza a linguagem
UML (Unified Modeling Language) e o software Rhapsody para gerar os prottipos dos
diversos componentes do computador de bordo do projeto ITASAT6 e realiza a adaptao
dessa ferramenta para o RTEMS, que o sistema operacional utilizado no satlite.
Para fazer o link do cdigo gerado pelo Rhapsody com o RTEMS, foi necessrio
modificar as funes da OSA (OS Abstraction layer) para se comunicarem com o sistema
operacional, uma vez que ela a nica parte do OXF (Object eXecution Framework)
que dependente do sistema operacional. Aps criado um arquivo da OSA especfico
para o RTEMS, foi necessrio link-lo aos demais arquivos fonte que compem o OXF e,
posteriormente, integrar o Rhapsody ao processo de montagem do executvel, alm de
permitir que o usurio possa configurar o RTEMS e iniciar a simulao da aplicao de
dentro do prprio Rhapsody (ABADIE, 2008).
Para validao do projeto desenvolvido, Abadie (2008) criou uma mquina de
estados e uma srie de testes, verificando um ganho significativo na velocidade de prototipao. Outra vantagem destacada pelo autor foi a simplificao do processo de design
proporcionada pela ferramenta visual de modelagem.
6
ITASAT um projeto, executado por equipes do ITA e da USP So Carlos, que visa desenvolver uma
srie de microsatlites universitrios (ABADIE, 2008).
50
No trabalho apresentado por Souza (2007), desenvolvida um metodologia para

realizar o porte do Linux em sistemas embarcados. A metologia proposta consiste, basicamente, na deteco das partes dos cdigos-fonte que devem ser modificadas para que o OS
seja portado para a nova plataforma, respeitando-se os seguintes passos (SOUZA, 2007,
p. 52):
N0 - Avaliar os requisitos iniciais do projeto usando um modelo de tomada de
deciso;
N1 - Identificar quais elementos de hardware no tem correspondente suporte de
software;
N2 - Identificar quais cdigos de software devem ser modificados;
N3 - Identificar as dependncias entre os componentes de software;
N4 - Identificar a precedncia de realizao das modificaes.
T0-0
T0-1
N0
N1
T1-0
T2-1
T2-0
T0-2
N2
T1-2
T2-3
T3-4
N3
N4
T4-3
T3-3
Figura 21 Grafo da metodologia em cinco passos. Fonte: Souza (2007, p. 53).
O mtodo apresentado por Souza (2007) rompe com a metodologia geral existente,
que, conforme apontado em seu trabalho, no dedica a ateno necessria para o porte do
sistema operacional, sendo uma das etapas menos sustentadas por processos e ferramentas.
Os passos descritos anteriormente no ocorrem de maneira linear, mas so colaborativos, seguindo a sequncia do grafo apresentado na Figura 21, em que as transies so
(SOUZA, 2007, p. 53):
T0-0 - Avaliao dos requisitos usando modelo de tomada de deciso;
T0-1 - Influncia dos elementos de hardware nos elementos de software;
T1-0 - Influncia dos elementos de hardware na reavaliao da rvore de deciso;
T2-0 - Influncia dos elementos de software a serem elaborados no total de trabalho
a ser realizado;
51
T0-2 - Influncia dos elementos de software na reavaliao da rvore de deciso;

T2-1 - Influncia dos elementos de software disponveis na definio do hardware;
T1-2 - Influncia dos elementos de hardware disponveis na definio do software;
T2-3 - Influncia dos novos elementos de software na matriz de dependncia;
T3-3 - Definio recursiva das dependncias de software;
T3-4 - Atualizao na lista de prioridade em funo das dependncias;
T4-3 - Influncia da lista de prioridades na lista de dependncias - Gerao da
Matriz de precedncia.
Pode-se notar que o processo iterativo, transitando entre os estados N0, N1
e N2 at que todo o mapeamento hardware-software seja completado. Vrias iteraes
so tambm executadas no estado N3, em que criada a matriz de dependncia entre
os componentes de software. A partir do processamento das informaes da matriz de
dependncia, obtm-se a matriz de precedncia, que consiste na ordenao das prioridades
para a realizao das modificaes.
O modelo de tomada de deciso proposto por Souza (2007) apresentado na
Figura 22 e ilustra de forma resumida todos os passos da metodologia apresentada.
2.6.2 Algoritmos de escalonamento e RTOS

Existem, atualmente, no mercado diversos RTOS comerciais, tais como o VxWorks,
utilizado em produtos das mais diversas reas de tecnologia, como aeroespacial, defesa,
automotiva, industrial, robtica, eletrnicos de consumo, medicina e networking. Entretanto,
o desenvolvimento do sistema operacional Linux, que vem ocorrendo recentemente, tem
gerado muito interesse na possibilidade de adaptar o Linux para o controle de tempo
real. Embora o recente desenvolvimento do kernel do Linux tenha providenciado solues
para vrios dos fatores que o impediam de funcionar como sistema operacional de tempo
real, tais como atribuio de prioridades e preempo, o Linux ainda no est apto
para aplicaes hard real-time, como requerido em controle de malha fechada em certos
dispositivos, como o tokamak7 . Neste caso, de fato, tempos de resposta imprevisveis
podem deteriorar a qualidade do controle, o que pode levar o sistema a instabilidades
catastrficas (BARBALACE et al., 2008).
Barbalace et al. (2008) fazem um estudo de como utilizar as extenses do Linux
Xenomai e RTAI para transform-lo em RTOS e fazem o porte de quatro sistemas
operacionais (VxWorks, Linux, Xenomai e RTAI) para uma plataforma com processador
PowerPC, comparando o desempenho dos quatro sistemas quanto latncia de interrupo
7
Tokamak o sistema de confinamento magntico mais desenvolvido e a base para o projeto de

futuros reatores de fuso nuclear (CULHAM CENTRE FOR FUSION ENERGY, 2012).
52
Figura 22 Um modelo de tomada de deciso para sistemas embarcados. Fonte: Souza (2007,
p. 55).
e reescalonamento e quanto ao delay de comunicao entre processos - IPC (Inter-Process

Communication). Os resultados obtidos mostraram que o kernel 2.6 do Linux aceitvel
para aplicaes hard real-time de pequenas dimenses e baixa criticidade. J o Xenomai
e o RTAI representam alternativas vlidas para o VxWorks em sistemas de controle de
tempo real, tais como o RFX-mod. Um ponto negativo apontado por Barbalace et al.
(2008) foi que os sistemas com RTAI e Xenomai so menos amigveis ao desenvolvedor, se
comparados com o VxWorks, uma vez que as tarefas de tempo real devem ser executadas
em modo kernel para atingir o desempenho desejado, impedindo o programador de utilizar
servios de sistema disponveis em modo usurio, o que dificulta a depurao.
Stangaciu, Micea e Cretu (2014) tambm propem a utilizao de uma extenso
para adaptar um RTOS open source (FreeRTOS) a fim de desenvolver tarefas hard real-time.
Para tanto, foi necessrio realizar a integrao do HARETICK (Hard Real-Time Compact
Kernel)8 , um ambiente de execuo hard real-time, com o sistema operacional de tempo
real, de forma a obter um sistema hbrido que apresentasse as vantagens do FreeRTOS, de
fcil utilizao, compacto e com capacidades de escalonamento, priorizao de tarefas e
8
HARETICK um kernel operacional de tempo real crtico, com suporte a multitasking, projetado
para sistemas embarcados, capaz de fornecer previsibilidade mxima para aplicaes hard real-time
(STANGACIU; MICEA; CRETU, 2014).
53
servios de interrupo, bem como as caractersticas de determinismo e previsibilidade

de um ambiente de execuo hard real-time. Verificou-se que a soluo proposta pode
melhorar a funcionalidade dos sistemas de controle, pois oferece suporte para a execuo
de tarefas crticas de tempo real sem jitter 9 e realiza o escalonamento e a execuo de
tarefas de maneira totalmente determinstica.
Jitter a mxima variao dos tempos de liberao das instncias de uma tarefa (FARINES;
FRAGA; OLIVEIRA, 2000, p. 14).
54
3 Desenvolvimento
Este captulo apresenta a metodologia de porte desenvolvida com base em um
estudo de um BSP existente e funcional, obtido com o auxlio do PEx (Processor Expert)1 ,
para o porte do FreeRTOS em uma plataforma ARM.
3.1 Estudo do BSP para porte do FreeRTOS em uma plataforma

ARM
Nesta seo, apresentado o estudo de um BSP existente e funcional utilizado
para realizar o porte do sistema operacional FreeRTOS em uma placa FRDM-KL25Z, que
uma plataforma de desenvolvimento baseada em processador ARM Cortex M0+.
Para realizar o estudo, foi necessrio instalar o KDS2 , juntamente com as extenses
do PEx e o KSDK. Os detalhes de instalao e configurao do ambiente so apresentados
no Apndice A.
A estrutura dos componentes criados pelo KSDK em um projeto qualquer
apresentada na Figura 23.
User Applications
Stacks and Middle Wares
OSA
Peripheral
Drivers
Hardware Abstraction Layer
CMSIS Core
Header Files
Board
Configuration
System
Services
SOC header, IP
extension header files
CMSIS
DSP
Hardware
Figura 23 Componentes de um projeto criado com o KSDK. Fonte: Learning. . . (2015).

1
O PEx uma ferramenta integrada ao KDS que auxilia na gerao de cdigo fonte a partir de
bibliotecas pr-programadas, incentivando a reutilizao de cdigo.
O KDS um IDE que fornece ferramentas para edio, compilao e depurao de projetos para
dispositivos Kinetis Cortex-M. baseado em Eclipse e utiliza as ferramentas GNU.
Captulo 3. Desenvolvimento
55
3.1.1 Estrutura de um projeto FreeRTOS bsico

Um kernel bsico do FreeRTOS composto, geralmente, por trs arquivos fonte
comuns a todos os portes de RTOS e um ou mais arquivos fonte especficos para o
microcontrolador, alm dos arquivos de cabealho (header files). Os arquivos comuns
a todos os portes, os quais encontram-se geralmente na pasta Source ou src so
(FREERTOS, 2016b):
tasks.c
queue.c
list.c
Caso o software utilize timer, ser necessrio incluir o arquivo timers.c e, caso
utilize a funcionalidade de corrotinas, deve-se incluir croutine.c.
Os arquivos fonte essenciais que dependem do compilador e da plataforma em que
sero embarcados so:
port.c
heap_x.c, onde x pode ser 1, 2, 3, 4 ou 5
Cada arquivo fonte tambm inclui um header file correspondente. Os arquivos header
encontram-se, geralmente, na pasta include. Outro arquivo de cabealho importante
o portmacro.h, que contm a definio de constantes e macros utilizadas no porte
do RTOS. Esse arquivo especfico para cada plataforma de hardware e, assim como o
arquivo port.c, localiza-se, na maioria dos casos, em uma pasta chamada portable
ou port (FREERTOS, 2016a). Dependendo do compilador e da plataforma, o projeto
pode conter tambm, nesse mesmo diretrio, um arquivo em linguagem de montagem
denominado portasm.S, que possui algumas definies de macros e funes de kernel
especficas para o hardware utilizado.
Outro arquivo importante, geralmente escrito em linguagem assembly, o vetor
de interrupes, o qual chamado toda vez que um dispositivo, como o timer, gera uma
interrupo, ou quando houver troca de contexto.
Todo projeto tambm possui um arquivo chamado FreeRTOSConfig.h, o qual
customiza o kernel do RTOS aplicao sendo desenvolvida. Como esse arquivo especfico
para o aplicativo e no para o RTOS, ele deve ser localizado nos diretrios do aplicativo.
O Processor Expert importa tambm do KSDK um arquivo chamado fsl_os_abstraction_free_rtos.c, que funciona como uma camada de abstrao do OS
(OSA) e fornece para o aplicativo funes de manipulao dos objetos do kernel, tais como
56
tarefas, semforos, mutexes, entre outros. Embora no faa parte do BSP e no tenha
relao direta com o porte do RTOS, esse arquivo ser estudado neste trabalho por conter
uma API completa que esconde do software aplicativo os detalhes de implementao do
RTOS, de forma que o cdigo da aplicao de usurio fique independente do sistema
operacional.
Os drivers de perifricos tambm so importados pelo PEx e fornecem ao aplicativo
as funes necessrias para a utilizao do dispositivo. Um conjunto de funes que
interagem diretamente com o hardware disponibilizado para os drivers, formando uma
camada de abstrao chamada HAL (Hardware Abstraction Layer). O escopo da HAL
fornecer o controle funcional, as configuraes e a implementao de operaes bsicas dos
perifricos (LEARNING. . . , 2015).
A Figura 24 mostra a estrutura do kernel bsico obtido pelo KDS ao se criar um
projeto utilizando o PEx.
3.1.2 Anlise dos arquivos responsveis pelo porte

Nesta seo, apresentada uma anlise resumida dos principais arquivos necessrios
para o porte do FreeRTOS na plataforma de desenvolvimento FRDM-KL25Z.
3.1.2.1 port.c
O arquivo port.c contm vrias definies de constantes, macros e funes
importantes para o porte do FreeRTOS, que permitem, por exemplo, a manipulao de
contadores de ticks e do NVIC (Nested Vectored Interrupt Controller), que o controlador
de interrupes da CPU.
As principais funes contidas nesse arquivo so:
a) pxPortInitialiseStack()
Inicializa um quadro de pilha (stack frame) como se tivesse sido criado por
uma interrupo para troca de contexto;
Salva na pilha os dados iniciais dos registradores PSR (Program Status
Register), PC (neste caso, o entry point da tarefa), LR (Link Register) e
R0 (parmetro da funo) e aloca espao para os demais registradores (R1 R12);
Retorna o ponteiro para o topo da pilha.
b) vPortInitTickTimer()
Configura a prioridade de interrupo do timer e habilita o disparo de
interrupes;
Inicializa o timer do contador de ticks para gerar interrupes periodicamente.
Figura 24 Estrutura do kernel em estudo.
57
58
c) vPortStartTickTimer()
Habilita o timer do contador de ticks.
d) vPortStopTickTimer()
Desabilita o timer do contador de ticks.
e) xPortStartScheduler()
a funo do RTOS que inicializa o escalonador;
Chama as funes que inicializam e habilitam o timer;
Chama a funo que inicia a primeira tarefa.
f) vPortEndScheduler()
Chama a funo que desabilita o timer;
Faz um salto retornando ao estado do processador anterior inicializao do
escalonador.
g) vPortEnterCritical()
Desabilita as interrupes e incrementa a contagem de sees crticas aninhadas.
h) vPortExitCritical()
Decrementa a contagem de sees crticas aninhadas;
Habilita as interrupes caso a contagem seja zerada.
i) vPortYieldFromISR()
Gera uma exceo PendSV para solicitar troca de contexto.
j) uxGetTickCounterValue()
Retorna o valor do contador de ticks.
k) vPortTickHandler() (ou SysTick_Handler() para o KSDK)
Incrementa o contador de ticks e solicita troca de contexto, caso necessrio;
SysTick uma exceo gerada pelo timer do sistema quando este zerado.
l) vPortStartFirstTask()
Funo implementada em assembly que inicia a primeira tarefa;
Seta o registrador MSP (Main Stack Pointer) com o incio da pilha;
Carrega o contexto da tarefa;
Habilita interrupes;
Faz uma chamada de sistema para iniciar a primeira tarefa.
m) vPortSVCHandler() (ou SVC_Handler() para o KSDK)
59
Funo tambm implementada em assembly, que restaura o contexto de uma

tarefa;
SVC (Supervisor Call) uma exceo disparada pela instruo svc, usada
por aplicativos para acessar funes do kernel ou drivers de dispositivos.
n) vPortPendSVHandler() (ou PendSV_Handler() para o KSDK)
Implementada em assembly, essa funo realiza uma troca de contexto,
salvando o contexto de uma tarefa em seu TCB e carregando o da prxima
tarefa a ser executada,
PendSV uma solicitao baseada em interrupo por um servio system
level.
3.1.2.2 portmacro.h
Esse arquivo contm definies especficas do porte, de forma a configurar o
FreeRTOS corretamente para o compilador e o hardware sendo utilizados. As principais
configuraes incluem:
a) Definies de tipo
b) Configuraes especficas de hardware, como:
portBYTE_ALIGNMENT: no caso da plataforma ARM, o valor 8, pois a
memria sempre alinhada a byte.
portSTACK_GROWTH: para um microcontrolador ARM, com crescimento
da pilha descendente, o valor -1.
portTICK_PERIOD_MS: configura o perodo entre os ticks em ms, baseado
na frequncia do clock.
c) Gerenciamento da seo crtica
d) Utilidades do escalonador
e) Otimizaes especficas da arquitetura
f) Funcionalidades de suprimir os ticks e economia de energia
g) Prottipos das funes implementadas em port.c
3.1.2.3 FreeRTOSConfig.h
O arquivo de configurao FreeRTOSConfig.h customiza o kernel do RTOS
aplicao em desenvolvimento. Nele esto contidas diversas definies de constantes e
macros, das quais, destacam-se algumas na Tabela 1.
60
Tabela 1 Valores das principais constates definidas em FreeRTOSConfig.h.

Nome
configCPU_CLK_HZ
configTICK_RATE_HZ
configMAX_PRIORITIES
configMINIMAL_STACK_SIZE
configTOTAL_HEAP_SIZE
configUSE_PREEMPTION
configUSE_MUTEXES
configUSE_TIMERS
configTIMER_TASK_PRIORITY
configCOMPILER
configPRIO_BITS
INCLUDE_*
Valor
48000000
200
8
200
10240
1
1
1
3
1
2
1
Significado
Frequncia do clock da CPU
Frequncia de interrupo do tick
Nmero mximo de nveis de prioridade
Tamanho mnimo da pilha
Dimenso do heap
Modo preemptivo
Uso de mutex
Uso de timers
Configura prioridade do timer
Compilador ARM GCC
2 bits / 4 nveis de prioridade
Inclui todas as funes API na compilao
3.1.2.4 Vetor de interrupo: startup_MKL25Z4.S

O vetor de interrupo implementado em um arquivo escrito em linguagem
assembly. Iniciando-se no endereo 0, apenas quatro valores so estritamente necessrios:
__StackTop: endereo do topo da pilha;
Reset_Handler: localizao da rotina de inicializao (reset);
NMI_Handler: localizao da rotina de tratamento de interrupo (ISR) da exceo
NMI (Non-Maskable Interrupt);
HardFault_Handler: localizao da ISR de hard fault.
Nesse mesmo arquivo, tambm so populadas, opcionalmente, as localizaes das
demais ISRs, tais como a SVC_Handler, PendSV_Handler, SysTick_Handler e as
rotinas de tratamento de interrupes externas.
Tambm encontra-se nesse arquivo a rotina de inicializao do sistema (Reset_Handler). Essa rotina define as primeiras instrues a serem executadas quando o sistema
energizado e consiste basicamente nos seguintes passos:
1. Desabilita as interrupes;
2. Chama a funo SystemInit, que inicializa o sistema e ser apresentada a seguir;
3. Faz a devida inicializao da memria RAM, copiando os dados necessrios da ROM;
4. Habilita as interrupes;
5. Chama a __libc_init_array, que faz a devida inicializao das sees da
memria;
61
6. Chama a funo __main, que responsvel por configurar a biblioteca C adequadamente e copiar cdigo/dados para os devidos locais em tempo de execuo. Essa
funo bastante especfica para a tool-chain e similar funo _start em GCC.
7. Transfere o controle ao aplicativo, chamando a funo main().
3.1.2.5 system_MKL25Z4.c
Esse arquivo, escrito em linguagem C, bastante especfico para o dispositivo e
fornece a configurao do clock do sistema. Possui apenas uma varivel global e duas
funes (ARM, 2015b):
SystemCoreClock - Varivel global que armazena o valor do clock do sistema;
SystemInit() - Inicializa o microcontrolador, configurando o oscilador e o PLL
(Phase-Locked Loop) para o clock do sistema desejado;
SystemCoreClockUpdate() - Atualiza o valor da varivel SystemCoreClock
com base nas configuraes dos registradores. Deve ser chamada toda vez que o clock
do sistema for alterado em tempo de execuo.
3.1.2.6 MKL25Z4.h
O arquivo MKL25Z4.h bastante extenso e possui todo o mapeamento de acesso aos
registradores dos perifricos suportados pelo microcontrolador e utilizados pelo aplicativo,
tais como: ADC (Analog-to-Digital Converter), CMP (comparador de alta velocidade), DAC
(Digital-to-Analog Converter), DMA, GPIO (General-Purpose Input/Output), I2 C (InterIntegrated Circuit Bus), NVIC, PORTx, RTC (Real-Time Clock), SPI, TPM (Timer/PWM
Module), UART, USB (Universal Serial Bus), entre outros. Esse arquivo especfico para
o microcontrolador e fornecido pelo fabricante ou desenvolvedores third party. Sua funo
basicamente mapear os registradores dos perifricos para seus respectivos endereos de
memria.
3.1.2.7 OSA: fsl_os_abstraction_free_rtos.c
A OSA a camada de abstrao do sistema operacional e possui uma srie de
funes que permitem a manipulao de objetos do kernel. A Tabela 2 apresenta as funes
contidas no arquivo fsl_os_abstraction_free_rtos.c e sua descrio resumida.
3.1.2.8 Outros arquivos fonte comuns
Os arquivos fonte que compem o kernel do FreeRTOS e so comuns a todos os
portes, independentemente da plataforma, compreendem:
62
Tabela 2 Funes que compem a OSA.

Objeto
Nome da funo
Descrio resumida
OSA_SemaCreate()
Cria um semforo
OSA_MemFree()
Concede um token do semforo, se disponvel, ou

coloca em espera por um tempo timeout, caso
contrrio
Tenta adquirir um semforo, ou incrementa, caso
no haja tarefa
Destri um semforo
Cria um mutex
Bloqueia o mutex, se estiver desbloqueado, ou coloca
em espera por um tempo timeout, caso contrrio
Desbloqueia o mutex
Destri um mutex
Cria um objeto de evento
Se o evento satisfaz a condio de espera, retorna
kStatus_OSA_Timeout; caso contrrio, timeout
ser usado para espera
Seta uma ou mais flags de um objeto de evento
Limpa uma ou mais flags de um objeto de evento
Obtm o status de flags de um evento
Destri um objeto de evento
Cria e inicializa uma tarefa
Destri uma tarefa
Quando uma tarefa chama esta funo, ela libera a
CPU e se coloca no final da lista ready
Obtm o bloco de controle da tarefa atual
Retorna a prioridade da tarefa
Configura a prioridade da tarefa
Cria uma fila de mensagens
Coloca uma mensagem na fila de mensagens
Obtm a mensagem da fila, ou colocada em espera
por um tempo timeout, caso a fila esteja vazia
Destri uma fila de mensagens
Aloca uma quantidade de memria em bytes
Aloca uma quantidade de memria em bytes e
inicializa com 0
Libera a memria previamente alocada
OSA_TimeDelay()
Cria um delay por n milissegundos
OSA_TimeGetMsec()
OSA_InstallIntHandler()
Obtm o tempo atual em milissegundos

Instala tratador de interrupo
Essa funo utilizada para garantir que uma seo
de cdigo no sofra preempo
Libera uma seo crtica
Primeira funo a ser chamada pela main(); usada
para configurar os servios bsicos
Essa funo usada para iniciar o escalonador do
RTOS
OSA_SemaWait()
Semforo
OSA_SemaPost()
OSA_SemaDestroy()
OSA_MutexCreate()
Mutex
OSA_MutexLock()
OSA_MutexUnlock()
OSA_MutexDestroy()
OSA_EventCreate()
OSA_EventWait()
Evento
Tarefa
Fila de
mensagens
OSA_EventSet()
OSA_EventClear()
OSA_EventGetFlags()
OSA_EventDestroy()
OSA_TaskCreate()
OSA_TaskDestroy()
OSA_TaskYield()
OSA_TaskGetHandler()
OSA_TaskGetPriority()
OSA_TaskSetPriority()
OSA_MsgQCreate()
OSA_MsgQPut()
OSA_MsgQGet()
OSA_MsgQDestroy()
OSA_MemAlloc()
Memria
Diversos
OSA_MemAllocZero()
OSA_EnterCritical()
OSA_ExitCritical()
OSA_Init()
OSA_Start()
63
tasks.c: Macros e funes que inicializam e gerenciam as tarefas e atividades

relacionadas a elas, como escalonamento, troca de contexto, prioridades, etc.;
queue.c: Macros e funes que criam e gerenciam as filas;
list.c: Esse arquivo contm apenas cinco funes, as quais inicializam uma lista,
criam, inserem e removem um item da lista;
timers.c: Contm definies de tipo e funes que criam e gerenciam timers;
event_groups.c: Algumas macros e funes que criam e manipulam grupos de
eventos;
croutine.c: Contm macros e funes que gerenciam corrotinas;
heap_x.c, onde x pode ser 1, 2, 3, 4, ou 5: Gerenciam alocao dinmica de
memria heap em cinco esquemas diferentes.
As funes e declaraes contidas nesses arquivos so utilizadas pelas funes da
OSA para manipular os objetos do kernel, fornecendo ao programa de usurio um nvel
maior de abstrao do hardware.
3.1.3 Sequncia de inicializao do FreeRTOS

Segundo FreeRTOS (2016b), uma aplicao do FreeRTOS inicializa e executa
exatamente como uma aplicao bare metal at que a funo vTaskStartScheduler()
chamada, o que acontece normalmente dentro da funo main() ou de funes aninhadas
a ela. Portanto, o RTOS passa a controlar a sequncia de execuo apenas aps a chamada
dessa funo.
A Figura 25 mostra um diagrama de sequncia que ilustra, de forma simplificada,
a inicializao do FreeRTOS, at inicializar o escalonador das tarefas.
Pode-se observar que a sequncia de inicializao segue o mesmo padro apresentado
na Figura 20, comeando pelo vetor de inicializao; em seguida, o hardware mnimo
(clock, PLL, memria de dados) inicializado e, posteriormente, os demais componentes de
hardware. A funo Components_Init(), contida no arquivo Cpu.c, inicializa todos
os componentes adicionados ao sistema por meio do Processor Expert.
Aps a inicializao do hardware, inicializado o RTOS e so criadas as tarefas do
sistema operacional. Por fim, o controle do fluxo de execuo passa para o escalonador,
que comea a gerenciar a execuo das tarefas do aplicativo.
64
S)1S))c)))S1SScS1
SSSSSSSSSSSSSSSSS
ScSS)cSSSSSSSSSc
SSSSSSSSc
cS))Sc
c)S)c)S))c))S)))SSc
)SS))SS)S)))SSc
_S)ScSSS)SSSScS)c)S_S))S
SScSSc
cSSSc
_S))SSScSS)
SS)))SSsS c
SSSsSSc
))S)SS)S))))S))
ScSS)c)))S))
)))SS)SSSS)SS))
cS))))
c)S)c)S))c))S)))S))
)SS))SS)S)))S))
)S)S)))S))
sSSSSSSS)S)SSScc)SS
c))ScccSc)))SSS)))S))
cccSc)))SSS)))S))
c))S)))SSS))))))
SS)))SSsS)))S))
)S)S)SSscS)SS)))
))SSs))))S)ccS)SS)))
sSSSSSSS)S)SSScc)SSrcSr)SScS
sSSSSSSS)S)SSScc)SSrcSr)SScS
)S)SSSSSS))
c)SSsSSSSSSc)))S))S))
sSSSSSSS)S)SSScc)SS
)))))))))))
Figura 25 Diagrama de sequncia ilustrando a inicializao do FreeRTOS.
3.1.4 Drivers de dispositivos

Uma parte importante do porte do sistema so os drivers dos perifricos de hardware,
embora no sejam utilizados estritamente pelo RTOS. Eles fornecem um conjunto de
funes que permitem ao desenvolvedor configurar os dispositivos com um nvel maior de
abstrao, dispensando um conhecimento especfico dos detalhes de implementao do
hardware.
Quando um componente adicionado ao projeto utilizando-se o PEx, um arquivo
de cdigo fonte includo na pasta drivers. Esse arquivo contm as funes com maior
nvel de abstrao, permitindo ao programa de usurio lidar com as funcionalidades do
dispositivo, como ligar, desligar, calibrar, realizar a leitura, etc. Outro arquivo adicionado
ao diretrio hal, que corresponde camada de abstrao do hardware, e fornece s
funes contidas nos drivers uma srie de definies e mtodos que lidam diretamente com
o hardware e, portanto, so bastante especficos para a plataforma sendo utilizada.
cS1)r1rc_r1
Neste projeto, foi adicionado o componente TSI (Touch Sensing Input), que
o slider de toque capacitivo. A Figura 26a apresenta a estrutura de diretrios com os
arquivos relacionados ao driver do TSI em destaque. As funes contidas nesses arquivos
podem ser visualizadas na janela de componentes, ilustrada na Figura 26b.
(a) Estrutura de diretrios.
65
(b) Componentes do sistema.
Figura 26 Drivers do dispositivo sensvel ao toque includo no projeto.
3.2 Metodologia para porte de um RTOS em uma plataforma de

hardware
Realizar o porte de um RTOS pela primeira vez em uma nova plataforma de
hardware no uma tarefa trivial. Essa atividade exige que o desenvolvedor tenha um
bom conhecimento do kernel do RTOS a ser portado, do microprocessador e seu conjunto
de instrues e da plataforma de hardware.
A metodologia desenvolvida neste trabalho de pesquisa e apresentada a seguir visa
fornecer os passos, em aspecto geral, para a realizao do porte de um RTOS qualquer
em uma plataforma de hardware, sem considerar suas peculiaridades, embora cada porte
66
seja nico e fortemente dependente do processador, do kernel e das ferramentas utilizadas

(FREERTOS, 2016a). A Figura 27 mostra o fluxograma do processo de porte proposto.
Figura 27 Fluxograma do processo de porte segundo a metodologia proposta.
67
Antes de iniciar o porte de um RTOS para uma plataforma, deve-se verificar se

j existe um porte especfico para essa combinao RTOS-hardware. Caso exista e no
seja necessria nenhuma modificao, o processo segue para a configurao das tarefas e
do cdigo de usurio (ID 7 da Figura 27). O foco deste trabalho ser o caso em que no
existe um BSP pronto para utilizao, prosseguindo para o processo ID 1 do fluxograma.
Muitos dos RTOSs j foram portados para diferentes plataformas de hardware. O
passo ID 1 consiste em verificar se existe um porte realizado para alguma plataforma da
mesma famlia ou similar. Caso exista, poupa-se tempo de desenvolvimento aproveitando-se
boa parte do cdigo j desenvolvido. Os passos ID 11, 12, 13 e 14 somente sero necessrios
caso o porte venha a ser realizado em uma plataforma totalmente nova e sero explicados
mais adiante.
O processo ID 2 da metodologia consiste em estudar a organizao do cdigo fonte
de um porte similar. Em geral, recomenda-se que os cdigos fonte do kernel e do BSP
sejam divididos em dois diretrios principais: um, contendo os arquivos dependentes do
porte e outro, os independentes (FREERTOS, 2016a).
Essa poro de cdigo dependente do target (ID 3) pode ser classificado em uma
das seguintes categorias (FREERTOS, 2016d):
especfico a um microcontrolador;
especfico a um conjunto de ferramentas de desenvolvimento (tool-chain) - compiler,
debugger, etc;
especfico a uma plataforma de hardware.
Esses arquivos especficos ao target so responsveis pela configurao do clock, do
timer gerador de ticks (interrupes peridicas para o escalonador), do controlador de
interrupes, da memria e pela troca de contexto.
A parte do kernel independente do porte (ID 4) est relacionada essencialmente
manipulao de tarefas, filas de mensagens, mutexes, listas e corrotinas.
O passo ID 5 consiste em selecionar e configurar o ambiente de desenvolvimento
que ser utilizado no porte, uma vez que o cdigo fonte tambm depende das ferramentas
que compem a tool-chain, tais como o compilador, o assembler e o debugger.
O processo ID 6, detalhado na Figura 28, o passo central desta metodologia, o
qual consiste em realizar as alteraes nos cdigos relacionados ao hardware. Esse passo
pode ser dividido em trs blocos:
a) Inicializao do hardware: compreende os cdigos que so essenciais para a
inicializao do sistema, porm so independentes do RTOS sendo portado, tais
como o vetor de inicializao e as funes de configurao do clock e PLL.
68
b) Porte do RTOS: so os arquivos de configurao que adaptam o RTOS para ser

executado na plataforma de hardware especfica. Esses arquivos constituem o
bloco identificado como OS BSP na Figura 19, que a parte essencial para o
porte do sistema operacional.
c) Drivers de dispositivos: a parte do BSP adicional, necessria para a utilizao
dos perifricos pelo aplicativo. Esse bloco no tem relao direta com o porte
do RTOS.
Figura 28 Desdobramento do processo ID 6 da metodologia apresentada.
69
Muitos microprocessadores possuem o cdigo em assembly do vetor de inicializao

disponvel para download, fornecido pelos prprios fabricantes. No entanto, caso seja
necessrio implement-lo, deve-se recorrer documentao do microprocessador, que
possui todas as informaes necessrias para sua configurao, tais como:
modos de operao do processador;
configurao da pilha;
mapa de registadores;
mapa de memria e endianness;
mapa do vetor de inicializao;
gerenciamento de energia;
conjunto de instrues;
perifricos do processador, como o controlador de interrupes e o timer do sistema.
Outro documento essencial para o porte o datasheet ou manual de referncia
do microcontrolador, o qual contm todas as informaes necessrias para configurar o
hardware, incluindo o clock, o controlador de interrupo, os timers e demais perifricos.
Entre essas informaes, destacam-se o endereo dos registradores, os bits de configurao e
os modos de operao de cada dispositivo. Um arquivo de cabealho contendo o mapeamento
dos registradores dos perifricos geralmente fornecido pelo fabricante do microcontrolador
ou desenvolvedores third party.
Para realizar o porte do sistema operacional, necessrio ainda consultar o manual
de porte e a documentao fornecida pelos desenvolvedores do RTOS, que servem de guia
para a implementao da interface completa para que o sistema operacional se comunique
adequadamente com o hardware. Em geral, essa interface composta por uma lista de
constantes que devem ser definidas e um conjunto de funes que devem ser implementadas.
Os passos subsequentes da metodologia so necessrios para verificar e validar
o porte realizado, apesar de no fazerem parte do processo de porte propriamente dito.
O passo ID 7, expandido na Figura 29, consiste em implementar um cdigo mnimo de
aplicativo e a funo main() para verificar se o porte foi realizado com sucesso.
O passo ID 8 equivale gerao da imagem executvel e carregamento no target.
Em caso de erro de compilao, deve-se realizar as correes necessrias (ID 9) e recompilar
o cdigo, em um processo iterativo, at que se obtenha a imagem executvel com xito.
Por fim, deve-se testar e depurar o programa (ID 10) para verificar se o sistema
atende aos requisitos funcionais e, principalmente, temporais, validando o processo de
porte do RTOS. Recomenda-se fortemente que esse processo seja iterativo e implementado
gradativamente, isto , deve-se compilar e testar o programa inicialmente com uma estrutura
70
Figura 29 Desdobramento do processo ID 7 da metodologia apresentada.
bsica para seu funcionamento e, ento, adicionar, de forma gradual, as funcionalidades

do RTOS no programa de usurio.
Como mencionado anteriormente, os passos ID 11 a 14 s sero necessrios nos
casos em que no existe nenhum porte realizado para plataformas semelhantes. O passo ID
11 consiste em copiar o cdigo que no depende do target, como os arquivos do kernel que
manipulam as tarefas, listas, filas de mensagem e corrotinas, em um diretrio separado.
Posteriormente, deve-se estudar o cdigo de outro porte realizado, bem como o guia de
porte do RTOS, para entender a parte do cdigo que dever ser implementada. Aps
a escolha e a configurao do ambiente de desenvolvimento, deve-se criar os arquivos
dependentes do porte em outro diretrio, definindo as constantes e implementando as
funes requeridas pelo RTOS. Os arquivos especficos para o target que so independentes
do sistema operacional, tais como o reset vector e o cdigo de inicializao do hardware
podem ser implementados da mesma forma que no primeiro caso, como explicado no passo
ID 6.
Ao final do processo, uma srie de testes deve ser realizada para assegurar-se de
que o sistema satisfaz todos os requisitos funcionais e temporais, validando assim o porte
realizado.
71
4 Experimentos
Neste captulo, apresentado o porte do FreeRTOS na plataforma de desenvolvimento FRDM-KL25Z realizado conforme a metodologia proposta neste trabalho de
pesquisa, para fins de verificao e validao.
4.1 Critrios para a definio do RTOS utilizado

Atualmente h centenas de produtos comerciais que podem ser categorizados como
sistemas operacionais de tempo real, desde kernels muito pequenos com reduzido volume
de memria, at grandes sistemas para aplicaes de tempo real bastante complexas
(BUTTAZZO, 2011). Portanto, os seguintes critrios foram definidos para a escolha do
RTOS utilizado neste experimento:
Ser open source;
Possuir volume de memria reduzido (< 50kB);
Ser robusto;
Possuir documentao em domnio pblico.
Foram considerados, neste trabalho, alguns dos RTOSs mais comumente utilizados
em aplicaes gerais de tempo real, tais como o VxWorks, o FreeRTOS, o OpenRTOS,
o RTEMS e o RTLinux. Dos RTOSs considerados, apenas o FreeRTOS, o RTEMS e o
RTLinux so open source, satisfazendo o primeiro critrio de seleo.
Apesar de os trs RTOSs open source selecionados serem altamente escalveis, o
FreeRTOS o que apresenta menor requisito de memria, com aproximadamente 5 a 10kB
de Flash/ROM e 250 bytes de RAM (FREERTOS, 2016c), seguido do RTEMS, que possui
um volume de memria da ordem de centenas de kilobytes (DRFLER, 2007). O RTLinux,
por ser o mais complexo dos RTOSs escolhidos, possui um volume de memria da ordem
de alguns megabytes (ANDERSSON; ANDERSSON, 2005), o que o torna invivel para
esta aplicao.
Segundo Sheridan-Barbian (2015), tanto o FreeRTOS quanto o RTEMS possuem
boa documentao, so de fcil utilizao e so robustos e comprovadamente qualificados
at para aplicaes espaciais. Como o FreeRTOS possui o menor volume de memria entre
os RTOSs considerados e projetado para alta portabilidade, este foi o sistema operacional
selecionado para o experimento realizado no presente trabalho.
Captulo 4. Experimentos
72
4.2 Critrios para a definio da plataforma de hardware utilizada

Para realizar o experimento, foi necessrio escolher uma plataforma de hardware
para onde seria portado o FreeRTOS. Essa escolha foi baseada nos seguintes critrios:
Processador;
Memria;
Perifricos;
Preo.
Para fins de comparao, foram consideradas as seguintes plataformas de hardware,
que se enquadram na mesma faixa de preo (em torno de US$15):
FRDM-KL25Z - baseada em microcontrolador ARM;
Start USB Board - que utiliza um microcontrolador PIC18F2550;
Arduino UNO R3 - que possui o microcontrolador ATmega328P.
Das plataformas consideradas, a plataforma de desenvolvimento da Freescale FRDMKL25Z supera as demais em todos os quesitos, possuindo mais opes de clock para o
processador, memrias FLASH e RAM maiores e um nmero muito maior de perifricos e
dispositivos onboard. Alm das caractersticas mencionadas, a plataforma possui um microcontrolador da srie Kinetis L em um pacote LQFP (Low-profile Quad Flat Package) de
80 pinos (MKL25Z128VLK4), baseada em ARM, que uma famlia de microcontroladores
muito utilizada tanto na indstria como na academia. Logo, a plataforma selecionada
para o experimento foi a FRDM-KL25Z, que apresenta ainda as seguintes especificaes
(FREESCALE SEMICONDUCTOR, 2012a):
a) Processador: ARM Cortex-M0+ de 32 bits
Suporta at 48MHz de operao
Porta de acesso de I/O rpida (single-cycle)
Projetado para ser o mais eficiente em consumo de energia da famlia ARM
Core pipeline de dois estgios
Consumo de energia: 9,8W/MHz
Debug: JTAG (Join Test Action Group) opcional ou SWD (Serial-Wire
Debug) com at 4 breakpoints e 2 watchpoints
56 instrues
Arquitetura ARMv6-M
Arquitetura de memria Von Neumann (dados e instrues compartilham
um barramento)
73
b) Memria
128kB Flash
16kB SRAM (Static Random Access Memory)
c) Sistema
Controlador DMA
COP (Computer Operating Properly) watchdog timer
d) Clocks
Mdulo de gerao de clock com FLL (Frequency-Locked Loop) e PLL para o
sistema e a CPU
Clocks internos de referncia de 4MHz e 32 kHz
Oscilador do sistema com suporte para cristal externo ou ressonador
Oscilador RC de baixo-consumo de 1kHz para o RTC e o COP watchdog
e) Timers
Um mdulo Timer/PWM de 6 canais
Dois mdulos Timer/PWM de 2 canais
Timer de interrupo peridica - PIT (Periodic Interrupt Timer) - de 2 canais
RTC
Timer de baixo-consumo - LPT (Low-Power Timer)
System tick timer
f) Perifricos
USB (Host/Device)
SPI (x2)
I2 C (x2)
UART (x3)
ADC (16 bit)
DAC (12 bit)
Sensor de toque capacitivo
GPIO (x66)
Acelermetro de 3 eixos
LED RGB
g) Alimentao
Conectores USB (x2)
Bateria tipo moeda
Fontes externas
74
A FRDM-KL25Z possui tambm uma interface de depurao OpenSDA (Openstandard Serial and Debug Adapter) com mltiplas aplicaes, incluindo:
programao da memria Flash por dispositivo de armazenamento em massa;
interface de debug P&E, que possibilita a depurao com controle de execuo e
compatibilidade com as ferramentas do IDE;
interface CMSIS-DAP: novo padro ARM para interface de depurao embarcada;
aplicao data logging.
Um diagrama de blocos simplificado ilustrado na Figura 30a e as principais
caractersticas da plataforma utilizada esto destacadas na Figura 30b.
(a) Diagrama de blocos.
(b) Principais elementos.
Figura 30 Plataforma FRDM-KL25Z. Fonte: Freescale Semiconductor (2012a, p. 4-5).
Outro ponto importante a ser considerado se o volume de memria do RTOS

compatvel com a capacidade do microcontrolador. Segundo FreeRTOS (2016c), um porte
bsico do FreeRTOS requer de 5 a 10kB de memria Flash e aproximadamente 250 bytes
de RAM. Como a plataforma escolhida possui 128kB Flash e 16kB SRAM, possvel
realizar o porte com uma grande quantidade de memria disponvel para a aplicao e a
criao de tarefas, filas de mensagem e outros objetos do kernel.
4.3 Aplicao da metodologia desenvolvida na plataforma de hardware escolhida

Para validao da metodologia proposta, foi realizado o porte do sistema operacional
e de um programa aplicativo bsico capaz de testar algumas funcionalidades do RTOS,
tais como temporizao, escalonamento de tarefas e bloqueio de recursos. O diagrama de
requisitos do sistema ilustrado na Figura 31.
75
eII 2eIeIe
o eeeeIe e II e11
i eieI i eiie
ssssssssssssssssssssss
eeee
eeee
eeee
eeeeeeeee
eeeeeeee o
eeeer e ee
1ee1ee11
1ee1ee12
1ee1ee13
e e eee ee ee e
eeee eeeee e ee e
eee e eeee e
eeeee
...
e e eee ee ee e
eeee eee o e e
ee eeee. e eeee e
eeeee ...
e e eee ee eee
e
eee e ee eeee e
ee
e e e e
e eeee e ee
e e e e
e e ee ee .
Figura 31 Diagrama de requisitos do sistema.
Para atender aos requisitos definidos para o sistema, no essencial a utilizao

de um RTOS, visto que a implementao pode ser feita com base no executivo cclico
cooperativo. Entretanto, o RTOS apresenta as vantagens de facilitar o gerenciamento
de recursos compartilhados e temporizao, em detrimento de um overhead de troca de
contexto e um maior consumo de memria. Como apontado por Locke (1992), a utilizao
de um RTOS indicada para todas as aplicaes crticas de tempo real, desde que no haja
restries de jitter para as tarefas, uma vez que este propiciado devido s preempes
ocasionadas por tarefas de maior prioridade. Portanto, justificada a utilizao de um
RTOS para este experimento, visando validar a metodologia de porte desenvolvida.
Segundo o fluxograma apresentado na Figura 27, o primeiro passo consiste em
identificar o cdigo fonte de um porte anterior. Apesar de o porte do FreeRTOS para a
plataforma FRDM-KL25Z j ter sido realizado e o cdigo estar disponvel em domnio
pblico, optou-se por implementar um porte separado para validar a metodologia proposta.
Os passos ID 1 e 2 foram apresentados na seo 3.1, onde feito o estudo do cdigo
obtido no porte utilizando-se o PEx. Para organizar o cdigo fonte do RTOS conforme a
metodologia, foi consultado o guia de porte do FreeRTOS (FREERTOS, 2016a), o qual
informa a estrutura de diretrios e a organizao do cdigo fonte do sistema operacional.
Primeiramente, foi feito o download dos arquivos fonte do FreeRTOS a partir de seu
site oficial (<http://www.freertos.org>) e, em seguida, organizou-se o cdigo da maneira
apresentada na Figura 32, a qual mostra o diagrama de pacotes utilizado na modelagem
do programa implementado no experimento.
1 iee1e e1
Conforme os passos ID 3 e 4 da metodologia, o cdigo fonte do FreeRTOS foi

dividido em dois diretrios separados. No diretrio portable foram colocados os arquivos
que dependem do porte, os quais ainda foram subdivididos nas pastas CortexM0p_GCC
e MemMang. Na primeira pasta foram colocados os arquivos port.c e portmacro.h,
que dependem do processador e do compilador, e na segunda, foi copiado o arquivo que
76
IsIIIIIISsnennInIssICsnssnIInIss
nsnnsiISnngnIisn
sssssssssssssssssss
nnnnnnnnnnn
snnsnsnCCnss
snnnssss
snssnss
snnnssss
snssnss
sngs
sngs
sngs
SsssSSSs
ssn
nnnnsss
nnsnnens
CnsnsCCCnCCCC
CsgCnng
Figura 32 Diagrama de pacotes implementados.
gerencia a memria heap. O FreeRTOS fornece cinco implementaes diferentes de alocao

de memria, das quais o heap_1.c a mais simples. Logo, como o programa no requer
que uma tarefa, fila ou semforo seja deletado, foi utilizado o arquivo heap_1.c. No
outro diretrio (src) foram colocados os arquivos do kernel que no so especficos ao
porte realizado, tais como tasks.c, list.c e queue.c.
Aps a organizao dos arquivos fonte do kernel, foi realizada a configurao
do ambiente de desenvolvimento KDS. Um novo projeto do Processor Expert, chamado
de tcc_blink, foi criado para a plataforma FRDM-KL25Z, porm o KSDK no foi
utilizado para a gerao automtica de cdigo. Dessa forma, o projeto importou apenas o
makefile, os arquivos de configurao do linker e do debugger e os arquivos especficos
ao microcontrolador, fornecidos pela prpria NXP, fabricante da plataforma. Os arquivos
1ngsI1In1I1o projeto inicialmente criado so apresentados na Figura 33.
que compem
Os seguintes arquivos de cabealho so especficos para a famlia do processador
utilizado e contm uma srie de definies de macros e funes para diferentes compiladores:
core_cm0plus.h: Camada de acesso aos perifricos do processador
77
Figura 33 Estrutura do projeto inicial.
core_cmFunc.h: Funes de acesso aos registradores do processador

core_cmInstr.h: Interface de instrues do processador
MKL25Z4.h: Camada de acesso aos perifricos do microcontrolador
Esses arquivos so fornecidos pela NXP juntamente com o KSDK para dar suporte
plataforma FRDM-KL25Z e tambm podem ser encontrados em outros sites para download.
O objetivo desse cdigo fornecer uma interface para os desenvolvedores das camadas
mais altas do software utilizarem o hardware com um nvel maior de abstrao, sem
se preocuparem com as peculiaridades do hardware e dos compiladores. Neste trabalho,
sero utilizados os arquivos de cabealho fornecidos para efeito de simplificao, uma
vez que so facilmente encontrados mesmo para outras plataformas e podem ainda ser
escritos com base simplesmente na documentao do microprocessador (ARM, 2012) e do
microcontrolador (FREESCALE SEMICONDUCTOR, 2012b).
Os arquivos contidos no diretrio Startup_Code, tambm importados automaticamente no projeto, correspondem ao vetor de inicializao startup_MKL25Z4.S, ao
arquivo de inicializao do sistema system_MKL25Z4.c e seu respectivo header. Esses
arquivos so definidos no padro CMSIS-CORE1 . Os fabricantes de chips Cortex-M fornecem uma implementao bsica desses arquivos, que configuram a funcionalidade mnima
requerida para o desenvolvimento de software nessas plataformas. O arquivo em linguagem
de montagem contm o vetor de interrupo, o cdigo para inicializao da pilha e do
heap e a rotina de inicializao (reset handler). O outro arquivo bastante especfico ao
hardware utilizado e contm a configurao do clock do sistema, como apresentado na
subseo 3.1.2.5 (ARM, 2011).
1
CMSIS (Cortex Microcontroller Software Interface Standard) uma norma que padroniza o desenvolvimento para dispositivos ARM Cortex-M, de forma a facilitar o trabalho de desenvolvedores de
software e fabricantes de plataformas e ferramentas.
78
A tool-chain (ID 5) utilizada para gerao da imagem executvel foi a arm-noneeabi, que gera cdigo para arquitetura ARM, no possui distribuidor, no especfica
para nenhum sistema operacional e atende ao padro ARM EABI (Embedded-Application
Binary Interface) (DUTTA, 2012).
O prximo passo da metodologia (ID 6), expandido na Figura 28, realizar as
alteraes nos cdigos relacionados ao hardware. Como o vetor de inicializao (ID 6.a)
dependente apenas da plataforma de hardware e no do RTOS sendo portado e j
foi fornecido pelo fabricante, no foi necessrio implement-lo, nem efetuar nenhuma
alterao.
Como mencionado anteriormente, a configurao do clock do sistema (ID 6.b)
implementada no arquivo system_MKL25Z4.c, o qual no necessita de modificaes
pelo mesmo motivo do item ID 6.a. Para esta aplicao, foi utilizado o mdulo MCG
(Multipurpose Clock Generator) e selecionado o modo de operao PEE (PLL Engaged
External), que usa um cristal externo de 8 MHz e um PLL para alcanar a frequncia de
48 MHz de alta preciso (ARM, 2012). O modo de operao, com servio de watchdog
desabilitado, foi configurado no arquivo de cabealho system_MKL25Z4.h, onde foram
definidas duas constantes conforme o Quadro 1.
1
2
3
4
5
6
7
8
9
/* Disable watchdog service */

#ifndef DISABLE_WDOG
#define DISABLE_WDOG 1
#endif
/* Index of selected clock configuration */
#ifndef CLOCK_SETUP
#define CLOCK_SETUP
4
#endif
Quadro 1 Constantes definidas no arquivo system_MKL25Z4.h.
O bloco seguinte da metodologia proposta consiste na configurao do RTOS para

rodar na plataforma de hardware escolhida. A configurao especfica da arquitetura (ID
6.c) foi feita no arquivo portmacro.h, onde foram definidas as constantes para configurar
a direo de crescimento da pilha e alinhamento de memria, bem como uma macro para
o clculo do perodo das interrupes com base na frequncia do SysTick (Quadro 2). As
informaes especficas da arquitetura foram extradas de ARM (2012).
1
2
3
4
/* Architecture specifics. */
#define portSTACK_GROWTH
#define portTICK_PERIOD_MS
#define portBYTE_ALIGNMENT
( -1 )
( ( TickType_t ) 1000 / configTICK_RATE_HZ )
8
Quadro 2 Constantes definidas no arquivo portmacro.h.
79
No arquivo FreeRTOSConfig.h foram definidas as constantes que customizam o

FreeRTOS para a aplicao especfica (ID 6.d), conforme o Quadro 3. Para a implementao
desse cdigo, foi utilizado como referncia o manual do FreeRTOS (BARRY, 2005).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/*----------------------------------------------------------* Application specific definitions.

*
* These definitions should be adjusted for your particular hardware and
* application requirements.
*
* THESE PARAMETERS ARE DESCRIBED WITHIN THE 'CONFIGURATION' SECTION OF THE
* FreeRTOS API DOCUMENTATION AVAILABLE ON THE FreeRTOS.org WEB SITE.
*
* See http://www.freertos.org/a00110.html.
*----------------------------------------------------------*/
#define configUSE_PREEMPTION
1
#define configUSE_IDLE_HOOK
0
#define configUSE_TICK_HOOK
0
#define configCPU_CLOCK_HZ
( SystemCoreClock )
#define configTICK_RATE_HZ
( ( TickType_t ) 200 )
#define configMAX_PRIORITIES
( 2 )
#define configMINIMAL_STACK_SIZE
( ( unsigned short ) 200 )
#define configTOTAL_HEAP_SIZE
( ( size_t ) ( 8192 ) )
#define configMAX_TASK_NAME_LEN
( 6 )
#define configUSE_TRACE_FACILITY
0
#define configUSE_16_BIT_TICKS
1
#define configIDLE_SHOULD_YIELD
1
#define configUSE_MUTEXES
1
#define configQUEUE_REGISTRY_SIZE
8
#define configCHECK_FOR_STACK_OVERFLOW 0
#define configUSE_RECURSIVE_MUTEXES
0
#define configUSE_MALLOC_FAILED_HOOK
0
#define configUSE_APPLICATION_TASK_TAG 0
#define configUSE_COUNTING_SEMAPHORES
1
#define configGENERATE_RUN_TIME_STATS
0
#define configUSE_QUEUE_SETS
0
/* Co-routine definitions. */
#define configUSE_CO_ROUTINES
0
#define configMAX_CO_ROUTINE_PRIORITIES ( 2 )
/* Software timer definitions. */
#define configUSE_TIMERS
#define configTIMER_TASK_PRIORITY
#define configTIMER_QUEUE_LENGTH
#define configTIMER_TASK_STACK_DEPTH
0
( 1 )
5
( 80 )
/* Set the following definitions to 1 to include the API function, or zero

to exclude the API function. */
#define INCLUDE_vTaskPrioritySet
1
#define INCLUDE_uxTaskPriorityGet
1
#define INCLUDE_vTaskDelete
1
#define INCLUDE_vTaskCleanUpResources
1
#define INCLUDE_vTaskSuspend
1
#define INCLUDE_vTaskDelayUntil
1
#define INCLUDE_vTaskDelay
1
#define INCLUDE_eTaskGetState
1
Quadro 3 Constantes definidas no arquivo FreeRTOSConfig.h.
Os passos ID 6.e a 6.g foram implementados no arquivo port.c (seo B.1), o

qual contm as funes necessrias para que o RTOS execute na plataforma de hardware
utilizada. Para realizar essa implementao, foi consultado o guia de usurio para pro-
80
cessadores Cortex-M0+ (ARM, 2012). Configurar o controlador de interrupo (ID 6.e)

compreende:
a) a configurao das prioridades de cada evento:
realizada na funo xPortStartScheduler();
b) a implementao das ISRs:
os dois tipos de interrupo utilizados neste programa so a do SysTick, que
gera interrupes peridicas a partir do timer, e a PendSV, que dispara uma
chamada de sistema para que seja realizada a troca de contexto. As rotinas
de tratamento dessas interrupes foram implementadas, respectivamente,
nas funes xPortSysTickHandler() e xPortPendSVHandler();
c) a ativao dos bits que habilitam as interrupes:
a interrupo do SysTick habilitada na funo prvSetupTimerInterrupt() e a PendSV no possui um bit de controle para habilitar/desabilitar
a interrupo.
O timer SysTick (ID 6.f) configurado e inicializado na funo prvSetupTimerInterrupt(). As demais funes implementadas no arquivo port.c so responsveis
pelas seguintes atividades (ID 6.g):
gerenciamento da seo crtica: vPortEnterCritical() e vPortExitCritical();
troca de contexto: implementada na ISR PendSV_Handler() e chamada a partir
de excees geradas pelas funes vPortYield() e SysTick_Handler();
inicializao da pilha: pxPortInitialiseStack();
inicializao do TCB: vPortStartFirstTask();
inicializao do escalonador: xPortStartScheduler() e vPortEndScheduler();
Para implementar as funes que gerenciam a pilha, o TCB e a troca de contexto,
foi consultado tambm, alm do guia de usurio (ARM, 2012), o PCS (Procedure Call
Standard) para arquitetura ARM (ARM, 2015a), que define o padro segundo o qual os
dados devem ser empilhados e a conveno de chamada de sub-rotinas.
Os arquivos contidos no diretrio Application foram ento implementados
para executar as tarefas do aplicativo. Os arquivos led_driver.c (seo B.2) e led_driver.h (seo B.3) implementam um driver mnimo para utilizao do LED RGB
contido na plataforma de desenvolvimento (ID 6.h). O manual de referncia do target
(FREESCALE SEMICONDUCTOR, 2012b) foi utilizado para a implementao do driver
de acionamento do LED, cujo esquemtico apresentado na Figura 34.
81
SW
RGB LED FEATURE
TP14
TP13
D3
PTB18
R8
220
LEDRGB_RED
P3V3
1
R
LEDRGB_GREEN
R7
LEDRGB_BLUE
R11
PTB19
220
220
D13
P3V
pg(3,5)
TP17
CLV1A-FKB-CJ1M1F1BB7R4S3
Figura 34 Diagrama esquemtico de ligao do LED RGB. Fonte: Freescale (2013, p. 3).
GND
5
O passo ID 7 consiste na criao e configurao das tarefas Task1 e Task2 do

software aplicativo, de forma a satisfazer os requisitos do sistema. As funes Task1_init() e Task2_init() implementam a inicializao das tarefas (ID 7.a) e as funes
Task1_task() e Task2_task() correspondem s atividades executadas pelas tarefas
(ID 7.b). Os diagramas de atividades da Task1 e da Task2 so ilustrados na Figura 35 e
na Figura 36, respectivamente.
II IoIoIo
% oooooIo oo IIooII
oo%ooioIo iooiioo
111111111111111111111111111111
oooooooooooooooo
oo ooo
o ooooo o o ooo
oooooooo
o oooo o ooo
oo%%o % %ooooo %%
o o% oooooooooo
o% %oooo %oooo o o
%o oo oooo oo ooo o o
ooo%o o% ooo
Figura 35 Diagrama de atividades da tarefa Task1.
Por fim, o programa foi compilado e testado de forma iterativa, at que os requisitos
do sistema fossem satisfeitos, conforme sugerem os passos ID 8 a 10 da metodologia. O
diagrama de definio de blocos dos principais componentes do sistema so apresentados
na Figura 37. O cdigo completo pode ser encontrado em <https://github.com/tiagoukei/
tcc_blink>.
Os blocos destacados em amarelo na Figura 37 constituem o software aplicativo,
implementado pelo usurio, e o arquivo FreeRTOSConfig.h, que faz parte do cdigo
baixado do site do FreeRTOS, onde foram definidas as constantes para customizar o kernel
do sistema operacional para a aplicao. Os blocos verdes so especficos ao hardware
82
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
iIiIIiIIiIiIIiiIi
222222222222222222222222222222
iIoIiIIIoIoooIII
io IIII I I IIoIIIII I
I IoI IoIoIIoI
iIIIII II
% IIIIIi%I % IIIIIII %
I II IIoIoooIII
III%IIII IooI IIII

IiIIIIIIIIIIII IIII IIII
IIIIiIIIiIIIoI
Figura 36 Diagrama de atividades da tarefa Task2.

dIIIttii
inIinIIIIIIIinnIInIniIIIn
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
iIiIIiIIiIiIIiiIi
InnInsginInIsInIIiIgIInIIIInIIInIIiginIIIn
sssssssssssssssssssssssssssssss
tIInIIIIIIgIgIIII nIIInIIiginIIIn
InnInsginInIIIInIIiIIInIIiginIIIn
innIinIiiIniiInnIIIIniiIiiI
IiIIiIndgIIIiiInnIIIIniittdII44
tIIgdIgdIIgtdnnIniinidid...
IIgtIdIgdtIIgdiiniiinididIiI
innIinIiiIniiIIIInIniiIII
innIinIiiIniiIIIInIniiIIni1
innIinIiiIniiIIIInIniiIIniI
ddIIIniidIIIiIIIdididIiI
IIni1diniiddidIiI
IIni1diInidnddIIInIiIIidIiII.did...
IIniIdiniiddidIiI
IIniIdiInidnddIIInIiIIidIiI.did...
innIinIiiIniiIIIInIniinIin
innIinIiiIniiInnIIIIniigIIIgIgIgIngii
IIIIInInIIIIi.IInInIIII.In...
dIniiiIIidIIIninddidIiI
dIniiiIIidIIInInIIIIddidIiI
dIniiiIIidIdIIinIIIIInddidIiI
nIinddiini
ddinIddIniIIddidIiI
gInIid.InIIIIddidIiI
tIgIIIiIIgddidIiI
IiIIiIndgIIIiiIIIInIniin*niIndttdII44
gIIIgIgIiinIIiIIIIiitIntIniiiIIInd1
IiII IIoI
IiIIiIndgIIIiiIIIInIniiniIIiIndttdII44
nIInnd7
nIInnd8
gIIIgIgIdIIIInIdgiIIn
nddIIitIIIInddidIiII.
ddIIigIIIdndidIiI.didIiI
ddIIiIniiiIIinItIIninddidIiI
.dIIiIIigIII.IInIidIddinidIdi
I*niIngIIIgIIniiIinitIdi
I*niInIniiddidIiI
I*niIngIIIgIIniinIIiIddidIiI
gIIIgIgIiinIIiIIIIiigIIiI.ttndIggiinIIinInII
gIIIgIgIiinIIiIIIIiigIIiI.ttndIggiinIIi
n.dIIiIniiiIIinIIiInidn.IInggIiIniiIiIniI*nIdi.*n.gIIIiIInigInniiIndi*nddIIInIiIInidIiI.diIiIniI*nIdi.
nIdIIniI.iiIIIIIddidIiI
ddIIiIiIIigiIniIIniddidIiI
.dIIiIiIIiInIIIIIIIdditInII*nIdi
ddIIiInIInIIIIIIIddidIiI
ddIIidiIIIddidIiI
ddIIiIniIIgIiiiinIIddidIiI
ddIIiI.iigIiiinIIddidIiI
IIIIiIniIIIInitInigIInIIgddiInniinIIIIIni
dgIIIIIniIIIInitInigIInIIgdIItIniiInniinIIIIInididIiI
dInIIdd.InIIIIddidIiI
I*nIinid.InIIIIddidIiI
nIdIIiInIinIIIniIIIIniddidIiI
nIIiIIigtdIggtI.iini
nIIiIIgtddIgIgtdtIiini
nIIitdIIdidIIttItIiini
nIIititdtIdidiini
nIIidIIdtddidIiI
nIIidIIdtdgggtdIIgddidIiI
nIIiIttdItIIg.ItIdIIgddidIiI
nIIitIIitdIdItIIggidIIddidIiI
nIIiItitdIdItIIggidIIddidIiI
nIIiItIIgdggIIIgidddidIiI
nIIiItIIdggIIIgidddidIiI
nIIiIiItdgitgIIgtddggIgddidIiI
nIIiIiItdgitgIIgtddidIiI
nIIitgdddidIiI
nIIiIIIdItIIggidIdtiItdgggtdIIgddidIiI
nIIigdIigdItIIggidIdtiItdgggtdIIgddidIiI
Figura 37 Diagrama de definio de blocos.
83
e fornecidos pela NXP, enquanto os laranjas so os arquivos fonte do RTOS, os quais

no sofreram modificao. J os blocos em azul so os arquivos centrais do porte, que
permitem a comunicao do software com o hardware. Ambos os arquivos (port.c e
portmacro.h) foram reaproveitados de um porte anterior realizado em um processador
Cortex-M0, com algumas modificaes para adapt-los para o Cortex-M0+, conforme
descrito anteriormente.
A Tabela 3 contm a matriz de rastreabilidade das etapas e suas implementaes.
Tabela 3 Matriz de rastreabilidade das etapas versus implementaes.

ID etapa
ID 6.a
ID 6.b
ID 6.c
ID 6.d
ID 6.e
ID 6.f
ID 6.g
ID 6.h
ID 7.a
ID 7.b
Implementao
startup_MKL25Z4.S
system_MKL25Z4.c
system_MKL25Z4.h
- DISABLE_WDOG: desabilita watchdog timer
- CLOCK_SETUP: configura modo de clock
portmacro.h
- portSTACK_GROWTH: direo de crescimento da pilha
- portTICK_PERIOD_MS: perodo das interrupes do escalonador
- portBYTE_ALIGNMENT: alinhamento de memria
FreeRTOSConfig.h
port.c
- xPortStartScheduler(): configurao das prioridades de cada evento
- xPortSysTickHandler(): implementao da ISR do SysTick
- xPortPendSVHandler(): implementao da ISR de chamadas de sistema
do tipo PendSV
- prvSetupTimerInterrupt(): habilita interrupo do SysTick
port.c
- prvSetupTimerInterrupt()
port.c
- vPortEnterCritical(): seo crtica
- vPortExitCritical(): seo crtica
- PendSVHandler(): implementao da troca de contexto
- vPortYield(): solicita PendSV para troca de contexto
- SysTickHandler(): solicita PendSV para troca de contexto
- pxPortInitialiseStack(): inicializao da pilha
- vPortStartFirstTask(): inicializao do TCB
- xPortStartScheduler(): inicializao do escalonador
- vPortEndScheduler(): shutdown do escalonador
led_driver.c
led_driver.h
Task1.c
- Task1_init()
Task2.c
- Task2_init()
Task1.c
- Task1_task()
Task2.c
- Task2_task()
84
A Figura 38 mostra o sistema em funcionamento.
Figura 38 Sistema em funcionamento.
85
5 Resultados
Os requisitos do sistema utilizado para validao da metodologia proposta neste
trabalho incluem restries temporais bem definidas, tratamento de interrupes e gerenciamento de recursos compartilhados, bem como acesso a perifricos da plataforma
de desenvolvimento, conforme o diagrama de requisitos apresentado na Figura 31, o que
confere ao sistema vrias caractersticas dos sistemas embarcados de tempo real.
O acionamento dos LEDs e o correto funcionamento do compartilhamento de
recursos (REQ3) podem ser comprovados por observao. A Figura 39 mostra uma
fotografia do sistema em movimento, com exposio durante 10 segundos, a fim de ilustrar
seu funcionamento bsico.
Figura 39 Fotografia do sistema em movimento, com exposio durante 10 segundos.
Pode-se notar que o acionamento dos LEDs ocorre de forma intercalada e que o
LED vermelho pisca a uma frequncia menor que o LED verde, conforme os requisitos
definidos para o sistema. Contudo, para verificar se os requisitos temporais so satisfeitos,
necessria uma anlise mais precisa da temporizao. Para tanto, foi utilizado um
osciloscpio de dois canais e a sada foi plotada utilizando-se o programa Matlab. A
Figura 40 ilustra a alternncia das tarefas e seu impacto na sada dos pinos que acionam
os LEDs. A Figura 41 mostra os sinais de sada em grficos separados, com alguns pontos
em destaque para verificar os requisitos de temporizao.
Deve-se notar que a conexo do LED implementa uma lgica inversa, isto , a
ativao ocorre em nvel baixo, como pode ser visto no esquemtico da Figura 34. Observase, a partir da Figura 41, que o perodo de acionamento do LED vermelho de 2 segundos,
com duty cycle de 50%, indicando que o REQ2 foi cumprido com preciso ( < 1ms). O
LED verde, por sua vez, apresentou perodo de 20 ms e duty cycle de 50%, satisfazendo o
REQ1.
importante ressaltar tambm que o volume de memria obtido no porte seguindo
a metodologia (18.556 bytes) foi reduzido em relao ao obtido pelo PEx (20.872 bytes), o
Captulo 5. Resultados
86
que equivale a uma reduo de aproximadamente 11%, decorrente do fato de o programa

ser customizado para a aplicao, sendo retirada boa parte de cdigo desnecessrio.
Resposta nas sadas digitais que acionam os LEDs
LEDRGB_RED
LEDRGB_GREEN
Tenso [V]
Task1
1
Task2
4
5
Tempo [s]
Figura 40 Sada nos pinos dos LEDs durante a execuo de cada tarefa.
Sada no pino LEDRGB_RED
4
X: 0.864
Y: 3.36
Tenso [V]
X: 2.864
Y: 3.36
X: 4.864
Y: 3.36
2
1
0
X: 1.864
Y: 0
X: 3.864
Y: 0
4
5
Tempo [s]
X: 5.864
Y: 0
Sada no pino LEDRGB_GREEN
X: 7.064
Y: 3.36
X: 6.864
Y: 3.44
3
Tenso [V]
X: 6.864
Y: 3.36
2
1
0
X: 6.964
Y: 0
4
5
Tempo [s]
Figura 41 Temporizao medida com o osciloscpio.
87
6 Concluso
O objetivo da presente pesquisa consistiu em desenvolver uma metodologia de
porte de um RTOS em uma plataforma de hardware, bem como validar a metodologia
desenvolvida por meio da implementao de um porte especfico.
Conforme observa-se nos resultados apresentados no captulo anterior, Captulo 5,
a metodologia mostrou-se adequada para o porte efetuado, satisfazendo todos os requisitos
do sistema. Realizou-se um port do RTOS FreeRTOS para uma plataforma de hardware
baseada em ARM Cortex M0+.
A partir do experimento realizado pode-se concluir que os seguintes itens foram
executados com sucesso:
configurao do clock e do timer;
inicializao da pilha do sistema e dos TCBs das tarefas;
gerenciamento da troca de contexto;
lanamento de excees e tratamento de interrupes;
gerenciamento de recurso compartilhado;
utilizao dos perifricos de hardware.
Graas ao xito obtido em cada uma das atividades mencionadas anteriormente,
foi possvel cumprir os deadlines das tarefas, que um requisito intrnseco a todo sistema
de tempo real, indicando que houve um correto acoplamento entre hardware e software,
propiciado pelo porte adequado do sistema operacional conforme a metodologia proposta
neste trabalho.
A metodologia desenvolvida difere-se das estudadas na literatura no sentido em
que define claramente, por meio de um fluxograma de processo, a sequncia das atividades
necessrias para realizar o porte de um RTOS e tambm pelo fato de fornecer uma
abstrao que permite a aplicao desses conceitos a qualquer combinao de sistema
operacional e plataforma de hardware, embora a implementao do BSP seja bastante
especfica.
Pode-se concluir deste trabalho que uma sequncia de passos bem definidos capaz
de auxiliar o desenvolvedor no processo de porte para que este seja efetuado com sucesso.
A aplicao da metodologia proposta neste trabalho de pesquisa resultou em uma
reduo de aproximadamente 11% no volume de memria utilizado, quando comparado ao
resultado da ferramenta PEx.
Captulo 6. Concluso
88
6.1 Trabalhos futuros

Sugere-se para trabalhos futuros a realizao de porte de diferentes RTOSs em
diversas plataformas utilizando-se desta metodologia, a fim de que se possa expandir a
validao de sua aplicabilidade e que ela seja, eventualmente, aprimorada.
Este trabalho de pesquisa ser continuado e desenvolvido numa dissertao de
mestrado, cujo objetivo ser apresentar uma metodologia para a adaptao de um sistema
operacional para sistema operacional de tempo real, visando modificar seu escalonador
para atender s restries das tarefas de tempo real.
6.2 Submisso de artigo

Foi escrito um artigo (Uma Metodologia de Porte de Sistema Operacional de
Tempo Real para Plataformas de Hardware, Apndice C), abordando os resultados
obtidos neste trabalho de pesquisa. Tal artigo foi submetido SBA (Sociedade Brasileira
de Automtica) para avaliao, com o intuito de public-lo no XXI Congresso Brasileiro
de Automtica (CBA2016).
89
Referncias
ABADIE, A. K. Adaptao da ferramenta Rhapsody para modelagem de aplicaes
embarcadas de tempo real sobre RTEMS. 53 f. Trabalho de Concluso de Curso (Graduao
em Engenharia Eletrnica) Instituto Tecnolgico de Aeronutica, So Jos dos Campos,
2008.
ABBOTT, D. Linux for Embedded and Real-time Applications. 2. ed. Burlington: Newnes,
2006.
ANDERSSON, K.; ANDERSSON, R. A comparison between FreeRTOS and RTLinux in
embedded real-time systems. 13 f. Linkping University, Linkping, 2005.
ARM. Booting a Cortex-M7 system. 2011. Disponvel em: <http://infocenter.arm.com/
help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s02s06.html#>. Acesso em: 8 mai.
2016.
ARM. Cortex-M0+ Devices: Generic user guide. 2. ed. [S.l.], 2012.
ARM. Procedure Call Standard for the ARM Architecture. [S.l.], 2015.
ARM. System and clock configuration. 2015. Disponvel em: <https:
//www.keil.com/pack/doc/CMSIS/Core/html/group__system__init__gr.html#
ga93f514700ccf00d08dbdcff7f1224eb2>. Acesso em: 8 mai. 2016.
BARABANOV, M. A Linux-based real-time operating system. 36 f. Dissertao (Mestrado
em Cincia da Computao) New Mexico Institute of Mining and Technology, Socorro,
NM, USA, 1997.
BARBALACE, A. et al. Performance comparison of VxWorks, Linux, RTAI, and Xenomai
in a hard real-time application. IEEE Transactions on Nuclear Science, v. 55, n. 1, p.
435439, fev. 2008.
BARR, M.; MASSA, A. Programming Embedded Systems: with C and GNU Development
Tools. 2. ed. Sebastopol: OReilly Media, 2006.
BARRY, R. FreeRTOS - A Free RTOS for small real time embedded systems. [S.l.], 2005.
BUTTAZZO, G. C. Hard Real-Time Computing Systems: Predictable scheduling
algorithms and applications. 3. ed. New York: Springer US, 2011.
CHENG, A. M. K. Real-time systems: Scheduling, analysis, and verification. New Jersey:
Wiley-Interscience, 2002.
CORBET, J.; RUBINI, A.; KROAH-HARTMAN, G. Linux device drivers. 3. ed. [S.l.]:
OReilly, 2005.
CULHAM CENTRE FOR FUSION ENERGY. The tokamak. 2012. Disponvel em:
<http://www.ccfe.ac.uk/tokamak.aspx>. Acesso em: 5 fev. 2016.
Referncias
90
DAVIS, R.; MERRIAM, N.; TRACEY, N. How embedded applications using an RTOS
can stay within on-chip memory limits. In: CITESEER. 12th EuroMicro Conference on
Real-Time Systems. [S.l.], 2000. p. 7177.
DRFLER, T. Notas de aula. Introduction to RTEMS. Puccheim: Embedded Brains
GmbH, 2007.
DUTTA, P. Toolchains. Ann Arbor: University of Michigan, 2012. Lecture.
FARINES, J.-M.; FRAGA, J. da S.; OLIVEIRA, R. S. de. Sistemas de tempo real.
Florianpolis: Universidade Federal de Santa Catarina, 2000.
FREDERICKS, R. Faq: What is a board support package? Wind River, p. 11, ago. 2001.
Disponvel em: <http://www.windriver.com/products/bsp_web/what_is_a_bsp.pdf>.
FREERTOS. Creating a New FreeRTOS Port. 2016. Disponvel em: <http:
//www.freertos.org/FreeRTOS-porting-guide.html>. Acesso em: 8 fev. 2016.
FREERTOS. Creating a New FreeRTOS Project. 2016. Disponvel em: <http:
//www.freertos.org/Creating-a-new-FreeRTOS-project.html>. Acesso em: 8 fev. 2016.
FREERTOS. FreeRTOS FAQ. 2016. Disponvel em: <http://www.freertos.org/FAQMem.
html>. Acesso em: 7 abr. 2016.
FREERTOS. Modifying a FreeRTOS Demo. 2016. Disponvel em: <http://www.freertos.
org/porting-a-freertos-demo-to-different-hardware.html>. Acesso em: 8 fev. 2016.
FREESCALE. FRDM-KL25Z : Kl25z mcu. [S.l.], 2013. Drawing.
FREESCALE SEMICONDUCTOR. FRDM-KL25Z Users Manual. 1. ed. [S.l.], 2012.
FREESCALE SEMICONDUCTOR. KL25 Sub-Family Reference Manual. 3. ed. Tempe,
2012.
FURHT, B. et al. Real-Time UNIX Systems: Design and application guide. [S.l.]: Springer
US, 1991.
HEDLUND, M.; ARONSON, F. Evaluation of real-time operating systems for
safety-critical systems. 126 f. Dissertao (Mestrado em Engenharia Eletrnica)
Jnkping University, Jnkping, 2002.
JOSHI, M. et al. BSP customization and porting of Linux on ARM Cortex based i.Mx6
processor with Yocto build environment. International Journal of Research in Engineering
and Technology, v. 3, n. 5, p. 691696, mai. 2014.
KUMAR, K. E.; KAMARAJU, M.; YADAV, A. K. Porting and BSP customization of
Linux on ARM platform. International Journal of Computer Applications, v. 80, n. 15, p.
3642, out. 2013.
LAMIE, W. E. Keeping your priorities straight: Part 1 - context switching. [s.n.], 2009.
Disponvel em: <http://www.embedded.com/design/testissue/212902706>. Acesso em:
23 jun. 2009.
LEARNING about Kinetis SDK. [s.n.], 2015. Disponvel em: <http://mcuoneclipse.com/
2015/07/20/learning-about-kinetis-sdk/#more-15713>. Acesso em: 10 fev. 2016.
Referncias
91
LI, Q.; YAO, C. Real-Time Concepts for Embedded Systems. Berkeley: CMP Books, 2003.
LOCKE, C. D. Software architecture for hard real-time applications: Cyclic executives vs.
fixed priority executives. The Journal of Real-Time Systems, v. 4, n. 1, p. 3753, mar.
1992.
MARTINS, G. S. Anlise do uso de um sistema operacional de tempo real em um software
desenvolvido para um contador crescente/decrescente com resoluo de 100 ms. 168 f.
Trabalho de Concluso de Curso (Graduao em Engenharia de Controle e Automao)
Universidade Estadual de Campinas, Campinas, 2009.
SCHFER, P. A. Dynamic loading and linking native code on a real-time operating
system. 113 f. Dissertao (Mestrado em Engenharia Eletrnica e Cincia da Computao)
Instituto Tecnolgico de Aeronutica, So Jos dos Campos, 2007.
SHERIDAN-BARBIAN, K. K. A survey of real-time operating systems and virtualization
solutions for space systems. 147 f. Dissertao (Mestrado em Cincia da Computao)
Naval Postgraduate School, Monterey, 2015.
SOARES, M. S. Comparao entre metodologias geis e tradicionais para o
desenvolvimento de software. Journal of Computer Science, v. 3, n. 2, p. 813, nov. 2004.
SOUZA, O. de. Metodologia para porte do sistema operacional Linux para sistemas
embarcados. 78 f. Dissertao (Mestrado em Engenharia de Teleinformtica)
Universidade Federal do Cear, Fortaleza, 2007.
STANGACIU, C. S.; MICEA, M. V.; CRETU, V. I. Hard real-time execution environment
extension for FreeRTOS. IEEE International Symposium on Robotic and Sensors
Environments, p. 124129, out. 2014.
STANKOVIC, J. A. Misconceptions about real-time computing. IEEE Computer, v. 21,
n. 10, p. 1019, out. 1988.
STANKOVIC, J. A.; RAJKUMAR, R. Real-time operating systems. Kluwer Academic
Publishers, v. 28, p. 237253, 2004.
TANENBAUM, A. S. Modern operating systems. 2. ed. New Jersey: Prentice Hall, 2001.
VALVANO, J. W. Embedded microcomputer systems: Real time interfacing. 2. ed. Canad:
Thomson, 2007. 814 p.
VEERABAHU, M. Using Android for embedded systems. [s.n.], 2011. Disponvel em:
<http://www.e-consystems.com/blog/linux-android/?p=457>. Acesso em: 5 fev. 2016.
VINCENT, J. et al. Principles of built-in-test for run-time-testability in component-based
software systems. Software Quality Journal, v. 10, n. 2, p. 115133, set. 2002.
WOLF, M. Computers as Components. 3. ed. Boston: Morgan Kaufmann, 2012.
YOCTO PROJECT. About. 2013. Disponvel em: <https://www.yoctoproject.org/about>.
Acesso em: 5 fev. 2016.
YOUNG, R. Porting a real-time operating system and developing a board support package.
18 f. Trabalho de Concluso de Curso (Graduao em Engenharia da Computao)
University of Evansville, Evansville, IN, USA, 2015.
Apndices
93
APNDICE A Detalhes de instalao do

ambiente de desenvolvimento
Para instalar e configurar o ambiente de desenvolvimento para o estudo do BSP,
foram necessrios os seguintes passos:
1. Realizar o download do KDS verso 3.0.0 e da atualizao do PEx para Kinetis 3.0.2,
diretamente do site oficial da NXP;
2. Instalar o IDE no Windows 7, bem como a atualizao mencionada;
3. Realizar download e instalao do KSDK 1.2.0 Mainline;
4. Criar novo projeto em: File New Processor Expert Project;
5. Inserir o nome do projeto e clicar em Next;
6. Selecionar o dispositivo em: Boards Kinetis FRDM-KL25Z e clicar em Next,
conforme Figura 42;
Figura 42 Janela New Kinetis Project.
APNDICE A. Detalhes de instalao do ambiente de desenvolvimento
94
7. Selecionar o KSDK_1.2.0 e marcar a caixa de seleo do Processor Expert, com as

configuraes padro, e clicar em Next (Figura 43);
8. Selecionar o compilador GNU C Compiler e clicar em Finish;
9. Abrir as perspectivas C/C++, Hardware e Processor Expert;
10. Sob a perspectiva Processor Expert, dar um duplo clique no componente osa1:fsl_os_abstraction, que pode ser encontrado na janela Components, dentro da pasta
OSs (Figura 44);
11. Na janela Component Inspector, selecione o sistema operacional FreeRTOS, na caixa
de seleo OS;
12. Na janela Components Library, dar um duplo clique no componente OS_Task para
adicionar uma nova tarefa ao programa (Figura 45);
13. Sob a perspectiva Hardware, possvel configurar as portas e os registradores do
processador em um ambiente grfico. Nesse mesmo ambiente, clicar em Generate
Code (Figura 46);
14. Confirmar a excluso dos arquivos desnecessrios (utilizados em configurao bare
metal);
15. Salvar o projeto;
16. Sob a perspectiva C/C++, possvel selecionar os arquivos fonte na janela Project
Explorer e visualiz-los (Figura 47).
Para instalar a atualizao do Processor Expert (Item 2), necessrio descomprimir
o arquivo baixado, clicar no menu Help Install New Software Add. Clicar no boto
Archive e selecionar o local do arquivo .zip, que estar dentro da pasta descompactada.
Clicar em OK, marcar a caixa de seleo ao lado da atualizao e prosseguir com a
instalao.
Outro item importante instalar o KSDK 1.2.0 (Item 3), pois ele fornece suporte s
plataformas da famlia FRDM-K2xx. Aps baixar o arquivo de instalao do Kinetis SDK
1.2.0 Mainline e instalar o KSDK, deve-se clicar no menu Help Install New Software
Add Archive e buscar o arquivo KSDK_INSTALL_DIRECTORY/tools/eclipse_update/KSDK_1.2.0_Eclipse_Update.zip. Prosseguir com a instalao da mesma
maneira que o item anterior.
Figura 43 Selecionando o KSDK.
95
Figura 44 Selecionando o FreeRTOS, na perspectiva Processor Expert.
Figura 45 Adicionando uma tarefa, na perspectiva Processor Expert.
96
Figura 46 Perspectiva Hardware.
Figura 47 Perspectiva C/C++.
97
98
APNDICE B Cdigos
B.1 port.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
/*
FreeRTOS V8.2.3 - Copyright (C) 2015 Real Time Engineers Ltd.
All rights reserved
VISIT http://www.FreeRTOS.org TO ENSURE YOU ARE USING THE LATEST VERSION.
This file is part of the FreeRTOS distribution.
FreeRTOS is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License (version 2) as published by the
Free Software Foundation >>>> AND MODIFIED BY <<<< the FreeRTOS exception.
***************************************************************************
>>!
NOTE: The modification to the GPL is included to allow you to
!<<
>>!
distribute a combined work that includes FreeRTOS without being
!<<
>>!
obliged to provide the source code for proprietary components
!<<
>>!
outside of the FreeRTOS kernel.
!<<
***************************************************************************
FreeRTOS is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. Full license text is available on the following
link: http://www.freertos.org/a00114.html
***************************************************************************
*
*
FreeRTOS provides completely free yet professionally developed,
*
*
robust, strictly quality controlled, supported, and cross
*
*
platform software that is more than just the market leader, it
*
*
is the industry's de facto standard.
*
*
*
*
Help yourself get started quickly while simultaneously helping
*
*
to support the FreeRTOS project by purchasing a FreeRTOS
*
*
tutorial book, reference manual, or both:
*
*
http://www.FreeRTOS.org/Documentation
*
*
*
*
***************************************************************************
http://www.FreeRTOS.org/FAQHelp.html - Having a problem? Start by reading
the FAQ page "My application does not run, what could be wrong?". Have you
defined configASSERT()?
http://www.FreeRTOS.org/support - In return for receiving this top quality
embedded software for free we request you assist our global community by
participating in the support forum.
http://www.FreeRTOS.org/training - Investing in training allows your team to
be as productive as possible as early as possible. Now you can receive
FreeRTOS training directly from Richard Barry, CEO of Real Time Engineers
APNDICE B. Cdigos
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
99
Ltd, and the world's leading authority on the world's leading RTOS.
http://www.FreeRTOS.org/plus - A selection of FreeRTOS ecosystem products,
including FreeRTOS+Trace - an indispensable productivity tool, a DOS
compatible FAT file system, and our tiny thread aware UDP/IP stack.
http://www.FreeRTOS.org/labs - Where new FreeRTOS products go to incubate.
Come and try FreeRTOS+TCP, our new open source TCP/IP stack for FreeRTOS.
http://www.OpenRTOS.com - Real Time Engineers ltd. license FreeRTOS to High
Integrity Systems ltd. to sell under the OpenRTOS brand. Low cost OpenRTOS
licenses offer ticketed support, indemnification and commercial middleware.
http://www.SafeRTOS.com - High Integrity Systems also provide a safety
engineered and independently SIL3 certified version for use in safety and
mission critical applications that require provable dependability.
1 tab == 4 spaces!
*/
/*----------------------------------------------------------* Implementation of functions defined in portable.h for the ARM CM0 port.
* Modified by: Tiago Ukei
*----------------------------------------------------------*/
/* Scheduler includes. */
#include "FreeRTOS.h"
#include "task.h"
#include "portmacro.h"
#include "MKL25Z4.h"
/* Constants required to manipulate
#define portNVIC_SYSTICK_CLK
#define portNVIC_SYSTICK_INT
#define portNVIC_SYSTICK_ENABLE
#define portNVIC_PENDSVSET
#define portNVIC_PENDSV_PRI
#define portNVIC_SYSTICK_PRI
the NVIC. */
(1UL << 2UL)
(1UL << 1UL)
1UL
(1UL << 28UL)
(255UL)
(255UL)
//processor clock
//enables systick interrupt
//enables the counter
//set pending SV bit
//pending SV priority
//systick configuration
/* Constants required to set up the initial stack. */

#define portINITIAL_XPSR
(1UL << 24UL)
/* Each task maintains its own interrupt status in the critical nesting
variable. */
static UBaseType_t uxCriticalNesting = 0;
/*-----------------------------------------------------------*/
/*
* See header file for description.
*/
StackType_t *pxPortInitialiseStack( StackType_t *pxTopOfStack, TaskFunction_t pxCode, void *pvParameters )
{
/* Simulate the stack frame as it would be created by a context switch
interrupt. */
pxTopOfStack--; /* Offset added to account for the way the MCU uses the stack on entry/exit of interrupts. */
/* xPSR */
*pxTopOfStack = portINITIAL_XPSR;
pxTopOfStack--;
APNDICE B. Cdigos
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
*pxTopOfStack =
pxTopOfStack--;
*pxTopOfStack =
pxTopOfStack -=
*pxTopOfStack =
pxTopOfStack -=
100
( StackType_t ) pxCode; /* PC */
( StackType_t ) prvTaskExitError;
/* LR */
5; /* R12, R3, R2 and R1. */
( StackType_t ) pvParameters;
/* R0 */
8; /* R11..R4. */
return pxTopOfStack;
}
/*-----------------------------------------------------------*/
static void prvTaskExitError( void )
{
/* A function that implements a task must not exit or attempt to return to
its caller as there is nothing to return to. If a task wants to exit it
should instead call vTaskDelete( NULL ).
Artificially force an assert() to be triggered if configASSERT() is
defined, then stop here so application writers can catch the error. */
configASSERT( uxCriticalNesting == ~0UL );
portDISABLE_INTERRUPTS();
for( ;; );
}
/*-----------------------------------------------------------*/
void vPortStartFirstTask( void )
{
/* The MSP stack is not reset as, unlike on M3/4 parts, there is no vector
table offset register that can be used to locate the initial stack value.
Not all M0 parts have the application vector table at address 0. */
__asm volatile(
"
ldr r2, pxCurrentTCBConst2 \n" /* Obtain location of pxCurrentTCB. */
"
ldr r3, [r2]
\n"
"
ldr r0, [r3]
\n" /* The first item in pxCurrentTCB is the task top ofstack. */
"
add r0, #32
\n" /* Discard everything up to r0. */
"
msr psp, r0
\n" /* This is now the new top of stack to use in the task. */
"
movs r0, #2
\n" /* Switch to the psp stack. */
"
msr CONTROL, r0
\n"
"
pop {r0-r5}
\n" /* Pop the registers that are saved automatically. */
"
mov lr, r5
\n" /* lr is now in r5. */
"
cpsie i
\n" /* The first task has its context and interrupts canbe enabled. */
"
pop {pc}
\n" /* Finally, pop the PC to jump to the user defined task code. */
"
\n"
"
.align 2
\n"
"pxCurrentTCBConst2: .word pxCurrentTCB
"
);
}
/*-----------------------------------------------------------*/
/*
* See header file for description.
*/
BaseType_t xPortStartScheduler( void )
{
/* Make PendSV, CallSV and SysTick the same priority as the kernel. */
APNDICE B. Cdigos
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
101
NVIC_SetPriority(PendSV_IRQn,portNVIC_PENDSV_PRI);
NVIC_SetPriority(SysTick_IRQn,portNVIC_SYSTICK_PRI);
/* Start the timer that generates the tick ISR.
here already. */
prvSetupTimerInterrupt();
Interrupts are disabled
/* Initialize the critical nesting count ready for the first task. */
uxCriticalNesting = 0;
/* Start the first task. */
vPortStartFirstTask();
/* Should never get here as the tasks will now be executing! Call the task
exit error function to prevent compiler warnings about a static function
not being called in the case that the application writer overrides this
functionality by defining configTASK_RETURN_ADDRESS. */
prvTaskExitError();
/* Should not get here! */
return 0;
}
/*-----------------------------------------------------------*/
void vPortEndScheduler( void )
{
/* Not implemented in ports where there is nothing to return to.
Artificially force an assert. */
configASSERT( uxCriticalNesting == 1000UL );
}
/*-----------------------------------------------------------*/
void vPortYield( void )
{
/* Set a PendSV to request a context switch. */
SCB->ICSR |= portNVIC_PENDSVSET;
/* Barriers are normally not required but do ensure the code is completely
within the specified behaviour for the architecture. */
__asm volatile( "dsb" );
__asm volatile( "isb" );
}
/*-----------------------------------------------------------*/
void vPortEnterCritical( void )
{
portDISABLE_INTERRUPTS();
uxCriticalNesting++;
__asm volatile( "dsb" );
__asm volatile( "isb" );
}
/*-----------------------------------------------------------*/
void vPortExitCritical( void )
{
configASSERT( uxCriticalNesting );
uxCriticalNesting--;
if( uxCriticalNesting == 0 )
{
portENABLE_INTERRUPTS();
APNDICE B. Cdigos
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
102
}
}
/*-----------------------------------------------------------*/
uint32_t ulSetInterruptMaskFromISR( void )
{
__asm volatile(
" mrs r0, PRIMASK
\n"
" cpsid i
\n"
" bx lr
"
);
/* To avoid compiler warnings.
return 0;
This line will never be reached. */
}
/*-----------------------------------------------------------*/
void vClearInterruptMaskFromISR( uint32_t ulMask )
{
__asm volatile(
" msr PRIMASK, r0
\n"
" bx lr
"
);
/* Just to avoid compiler warning. */
( void ) ulMask;
}
/*-----------------------------------------------------------*/
void xPortPendSVHandler( void )
{
/* This is a naked function. */
__asm volatile
(
"
mrs r0, psp
"
"
ldr r3, pxCurrentTCBConst
"
ldr r2, [r3]
"
"
sub r0, r0, #32
registers. */
"
str r0, [r2]
"
stmia r0!, {r4-r7}
saved automatically. */
"
mov r4, r8
"
mov r5, r9
"
mov r6, r10
"
mov r7, r11
"
stmia r0!, {r4-r7}
"
"
push {r3, r14}
"
cpsid i
"
bl vTaskSwitchContext
"
cpsie i
"
pop {r2, r3}
*/
"
"
ldr r1, [r2]
\n"
\n"
\n" /* Get the location of the current TCB. */
\n"
\n"
\n" /* Make space for the remaining low \n" /* Save the new top of stack. */
\n" /* Store the low registers that are not \n" /* Store the high registers. */
\n"
\n"
\n"
\n"
\n"
\n"
\n"
\n"
\n"
\n" /* lr goes in r3. r2 now holds tcb pointer. \n"
\n"
APNDICE B. Cdigos
279
"
280
281
282
283
284
285
286
287
"
"
"
"
"
"
"
"
288
289
"
"
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
"
"
"
bx r3
"
"
.align 2
"pxCurrentTCBConst: .word pxCurrentTCB
);
ldr r0, [r1]

task top of stack. */
add r0, r0, #16
ldmia r0!, {r4-r7}
mov r8, r4
mov r9, r5
mov r10, r6
mov r11, r7
msr psp, r0
task. */
sub r0, r0, #32
not automatically restored. */
ldmia r0!, {r4-r7}
103
\n" /* The first item in pxCurrentTCB is the \n" /* Move to the high registers. */
\n" /* Pop the high registers. */
\n"
\n"
\n"
\n"
\n"
\n" /* Remember the new top of stack for the \n"
\n" /* Go back for the low registers that are \n" /* Pop low registers.
\n"
\n"
\n"
\n"
"
*/
}
/*-----------------------------------------------------------*/
void xPortSysTickHandler( void )
{
uint32_t ulPreviousMask;
ulPreviousMask = portSET_INTERRUPT_MASK_FROM_ISR();
{
/* Increment the RTOS tick. */
if( xTaskIncrementTick() != pdFALSE )
{
/* Pend a context switch. */
SCB->ICSR |= portNVIC_PENDSVSET;
}
}
portCLEAR_INTERRUPT_MASK_FROM_ISR( ulPreviousMask );
}
/*-----------------------------------------------------------*/
/*
* Setup the systick timer to generate the tick interrupts at the required
* frequency.
*/
void prvSetupTimerInterrupt( void )
{
/* Configure SysTick to interrupt at the requested rate. */
SysTick->LOAD = ( configCPU_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL;
SysTick->CTRL = portNVIC_SYSTICK_CLK | portNVIC_SYSTICK_INT | portNVIC_SYSTICK_ENABLE;
}
/*-----------------------------------------------------------*/
APNDICE B. Cdigos
104
B.2 led_driver.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
/*
* led_driver.c
*
* Contains the functions that handle the LED
*
* Created on: 08/05/2016
Author: Tiago Ukei
*
*/
#include "MKL25Z4.h"
#include "led_driver.h"
void vLedInit(led_t led) {
SIM_SCGC5 |= SIM_SCGC5_PORTB_MASK;
switch(led) {
case LEDRGB_RED:
PORTB_PCR18 = PORT_PCR_MUX(1);
GPIOB_PDDR |= LEDRGB_RED_DIR;
GPIOB_PSOR |= LEDRGB_RED_SET;
break;
case LEDRGB_GREEN:
PORTB_PCR19 = PORT_PCR_MUX(1);
GPIOB_PDDR |= LEDRGB_GREEN_DIR;
GPIOB_PSOR |= LEDRGB_GREEN_SET;
break;
//enables system clock gating for PORTB
//enables PTB18 as GPIO

//set output direction
//turn off led
//enables PTB19 as GPIO

//set output direction
//turn off led
default:
break;
}
}
void vLedToggle(led_t led) {
switch(led) {
case LEDRGB_RED:
GPIOB_PTOR |= LEDRGB_RED_SET;
//toggle red led
break;
case LEDRGB_GREEN:
GPIOB_PTOR |= LEDRGB_GREEN_SET; //toggle green led
break;
default:
break;
}
}
APNDICE B. Cdigos
105
B.3 led_driver.h
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/*
* led_driver.h
*
* Header file for led.c
*
* Created on: 08/05/2016
Author: Tiago Ukei
*
*/
#ifndef APPLICATION_INCLUDES_LED_DRIVER_H_
#define APPLICATION_INCLUDES_LED_DRIVER_H_
#define INPUT
#define OUTPUT
0
1
#define LEDRGB_RED_DIR
#define LEDRGB_RED_SET
(OUTPUT << 18)

(1 << 18)
#define LEDRGB_GREEN_DIR
#define LEDRGB_GREEN_SET
(OUTPUT << 19)

(1 << 19)
typedef enum led_type{LEDRGB_RED, LEDRGB_GREEN} led_t;

void vLedInit(led_t);
void vLedToggle(led_t);
#endif /* APPLICATION_INCLUDES_LED_DRIVER_H_ */
106
APNDICE C Artigos
C.1 CBA 2016
Artigo submetido ao SBA para avaliao, com o objetivo de apresent-lo no XXI
Congresso Brasileiro de Automtica.
UMA METODOLOGIA DE PORTING DE SISTEMA OPERACIONAL DE TEMPO

REAL PARA PLATAFORMAS DE HARDWARE
Tiago N. Ukei, Denis S. Loubach
Laborat
orio de Computac
ao Avancada, Controle e Sistemas Embarcados - FEM
Universidade Estadual de Campinas - UNICAMP
Campinas, SP, Brasil
Emails: tiago.ukei@gmail.com, dloubach@fem.unicamp.br
Abstract Real-time embedded systems have become more and more complex, requiring the development
of more reliable and more efficient code. Although the testing stage of these systems has been improved in
the past few years, it is not able to simulate all the possible conditions to which the system will be exposed
during its lifecycle, making it necessary to develop techniques and methodologies in order to increase quality
and reliability of such systems. Despite the vast research performed on this subject, a unified and systematic
method for porting a real-time operating system on a hardware platform is hardly found in the literature. This
article presents, therefore, a methodology with this purpose, which was then tested and validated through porting
FreeRTOS on an ARM platform. We suggest the use of our methodology in future works for further testing and
possible improvements.
Keywords
Embedded systems, Porting, Methodology, RTOS.
Resumo Os sistemas embarcados de tempo real t

em se tornado cada vez mais complexos, o que exige o
desenvolvimento de c
odigos mais confi
aveis e eficientes. Embora a fase de testes desses sistemas venha sendo
aprimorada nos u
ltimos anos, ela n
ao
e capaz de reproduzir todas as condico
es a que o sistema estar
a exposto
durante seu funcionamento, tornando-se necess
ario o desenvolvimento de t
ecnicas e metodologias para aumentar
a qualidade e confiabilidade de tais sistemas. Apesar do grande n
umero de pesquisas nessa a
rea, ainda n
ao
se encontra na literatura um m
etodo u
nico e sistem
atico para realizar o porting de um sistema operacional de
tempo real em uma plataforma de hardware. Este artigo apresenta uma metodologia com essa finalidade, a qual
foi testada e validada por meio de um port realizado do FreeRTOS em uma plataforma ARM. Sugere-se que a
metodologia apresentada seja utilizada em trabalhos futuros para testes e eventuais aprimoramentos.
Palavras-chave
Sistemas embarcados, Porting, Metodologia, RTOS.
Introdu
c
ao
Os sistemas embarcados de tempo real est

ao presentes em todos os lugares: automoveis, aeronaves, eletrodomesticos, televisoes, celulares, MP3,
porteiros eletronicos, roteadores e dispositivos de
rede, entre muitos outros. Em muitas dessas aplicacoes, o tempo que os dispositivos de controle levam para produzir a resposta a estmulos externos
e criticamente importante. Um controlador de voo
de um caca supersonico, por exemplo, deve atuar
em fracoes de segundo para evitar que ocorra uma
catastrofe.
Com as aplicacoes tornando-se cada vez mais
complexas, surge a necessidade de um gerenciamento confiavel e eficiente das tarefas executadas
por um dispositivo. Portanto, os desenvolvedores de software tem se apoiado cada mais em sistemas operacionais para desempenhar suas funcoes. Apesar do constante avanco em tecnologia
de hardware, ainda constitui um desafio manter
a alta qualidade e confiabilidade de sistemas cada
vez mais complexos (Abadie, 2008, p. 12).
Embora uma serie de testes seja realizada antes da liberacao do produto para o mercado, n
ao
e possvel replicar todas as condicoes a que o sistema estara exposto quando colocado em funcionamento, ou seja, o teste de software n
ao representa, por si so, uma solucao para alcancar a
previsibilidade nos sistemas de tempo real. Para

se obter uma performance mais robusta sob varias condic
oes de operac
ao, e necess
ario utilizar
metodologias de projeto avancadas, alem de uma
an
alise aprofundada do c
odigo fonte e mecanismos especficos do sistema operacional, projetados
para suportar aplicac
oes com restric
oes temporais
(Buttazzo, 2011).
Apesar do grande n
umero de pesquisas e estudos relacionados aos sistemas computacionais de
tempo real na atualidade, n
ao se encontra, na literatura, um metodo sistem
atico e u
nico para realizar o porting de um sistema operacional de tempo
real (real-time operating system - RTOS) em uma
plataforma de hardware. Devido `
a complexidade
envolvida nesse processo, e importante que haja
uma sequencia bem definida das atividades necess
arias para que o port do sistema seja efetuado
com exito.
Dado esse contexto, o objetivo deste artigo e
apresentar uma metodologia geral de porting de
um RTOS em uma plataforma de hardware, bem
como valid
a-la por meio da implementac
ao do port
do FreeRTOS em uma plataforma de desenvolvimento FRDM-KL25Z, seguindo os passos da nossa
metodologia.
Este artigo e organizado em seis sec
oes. A
Sec
ao 1, discorrida ate este ponto, apresenta
uma breve introduc
ao aos sistemas embarcados de
tempo real e sua importancia, bem como a motivacao e o objetivo deste trabalho. A Secao 2 contem uma revisao de literatura, com as principais
definicoes e trabalhos relacionados. Na Sec
ao 3
e apresentada nossa proposta de metodologia de
porting de um RTOS em forma de um fluxograma
de processo, o qual e utilizado para a implementacao de um port especfico, descrita na Sec
ao 4. A
Secao 5 apresenta os resultados obtidos do experimento e, por fim, na Secao 6, sao apresentadas as
conclusoes e principais contribuicoes deste artigo.
2
Revis
ao de literatura
Os sistemas embarcados com hardware relativamente simples (e.g., relogio digital), onde n
ao se
justifica a adocao de um sistema operacional devido ao overhead introduzido na aplicacao, s
ao geralmente implementados com base em uma arquitetura bare metal. Em contrapartida, aplicac
oes
mais complexas, como um sistema avionico, requerem um gerenciamento mais preciso do escalonamento das tarefas, o que justifica a utilizac
ao
de um RTOS.
De acordo com Barabanov (1997, p. 1), um
sistema operacional de tempo real e um sistema
operacional capaz de garantir os requisitos de
tempo dos processos sob seu controle. Ele deve
escalonar a execucao dos programas de maneira
temporizada, gerenciar os recursos do sistema e
prover suporte basico para sincronizacao, comunicacao, temporizacao precisa, gerenciamento de
dispositivos de entrada/sada (E/S) e uma fundacao consistente para o desenvolvimento do c
odigo
de aplicativo (Li and Yao, 2003; Stankovic and
Rajkumar, 2004).
Para que o RTOS comunique-se de forma
adequada com o hardware, e necessario um conjunto de drivers especficos para os componentes
de hardware do sistema, conhecido como board
support package (BSP) (Li and Yao, 2003). O
BSP e um componente de software que faz parte
da imagem executavel, assim como uma serie de
outros modulos, como mostra a Figura 1.
Aplicativo
Software
Outros componentes/mdulos embarcados

Pilhas de protocolos (i.e. TCP/IP)
uma implementac
ao do c
odigo de suporte especfico para uma dada placa que se conforma a um
dado sistema operacional, ou seja, o BSP fornece
o suporte mnimo para carregar o sistema operacional e contem os device drivers para todos os dispositivos no sistema target, disponibilizando uma
abstrac
ao do hardware para as camadas mais altas do software. Segundo Hedlund and Aronson
(2002), a estrutura de um BSP inclui a configurac
ao da CPU, da mem
oria (stack, heap), das interrupc
oes de hardware, do timer do escalonador do
sistema e os drivers de dispositivos.
O desenvolvimento de um BSP n
ao e uma tarefa trivial, dependendo do nvel de complexidade
do hardware. Para escrever um BSP, e necess
ario
conhecer a arquitetura de hardware do target, o
fluxo de dados, o mapa de mem
oria, o mapa de
interrupc
oes, alem da linguagem de montagem especfica para o microprocessador. Boa parte dos
desenvolvedores, no entanto, utiliza o BSP de um
port anteriormente realizado para uma plataforma
de hardware similar e faz as devidas adaptac
oes no
c
odigo para a aplicac
ao especfica. Em geral, os
registradores necess
arios para o port s
ao listados
nesses BSPs, juntamente com uma sequencia para
inicializar corretamente o hardware do target (Li
and Yao, 2003).
A metodologia empregada por Young (2015)
para realizar o port do FreeRTOS em uma plataforma de desenvolvimento FRDM-KL25Z resumese nos seguintes passos:
1. Pesquisar sobre a arquitetura do processador
e o esquema de gerenciamento de mem
oria.
Definir as constantes e macros apropriadas
nos arquivos de cabecalho, necess
arias para
a configurac
ao do clock, tamanho do heap e
da pilha, nveis de prioridade, entre outras
definic
oes;
2. Utilizando o c
odigo de um port anterior para
uma plataforma semelhante, realizar as modificac
oes necess
arias no arquivo port.c, implementando inicialmente a func
ao de inicializac
ao da pilha (pxPortInitialiseStack());
3. Determinar quais func
oes s
ao dependentes de
pxPortInitialiseStack() e implement
a-las
de forma incremental ate que seja possvel
compilar o FreeRTOS;
Sistema operacional de tempo real (RTOS)

Board Support Package (BSP)
MICROPROCESSADOR
ETHERNET
PORTA SERIAL
Hardware
BDM / JTAG
RAM / ROM / FLASH
TIMER
Figura 1: Componentes de software de uma imagem executavel. Fonte: Li and Yao (2003).
Kumar et al. (2013, p. 36) definem BSP como
4. Implementar um BSP mnimo para suportar

a utilizac
ao do LED RGB, utilizado nos testes
de temporizac
ao.
No estudo apresentado por Sch
afer (2007), em
que e feito o port do RTEMS em uma plataforma
Blackfin, tambem e adotada uma abordagem incremental, iniciando-se por um port simples e, posteriormente, adicionando-se funcionalidades mais
complexas ao sistema, como rotinas de tratamento
de interrupc
oes. As tarefas essenciais apontadas
pelo autor para que o port fosse realizado com sucesso envolvem a implementacao das func
oes de
gerenciamento da troca de contexto e das rotinas
de tratamento de interrupcoes, alem dos drivers de
necess
dispositivos e configuracao do clock. E
ario
ainda configurar adequadamente algumas macros
para a correta inicializacao e utilizacao da pilha,
tais como as que definem a direcao de crescimento,
o tamanho mnimo e o alinhamento.
No trabalho apresentado por Souza (2007) e
desenvolvida um metodologia iterativa para realizar o porting do Linux em sistemas embarcados.
A metodologia proposta consiste, basicamente, na
deteccao das partes dos codigos-fonte que devem
ser modificadas para que seja realizado o port
do sistema operacional para a nova plataforma,
respeitando-se os passos apresentados na Figura 2
(Souza, 2007, p. 52).
um RTOS qualquer em uma plataforma de hardware, sem considerar suas peculiaridades. A Figura 3 mostra o fluxograma do processo de porting
proposto. Os pontos mais importantes desta metodologia ser
ao discorridos adiante.
T0-0
T0-1
N0
N1
T1-0
T2-1
T2-0
T0-2
N2
T1-2
T2-3
T3-4
N3
N4
T4-3
T3-3
Figura 2: Grafo da metodologia em cinco passos.

Fonte: Souza (2007).
N0 - Avaliar os requisitos iniciais do projeto
usando um modelo de tomada de decis
ao;
N1 - Identificar quais elementos de hardware
nao tem correspondente suporte de software;
N2 - Identificar quais codigos de software devem ser modificados;
N3 - Identificar as dependencias entre os
componentes de software;
N4 - Identificar a precedencia de realizac
ao
das modificacoes.
3
Metodologia proposta para porting de

um RTOS em uma plataforma de
hardware
A nossa metodologia baseou-se em um estudo previamente realizado de um BSP existente e funcional fornecido pelo KSDK (Kinetis Software
Development Kit) para o port do FreeRTOS em
uma plataforma FRDM-KL25Z, utilizando-se o
Processor Expert, que e uma ferramenta integrada
ao ambiente de desenvolvimento para auxiliar na
geracao automatica de codigo. Apos analisadas a
estrutura e a implementacao do codigo, foi desenvolvida uma metodologia que visa fornecer os passos, em aspecto geral, para a realizacao do port de
Figura 3: Fluxograma do processo de porting segundo a metodologia proposta.

Em geral, recomenda-se que os c
odigos fonte
do kernel e do BSP sejam divididos em dois diret
orios principais: um, contendo os arquivos dependentes do port e outro, os independentes. Os
arquivos especficos ao target (ID 3) s
ao responsaveis pela configurac
ao do clock, do timer gerador
de ticks (interrupc
oes peri
odicas para o escalonador), do controlador de interrupc
oes, da mem
oria
e pela troca de contexto. A parte do kernel independente do port (ID 4) est
a relacionada essencialmente `
a manipulac
ao de tarefas, filas de mensagens, mutexes, listas e corrotinas.
O processo ID 6, detalhado na Figura 4, e o
passo central desta metodologia, o qual consiste
em realizar as alterac
oes nos c
odigos relacionados
ao hardware. Esse passo pode ser dividido em tres
blocos:
Inicializa
c
ao do hardware: compreende os
codigos que sao essenciais para a inicializacao do sistema, porem sao independentes do
RTOS sendo portado, tais como o vetor de
inicializacao e as funcoes de configurac
ao do
clock e PLL (Phase Locked Loop).
Port do RTOS: sao os arquivos de configuracao que adaptam o RTOS para ser executado na plataforma de hardware especfica.
Drivers de dispositivos: e a parte do BSP
adicional, necessaria para a utilizacao dos perifericos pelo aplicativo.
o controlador de interrupc
ao, os timers e demais
perifericos. Entre essas informac
oes, destacam-se
o endereco dos registradores, os bits de configurac
ao e os modos de operac
ao de cada dispositivo.
Um arquivo de cabecalho contendo o mapeamento
dos registradores dos perifericos e geralmente fornecido pelo fabricante do microcontrolador ou desenvolvedores third party.
Para realizar o port do sistema operacional, e
necess
ario ainda consultar o manual de porting e a
documentac
ao fornecida pelos desenvolvedores do
RTOS, que servem de guia para a implementacao
da interface completa para que o sistema operacional se comunique adequadamente com o hardware.
Em geral, essa interface e composta por uma lista
de constantes que devem ser definidas e um conjunto de func
oes que devem ser implementadas.
Os passos subsequentes da metodologia sao
necess
arios para verificar e validar o port realizado, apesar de n
ao fazerem parte do processo de
porting propriamente dito. O passo ID 7, expandido na Figura 5, consiste em implementar um codigo mnimo de aplicativo e a func
ao main() para
verificar se o port foi realizado com sucesso.
Figura 5: Desdobramento do processo ID 7 da

metodologia apresentada.
Figura 4: Desdobramento do processo ID 6 da

metodologia apresentada.
Muitos microprocessadores possuem o c
odigo
em assembly do vetor de inicializacao disponvel
para download, fornecido pelos proprios fabricantes. No entanto, caso seja necessario implement
alo, deve-se recorrer `a documentacao do microprocessador, que possui todas as informacoes necessarias para sua configuracao, tais como os modos
de operacao do processador, a configuracao da pilha, o mapa de registradores, de memoria e do
vetor de inicializacao, o gerenciamento de energia, o conjunto de instrucoes e os perifericos do
processador.
Outro documento essencial para o porting e o
datasheet ou manual de referencia do microcontrolador, o qual contem todas as informacoes necess
arias para configurar o hardware, incluindo o clock,
O passo ID 8 equivale `
a gerac
ao da imagem
execut
avel e carregamento no target. Em caso de
erro de compilac
ao, deve-se realizar as correc
oes
necess
arias (ID 9) e recompilar o c
odigo, em um
processo iterativo, ate que se obtenha a imagem
execut
avel com exito.
Por fim, deve-se testar e depurar o programa
(ID 10) para verificar se o sistema atende aos
requisitos funcionais e, principalmente, temporais, validando o processo de porting do RTOS.
Recomenda-se fortemente que esse processo seja
iterativo e implementado gradativamente, isto e,
deve-se compilar e testar o programa inicialmente
com uma estrutura b
asica para seu funcionamento
e ent
ao adicionar, de forma gradual, as funcionalidades do RTOS no programa de usu
ario.
4
Teste e valida
c
ao da metodologia
Para validac
ao da metodologia proposta, foi realizado o port do FreeRTOS em uma plataforma
FRDM-KL25Z e de um programa aplicativo basico capaz de testar algumas funcionalidades do
RTOS, tais como temporizacao, escalonamento de

tarefas e bloqueio de recursos. O diagrama de requisitos do sistema e ilustrado na Figura 6.
eII 2eIeIe
o eeeeIe e II e11
i eieI i eiie
ssssssssssssssssssssss
eeee
eeee
eeeeeeeee
eeee
eeeeeeee o
eeeer e ee
1ee1ee11
1ee1ee12
1ee1ee13
e e eee ee ee e
eeee eeeee e ee e
eee e eeee e
eeeee
...
e e eee ee ee e
eeee eee o e e
ee eeee. e eeee e
eeeee ...
e e eee ee eee
e
eee e ee eeee e
ee
e e e e
e eeee e ee
e e e e
e e ee ee .
Figura 6: Diagrama de requisitos do sistema.

Primeiramente foi feito um estudo do c
odigo
do BSP obtido com o auxlio do Processor Expert,
bem como de sua organizacao. Para organizar o
codigo fonte do RTOS conforme a metodologia,
foi consultado o guia de porting do FreeRTOS, o
qual informa a estrutura de diretorios e a organizacao do codigo fonte do sistema operacional.
Em seguida, realizou-se o download dos arquivos fonte do FreeRTOS a partir de seu site oficial
(http://www.freertos.org) e, entao, organizouse o codigo da maneira apresentada na Figura 7,
a qual mostra o diagrama de pacotes utilizado na
modelagem do programa implementado no experimento.
Cnngssssnaasnsnnsnsnassansnngannnn
nsnnssshaSnngnahsnasahsnnsahnsennh
sssssssssssssssssss
nnnnnnnnnnn
1 iee1e
e1
snnnssss
snnsnsnCCnss
snssnss
snnnssss
snssnss
sngs
sngs
sngs
SsssSSSs
ssn
nnnnsss
nnsnnens
CnsnsCCCnCCCC
CsgCnng
projeto importou apenas o makefile, os arquivos

de configurac
ao do linker e do debugger e os arquivos especficos ao microcontrolador, fornecidos
pela pr
opria NXP, fabricante da plataforma. A
tool-chain utilizada para gerac
ao da imagem execut
avel foi a arm-none-eabi-.
Os arquivos respons
aveis pela inicializac
ao do
hardware, relacionados aos passos 6.a e 6.b da Figura 4, s
ao definidos no padr
ao CMSIS (Cortex
Microcontroller Software Interface Standard) e
fornecidos pela NXP. O CMSIS-Core define os arquivos startup_MKL25Z.S e system_MKL25Z4.c,
contidos na pasta Startup_Code. No arquivo
system_MKL25Z4.h foi selecionada a configuracao
desejada para o clock do sistema - modo PEE
(PLL Engaged External), que usa um cristal externo de 4 MHz e um PLL para alcancar a frequencia de 48 MHz de alta precis
ao.
As definic
oes do passo 6.c foram realizadas no arquivo portmacro.h.
O arquivo
FreeRTOSConfig.h contem uma lista de definicoes
para configurar o RTOS conforme as necessidades
do software aplicativo (ID 6.d). Os passos 6.e a 6.g
foram implementados no arquivo port.c, o qual
contem as func
oes necess
arias para que o RTOS
execute na plataforma de hardware utilizada.
Os
arquivos
contidos
no
diret
orio
Application foram ent
ao implementados para
executar as tarefas do aplicativo. Os arquivos
led_driver.c e led_driver.h implementam
um driver mnimo para utilizac
ao do LED RGB
contido na plataforma de desenvolvimento (ID
6.h).
O passo ID 7 consiste na criac
ao e configurac
ao das tarefas Task1 e Task2 do software aplicativo, de forma a satisfazer os requisitos do sistema.
O diagrama de atividades da Task1 e exemplificado na Figura 8.
II IoIoIo
% oooooIo oo IIooII
oo%ooioIo iooiioo
111111111111111111111111111111
Figura 7: Diagrama de pacotes implementados.

Conforme os passos ID 3 e 4 da nossa metodologia, o codigo fonte do FreeRTOS foi dividido em dois diretorios separados. No diret
orio
portable foram colocados os arquivos que dependem do port, os quais ainda foram subdivididos
nas pastas CortexM0p GCC e MemMang. Na primeira pasta foram colocados os arquivos port.c e
1ngsa1an1a1
portmacro.h,
que dependem do processador e do
compilador, e na segunda, foi copiado o arquivo
que gerencia a memoria heap. No outro diret
orio
(src) foram colocados os arquivos do kernel que
nao sao especficos ao port realizado, tais como
tasks.c, list.c e queue.c.
Foi configurado entao o ambiente de desenvolvimento KDS (Kinetis Design Studio) e criado
um novo projeto do Processor Expert, chamado
tcc_blink, porem o KSDK nao foi utilizado para
a geracao automatica de codigo. Dessa forma, o
oooooooooooooooo
oo ooo
o ooooo o o ooo
oooooooo
o oooo o ooo
oo%%o % %ooooo %%
o o% oooooooooo
o% %oooo %oooo o o
%o oo oooo oo ooo o o
ooo%o o% ooo
Figura 8: Diagrama de atividades da Task1.

Por fim, o programa foi compilado e testado
de forma iterativa, ate que os requisitos do sistema
fossem satisfeitos, conforme sugerem os passos ID
8 a 10 da metodologia. O diagrama de definicao
de blocos dos principais componentes do sistema
s
ao apresentados na Figura 9. O c
odigo completo
pode ser encontrado em <https://github.com/
tiagoukei/tcc_blink>.
ioo oooo
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaahahaaaaahhaaaaahaaaaahaahaah
sssssssssssssssssssssssssssssss
annaaaaaaaahhdaaaaaaahhaaaa
naaaaandaaaahhdaaaaaaahhtth2444
tndadhgdhdatdaaaahaaadhd...
hdatndhgdtndadaaahhaaadhdaaa
annaaaaaaaahhnaaaaaahhaaadaaadaa
annaaaaaaaahhnaaaaaahhhaah1
annaaaaaaaahhnaaaaaahhhaah2
dhaadaaadaaahaaadadhdaaa
haah1daaaaddhdaaa
haah1daaahdnddaaaaaaaahdaaaa.dhd...
haah2daaaaddhdaaa
haah2daaahdnddaaaaaaaahdaaa.dhdaaa
annaaaaaaaahhnaaaaaahhaaaa
annaaaaaaaahhdaaaaaaahhgaaaghgnaaagaa
aaanaaanhaaah.naaanhaaa.aa...
ddaaaaaaadahaahaddhdaaa
ddaaaaaaadanaaanhaaaddhdaaa
ddaaaaaaadadaaanhaaaaaddhdaaa
aaaaddhaaa
naaaaandaaaahhnaaaaaahhaaaaaandtth2444
ddaaaddaaaaaddhdaaa
gaaaad.aaaaaaddhdaaa
hagaaaadngddhdaaa
naaaaandaaaahhnaaaaaahha*aaaadtth2444
gaaaghgnhhnaaaahaahhtaataaahhhaand1
aaaaad7
aaaaad8
gaaaghgndnaaaaadgaaaa
nddaaataaaaaddhdaaaa.
ddaaagaaadndhdaaa.dhdaaa
ddaaadaaaaaaaaaaaaahaddhdaaa
.daaataagaaa.aannadaddhaadada
n*aaaaaaaaaaaahhaaaat2da
n*aaaadaaaddhdaaa
n*aaaaaaaaaaaahhnaaaaddhdaaa
gaaaghgnhhnaaaahaahhaaaaa.ttndtaahhnaaaaaaaa
gaaaghgnhhnaaaahaahhaaaaa.ttndtaahhnaaa
n.daaadaaaaaaaaanaaahdn.hanggnaaahhnaaahh*nada.*n.aaaahhaahgaaaaaaada*nddaaaaaaaaahdaaa.dhnaaahh*nada.
nadhaahd.aadaaaaddhdaaa
ddaaanda.aaaaaaddhdaaa
ddaaanaaaagaaaahaahddhdaaa
.daaanaaaanahaaaaaaddhaaaah*nada
ddaaadaanahaaaaaaddhdaaa
ddaaadaaaaddhdaaa
ddaaadaaaaaaaaaaaaaddhdaaa
ddaaad.aaaaaaaaaaddhdaaa
aanaadaaaaaanataahgaaadngddhaaaaaaaaaaaaa
daaaaadaaaaaanataahgaaadngdaataahhaaaaaaaaaaaaadhdaaa
daaandd.aaaaaaddhdaaa
n*ahaahd.aaaaaaddhdaaa
nadnaaanhaaaadaaaaaanaddhdaaa
naaanhaatdtggth.haaa
naaahdatdddgdghdtnhaaa
naaaadhddahdtttdthhaaa
naaatatdhdhadhaaa
naaadddhhddhdaaa
naaadddhhdgggtddngddhdaaa
naaadthdntdha.dttddngddhdaaa
naaahdnaahdddthdgghdhnddhdaaa
naaadtaahdddthdgghdhnddhdaaa
naaadthdgdagdhdaahddhdaaa
naaadtdhdagdhdaahddhdaaa
naaahantdghtahdgtddgghgddhdaaa
naaahantdghtahdgtddhdaaa
naaatgdddhdaaa
naaandhddthdgghdhdtantdgggtddngddhdaaa
naaaahdagddthdgghdhdtantdgggtddngddhdaaa
Nossa metodologia difere-se das estudadas na

literatura no sentido em que define claramente,
por meio de um fluxograma de processo, a sequencia das atividades necess
arias para realizar o port
de um RTOS e tambem pelo fato de ser aplic
avel
a qualquer combinac
ao de sistema operacional e
plataforma de hardware.
Pode-se concluir deste trabalho que uma
sequencia de passos bem definidos e capaz de
auxiliar o desenvolvedor no processo de porting,
para que este seja efetuado com sucesso. Sugerese, para trabalhos futuros, a realizac
ao de port
de diferentes RTOSs em diversas plataformas
utilizando-se desta metodologia, a fim de que se
possa expandir a validac
ao de sua aplicabilidade e
que ela seja, eventualmente, aprimorada.
Figura 9: Diagrama de definicao de blocos.

Agradecimentos
Os blocos destacados em amarelo na Figura
9 constituem o software aplicativo, implementado
pelo usuario. Os blocos verdes sao especficos ao
hardware e fornecidos pela NXP, enquanto os laranjas sao os arquivos fonte do RTOS. Ja os blocos
daaaa1aaga1
em azul sao os arquivos centrais do port, que foram implementados para permitir a comunicac
ao
do software com o hardware.
5
Resultados
Os resultados obtidos seguindo a metodologia proposta podem ser considerados satisfatorios, visto
que os requisitos do sistema foram atendidos. Esses requisitos incluem restricoes temporais bem
definidas, tratamento de interrupcoes e gerenciamento de recursos compartilhados, bem como
acesso a perifericos da plataforma de desenvolvimento, conforme o diagrama de requisitos apresentado na Figura 6, o que confere ao sistema
varias caractersticas dos sistemas embarcados de
tempo real.
importante ressaltar tambem que o
E
footprint de memoria obtido no port seguindo a
metodologia (18.556 bytes) foi reduzido em relacao ao obtido pelo Processor Expert (20.872
bytes). Essa reducao deve-se ao fato de o programa ser customizado para a aplicacao, sendo
retirada boa parte de codigo desnecessario.
6
Conclus
oes
Como apontado na Secao 5, a metodologia apresentada neste artigo mostrou-se adequada para o
porting realizado, satisfazendo todos os requisitos do sistema. Por meio dos resultados obtidos,
pode-se observar que os deadlines das tarefas foram cumpridos, o que nos permite concluir que
o software foi adequadamente acoplado ao hardware, utilizando suas funcoes de clock, timers, controladores de interrupcao e perifericos.
Agradecemos `
a Universidade Estadual de Campinas e `
a Faculdade de Engenharia Mec
anica por
fornecerem os meios necess
arios para o desenvolvimento deste trabalho.
Refer
encias
Abadie, A. K. (2008). Adaptac
ao da ferramenta
Rhapsody para modelagem de aplicac
oes embarcadas de tempo real sobre RTEMS, Trabalho de conclus
ao de curso (graduac
ao em
engenharia eletr
onica), Instituto Tecnol
ogico
de Aeron
autica, S
ao Jose dos Campos.
Barabanov, M. (1997). A Linux-based real-time
operating system, Dissertac
ao (mestrado em
ciencia da computac
ao), New Mexico Institute of Mining and Technology, Socorro, NM,
USA.
Buttazzo, G. C. (2011). Hard Real-Time Computing Systems, 3 edn, Springer US, New York.
Hedlund, M. and Aronson, F. (2002). Evaluation of real-time operating systems for safetycritical systems, Dissertac
ao (mestrado em
engenharia eletr
onica), J
onk
oping University,
J
onk
oping.
Kumar, K. E., Kamaraju, M. and Yadav, A. K.
(2013). Porting and BSP customization of Linux on ARM platform, International Journal
of Computer Applications 80(15): 3642.
Li, Q. and Yao, C. (2003). Real-Time Concepts for
Embedded Systems, CMP Books, Berkeley.
Sch
afer, P. A. (2007). Dynamic loading and linking
native code on a real-time operating system,
Dissertac
ao (mestrado em engenharia eletronica e ciencia da computac
ao), Instituto Tecnol
ogico de Aeron
autica, S
ao Jose dos Campos.
Souza, O. (2007). Metodologia para porte do sistema operacional Linux para sistemas embarcados, Dissertacao (mestrado em engenharia
de teleinformatica), Universidade Federal do
Ceara, Fortaleza.
Stankovic, J. A. and Rajkumar, R. (2004). Realtime operating systems, Kluwer Academic
Publishers 28: 237253.
Young, R. (2015). Porting a real-time operating
system and developing a board support package, Trabalho de conclusao de curso (graduacao em engenharia da computacao), University of Evansville, Evansville, IN, USA.

Main

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Main

Загружено:

Авторское право:

Доступные форматы

Universidade Estadual de Campinas

Faculdade de Engenharia Mecnica

Uma Metodologia de Porte de Sistema

Autor: Tiago Noboru Ukei

Universidade Estadual de Campinas

Uma Metodologia de Porte de Sistema

Trabalho de Concluso de Curso apresentado

Autor: Tiago Noboru Ukei

Dedico este trabalho minha famlia,

Se algum de vocs deficiente em sabedoria,

Exemplos de sistemas embarcados . . . . . . . . . . . . . . . . . . . . .

Diagrama de atividades da tarefa Task2 . . . . . . . . . . . .

GPOS General-Purpose Operating System

TSI Touch Sensing Input

APNDICE A DETALHES DE INSTALAO DO AMBIENTE

APNDICE C ARTIGOS . . . . . . . . . . . . . . . . . . . . . . . 106

Figura 1 Exemplos de sistemas embarcados. Fonte: Veerabahu (2011).

Em muitas dessas aplicaes, o tempo que os dispositivos de controle levam para

necessariamente pequeno, mas o resultado deve ser produzido dentro de um intervalo de

A partir do exemplo mencionado anteriormente, pode-se inferir que, durante a

1.3 Estrutura do documento

2.1 Sistemas embarcados de tempo real

Unidade de processamento microcontrolador, microprocessador;

Captulo 2. Reviso da literatura

Captulo 2. Reviso da literatura

Um conceito que no deve ser confundido que, se um sistema de tempo real, no

Sistemas embarcados de tempo real so sistemas embarcados que exibem

Figura 3 Sistemas embarcados de tempo real. Fonte: Li e Yao (2003, p. 19).

Captulo 2. Reviso da literatura

2.1.2 Classificao dos sistemas de tempo real

2.1.3 Propriedades fundamentais dos sistemas de tempo real

Captulo 2. Reviso da literatura

Eficincia. O sistema operacional deve possuir um gerenciamento eficiente dos

2.1.4 Fatores que influenciam a previsibilidade

Captulo 2. Reviso da literatura

Captulo 2. Reviso da literatura

Captulo 2. Reviso da literatura

suportar o desenvolvimento de aplicaes de tempo real, a exemplo da Real-Time Euclid,

2.2 Sistemas operacionais de tempo real

Captulo 2. Reviso da literatura

e uma estrutura robusta quando alguma alterao necessria durante a manuteno do

2.2.1 Principais caractersticas de um RTOS

2.2.2 Kernel: o ncleo de um RTOS

CHAPTER 6 Processes and Operating Systems

6.4.1 Two basic concepts

To make our operating system work, weRTOS

que mostra um exemplo de execuo preemptiva do sistema operacional (WOLF, 2012).

Os principais componentes do kernel de um RTOS so (LI; YAO, 2003):

Captulo 2. Reviso da literatura

Captulo 2. Reviso da literatura

Figura 7 Troca de contexto entre tarefas. Fonte: Li e Yao (2003, p. 70).

Em qualquer momento durante a execuo do RTOS, o fluxo de controle passa

Captulo 2. Reviso da literatura

Figura 8 Escalonamento preemptivo por prioridade. Fonte: Li e Yao (2003, p. 72).

A prioridade atribuda s tarefas no momento em que so criadas, mas podem

Captulo 2. Reviso da literatura

Figura 9 Round-robin e escalonamento preemptivo. Fonte: Li e Yao (2003, p. 72).

Captulo 2. Reviso da literatura

Figura 10 Estrutura de uma tarefa. Fonte: Li e Yao (2003, p. 81).

Na inicializao do kernel, so criadas as tarefas de sistema e alocadas as prioridades

Captulo 2. Reviso da literatura

Determina quantos tokens de

Figura 12 Estrutura de um semforo. Fonte: Li e Yao (2003, p. 96).

Captulo 2. Reviso da literatura