Desenvolvimento de Sistemas Embarcados U

CENTRO UNIVERSITÁRIO DO LESTE DE MINAS GERAIS
CURSO DE COMPUTAÇÃO SISTEMAS DE INFORMAÇÃO
DESENVOLVIMENTO DE SISTEMAS EMBARCADOS UTILIZANDO O

SISTEMA OPERACIONAL UCLINUX
Coronel Fabriciano
2004
ALAN CARVALHO DE ASSIS

Monografia apresentada ao Departamento de Com-

putação Sistemas de Informação do UnilesteMG,
como requisito para a obtenção parcial do grau de
bacharel em Computação Sistemas de Informação.
Orientador: Dr. Max Mauro Dias dos Santos
Coronel Fabriciano
2004
Assis, Alan Carvalho de
Desenvolvimento de sistemas embarcados utilizando o sistema ope-

racional uClinux / Alan Carvalho de Assis - 2004
45.p
1.Sistemas Embarcados 2. Linux.. I.Tı́tulo.

CDD: 536.7
CDU: 536.21
ALAN CARVALHO DE ASSIS

Monografia apresentada ao Curso de Computação

Sistemas de Informação do UnilesteMG, como re-
quisito para a obtenção parcial do grau de bacharel
em Computação Sistemas de Informação.
Aprovado em 13 de dezembro de 2004
Prof. Orientador Dr.Max Mauro Dias dos Santos

Titulação: Engenharia de Produção Industrial
Instituição: UnilesteMG
Prof.Elizabete Marinho Serra Negra

Titulação: Especialista em Perı́cia Contábil
Instituição: UnilesteMG
Prof.Nome do Examinador 3
Titulação: Não Disponı́vel
Instituição: Não Disponı́vel
À minha famı́lia.
Aos meus amigos.
À todas as pessoas que contibuiram para a re-
alização deste trabalho.
À PAZ.
Resumo
É inegável a revolução que o computador têm causado na sociedade contem-

porânea, e esta revolução está apenas começando, pois atualmente o computador está
sendo integrado em vários objetos de uso cotidiano. O expoente máximo deste tipo de
objetos é sem dúvida o telefone celular, que a cada dia agrega novos recursos e funções
que até então eram inimagináveis.
Estes objetos que incorporam um computador internamente receberam a de-
nominação especial de sistemas embarcados. Tais sistemas utilizam hardware e software
diferentes dos utilizados pelos computadores pessoais (PC). Normalmente possuem algu-
mas restrições como quantidade de memória, consumo de energia e poder de processa-
mento.
O software também precisa ser otimizado para tirar o máximo aproveitamento
do hardware, evitando o consumo excessivo de energia e inicializando o sistema no menor
tempo possı́vel.
Visando atender a estes objetivos, o Linux foi modificado para suportar os
vários tipos de hardware (microcontroladores e microprocessadores sem MMU) utilizados
em sistemas embarcados, surgia então o projeto uClinux (pronúncia-se you see linux ).
Este trabalho propõem a utilização do uClinux com uma plataforma para de-
senvolvimento de sistemas embarcados, apresentando um caso de estudo real da aplicação
do mesmo em uma placa embarcada da AvNet que utiliza o microcontrolador MCF5282
da Motorola.
Palavras-chaves: Sistemas Embarcados, uClinux, Linux, Microcontroladores.

Abstract
Nobody can deny the revolution that computer has made in our society in
currently days, but this revolution is in initial stage, because the computer is being inte-
grated in every objects around us. An object that better represent it is the cell phone,
this device is became more and more complex including new features that some times ago
nobody could imagine.
These objects that has a computer embedded is known as embedded systems.
Such objects use other kind of hardware and software than it used in personal compute
(PC). Normally have some constrains as amount of memory, power consumption and
processing power.
The software also need some optimizations to get the maximum hardware
benefit, preventing hight power consumption and starting the system so fast as possible.
Aiming to take care these objectives, the operating system Linux was modified
to get support to many kind of embedded hardware as microcontroller and microprocessor
without MMU, this project is known as uClinux.
This work suggest the use of uClinux as a platform to development of embedded
systems, showing a real case of study of an aplication using a embedded board from AvNet
Company, this board is use the Motorola MCF5282 microcontroller.
Keywords: Embedded Systems, uClinux, Linux, Microcontroller.

Agradecimentos
Agradeço a todos os integrantes do Laboratório de Sistemas de Tempo Real

(LTR) por estes dois anos de convivência e trocas de experiências, são eles(as) Antônio
Pedro, Fernando Henrique, Bruna, Ricardo, João, Rafael, Bruno, Taciane, Valdimar e
Pollyana.
Ao professor Dr. Max Mauro pela oportunidade de estar desenvolvendo pesquisa

e pela confiança depositada em mim.
Aos membros participantes da lista de discursão uclinux-dev pelo auxı́lio às

dúvidas que surgiram ao longo do meu aprendizado.
Ao Júlio, Lı́vio e Rafael da eletrônica da Unileste, pela prestatividade em

ajudar na realização da parte eletrônica deste projeto.
Ao amigo Marcelo Barros que sempre me ajudou com dicas e idéias legais, e
foi através dele que me interessei sobre sistema embarcados.
Á minha famı́lia que, apesar de todas as dificuldades, sempre me apoiou e me

deu forças para prosseguir.
E principalmente, à minha mãe, que nunca dormia até que eu chegasse em

casa. Se tem um culpado por eu ter chegado até aqui, este alguém é você MÃE ...
“Não interessa se você acredita ou não
na existência de Deus. O que interessa
é que você tenha um valor e que dê um
sentido a sua vida.”
−− Padre de Man
Lista de Figuras
1.1 Equipamentos que utilizam o Linux como sistema operacional embarcado. . 11

1.2 Pesquisa de mercado sobre a utilização do Linux em projetos embarcados . 12
1.3 uClinux em execução no Palm Pilot III . . . . . . . . . . . . . . . . . . . . 26
1.4 Vista superior da placa AvNet5282. . . . . . . . . . . . . . . . . . . . . . . 29
1.5 Diagrama interno do MCF5282 . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Diagrama esquemático do controle do motor . . . . . . . . . . . . . . . . . 54
4.2 Página CGI para controle dos LEds da placa . . . . . . . . . . . . . . . . . 59

4.3 LEDs da placa controlados por um CGI . . . . . . . . . . . . . . . . . . . 60
Lista de Tabelas
1.1 Tabela de classificação dos sistemas embarcados por tamanho . . . . . . . 15

1.2 Tabela do Mapa de Memória . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3 Limitações da versão gratuı́ta do kernel RTXC . . . . . . . . . . . . . . . . 31
Sumário
1 INTRODUÇÃO 9
1.1 Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.1 Classificação dos sistemas embarcados . . . . . . . . . . . . . . . . 13
1.1.2 Alguns sistemas operacionais embarcados comerciais . . . . . . . . . 16
1.2 O kernel Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.1 Caracterı́sticas do Linux . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.2 Vantagens do Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.3 Desvantagens do Linux . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3 O Sistema Operacional Embarcado uClinux . . . . . . . . . . . . . . . . . 25
1.4 A placa embarcada AvNet 5282 . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5 As licenças GPL e LGPL, e suas implicações . . . . . . . . . . . . . . . . . 32
2 PROCEDIMENTOS PARA INSTALAÇÃO DO uClinux NA PLACA

AVNET5282 34
2.1 Instalando o BDM-GDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.1.1 Testando e usando o GDB . . . . . . . . . . . . . . . . . . . . . . . 37
2.1.2 Executando um programa através do BDM . . . . . . . . . . . . . . 38
2.2 Instalando o bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3 Instalando o uClinux na BSP . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.3.1 Configuração e compilação do uClinux . . . . . . . . . . . . . . . . 46
2.3.2 Enviando a imagem do uClinux para a placa . . . . . . . . . . . . . 48
3 UMA MALHA DE CONTROLE USANDO A PLACA AVNET5282 54
4 DISCUSSÃO DOS RESULTADOS 57
ANEXOS 59
4.1 Anexo A. Controlando os LEDs da placa pelo browser . . . . . . . . . . . . 59
4.2 Anexo B. Foto da placa com os LEDs acesos . . . . . . . . . . . . . . . . . 60
4.3 Anexo C. Device Driver do LedMonitor . . . . . . . . . . . . . . . . . . . . 61
4.4 Anexo D. Arquivo fonte do CGI . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5 Anexo E. Device Driver do QADC . . . . . . . . . . . . . . . . . . . . . . 71
4.6 Anexo F. Aplicativo da Malha de Controle . . . . . . . . . . . . . . . . . . 78
REFERÊNCIA 86
1 INTRODUÇÃO
É crescente a utilização de sistema embarcados em aplicações domésticas,
médicas, industriais e militares. Sistemas embarcados (ou sistemas embutidos) são dis-
positivos eletrônicos que possuem um computador internamente, mas que não são vistos
como sendo um computador (WILMSHURST, 2001).
Estes sistemas são caracterizados por possuı́rem uma aplicação especı́fica,
por exemplo: telefones celulares, fornos micro-ondas, vı́deo cassetes inteligentes e au-
tomóveis. Tais sistemas surgiram da necessidade de substituir os controles mecânicos ou
eletromecânicos em máquinas usadas em aplicações industriais e domésticas.
Os sistemas embarcados são utilizados em vários objetos de uso cotidiano, e a
maioria das pessoas nem mesmo se dá conta de sua existência. São vastamente utilizados
em aplicações automotivas, pois, atualmente, todos os controles tendem a ser realizados
por sistemas eletrônicos, desde o sincronismo da centelha que queima o combustı́vel no
interior do pistão, à regulagem da inclinação da poltrona. Tudo isso é controlado por
sistemas embarcados.
Esta grande gama de aplicações dos sistemas embarcados tornam a programação
um tanto quanto complexa. Para simplificar o desenvolvimento destas, o desenvolvedor
poderá contar com o auxı́lio de um sistema operacional embarcado. Este sistema operacio-
nal deverá fornecer uma interface de programação de aplicações, Application Programming
Interface (API), que tornará tal tarefa menos árdua.
Existem vários sistemas operacionais para sistemas embarcados, por exemplo
o VxWorks da WindRiver, o WindowsCE da Microsoft, o PalmOS da Palm Computing
e o uC/OS-II da Micrum. O Linux não foi projetado visando o mercado de aplicações

10
embarcadas, porém, suas caracterı́sticas técnicas o qualificaram como uma opção real para
este mercado.
A criação do uClinux, que é uma modificação do kernel do Linux para su-
portar microprocessadores sem unidade de gerenciamento de memória (MMU), também
contribuiu muito para o crescimento do Linux em aplicações embarcadas.
O uClinux reúne todas as principais vantagens do Linux, como: excelente
suporte a rede, padrão POSIX, grande quantidade de programas, estabilidade, extensa
documentação, código fonte livre, entre outras.
Por estes motivos, e principalmente por não exigir pagamento de royaties, o
Linux (assim como o uClinux ) estão conquistando cada vez mais mercado. Vários fabri-
cantes de roteadores, DVDs, MP3 players estão incorporando o Linux em seus produtos.
Na Figura 1.1 pode ser visto alguns dispositivos que utilizam o Linux embar-
cado.
Segundo uma pesquisa de mercado realizada pelo Venture Development Cor-
poration (VDC) em jullho de 2004 com 27.000 desenvolvedores revelou que o Linux é o
sistema operacional embarcado mais utilizado em novos projetos (VDC, 2004).
A Figura 1.2 mostra o gráfico da pesquisa dos sistemas operacionais embarca-
dos mais utilizados em novos projetos.
O crescimento do Linux como sistema operacional embarcado foi a causa inicial
para o desenvolvimento deste trabalho. Os seguintes tópicos serão abordados: sistemas
embarcados, o uClinux, e um estudo de caso de uma aplicação utilizando uma placa
embarcada que utiliza o uClinux como sistema embarcado.

11
Figura 1.1: Equipamentos que utilizam o Linux como sistema operacional embarcado.
Fonte: www.linuxdevices.com
1.1 Sistemas Embarcados
Sistemas embarcados são sistemas construı́dos para aplicações especı́ficas. Estes
sistemas possuem como caracterı́sticas principais o baixo custo e o reduzido consumo de
energia. Objetivando criar sistemas de baixo custos, geralmente são utilizados disposi-
tivos com pouca quantidade de memória e com limitado poder de processamento, embora
a tendência atual é o uso de processadores mais rápidos.
Vários são os fatores que permitiram o surgimento dos sistemas embarcados
modernos, será apresentado a seguir, cronologicamente, o seu desenvolvimento.

12
Figura 1.2: Pesquisa de mercado sobre a utilização do Linux em projetos embarcados.
Fonte: www.vdc-corp.com
O transistor foi inventado pela Bell Labs em 1947 (MASSEY, 1997) e em 1958
vários transistores foram integrados numa única pastilha, surgia então o Circuito Inte-
grado (CI) criado pela Texas Instruments (KILBY, 2002).
Mas o principal fator que permitiu a disceminação dos sistemas embarcados
foi a criação do microprocessador pela empresa Intel em 1971 (INTEL, 1971). O primeiro
microprocessador criado foi o 4004, este microprocessador possuı́a 2250 transistores inte-
grados numa única pastilha de silı́cio.
Inicialmente não eram previstas muitas utilidades para os microprocessadores,
seu uso estava restrito às calculadoras e pequenos microcomputadores que começaram a
surgir depois de sua criação (ZELENOVSKY; MENDONCA, 1999).
Porém, em pouco tempo, os microprocessadores começaram a ser utilizados
em produtos que aparentemente não eram vistos com sendo um computador, por exem-
13
plo: impressoras e fotocopiadoras. Eram sistemas simples, possuindo basicamente um
microprocessador, algumas memórias e alguns periféricos como interface serial, conversor
analógico/digital e digital/analógico.
Estes sistemas, apesar de simples, necessitavam de alguns chips além do micro-
processador, o que elevava o preço final do sistema, aumentava a complexidade da placa
de circuito impresso, aumentava o consumo de energia, etc.
Visando reduzir o consumo de energia, o espaço fı́sico e a complexidade dos
circuitos, a memória e alguns periféricos foram integrados dentro do chip com o micro-
processador. Tais chips receberam o nome de microcontroladores, e os sistemas que eram
controlados por estes receberam o nome de sistemas embarcados.(WILMSHURST, 2001)
1.1.1 Classificação dos sistemas embarcados
Embora os sistemas embarcados possam ser classificados pela área de aplicação
como automotiva, aeronáutica, telecomunicações, produtos eletrônicos de consumo, entre
outras, esta classificação não provê informações das caracterı́sticas de cada sistema.
Uma forma adequada de classificação é a que leva em conta as caracterı́sticas
peculiares de cada sistema desenvolvido, como por exemplo, tamanho do sistema, restri-
ções temporais, suporte a rede e grau de interação com o usuário (YAGHMOUR, 2003).
• Tamanho do sistema
Esta classificação não envolve o tamanho fı́sico em si, uma vez que sistemas
embarcados podem ser tão pequenos a ponto de serem utilizados em relógios de pulso ou
tão grande a ponto ocuparem prédios inteiros como os sistemas de clusters.

14
Esta classificação envolve o tamanho ou a capacidade dos componentes eletrônicos
do sistema, como por exemplo, o poder de processamento da Unidade Central de Proces-
samento (CPU), a quantidade de memória RAM do sistema, a quantidade de memória de
armazenamento permanente (ROM, Flash, disco). Segundo esta caracterı́stica os sistemas
embarcados podem ser classificados em pequenos, médios ou grandes.
Os sistemas embarcados pequenos utilizam processadores com de baixa veloci-
dade (menos de 100MHz), com pouca quantidade de memória RAM (menos de 4MB) e
com pouco espaço para armazenamento permamente (menos de 2MB). Removendo alguns
recursos do kernel do Linux e utilizando um sistema de arquivo com poucos aplicativos ele
poderá suportar tais sistemas. O uClinux é o mais indicado para este tipo de aplicação,
juntamente com o pacote de aplicativos BusyBox.
Já os sistemas embarcados médios utilizam processadores com velocidade in-
termediária (entre 100 e 700MHz), com razoável quantidade de memória RAM (em torno
de 64MB) e com um espaço para armazenamento permanente de aproximadamente 32MB.
Este sistemas são os encontrados em PDAs, Web Appliencies, roteadores, tocadores de
MP3, etc. O uso do Linux é mais difundido neste tipo de sistema.
Por fim, os sistemas embarcados grandes são sistemas que possuem proces-
sadores muito rápidos ou que possuem vários processadores trabalhando em paralelo.
Geralmente são utilizados para aplicações que envolve intensivos cálculos matemáticos.
Este nicho de mercado também é suportado pelo Linux, a IBM desenvolve
vários supercomputadores com milhares de processadores paralelos utilizando o Linux
como sistema operacional. O computador mais rápido do mundo atualmente, segundo
www.top500.org, é o Blue Gene da IBM que roda Linux (GILL, 2002).
Na Tabela 1.1 é apresentado de forma resumida a classificação dos sistemas

15
embarcados por tamanho.
Tabela 1.1: Tabela de classificação dos sistemas embarcados por tamanho
Tipo CLOCK RAM ROM
Pequeno < 100MHz < 4MB < 2MB
Médio ∼ 500MHz ∼ 64MB ∼ 32MB
Grande > 1GHz > 1GB > 512MB
• Restrições temporais
Alguns sistemas embarcados precisam responder corretamente em um perı́odo
de tempo predefinido, nestes sistemas o não cumprimento ou o atraso de uma tarefa pode
causar resultados catastróficos, inclusive com perda de vidas humanas.
Os sistemas embarcados com paradigma de tempo real rı́gido geralmente são
utilizados em aplicações crı́ticas como na industria aeronáutica, automotiva, controle de
usinas nucleares, entre outras. O acionamento do air-bag no momento de uma colisão é
um exemplo onde deve-se empregar um sistema embarcado de tempo real, uma vez que
o atraso na resposta não pode ser admitido.
Existem aplicações que também necessitam de uma resposta em um perı́odo
de tempo predefinido, mas que seu não cumprimento não envolve perdas maiores, tais
sistemas são chamados de tempo real leve ou brando. Um exemplo de tal aplicação é a
transmissão de vı́deo por uma rede, o ideal é que não haja atrasos, mas o atraso de alguns
frames é tolerável.
• Suporte a rede
Atualmente todo tipo de dispositivo pode ter suporte a rede, isto facilita a
monitoração e controle do mesmo a distância. Várias caracterı́sticas tornam o suporte a

16
rede importante, como velocidade de transmissão e recebimento de dados, baixo custo,
interoperabilidade com computadores e outros dispositivos, etc.
O suporte a rede são limita-se apenas ao padrão Ethernet, uma vez que os
dispositivos que possuam suporte à wireless ou bluetooth podem acessar a rede de forma
semelhante e com a vantagem da mobilidade e ausência de cabos.
Uma vez que vários dispositivos embarcados possuam suporte a rede, eles
poderão ser integrados de forma a gerar uma maior redundância à falha e falta, como
também serem integrados de forma a gerar um sistema altamente distribuı́do.
• Interação com o usuário
O grau de interação com o usuário pode variar radicalmente de um sistema
para outro. Alguns sistemas são totalmente voltados para a interação com o usuário,
como por exemplo os PDAs. Outros sistemas poderão possuir alguns poucos botões e
LEDs indicando o estado do dispositivo ou nem mesmo possuir interação com o usuário.
Existem dispositivos que apesar de não possuı́rem nenhum tipo aparente de
interação com o usuário, podem ser controlados e configurados através de terminais seriais
(serial console) ou através da interface de rede, neste último caso o dispositivo possui
internamente um mini servidor web e o usuário poderá acessá-lo através de um navegador
para realizar as modificações necessárias.
1.1.2 Alguns sistemas operacionais embarcados comerciais
Existem vários sistemas operacionais embarcados disponı́veis no mercado, mas
em geral cada um domina um nicho de mercado muito especı́fico.

17
O VxWorks é o mais usado na maioria das aplicações embarcadas, mas na área
de dispositivos móveis como palmtops e celulares não tem grande participação.
Nesta seção será apresentada uma visão superficial dos três principais sistemas
operacionais embarcados mais usados no mercado atualmente. Um visão mais detalhada
foge do escopo deste trabalho.
• Windows CE
O Windows CE da Microsoft é uma versão reduzida e modificada do sistema
operacional Windows da mesma empresa. O sufixo CE não tem uma significação especial,
algumas pessoas acreditam que ela possa significar Consumer Electronics ou Compact
Edition.
O Windows CE foi reduzido para rodar em dispositivos com pouca quantidade
de memória RAM e armazenamento. O Windows CE pode executar em dispositivos com
no mı́nimo 2MB de memória RAM e 4MB de memória ROM (PALMLAND, 2002).
O Windows CE suporta aplicações de tempo real, possuindo 256 nı́veis de
prioridades. Ao contrários dos UNIX’s a unidade funtamental de execução é a thread.
Até a versão 3.0 a Microsoft disponibilizava o código fonte apenas para as fa-
bricantes de dispositivos embarcados que utilizavam o Window CE e que pagavam licença
de uso para tal, mas a partir desta versão ela passou a disponibilizar o código fonte para
qualquer desenvolvedor interessado.
Porém o fato de disponibilizar o código fonte não significa que ela o tenha tor-
nado o sistema um software livre, pelo contrório, qualquer empresa que queira desenvolver
um produto utilizando o Windows CE deverá pagar royalties à Microsoft.
O sistema é largamente utilizado em handheld’s, tendo também uma boa par-

18
ticipação nos dispositivos smartphone’s.
• VxWorks
O VxWorks é um sistema operacional embarcado desenvolvido pela empresa
californiana Wind River Systems. Ele é um dos sistemas embarcados mais utilizado no
mundo.
É largamente utilizado em aplicações médicas, equipamentos de rede, equipa-
mentos de empresas de telecomunicações, dispositivos para Internet, sistemas de defesa,
aerospacial, industrial, sistemas médicos e equipamentos de imagem digital (MISTRAL,
2002).
O VxWorks é também um sistema operacional de tempo real, sendo caracte-
rizado como um sistema operacional embarcado pequeno, rápido e preciso. Este sistema
trabalha com módulos para suporte a rede, gráficos, email, web, automotivos e defesa.
A sonda espacial Pathfinder enviada a marte pela agência espacial americana
(NASA) utilizava o VxWorks. Durante seu funcionamento em marte ocorreu um problema
de inversão de prioridade causado pela escalonador do sistema (JONES, 1997).
Uma exemplo prático de uso do VxWorks como produto embarcado é o modem
ADSL SpeedStream, este modem é oferecido por vários provedores de ADSL aos seus
clientes, especialmente pelo Velox da Telemar.
• QNX
O QNX é um sistema operacional embarcado de tempo real que utiliza um
microkernel, ou seja, um kernel muito simples com apenas as funções primordiais como
controle de processos, comunicação inter-processos, etc. As demais funções são executadas

19
como serviços, assim, caso ocorra o travamento de um destes serviços, o sistema não será
paralisado.
Este sistema provê multi-tarefa, escalonador preemptivo, nı́veis de prioridades
entre tarefas e troca de contexto muito rápida. É altamente configurável, possibilitando
ao desenvolvedor selecionar uma vasta gama de recursos para o sistema final.
O microkernel do QNX é conhecido como Neutrino, e o sistema todo é muito
pequeno, para se ter uma idéia, no site do fabricante há uma versão com suporte a modo
gráfico, conexão dial-up e navegador para Internet que cabe é único disquete de 1.44 MB.
O QNX possui 64 nı́veis de prioridades, as threads podem assumir prioridade
de 1 a 63 (prioridade mais alta), uma thread especial chamada idle recebe a prioridade 0
e é sempre executada quando não há nenhuma outra tarefa em execução (QNX, 2004).
O QNX é gratuito para fins acadêmicos e não comerciais, para outras aplicações
deve-se adquirir licença de uso e os devidos pagamentos de royalties.
1.2 O kernel Linux
O Linux é o kernel criado em 1991 pelo finlandês Linus Torvalds, na época
ele possuia apenas 21 anos de idade. Linus pretendia com isso aprender mais sobre a
arquitetura de 32 bits dos computadores IBM PCs 386 e criar um sistema operacional
semelhante ao UNIX, mas com o código fonte livre para quem desejasse modificá-lo (TOR-
VALDS; DIAMOND, 2001).
Linus havia divulgado na Usenet (rede de computadores que antecedeu à Inter-
net) que ele estava criando um sistema operacional, mas que este ainda estava em estado
inicial de desenvolvimento. Em pouco tempo, vários programadores se interessaram pelo

20
projeto.
A primeira versão do Linux (versão 0.01) foi disponibilizada para download no
dia 17 de setembro de 1991, Linus pretendia utilizar o nome Freax para o sistema ope-
racional que ele havia criado, mas um amigo que disponibilizou o arquivo para download
não gostou do nome e resolveu colocar o código fonte dentro de um diretório com o nome
Linux, este fato acabou marcando o surgimento do nome Linux.
Como a quantidade de programadores interessados em ajudar no desenvolvi-
mento do Linux estava aumentando, Linus resolveu licenciar o código fonte sob a licença
GNU General Public License (GPL), assim ele garantia que o código fonte permaneceria
livre e que todas as modificações realizadas seriam disponibilizadas para a comunidade
(TORVALDS, 2004).
1.2.1 Caracterı́sticas do Linux
O Linux possui suporte às principais caracterı́sticas das versões comerciais de
UNIX, além de suportar e incluir caracterı́sticas das API’s BSD e Unix System V. Também
implementa a especificação Portable Operating System Interface for Unix (POSIX), as-
sim aplicativos escritos seguindo esta especificação poderão facilmente ser portados para
outros sistemas operacionais que também a implementem (NIKKANEN, 2003).
Algumas das principais caracterı́sticas do Linux serão descritas nos tópicos a
seguir (ABBOTT, 2003).
• Multitarefa - o Linux possui um escalonador que é capaz de trabalhar com várias
tarefas simultaneamente, e ainda possui nı́veis de prioridade entre taferas. Assim
uma tarefa de prioridade maior poderá interromper a execução de uma tarefa de

21
menor prioridade, desde que a tarefa de menor prioridade não esteja executando
uma chamada ao sistema (system call).
• Multi-usuário - significa que vários usuários registrados no sistema podem acessar
simultaneamente o computador, cada usuário terá seu próprio ambiente com seus
dados privados.
• Multi-processamento - o Linux possui suporte a computadores com vários proces-
sadores, assim dois ou mais processos podem ser executados realmente paralela em
processadores distintos. O fato de possuir suporte a multi-processamento simétrico
(SMP) o torna apropriado para utilização em supercomputadores.
• Memória protegida - no Linux cada processo é executado em um espaço de memória
próprio, assim um processo não poderá interferir em outro. Esta proteção é realizada
pela unidade de gerenciamento de memória (MMU), e o processo que tentar invadir
a região de memória de outro é terminado imediatamente e uma notificação é gerada
pelo sistema operacional.
• Sistema de Arquivo Hierárquico - o Linux implementa vários sistemas de arquivos,
e, como todo sistema operacional moderno, suporta sistema de arquivos hierárquico,
ou seja a partir do ponto de montagem inicial (\) podem existir vários subdiretórios
organizados hierarquicamente. Possui suporte ainda a links que funcionam como
atalhos para outros arquivos e suporte a device file que permite mapear vários
dispositivos no próprio sistema de arquivo, assim os aplicativos podem ler ou escrever
num dispositivo qualquer da mesma forma que o fazem com arquivos comuns.
• Memória virtual - a memória virtual é um recurso que permite ao sistema operacional
utilizar mais memória do que a quantidade de memória RAM disponı́vel. O truque
consiste em usar o disco rı́gido como uma área para armazenar temporariamente
22
parte da memória RAM que foi alocada por um aplicativo, mas que não está em
uso num determinado momento. Assim, qualquer aplicativo que precise de memória
utilizará a área de memória RAM daquele programa, pois seu conteúdo foi salvo no
disco.
1.2.2 Vantagens do Linux
Algumas da vantagens do Linux se confundem com as próprias caracterı́sticas
do mesmo, como visto na Seção 1.2.1, por exemplo excelente suporte a rede, multi-usuário
e grande estabilidade (VANDERWIELE; SCOTT, 2003).
Outras vantagens são inerentes ao modelo de desenvolvimento e da tecnologia
utilizada, a licença GPL adotada pelo Linux, garante ao usuário o direito de usar o
aplicativo para quaisquer fins, de copiar e utilizar em quantos computadores ele desejar,
de modificar o aplicativo segundo sua necessidade e de distribuir as modificações realizadas
por ele.
O Linux possui milhares de aplicativos desenvolvidos pela comunidade de soft-
ware livre, o que significa dizer que o usuário poderá contar com inúmeros programas
gratuı́tos que podem ser baixados pela Internet. Por ser um clone do UNIX, o Linux
pode rodar aplicativos comerciais desenvolvidos para aquele sistema sem nenhuma modi-
ficação.
A simplicidade de funcionamento dos aplicativos tornam o trabalho mais pro-
dutivo. No Linux, assim como no UNIX, cada aplicativo executa apenas a função que
lhe é cabı́vel, por exemplo o comando para listar arquivos (ls) apenas lista arquivos, se
o usuário desejar listar em ordem alfabética ou em ordem inversa, deverá redirecionar a

23
saı́da deste para o programa que ordena (sort).
Devido ao fato do Linux e dos aplicativos desenvolvidos para este possuirem
o código fonte aberto, o usuário poderá customizar o sistema segundo sua necessidade.
Esta caracterı́stica de modificação segundo a necessidade do usuário é uma das maiores
vantagens do Linux.
Um fator importante para o desenvolvimento do Linux e dos aplicativos usado
por este é a fato de possuir milhares de desenvolvedores e usuários voluntários para testar
o sistema e revisar o código escrito por outros. Quando o usuário encontra um BUG no
programa ele é estimulado a enviar a informação diretamente ao mantenedor do programa,
e em geral, o programa é corrigido em seguida.
São estas comunidades de desenvolvendores e voluntários que lotam listas e
fóruns de discussões que promovem a difusão do Linux na medida em que ajudam os
novos usuários a resolver seus problemas e tirar suas dúvidas. Quando um usuário Linux
encontrar um problema em seu sistema a primeira atitude correta a tomar é procurar nos
sistemas de buscas da Internet, pois, muito provavelmente, outra pessoa já passou pelo
mesmo problema e alguém postou a resolução daquele problema numa lista de discussão.
Estas vantagens aliadas à não cobrança de royalties tem contribuı́do para que o
Linux seja adotado em várias organizações e governos de várias partes do mundo, inclusive
pelo governo Brasileiro.
1.2.3 Desvantagens do Linux
O Linux, assim como todo sistema operacional, possui vantagens e também
desvantagens. Teoricamente o fato de possuir o código fonte aberto permite que terceiros
24
procurem por falhas no sistema e possam explorar tais falhas para proveito próprio. Na
prática não se tem notı́cias de nenhum caso onde isto tenha acontecido.
O fato da maioria dos desenvolvedores gostarem mais de programar, de que
documentar seu trabalho, gera o problema da falta de documentação ou de pouca docu-
mentação para alguns aplicativos. Este problema vem sendo aos poucos resolvido através
de empresas que vendem distribuições Linux e que pagam pessoas apenas para documentar
alguns aplicativos.
Para o usuário final o maior problema do Linux é a amigabilidade do sistema,
isto porque o sistema foi desenvolvido deste o inı́cio no estilo ‘de programador para progra-
mador’. Geralmente o usuário tem que decorar enormes linhas de comando para instalar
ou configurar um determinado aplicativo, ou seja, a curva de aprendizado do Linux é
maior que de alguns sistemas operacionais mais amigáveis.
Embora este cenário ainda seja maioria, a tendência é que o sistema torne-
se mais simples a cada ano. Várias distribuições já possuem suporte plug and play que
encontram e configuram os dispositivos do computador. A própria instalação destas dis-
tribuições são bem simples de executar, o que permite a instalação do sistema até por
usuários leigos em informática.
Outro fator negativo é a falta de alguns aplicativos comercias largamente uti-
lizados no Windows e MacOS, isto é causado pelas empresas de software comerciais que
não desenvolvem seus aplicativos para Linux por não acreditar na demanda por tais
aplicativos ou porque a base instalada de usuários Linux é pequena.
Para as empresas que desenvolvem software a barreira pode ser a própria
GPL. Se uma empresa desejar criar uma aplicação baseada em outra aplicação que esteja
licenciada sob licença GPL ou se apenas compilar seu aplicativo utilizando a biblioteca
25
libc que esteja sob GPL, devera disponibilizar todo o código fonte de sua aplicação.
Para contornar este problema qualquer empresa comercial poderá utilizar bi-
bliotecas licenciadas sob a LGPL, assim poderá manter fechado o código de seu aplicativo.
A Free Software Foundation não incentiva a utilização da licença LGPL uma vez que esta
licença não induz o desenvolvimento colaborativo, que é uma caracterı́stica da GPL, ver
Seção 1.5.
Ao contrário dos demais sistemas UNIX que possuem um kernel muito grande,
o Linux é um sistema pequeno, um sistema completo com o kernel e alguns aplicativos
básicos pode ser facilmente integrados em um único disquete.
O kernel do Linux possui suporte a módulos, o que permite uma maior redução
do kernel, uma vez que os módulos ficam em arquivos separados, e só serão utilizados pelo
kernel quando necessário. São estas caracterı́stica, já citadas anteriormente, que tornaram
o Linux um forte concorrente na arena de sistemas embarcados.
1.3 O Sistema Operacional Embarcado uClinux
O uClinux é uma modificação do núcleo (kernel) do Linux para que este su-
porte microcontroladores e microprocessadores sem MMU. O projeto uClinux teve inı́cio
em 1997 com o objetivo de portar o kernel 2.0 do Linux para o processador Motorola
MC68328 DragonBall.
O projeto foi iniciado por Jeff Dionne e Kenneth Albanowski contando com
a colaboração de vários programadores (ASSIS; BARROS, 2003). A primeira versão do
uClinux foi liberada em 1998 e seu funcionamento foi demonstrado na arquitetura 3Com
PalmPilot, usando a placa de desenvolvimento TRG SuperPilot.

26
Na Figura 1.3 é apresentado o uClinux em execução no TRG SuperPilot
(Palm Pilot III), este dispositivo utiliza o microcontrolador Motorola DragonBall-EZ
MC68EZ328 operando a 16MHz, possuindo 8MB EDO DRAM e 2MB FLASH, display
monogramático 160x160 LCD, interface de infravermelho IrDA, interface serial RS232 e
tela sensı́vel ao toque (touch screen).
Figura 1.3: uClinux em execução no Palm Pilot III. Fonte: www.uclinux.org
Desde então o uClinux vem evoluindo rapidamente e hoje já suporta vários
processadores sem MMU, como por exemplo: M68K, Coldfire, ARM, PowerPC, Micro-
Blaze, NIOS e OpenRISC.
O tamanho de um sistema baseado no uClinux é bem reduzido, esta é uma car-
acterı́stica importante para aplicações embarcadas. Segundo (WEHRLI, 2002) um sistema
embarcado baseado no uClinux com o mı́nimo de recursos necessita de 600KB de RAM,
mas (UNGERER, 2004) conseguiu criar um sistema ainda menor, com apenas 256KB,
para o GameBoyAdvanced.
Além de possuir um tamanho reduzido, o uClinux implementa as APIs padrões
do Linux com poucas modificações, o que permite o porte de aplicativos escritos para o
Linux com relativa facilidade. Em alguns casos basta recompilar o aplicativo para tê-lo
funcionando no uClinux, embora na maioria dos aplivativos deve-se substituir algumas

27
funções por equivalentes, como a fork pela vfork.
A principal caracterı́stica de um sistema embarcado baseado no uClinux é o
suporte a rede. O uClinux implementa o protocolo TCP/IP por completo, além de vários
outros protocolos, sendo de fato um sistema operacional embarcado pronto para a Internet
(VENKATAKRISHNAN, 2003).
Os sistemas embarcados desenvolvidos usando o uClinux normalmente utilizam
uma biblioteca de linguagem C de tamanho reduzido, conhecida como uClibc, por isso
aplicativos que são portados do Linux ficam menores no uClinux. Outras bibliotecas
também podem ser utilizadas como a glibc e newlib.
Outro fator importante é a quantidade de sistemas de arquivos suportados,
como por exemplo os sistemas FAT16/32, NFS, EXT2, EXT3 e JFFS2. Através do
sistema de arquivo JFFS2 o uClinux pode trabalhar com a memória flash tanto para
leitura quanto para escrita, assim os aplicativos podem escrever na flash da mesma forma
que o fazem com o disco rı́gido.
Estas caracterı́sticas têm contribuı́do para que o uClinux seja adotado em
vários dispositivos comerciais como roteadores, DVDs players, celulares e muitos outros
dispositivos eletrônicos.
1.4 A placa embarcada AvNet 5282
A placa AvNet 5282 utiliza como unidade central de processamento o micro-
controlador Motorola MCF5282, da famı́lia ColdFire. Esta placa possui várias inter-
faces e recursos necessários à execução de um sistema embarcado moderno e destinado à
aplicações em rede, tais como:

28
• Processador Motorola Coldfire MCF5282;
• Interface Ethernet 10/100 Mbps;
• 2 portas seriais RS-232;
• Interface CAN (Controller Area Network );
• 16 Mbytes de memória SDRAM;
• 8 Mbytes de memória Flash;
• Conector BDM/JTAG;
• Conversor Analógico/Digital de 8 canais/10 bits (QADC);
• Queued SPI (Serial Peripheral Interface);
• Porta I2C (Inter Integrated Circuit);
• Conector de expansão (AvBus).
Além da memória disponı́vel na placa, o próprio microcontrolador MCF5282
possui internamente 512KB de Flash e 64KB de SRAM.
Na Figura 1.4 é apresentada a placa AvNet5282.
O MCF5282 foi o primeiro microcontrolador na Motorola a utilizar em um
único circuito integrado (CI) a interface de rede Ethernet, a interface de rede CAN e
memória FLASH, isto possibilita que diversas aplicações para controle industrial possam
ser desenvolvidas e integradas num único CI, e ainda possam ser controladas remota-
mente de qualquer lugar do mundo através da Internet ou outra rede que utilize o padrão
Ethernet.
29
Figura 1.4: Vista superior da placa AvNet5282. Fonte: www.avnet.com
Este processador enquadra-se na categoria Reduced Instruction Set Computer
(RISC), assim cada instrução gasta apenas um único ciclo de máquina para ser executada
(RISC, 2004), o que permite a este processador atingir a marca de 60 MIPS rodando a
66MHz.
Os 512KB de memória FLASH e os 64KB de memória RAM do processador
MCF5282 são suficientes para algumas aplicações simples, porém para utilizar um sistema
operacional multitarefa esta quantidade de memória é insulficiente. Para resolver este
problema a AvNet acrescentou mais 16MB de memória SDRAM e 8MB de memória
FLASH na placa.
O mapa de memória da placa AvNet 5282 pode ser visualizado na Tabela 1.2
Tabela 1.2: Tabela do Mapa de Memória

INÍCIO FIM DESCRIÇÃO
FF80 0000 FFFF FFFF Flash Externa
F000 0000 F007 FFFF Flash Interna
4000 0000 IPSBAR
2000 0000 2000 FFFF SRAM Interna
0000 0000 00FF FFFF SDRAM Externa
30
A placa AvNet 5282 é uma plataforma de referência para o desenvolvimento
de aplicações embarcadas que utilizem o microcontrolador Motorola MCF5282 como foco.
Uma vez que esta placa inclui todos os dispositivos da camada fı́sica (PHY), o desenvolve-
dor poderá criar qualquer aplicação envolvendo Ethernet 10/100Mps, UARTs, CAN, QSPI
e QADC.
Na Figura 1.5 pode ser visto o diagrama interno do MCF5282 com todas as
caracterı́sticas deste circuito integrado.
Figura 1.5: Diagrama interno do MCF5282. Fonte: www.freescale.com

31
Acompanha a placa um programador BDM da P&EMicro, através deste o
desenvolvedor poderá ter acesso direto aos registradores e à memória da placa. Neste
trabalho o programador BDM é utilizado para enviar o bootloader para a memória da
placa AvNet5282.
A AvNet fornece um kit contendo, além da placa e do programador BDM, uma
versão de demonstração por 30 dias da IDE CodeWarrior da Metrowerks, nela é possı́vel
encontrar vários exemplos de aplicativos para a placa AvNet5282. Porém, por tratar-se
de uma IDE comercial de custo alto, não foi utilizada, dando preferência às soluções em
software livre (GNU).
A placa é vendida com o sistema operacional de tempo real RTXC da Quadros
gravado na memória FLASH interna do processador, porém, neste trabalho, o RTXC foi
removido e substituı́do pelo uClinux, eliminando assim as limitações impostas pela versão
gratuı́ta deste RTOS, ver Tabela 1.3.
Tabela 1.3: Limitações da versão gratuı́ta do kernel RTXC

Recursos disponı́veis no kernel RTXC Estático Dinâmico
Nı́veis 2 N/A
Threads 6 N/A
Tarefas 1 1
Exceções 2 1
Semáforos 3 2
Fontes de eventos 1 1
Contadores 2 1
Alarmes 3 1
Pipes 1 1
Filas 1 1
Mailboxes 1 1
Partições de memória 2 1
Mutexes 1 1
Atualmente vários sistema operacionais embarcados estão disponı́veis para a
placa AvNet 5282, para citar alguns: eCos, RTEMS, uC/OS-II, SMX, além é claro do
32
uClinux.
1.5 As licenças GPL e LGPL, e suas implicações
A licença GPL foi criada por Richard Stallman, presidente da Free Software
Foundation (FSF), visando garantir a liberdade do usuário e incentivar o compartil-
hamento de conhecimento entre as pessoas.
Em termos gerais, a GPL baseia-se nas 4 liberdades (GPL, 2004):
1. A liberdade de executar o programa, para qualquer propósito (liberdade no. 0)
2. A liberdade de estudar como o programa funciona, e adaptá-lo para as suas ne-
cessidades (liberdade no. 1). Acesso ao código-fonte é um pré-requisito para esta
liberdade.
3. A liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo
(liberdade no. 2).
4. A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de modo
que toda a comunidade se beneficie (liberdade no. 3). Acesso ao código-fonte é um
pré-requisito para esta liberdade.
Desta forma a licença GPL assegura que o programa desenvolvido por uma
determinada pessoa possa ser distribuı́do e reaproveitado por várias outras, mas mantém
os direitos do autor, impedindo que o programa seja utilizado de maneira indevida.
A licença também protege o programador, evitando que seu programa seja
apoderado por outra pessoa. Por ser uma licença válida na constituição estadunidense,
33
sua abrangência é válida a todos os paı́ses que aceitam o acordo internacional de respeito
a patentes e direitos autorais.
A GPL permite que o desenvolvedor possa criar modificações para uso pessoal
sem a necessidade de disponibilizar o código fonte, porém se ele distribuir ou vender o
programa modificado, deverá enviar junto o código fonte com as modificações, do contrário
estará violando a licença.
O programador deve conhecer bem a licença GPL para cumprir com seus
deveres e obrigações, sabendo que todo trabalho derivado de outro trabalho sob licença
GPL também deverá ser licenciado sob GPL.
Considera-se como trabalho derivado a inclusão de código fonte de programa
sob licença GPL em outro programa, seja a inclusão de código fonte original ou modificado.
Isto obriga a toda e qualquer pessoa ou empresa, que fizer modificações ou melhorias em
um software GPL, a disponibilizar tais modificações para a comunidade.
Também considera-se trabalho derivado a ligação (linkage) estática ou dinâmica
de programa à bibliotecas que estejam licenciadas sob licença GPL. Este fato a princı́pio
impede que empresas que possuam segredos tecnológicos ou patentes desenvolvam pro-
gramas que utilizem as bibliotecas GNU.
Para contornar este problema a Free Software Foundation criou a licença Lesser
General Public License (LGPL). Esta licença é semelhante à GPL, porém permite a
ligação de código livre com código proprietário, sem torná-lo livre à força.
Portanto o desenvolvedor de sistemas embarcados deverá ficar atento à questão
do trabalho derivado, e caso tenha que desenvolver soluções que não possam ser disponi-
bilizadas como software livre, deverá optar por usar a bibliotecas sob licença LPGL.
2 PROCEDIMENTOS PARA INSTALAÇÃO DO UCLINUX NA PLACA
AVNET5282
A placa alvo utilizada nesta pesquisa é conhecida como Motorola Coldfire Eval-
uation Kit ou simplesmente AvNet5282, possuindo uma interface de depuração conhecida
como Background Debug Mode (BDM). Através desta interface, pode-se enviar qualquer
programa diretamente à memória RAM da placa e iniciar seu processamento em seguida,
o que acelera em muito o tempo de testes e de desenvolvimento.
Para a instalação do uClinux na placa AVNET5282 os seguintes passos foram
realizados:
1. Instalação do bootloader U-Boot na placa
2. Configuração e compilação do uClinux
3. Envio da imagem do uClinux compilada para a placa
4. Inicialização do uClinux para verificar seu funcionamento
5. Criar uma imagem compactada para ser gravada na FLASH
Para instalar o bootloader U-Boot na placa é necessário compilar o GNU De-
bugger (GDB) com um patch aplicado para que o mesmo tenha suporte ao BDM, como
verá visto na Seção 2.1. Com o GDB suportando a interface BDM é possı́vel enviar o
U-Boot para a placa como apresentado na Seção 2.2.
A configuração e compilação do uClinux é apresentado na Seção 2.3.1, onde
também é explicado passo-a-passo quais aplicativos devem ser instalados, além é claro da
configuração básica para a placa AVNET5282.

35
2.1 Instalando o BDM-GDB
Inicialmente deve-se baixar o GDB e os patches para suportar a interface BDM.
Baixe do site http://sourceforge.net/projects/bdm/ os arquivos:
bdm-gdb-20030717.tar.gz
gdb-5.3-m68k.patch
Baixe do site GNU, www.gnu.org, o arquivo:
gdb-5.3.tar.gz
Descompacte o arquivo do BDM:
tar -zxvf bdm-gdb-20030717.tar.gz
Para o processador MCF5282 é necessário realizar uma modificação no código
fonte, pois o registrador RAMBAR (usado para controle da memória RAM interna) teve
seu número alterado em relação aos processadores anteriores.
Modifica-se o arquivo ‘bdm-gdb-20030717/m68k/driver/bdm.c’ na linha 1230:
0xc04, /* BDM_REG_RAMBAR */
Alterando-a para:
0xc05, /* BDM_REG_RAMBAR */
Finalmente pode-se compilar o BDM:
cd bdm-gdb-20030717/m68k/
36
./local_scripts/build-it
cd driver/linux
make install
Também é necessário instalar a biblioteca do BDM para ser usada pelo GDB:
cd bdm-gdb-20030717/m68k/lib
make
make install
Após instalar o BDM, segue-se com a instalação do GDB, descompactando o
arquivo:
tar -zxvf gdb-5.3.tar.gz
Entra-se no diretório ‘gdb-5.3’ e aplica-se o patch:
cd gdb-5.3
patch -p1 < ../gdb-5.3-m68k.patch
Após aplicar o patch procede-se com a compilação e instalação:
./configure --target=m68k-bdm-elf
make
make install
Deve-se verificar se o arquivo ‘/dev/bdmcf0’ existe, caso não exista deve-se
criá-lo com o comando:
mknod /dev/bdmcf0 c 34 4
37
Para usar o BDM deve-se adicionar o device driver do BDM no sistema, através
do comando:
insmod bdm
2.1.1 Testando e usando o GDB
Para iniciar o GDB deve-se executar:
m68k-bdm-elf-gdb
Para conectar ao BDM deve-se executar o comando:
(gdb) target bdm /dev/bdmcf0
Uma vez conectado, pode-se executar os comandos para depurar os programas
e/ou obter informações sobre o processador. Por exemplo, o comando abaixo lista todos
registadores do processador bem como os valores assumidos por eles:
(gdb) select-frame 0
(gdb) info reg
Pode-se também reiniciar a placa alvo através do comando:
(gdb) bdm_reset
Outro comando que foi importante para os testes realizados neste projeto e
que está presente em qualquer GDB, mesmo sem aplicar os patchs é:
(gdb) disassemble 0x10000

38
Este comando desassembla o código presente em determinada posição de me-
mória, no exemplo 0x10000. O código em assembly exido deverá ser igual ao obtido do
arquivo binário, através do comando:
m68k-elf-objdump -D arquivo.elf
Outros comandos podem ser obtidos através do ‘help’ do próprio aplicativo,
fugindo do escopo deste estudo.
2.1.2 Executando um programa através do BDM
Nesta seção será mostrado como enviar um programa para a memória da placa
e executa-lo.
Para compilar este programa é necessário ter a versão das ferramentas GNU
para o processadores M68K instaladas no sistema.
• O arquivo main.c
Este é o arquivo fonte principal, nele encontram-se as instruções responsáveis
por acender e apagar alternadamente os LEDs da placa de testes.
int main()
int i;
unsigned char *ptcpar = (unsigned char *)0x4010005B;
unsigned char *ddrtc = (unsigned char *)0x40100024;
unsigned char *porttc = (unsigned char *)0x40100010;

39
*ptcpar = 0x00;
*ddrtc = 0x0F;
while(1)
*porttc = 0x01;
for (i=0;i<20000;i++);
*porttc = 0x04;
for (i=0;i<20000;i++);
return 0;
• O arquivo start.s
Este é o arquivo responsável por inicializar o hardware de forma que os pro-
gramas em linguagem C possam ser utilizados corretamente.
#define MEM_BASE 0x00000000
#define VBR_BASE MEM_BASE
#define MEM_SIZE 0x01000000
.global _main
.global _start
.global _rambase
.global _ramvec
.global _ramstart
.global _ramend
40
.data
_rambase:
.long 0
_ramvec:
.long 0
_ramstart:
.long 0
_ramend:
.long 0
.text
_start:
nop
move.w #0x2700, %sr
move.l #VBR_BASE, %a7
movec %a7, %VBR
move.l %a7, _ramvec
move.l %a7, _rambase
move.l #MEM_SIZE, %a0
move.l %a0, %d0
move.l %d0, %sp
move.l %d0, _ramend
jsr main
_exit:
jmp _exit
• O arquivo mem.ld
41
Este é o arquivo onde deve-se definir o endereçamento de memória para onde
o programa será enviado.
MEMORY {
ram : ORIGIN = 0x16000, LENGTH = 0x000fff
SECTIONS {
.text : {
_stext = . ;
*(.text)
_etext = ALIGN(0x4) ;
} > ram
.data BLOCK(0x4) : {
_sdata = . ;
__data_start = . ;
*(.rodata)
*(.data)
_edata = ALIGN(0x4) ;
} > ram
.bss BLOCK(0x4) : {
_sbss = . ;
*(.bss)
*(COMMON)
_ebss = ALIGN(0x4) ;
_end = ALIGN(0x4) ;
} > ram
42
}
• Makefile
O Makefile é o arquivo que contém as instruções para que o programa ‘make’
compile, usando as ferramentas GNU, os códigos fontes do projeto.
CC_EXEC_PREFIX = /usr/local/bin/m68k-elf-
CC = $(GCC_EXEC_PREFIX)gcc
AS = $(GCC_EXEC_PREFIX)as
LD = $(GCC_EXEC_PREFIX)ld
AR = $(GCC_EXEC_PREFIX)ar
OBJCOPY = $(GCC_EXEC_PREFIX)objcopy
PROGNAME = tstart
TARGET = $(PROGNAME).s19
OBJS = start.o main.o
CFLAGS += -g -m5307
ASFLAGS += -Wa,-as -m5307
$(PROGNAME).s19: $(PROGNAME).bin
$(OBJCOPY) --input-target=binary --output-target=srec
$(PROGNAME).bin $(PROGNAME).s19
$(PROGNAME).bin: $(PROGNAME).elf
$(OBJCOPY) -O binary $(PROGNAME).elf $@
$(PROGNAME).elf: $(OBJS)
$(LD) -T mem.ld -M -o $(PROGNAME).elf $(OBJS) >$(PROGNAME).map
.S.o:
$(CC) $(ASFLAGS) -c $<

43
.c.o:
$(CC) $(CFLAGS) -nostartfiles -nostdlib -c $<
clean:
rm *.o *.bin *.s19 *.elf *.map -f
start.o: start.S
all: $(TARGET)
• Compilando e enviando o programa para a placa
Para compilar o programa, basta executar o comando ‘make’. Se a operação
transcorrer corretamente será gerado um arquivo com o nome ‘tstart.elf’.
Deve-se então iniciar o GDB passando como parâmetro o nome do arquivo
binário:
m68k-bdm-elf-gdb tstart.elf
Em seguida, deve-se executar os comandos, na seguinte sequência:
(gdb) target bdm /dev/bdmcf0
(gdb) load
(gdb) set $pc=0x16000
(gdb) c
Continuing.
Imediatamente os LEDs da placa deverão acender de forma alternada.
O GDB foi de extrema importância neste projeto, uma vez que o mesmo foi
utilizado para enviar o bootloader U-Boot para e memória da placa.

44
2.2 Instalando o bootloader
Após baixar o U-Boot do site é necessário compilá-lo para a versão do proces-
sador da placa alvo.
Deve-se iniciar o executável do U-Boot através do programador BDM, da
mesma forma como se inicia um aplicativo qualquer, como exemplificado na Seção 2.1.2.
O U-Boot pode-se ser controlado através de um console serial, para isso deve-
se configurar um programa de comunicação serial, como o minicom, com as seguintes
configurações: ‘19200 8N1’ e com controle de fluxo por hardware e software desativado.
Quando o U-Boot for executado, será exibido pela console serial as informações
da placa e um prompt estará disponı́vel:
U-Boot 0.4.0 (Jan 26 2004 - 14:10:08)
CPU: MOTOROLA Coldfire MCF5282
Board: AvNet Motorola Coldfire Evalution Kit Board
DRAM: 16 MB
FLASH: 8 MB
*** Warning - bad CRC, using default environment
AVNETMCEK>
Usando o prompt de comandos do U-Boot configura-se o mesmo com as in-
formações de rede adequadas.
AVNETMCEK> setenv ethaddr 00:cf:52:72:c3:01
AVNETMCEK> setenv ipaddr 10.2.5.91
AVNETMCEK> setenv serverip 10.2.5.90

45
Onde o ethaddr é o número MAC da placa alvo, o ipaddr é o endereço IP da
placa alvo e o serverip é o endereço IP do servidor TFTP onde há o arquivo binário do
U-Boot a ser gravado na Flash (loader.bin).
Para descarregar o arquivo do servidor TFTP para a placa alvo, deve-se exe-
cutar o seguinte comando:
AVNETMCEK> tftp 20000 /tftpboot/loader.bin
Este comando irá baixar o arquivo ‘loader.bin’ para a memória RAM da placa
a partir da posição de memória 0x20000.
O próximo passo é salvar o arquivo na memória Flash, para isso, deve-se
desproteger a área de memória a ser usada e apagá-la:
AVNETMCEK> protect off ff800000 ff80ffff
AVNETMCEK> erase ff800000 ff80ffff
O comando usado para gravar o arquivo na Flash (cp.b) recebe como argumen-
tos, respectivamente, o endereço da memória RAM onde encontra-se os dados a serem
gravados (0x20000), o endereço da memória Flash para onde o arquivo será gravado
(0xff800000) e a quantidade de bytes a serem gravados (0x10000 - 64KB):
AVNETMCEK> cp.b 20000 ff800000 10000
Após finalizar a cópia do U-Boot, deve-se salvar as configurações da placa na memória
Flash, para isso, executa-se o seguinte comando:
AVNETMCEK> saveenv
46
Quando finalizar esta operação pode-se reiniciar a placa e imediatamente a mensagem
inicial do U-Boot deverá ser apresentada através da console serial.
Com o U-Boot instalado na memória da placa, pode-se enviar o uClinux para
a mesma.
2.3 Instalando o uClinux na BSP
Todo o desenvolvimento em uClinux utiliza as ferramentas disponibilizadas
pela GNU [citar], tais como o compilador GCC (GNU Compiler Collection), linker LD e
vários outros aplicativos.
Para a plataforma MCF5282 (famı́lia M68K), um pacote completo de desen-
volvimento (toolchain) pode ser obtido em www.uclinux.org/pub/uClinux/m68k-elf-tools/
m68k-elf-tools-20030314.sh.
Já o arquivo fonte do uClinux pode ser encontrado em www.uclinux.org/pub/
uClinux/dist/uClinux-dist-20030909.tar.gz
2.3.1 Configuração e compilação do uClinux
A instalação do toolchain deve ser feita com privilégios de super-usuário. Após
baixar o arquivo ‘m68k-elf-tools-20030314.sh’, executa-se o comando:
#sh m68k-elf-tools-20030314.sh
Para compilar o uClinux é necessário primeiramente descompactar o arquivo
‘uClinux-dist-20030909.tar.gz’, para isso executa-se o procedimento:

47
#tar -xzvf uClinux-dist-20030909.tar.gz
exit
Em seguida entra-se no diretório criado e inicializa a interface de configuração
do uClinux:
#cd uClinux-dist
make menuconfig
O primeiro passo é selecionar a plataforma através da opção Target Platform
Selection:
(Motorola/M5282C3)
(linux-2.4.x)
(uClibc)
[*]Customize Kernel Settings
[*]Customize Vendor/User Settings
Em seguida será exibida a tela de customização do kernel. Nesta tela as opções
em Processor type and features devem ser alteradas:
(MCF5282) CPU
(60MHz) CPU CLOCK Frequency
--- Platform
[*] Motorola M5282C3 board support
(AUTO) RAM size
(AUTO) RAM bit width
(RAM) Kernel executes from

48
Estas são as configurações básicas para o sistema funcionar na placa AvNet
Motorola Coldfire Evaluation Kit, os demais recursos devem ser ativados segundo a ne-
cessidade da aplicação para a qual o uClinux se baseia.
Vários protocolos são suportados pelo kernel e precisam ser ativados para que
aplicações que o utilizam possam funcionar. Por exemplo, para o interroperabilidade com
servidores Windows, é necessário ativar o protocolo smbfs em File Systems -> Network
File Systems.
Por fim, será exibida a tela de customização de Vendor/User. Nesta tela o
usuário irá selecionar os aplicativos do uClinux que deseja utilizar.
Finalmente, a compilação do kernel pode iniciada:
make dep
make
Quando a compilação finalizar, a imagem completa do uClinux (arquivo ‘im-
age.bin’) poderá ser encontrada dentro do diretório ‘images’. É este arquivo que deve ser
enviado para a memória RAM da placa para ser executado.
2.3.2 Enviando a imagem do uClinux para a placa
O processo para enviar a imagem do uClinux para a placa é semelhante ao
enviar um aplicativo comum. Para fazê-lo é preciso ter o arquivo ‘image.bin’ copiado
para o diretório base do servidor de TFTP (‘/tftpboot’).
Após inicializar a placa deve-se executar os comando para enviar o imagem do
uClinux a memória RAM da mesma e executá-la:

49
tftp 400000 image.bin
go 400000
Imediatamente o kernel do uClinux deverá exibir as mensagem de inicialização,
como mostrado abaixo:
Linux version 2.4.22-uc0 (alan@ltr03) (gcc version 2.95.3 20010315 (release4
uClinux/COLDFIRE(m5282)
COLDFIRE port done by Greg Ungerer, gerg@snapgear.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
On node 0 totalpages: 2048
zone(0): 0 pages.
zone(1): 2048 pages.
zone(2): 0 pages.
Kernel command line:
Calibrating delay loop... 5.84 BogoMIPS
Memory available: 2136k/8192k RAM, 0k/0k ROM (666k kernel code, 206k data)
kmem_create: Forcing size word alignment - vm_area_struct
kmem_create: Forcing size word alignment - mm_struct
kmem_create: Forcing size word alignment - filp
Dentry cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
kmem_create: Forcing size word alignment - bdev_cache
kmem_create: Forcing size word alignment - cdev_cache

50
kmem_create: Forcing size word alignment - kiobuf
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
kmem_create: Forcing size word alignment - sock
Initializing RT netlink socket
Starting kswapd
kmem_create: Forcing size word alignment - file_lock_cache
ColdFire internal UART serial driver version 1.00
ttyS0 at 0x40000200 (irq = 77) is a builtin ColdFire UART
ttyS1 at 0x40000240 (irq = 78) is a builtin ColdFire UART
kmem_create: Forcing size word alignment - blkdev_requests
fec.c: Probe number 0 with 0x0000
eth0: FEC ENET Version 0.2, a8:4a:c4:b7:a4:54
FEC: No PHY device found.
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
CSLIP: code copyright 1989 Regents of the University of California.
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 4DA4C8-5CF8C7 [VIRTUAL 4DA4C8-5CF8C7] (RO)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
PPP generic driver version 2.4.2

51
PPP MPPE compression module registered
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
kmem_create: Forcing size word alignment - ip_dst_cache
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 512)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 24k freed (0x4c2000 - 0x4c7000)
Shell invoked to run file: /etc/rc
Command: hostname uClinux
Command: /bin/expand /etc/ramfs.img /dev/ram1
Command: mount -t proc proc /proc
Command: mount -t ext2 /dev/ram1 /var
Command: mkdir /var/tmp
Command: mkdir /var/log
Command: mkdir /var/run
Command: mkdir /var/lock
Command: mkdir /var/empty
Command: ifconfig lo 127.0.0.1
Command: route add -net 127.0.0.0 netmask 255.0.0.0 lo
Command: dhcpcd -p -a eth0 &
[11]
Command: cat /etc/motd
Welcome to
52
____ _ _
/ __| ||_|
_ _| | | | _ ____ _ _ _ _
| | | | | | || | _ \| | | |\ \/ /
| |_| | |__| || | | | | |_| |/ \
| ___\____|_||_|_| |_|\____|\_/\_/
| |
|_|
For further information check:
http://www.uclinux.org/
Execution Finished, Exiting
Sash command shell (version 1.1.1)
/>
Se o uClinux inicializar corretamente, como no exemplo acima, pode-se então
gravá-lo na memória Flash, para isto é necessário criar um pacote que o U-Boot recon-
hecer. Deve-se entrar no diretório ‘/tftpboot’ e executar os seguintes comandos:
gzip image.bin
mkimage -A m68k -O linux -T kernel -C gzip -a 0x400000 -e 0x400000
-d image.bin.gz image.pkg
Este comando irá criar o pacote chamado ‘image.pkg’, que deverá ser enviando
a placa e gravado na memória Flash, usando os seguintes comandos:
tftp 400000 image.pkg

53
erase ff840000 ffffffff
cp.b 400000 ff840000 eee65
Onde ‘eee65’ é o tamanho em bytes, no formato hexadecimal, do arquivo ‘im-
age.pkg’.
Para inicializar o uClinux a partir da memória Flash deve-se executar o seguinte
comando:
setenv bootcmd bootm ff840000
setenv bootdelay 3
saveenv
O ‘bootdelay 3’ é o tempo, em segundos, que o U-Boot irá aguardar antes de
inicializar o kernel do uClinux.
Deve-se tomar cuidado ao se utilizar o ‘bootdelay 0’, pois, caso o kernel não
inicialize, não terá como recuperar o sistema e o U-Boot deverá ser reinstalado.
Como a imagem do uClinux gravada na memória flash pode-se ‘resetar’ ou
desligar e em seguida ligar novamente a placa embarcada, após alguns segundos o uClinux
iniciará automaticamente.
Uma vez que o uClinux encontra-se instalado na placa, todas as caracterı́sticas
inerentes a um sistema Linux podem ser exploradas. Para verificar o funcionamento do
servidor web chamado ‘boa’ que é executado por padrão no uClinux, conecte o cabo de
rede na placa e verifique através de um navegador web, acessando o IP da mesma.
Inúmeras aplicações podem ser devenvolvidas utilizando os recursos existente
na placa embarcada. Na Secão 4 encontra-se o código de uma aplicação simples que foi
desenvolvida para controlar os leds da placa através da rede.

3 UMA MALHA DE CONTROLE USANDO A PLACA AVNET5282
Como aplicação prática foi desenvolvido uma malha de controle utilizando-se
dois motores de corrente contı́nua, um atuando com gerador de força motriz e o outro
atuando como gerador de tensão, gerada através da interligação dos eixos de ambos.
Para controlar o motor gerador de força motriz foi construı́da uma placa que
recebe dados de forma serial, através da interface SPI, e os converte para paralelo,
convertendo-os em seguida para nı́veis analógicos que são amplificados e aplicados di-
retamente ao motor.
Na Figura 3.1 pode ser visualizado o esquemático do experimento realizado.
Aplicativo de controle
SPI
QADC
DAC /
Amplificador
Motor Gerador
Figura 3.1: Diagrama esquemático do controle do motor
A entrada analógica (QADC) da placa embarcada recebe a tensão gerada pelo
motor (que está atuando como gerador), esta tensão é proporcional à velocidade de rotação
que o primeiro motor está imprimindo sobre este gerador. Um programa que está em
55
execução na placa calcula a velocidade atual e a compara com o valor desejado. Em
seguida este atua sobre o motor gerador de força motriz, através de uma interface SPI
ligada a um conversor D/A, aumentando ou diminuindo a rotação do mesmo.
O algoritmo da lógica de controle é apresentado a seguir.
Inicio
Inteiro: val, vmotor, vgerador;
Escreva("Digite a velocidade desejada");
Leia(val);
initqspi(); //Funç~
ao para configurar e inicializar o QSPI
Enquanto (verdadeiro) faca //laço infinito
vgerador = readqadc() //leia velocidade atual
if(vgerador < val) //velocidade baixa, aumentar velocidade
if(vmotor < 255) //se a tens~

ao no motor n~
ao atingiu nı́vel máximo
vmotor++;
if(vgerador > val) //velocidade alta, diminuir velocidade
if(vmotor > 0) //se a tens~

ao no motor n~
ao atingiu nı́vel mı́nimo
vmotor--;
qspiwrite(vmotor) //enviar velocidade que o motor devera usar
usleep(10000) // durma por 10 ms
Fim Enquanto
Fim
56
Para desenvolver esta malha de controle o autor deste trabalho precisou criar
um device driver para ler a entrada analógica QADC. Já o driver do SPI havia sido
portado para o microcontrolador MCF5282 por um dos desenvolvedores do uClinux uma
semana antes de começar a realização desta experiência.

4 DISCUSSÃO DOS RESULTADOS
O objetivo deste trabalho foi alcançado, dentro do prazo previsto e segundo
a proposta original de desenvolvimento, que era apresentar e desenvolver um sistema
embarcado que utilizasse o uClinux como sistema operacional, demonstrando os benefı́cios
e as dificuldades enfrentadas para o desenvolvimento do mesmo.
Foi necessário um esforço além do previsto, pois um bootloader, conhecido
como U-Boot, precisou ser portado para a placa embarcada para que o uClinux pudesse
ser utilizado nesta. O bootloader é um programa encarregado de inicializar o hardware e
dar suporte à inicialização do sistema operacional embarcado.
Várias experiências com sistemas de arquivos e suporte a recursos de hardware
foram testados, verificando assim a capacidade e flexibilidade do uClinux como um sistema
embarcado. Em geral a imagem obtida com o kernel 2.4 é em torno de 2MB, porém como
o U-Boot aceita inicializar imagens compactadas, pôde-se utilizar este artifı́cio e obter
uma imagem final gravada na memória FLASH em torno de 1MB apenas.
Como aplicação prática, para a demonstração do funcionamento do uClinux
na placa, foi desenvolvido um device driver para controlar os LED s da placa. Assim foi
possı́vel acender ou apagar os LEDs através da console serial. Esta idéia evoluiu e criou-se
um CGI que permite controlar os LED s através da Internet.
Através deste trabalho verificou-se que o esforço necessário para a utilização
do uClinux em uma plataforma que utilize um processador suportado não é tão grande
como pode parecer à primeira vista. Além disto pode-se verificar que os participantes
da lista de discussão do uClinux estão dispostos à auxiliar aos desenvolvedores novatos,
compartilhando seus conhecimentos, algo que não ocorre facilmente quando trata-se de
58
sistemas comerciais, onde, quase sempre, a única fonte de informação é a própria fabricante
da solução.
ANEXOS
4.1 Anexo A. Controlando os LEDs da placa pelo browser
Figura 4.2: Página CGI para controle dos LEds da placa

60
4.2 Anexo B. Foto da placa com os LEDs acesos
Figura 4.3: LEDs da placa controlados por um CGI

61
4.3 Anexo C. Device Driver do LedMonitor
Arquivo ledmon.c
/*
* (C) Copyleft 2004
* Alan Carvalho de Assis, alan@unilestemg.br
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
* This program 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. See the
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
#define MODULE
62
#define __KERNEL__
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h> /* printk */
#include <linux/fs.h> /* everything... */
#include <linux/errno.h> /* error codes */
#include <linux/types.h> /* size_t */
#include <linux/proc_fs.h> /* proc file system */
#include <linux/fcntl.h> /* O_ACCMODE */
#include <asm/system.h> /* cli, flags */
#include <asm/uaccess.h> /* copy from/to user */
MODULE_LICENSE("GPL");
/*Registers to get leds access*/
volatile unsigned char * gptbdr = (unsigned char *)0x401b001d;
volatile unsigned char * gptbddr= (unsigned char *)0x401b001e;
volatile unsigned char * ptcpar = (unsigned char *)0x4010005A;
volatile unsigned char * ptdpar = (unsigned char *)0x4010005B;
volatile unsigned char * ddrtc = (unsigned char *)0x40100023;
volatile unsigned char * ddrtd = (unsigned char *)0x40100024;
volatile unsigned char * porttc = (unsigned char *)0x4010000f;
volatile unsigned char * porttd = (unsigned char *)0x40100010;

63
/* Function prototypes required by led.c */
int led_open (struct inode *inode, struct file *filp);
int led_release (struct inode *inode, struct file *filp);
ssize_t led_read(struct file *filp,char *buf,size_t count,loff_t *f_pos);
ssize_t led_write(struct file *filp,char *buf,size_t count,loff_t *f_pos);
void acende_leds(int leds);
void cleanup_module (void);
/* Structure to declare our file access functions. */
struct file_operations led_fops =
open: led_open,
read: led_read,
write: led_write,
release: led_release
};
/* Global driver variables. */
int led_major = 60; /* major number */
char led_buffer; /* data buffer */
int init_module(void)
64
{
int result;
/*Iniciatialize LEDs off*/
*ptcpar = 0x00;
*ptdpar = 0x00;
*ddrtc = 0x0f;
*ddrtd = 0x0f;
*gptbddr= 0x0f;
*gptbdr = 0x0f;
/* Register the device. */
result = register_chrdev(led_major, "led", &led_fops);
if (result < 0)
printk("<1>LED: couldn’t obtain major number %d\n",led_major);
return result;
printk("AvNet Led driver is installed\n");
printk("Copyleft Alan Carvalho de Assis - alan@unilestemg.br\n");
led_buffer = 0;
return 0;
}
65
/* Unload the module. */
void cleanup_module(void)
unregister_chrdev (led_major, "led");
printk("AvNet Led driver is removed\n");
/* Open the device file. */
int led_open(struct inode *inode, struct file *filp)
MOD_INC_USE_COUNT;
printk("Executing led_open\n");
return 0;
/* Close the device file. */
int led_release(struct inode *inode, struct file *filp)
MOD_DEC_USE_COUNT;
printk("Executing led_release\n");
return 0;
ssize_t led_read(struct file *filp,char *buf,size_t count,loff_t *f_pos)

66
{
led_buffer = 0xFF;
if(*porttc & 0x01)
led_buffer ^= 0x01;
if(*porttc & 0x04)
led_buffer ^= 0x02;
if(*porttd & 0x01)
led_buffer ^= 0x04;
if(*porttd & 0x04)
led_buffer ^= 0x08;
led_buffer ^= (*gptbdr<<4);
/* Move data to the user space */
if(copy_to_user (buf, &led_buffer, 1))
return -EFAULT;
*f_pos++;
return 1;
/* Write to the file. */

67
ssize_t led_write(struct file *filp,const char *buf,size_t count,loff_t *fpos)
printk("Executing led_write\n");
if(copy_from_user (&led_buffer, buf, 1))
return -EFAULT;
printk("Input = %c\n",led_buffer);
show_leds(led_buffer);
*fpos++;
return 1;
void show_leds(int leds)
*porttc = 0x05;
*porttd = 0x05;
*gptbdr = 0x0f;
if(leds&0x01)
*porttc ^= 0x01;
68
if(leds&0x02)
*porttc ^= 0x04;
if(leds&0x04)
*porttd ^= 0x01;
if(leds&0x08)
*porttd ^= 0x04;
leds = leds>>4;
*gptbdr ^= leds;
}
69
4.4 Anexo D. Arquivo fonte do CGI
Arquivo template.c baseado no cgi generic
#include <stdio.h>
#include "cgivars.h"
#include "htmllib.h"
#define DEBUG 0
int led;
int template_page(char **getvars, int form_method) {
int i;
FILE *f;
addTitleElement("LEDMONITOR");
if(form_method == GET) {
for (i=0; getvars[i]; i+= 2) {
#if DEBUG
printf("<li>DEBUG: [%s] = [%s]\n", getvars[i], getvars[i+1]);
#endif
if(strcmp(getvars[i],"led")==0)
70
led=atoi(getvars[i+1]);
if((f = fopen("/dev/led","wb"))==NULL)
printf("File /dev/led not found or Device Driver is not loaded!\n");
return -1;
fprintf(f,"%c",led);
fclose(f);
printf("<TABLE border=1>\n");
printf("<TR>\n");
for(i=128;i>=1;i=i>>1)
if(led & i)
printf("<TD>\n");
printf("<A href=\"/cgi-bin/cgi_led?led=%d\"><img \
src=\"/img/on.gif\"></A>\n",led & (~i));
printf("</TD>\n");
71
}
else
printf("<TD>\n");
printf("<A href=\"/cgi-bin/cgi_led?led=%d\"><img \
src=\"/img/off.gif\"></A>\n",led | i);
printf("</TD>\n");
printf("</TR>\n");
printf("</TABLE>\n");
return 0;
4.5 Anexo E. Device Driver do QADC
Arquivo qadc.c
/*
* (C) Copyleft 2004
* Alan Carvalho de Assis, alan@unilestemg.br
*
72
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
* This program 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. See the
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
#define MODULE
#define __KERNEL__
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h> /* printk */
#include <linux/fs.h> /* everything... */
#include <linux/errno.h> /* error codes */

73
#include <linux/types.h> /* size_t */
#include <linux/proc_fs.h> /* proc file system */
#include <linux/fcntl.h> /* O_ACCMODE */
#include <asm/system.h> /* cli, flags */
#include <asm/uaccess.h> /* copy from/to user */
MODULE_LICENSE("GPL");
/*Registers to get qadc access*/
volatile unsigned short * qadcmcr = (unsigned short *)0x40190000;
volatile unsigned short * qacr0 = (unsigned short *)0x4019000a;
volatile unsigned short * qacr1 = (unsigned short *)0x4019000c;
volatile unsigned short * qacr2 = (unsigned short *)0x4019000e;
volatile unsigned short * qasr0 = (unsigned short *)0x40190010;
volatile unsigned short * qasr1 = (unsigned short *)0x40190012;
volatile unsigned short *ccw = (unsigned short *)0x40190200;
volatile unsigned short *rjurr = (unsigned short *)0x40190280;
/* Function prototypes required by qadc.c */
int qadc_open (struct inode *inode, struct file *filp);

74
int qadc_release (struct inode *inode, struct file *filp);
ssize_t qadc_read(struct file *filp, char *buf, size_t count, loff_t *f_pos);
ssize_t qadc_write (struct file *filp, const char *buf, size_t count, loff_t *f_pos
void cleanup_module (void);
/* Structure to declare our file access functions. */
struct file_operations qadc_fops =
open: qadc_open,
read: qadc_read,
write: qadc_write,
release: qadc_release
};
/* Global driver variables. */
int qadc_major = 80; /* major number */
unsigned short values[64]; /* data buffer */
int init_module(void)
int cntr; //counter for loop;
int result;
75
*qadcmcr= 0x40; //QADC operates normally
*qacr0 = 0x7f; //QCLK, disable extern mux, set the trigger assignments
*qacr1 = 0x1100; //disable interrupts, select operate mode
*qacr2 = 0x11; //disable queue 2
*qasr0 = 0;
for(cntr=0;cntr<64;cntr++)
rjurr[cntr]=0;
for(cntr=0;cntr<64;cntr++)
ccw[cntr] = cntr;
/* Register the device. */
result = register_chrdev(qadc_major, "qadc", &qadc_fops);
if (result < 0)
printk("<1>QADC: couldn’t obtain major number %d\n",qadc_major);
return result;
}
76
printk("AvNet QADC driver is installed\n");
printk("Copyleft Alan Carvalho de Assis - alan@unilestemg.br\n");
return 0;
/* Unload the module. */
void cleanup_module(void)
unregister_chrdev (qadc_major, "qadc");
//printk("AvNet QADC driver is removed\n");
/* Open the device file. */
int qadc_open(struct inode *inode, struct file *filp)
MOD_INC_USE_COUNT;
//printk("Executing qadc_open\n");
return 0;
/* Close the device file. */
int qadc_release(struct inode *inode, struct file *filp)
MOD_DEC_USE_COUNT;
//printk("Executing qadc_release\n");
77
return 0;
ssize_t qadc_read(struct file *filp, char *buf, size_t count, loff_t *f_pos)
int cntr=0, adcntr, val;
*qacr1=0x1100; // Activate software triggered continous-scan mode
printk("Executing qadc_read");
while(cntr<8) //read only the 8 first channel
printk("Starting convertion");
if((*qasr1>>8) > 7) // When the queue is full, read it to RAM
printk("Data in queue");
*qacr1=0; // Deactivate software triggered continous-scan mode
for(adcntr=0;adcntr<8;adcntr++)
values[cntr++] = rjurr[adcntr]; // Read a value off the queue and i
}
78
val = (int) values[0];
*qacr1 = 0;
if(copy_to_user (buf, &val, 4))
return -EFAULT;
*f_pos++;
return 1;
/* Write to the file. */
ssize_t qadc_write(struct file *filp, const char *buf, size_t count, loff_t *fpos)
//QADC is read only, this funciton can be removed
return 1;
4.6 Anexo F. Aplicativo da Malha de Controle
Arquivo qspid.c
79
#include <stdio.h>
#include <asm/fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include "mcf_qspi.h"
typedef unsigned char bigbuf[128];
int fdq; // file handle
bigbuf mybuff; // buffer for read/write data
int xfersize;
qspi_read_data qspi_rcd; // from combined_mcf_qspi.h
int initqspi() {
int i, j, k, result, yield;
qspi_rcd.length = 1; // initialize default? data structure
for (i=0; i <16; i++) {
qspi_rcd.buf[i] = 0x0;
} // clear xmit buff
qspi_rcd.loop = 1;
80
// first open qspi driver for I/O with chip select 0 (default)
fdq = open("/dev/qspi0", O_RDWR);
if (fdq < 0) {
printf("\nCan’t open /dev/qspi0\n");
return 0;
if (j = ioctl(fdq, QSPIIOCS_BITS, 8)) {
printf("bad QSPIIOCS_BITS\n");
}; // set 8-bit transfers
if (j = ioctl(fdq, QSPIIOCS_CPOL, 0)) {
printf("bad QSPIIOCS_CPOL\n");
};
if (j = ioctl(fdq, QSPIIOCS_CPHA, 0)) {
printf("bad QSPIIOCS_CPHA\n");
};
// active edge for clock
// 0 means input data sampled on rising edge, output changes on falling ed
// 1 means input data sampled on falling edge,output changed on rising edg
if (j = ioctl(fdq, QSPIIOCS_BAUD, 255)) {

81
printf("bad QSPIIOCS_BAUD\n");
}; // clock baud rate divider
// 0 turns off clock, valid range is 2 to 255
// qspi clock = cpu-clock/2, the divided by this number
// 32 equals 1 MHz clock, 16 equals 2 MHz clock, etc.
if (j = ioctl(fdq, QSPIIOCS_QCD, 127)) {
printf("bad QSPIIOCS_QCD\n");
};
// start delay CS-to-clock edge 127=5us
if (j = ioctl(fdq, QSPIIOCS_DTL, 255)) {
printf("bad QSPIIOCS_DTL\n");
};
// after delay, 1 OK for eeprom, 2= about 5 us, 24= 20 us
if (j = ioctl(fdq, QSPIIOCS_CONT, 0)) {
printf("bad QSPIIOCS_CONT\n");
};
// 1 = continus CS while transfering
// 0 = unassert CS in between each 8 or 16 bit transfer
if (j = ioctl(fdq, QSPIIOCS_POLL_MOD, 1)) {
printf("bad QSPIIOCS_POLL_MOD\n");
};
82
// 1 = polling, only for small tranfers
// 0 = interruption
//Note that in the next line, qspi_rcd must pass a pointer to itself,
//there is no pass by reference (&) in standard c code.
if (j = ioctl(fdq, QSPIIOCS_READDATA, (unsigned long) &qspi_rcd )) {
printf("bad QSPIIOCS_READDATA err=%d\n \n",j);
return 0;
int qspiwrite(unsigned char value) {
int yield;
if(value>255)
printf("Valor deve ser menor ou igual a 255.\n");
return -1;
mybuff[0] = value;
83
yield = write(fdq, &mybuff, 1);//write 1byte out
return yield;
int main()
int f, val=0, vatual=0, vlc = 0; //velocidade
printf("\nDigite o velocidade desejada (64 - 750):");
scanf("%d",&val);
initqspi(); //start qspi
//start in the max speed
qspiwrite(vatual);
while(1)
//open QADC
f = open("/dev/qadc", O_RDONLY);
if (f < 0) {
84
printf("\nCan’t open /dev/qadc\n");
return -1;
//load speed
read(f, &vlc, 4);
//show speed
printf("Velocidade: %d\n",vlc);
//aumentar velocidade
if (vlc < val)
if(vatual < 255)
vatual++;
//diminuir velocidade
if (vlc > val)
if(vatual > 0)
vatual--;
//motor parou, jogar velocidade maxima para vencer inercia
//if (vlc < 64)
//vatual = 255;
qspiwrite(vatual);
85
//wait 10 ms.
usleep(10000);
close(f);
close(fdq);
return 0;
}
REFERÊNCIA
ABBOTT, D. Linux for Embedded and Real-time Applications. [S.l.]: Newner, 2003.
ISBN 0-7506-7546-2.
ASSIS, A. C.; BARROS, M. A. uclinux: o linux dos pequenos. Revista do Linux, 2003.
GILL, L. IBM Chooses Linux for ‘Blue Gene’ Supercomputer. 2002. Disponı́vel em:
<http://www.newsfactor.com/perl/story/19772.html>. Acesso em: 02 nov. 2004.
GPL. 2004. Disponı́vel em: <http://www.gnu.org/copyleft/gpl.html>. Acesso em: 10
dez. 2004.
INTEL. 1971. Disponı́vel em:
<http://www.intel.com/education/mpworks/INDEX.HTM>. Acesso em: 17
nov. 2004.
JONES, M. What really happened on Mars? 1997. Disponı́vel em:
<http://research.microsoft.com/mbj/Mars Pathfinder/Mars Pathfinder.html>.
Acesso em: 16 nov. 2004.
KILBY, J. Texas Hall of Fame for Science, Mathematics and Technology. 2002.
Disponı́vel em: <http://www.texassciencesummit.org/2kbiopages/kilby/kilby.htm>.
MASSEY, D. BELL LABS. 1997. Disponı́vel em:
<http://www.bellsystemmemorial.com/belllabs transistor.html>. Acesso em: 11
nov. 2004.
87
MISTRAL. 2002. Disponı́vel em:
<http://www.mistralsoftware.com/html/news events/vxworks1.pdf>. Acesso
em: 16 nov. 2004.
NIKKANEN, K. uClinux as an Embedded Solution. [S.l.], 2003.
PALMLAND. 2002. Disponı́vel em: <http://www.palmland.com.br/wince/>. Acesso
em: 16 nov. 2004.
QNX. 2004. Disponı́vel em:
<http://www.qnx.com/developers/docs/momentics621 docs/neutrino/sys arch/kernel.html>.
RISC. 2004. Disponı́vel em: <http://cse.stanford.edu/class/sophomore-college/projects-
00/risc/risccisc/>. Acesso em: 06 dez. 2004.
TORVALDS, L. Linux History. 2004. Disponı́vel em:
<http://www.li.org/linuxhistory.php>. Acesso em: 05 out. 2004.
TORVALDS, L.; DIAMOND, D. Só por prazer, Linux, os bastidores da sua criação. [S.l.:
s.n.], 2001.
UNGERER, G. Atmel ships $3-$4 SoCs. But will they run Linux? 2004. Disponı́vel em:
<http://www.linuxdevices.com/news/NS6348089357.html>. Acesso em: 01 dez. 2004.
VANDERWIELE, M.; SCOTT, L. Putting Linux reliability to the test. 2003. Disponı́vel
em: <http://www-106.ibm.com/developerworks/linux/library/l-rel/>. Acesso em: 23
nov. 2004.
VDC. 2004. Disponı́vel em: <http://www.vdc-corp.com/embedded/reports/04/br04-
21.html>. Acesso em: 23 nov. 2004.

88
VENKATAKRISHNAN, M. Porting uCLinux to the MC68360 Based Board. 2003.
Disponı́vel em: <http://www.linuxdevices.com/articles/AT6851875594.html>. Acesso
em: 11 nov. 2004.
WEHRLI, R. eCos vs. uClinux: Which is best for your embedded target? 2002.
Disponı́vel em: <http://www.linuxdevices.com/articles/AT3393503683.html>. Acesso
em: 17 nov. 2004.
WILMSHURST, T. An Introduction to the Design of Small-scale Embedded Systems.
[S.l.]: Palgrave Macmillan, 2001.
YAGHMOUR, K. Building Embedded Linux Systems. [S.l.]: O’Reilly, 2003.
ZELENOVSKY, R.; MENDONCA, A. PC: um Guia Prático de Hardware e
Interfaceamento. [S.l.]: MZ Editora, Ltda, 1999.

Desenvolvimento de Sistemas Embarcados U

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento de Sistemas Embarcados U

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO UNIVERSITÁRIO DO LESTE DE MINAS GERAIS

CURSO DE COMPUTAÇÃO SISTEMAS DE INFORMAÇÃO

DESENVOLVIMENTO DE SISTEMAS EMBARCADOS UTILIZANDO O

DESENVOLVIMENTO DE SISTEMAS EMBARCADOS UTILIZANDO O

Monografia apresentada ao Departamento de Com-

Orientador: Dr. Max Mauro Dias dos Santos

Desenvolvimento de sistemas embarcados utilizando o sistema ope-

1.Sistemas Embarcados 2. Linux.. I.Tı́tulo.

DESENVOLVIMENTO DE SISTEMAS EMBARCADOS UTILIZANDO O

Monografia apresentada ao Curso de Computação

Aprovado em 13 de dezembro de 2004

Prof. Orientador Dr.Max Mauro Dias dos Santos

Prof.Elizabete Marinho Serra Negra

É inegável a revolução que o computador têm causado na sociedade contem-

Palavras-chaves: Sistemas Embarcados, uClinux, Linux, Microcontroladores.

Keywords: Embedded Systems, uClinux, Linux, Microcontroller.

Agradeço a todos os integrantes do Laboratório de Sistemas de Tempo Real

Ao professor Dr. Max Mauro pela oportunidade de estar desenvolvendo pesquisa

Aos membros participantes da lista de discursão uclinux-dev pelo auxı́lio às

Ao Júlio, Lı́vio e Rafael da eletrônica da Unileste, pela prestatividade em

Á minha famı́lia que, apesar de todas as dificuldades, sempre me apoiou e me

E principalmente, à minha mãe, que nunca dormia até que eu chegasse em

1.1 Equipamentos que utilizam o Linux como sistema operacional embarcado. . 11

3.1 Diagrama esquemático do controle do motor . . . . . . . . . . . . . . . . . 54

4.2 Página CGI para controle dos LEds da placa . . . . . . . . . . . . . . . . . 59

1.1 Tabela de classificação dos sistemas embarcados por tamanho . . . . . . . 15

2 PROCEDIMENTOS PARA INSTALAÇÃO DO uClinux NA PLACA

3 UMA MALHA DE CONTROLE USANDO A PLACA AVNET5282 54

4 DISCUSSÃO DOS RESULTADOS 57

É crescente a utilização de sistema embarcados em aplicações domésticas,

como sendo um computador (WILMSHURST, 2001).

Estes sistemas são caracterizados por possuı́rem uma aplicação especı́fica,

tomóveis. Tais sistemas surgiram da necessidade de substituir os controles mecânicos ou

eletromecânicos em máquinas usadas em aplicações industriais e domésticas.

Os sistemas embarcados são utilizados em vários objetos de uso cotidiano, e a

em aplicações automotivas, pois, atualmente, todos os controles tendem a ser realizados

por sistemas eletrônicos, desde o sincronismo da centelha que queima o combustı́vel no

interior do pistão, à regulagem da inclinação da poltrona. Tudo isso é controlado por

Esta grande gama de aplicações dos sistemas embarcados tornam a programação

um tanto quanto complexa. Para simplificar o desenvolvimento destas, o desenvolvedor

nal deverá fornecer uma interface de programação de aplicações, Application Programming

Interface (API), que tornará tal tarefa menos árdua.

Existem vários sistemas operacionais para sistemas embarcados, por exemplo

o VxWorks da WindRiver, o WindowsCE da Microsoft, o PalmOS da Palm Computing

e o uC/OS-II da Micrum. O Linux não foi projetado visando o mercado de aplicações

A criação do uClinux, que é uma modificação do kernel do Linux para su-

portar microprocessadores sem unidade de gerenciamento de memória (MMU), também

contribuiu muito para o crescimento do Linux em aplicações embarcadas.

O uClinux reúne todas as principais vantagens do Linux, como: excelente

suporte a rede, padrão POSIX, grande quantidade de programas, estabilidade, extensa

documentação, código fonte livre, entre outras.

Por estes motivos, e principalmente por não exigir pagamento de royaties, o

Segundo uma pesquisa de mercado realizada pelo Venture Development Cor-

sistema operacional embarcado mais utilizado em novos projetos (VDC, 2004).

A Figura 1.2 mostra o gráfico da pesquisa dos sistemas operacionais embarca-

dos mais utilizados em novos projetos.

O crescimento do Linux como sistema operacional embarcado foi a causa inicial

para o desenvolvimento deste trabalho. Os seguintes tópicos serão abordados: sistemas

embarcados, o uClinux, e um estudo de caso de uma aplicação utilizando uma placa

embarcada que utiliza o uClinux como sistema embarcado.

1.1 Sistemas Embarcados

Sistemas embarcados são sistemas construı́dos para aplicações especı́ficas. Estes

sistemas possuem como caracterı́sticas principais o baixo custo e o reduzido consumo de