universidade do vale do itajaÍ centro de …siaibib01.univali.br/pdf/julio cesar fiamoncini.pdf ·...

UNIVERSIDADE DO VALE DO ITAJAÍ

CENTRO DE CIÊNCIAS TECNOLÓGICAS, DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE DRIVERS DE DISPOSITIVOS PARA UMA

PLATAFORMA DE SISTEMA EMBARCADO MICROCONTROLADO

Área de Sistemas Embarcados

Julio Cesar Fiamoncini

Itajaí (SC), julho de 2004

UNIVERSIDADE DO VALE DO ITAJAÍ

CENTRO DE CIÊNCIAS TECNOLÓGICAS, DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE DRIVERS DE DISPOSITIVOS PARA UMA

PLATAFORMA DE SISTEMA EMBARCADO MICROCONTROLADO

Área de Sistemas Embarcados


Relatório apresentado à Banca

Examinadora do Trabalho de Conclusão do

Curso de Ciência da Computação para

análise e aprovação.

Itajaí (SC), julho de 2004

EQUIPE TÉCNICA

Acadêmico


Professor Orientador

Cesar Albenes Zeferino, Dr.

Professor Co-orientador

Rafael Luiz Cancian, M.Sc.

Coordenadores dos Trabalhos de Conclusão de Curso

Anita Maria da Rocha Fernandes, Dra.

Cesar Albenes Zeferino, Dr.

Coordenador do Curso

Luís Carlos Martins, Esp.

DEDICATÓRIA

Dedico este Trabalho ao meu pai, que ensinou-me com

sua integridade a lutar na vida, e a minha mãe, por me

encorajar nesta caminhada, ensinar-me que, tão importante

quanto a luta, são a arte, o amor, a solidariedade e a fé.

Dedico também aos meus irmãos pelo incentivo e força que

sempre me deram.

AGRADECIMENTOS

A Deus por minha existência e por ter colocado pessoas maravilhosas na minha vida.

A minha mãe Elisabete que sempre orou por mim nas horas de aflição, ao meu pai Vitorino por ser

um exemplo de vida. Aos dois pela garra e batalha para poder me proporcionar esta faculdade.

Agradeço também os ensinamento que me deram e principalmente pelo amor dedicado a mim.

Ao Cesar, pelo privilégio de ser seu orientando, pelo incentivo e ensinamentos. Pelos momentos de

descontração e por sua amizade.

Ao meu Co-Orientador Rafael, pelos ensinamentos e sua contribuição para o desenvolvimento deste

trabalho de conclusão de curso.

A Fabiane, pelos ensinamentos, adquiridos durante o período em que trabalhamos juntos no projeto

Gemetrics, e as conversas em que tivemos nos momentos em que encontrei dificuldade.

Ao meu irmão Vitor Hugo e sua família que me acolheram durante estes anos de faculdade, sempre

dando incentivo e me encorajando nesta caminhada.

Ao meu irmão Alexandre por acreditar em mim e sempre dar forças para continuar.

Ao meu irmão Jéferson e sua esposa que sempre me incentivaram e foram companheiros nesta

jornada.

A Fernanda que soube me escutar e me ajudar nos momentos difíceis em que passei na minha vida,

por torcer por mim, incentivando-me a chegar até aqui. Ao Carlos pela sua ajuda e troca de

experiências no decorrer do trabalho de conclusão de curso, e pelas descontrações no LSED.

Para os meus amigos Guilherme (compadre), Fernando e Rafael pelas noites de estudo em que

passamos resolvendo problemas que a faculdade nos exigia. Pela força e incentivo no decorrer deste

curso ajudando-me a superar as dificuldades encontradas.

SUMÁRIO

LISTA DE ABREVIATURAS E SIGLAS ...................................vi

LISTA DE FIGURAS ...................................................................vii

LISTA DE TABELAS.................................................................... ix

RESUMO ......................................................................................... x

ABSTRACT ....................................................................................xi

I. INTRODUÇÃO............................................................................ 1

1. APRESENTAÇÃO.......................................................................................1

2. JUSTIFICATIVA.........................................................................................2

3. IMPORTÂNCIA ..........................................................................................2

4. OBJETIVOS DO TRABALHO ..................................................................3

4.1 Objetivo Geral ................................................................................................................ 3

4.2 Objetivos Específicos...................................................................................................... 3

5. METODOLOGIA ........................................................................................4

5.1 Revisão Bibliográfica ..................................................................................................... 4

5.2 Desenvolvimento............................................................................................................. 5

II – REVISÃO BIBLIOGRÁFICA................................................ 7

1. SISTEMAS EMBARCADOS......................................................................7

1.1 Características dos sistemas embarcados .................................................................... 7

1.2 Aplicações dos sistemas embarcados ............................................................................ 8

1.3 Projeto de Sistemas Embarcados.................................................................................. 9

1.4 Requisitos ........................................................................................................................ 9

1.5 Metodologias de Projeto .............................................................................................. 10

1.5.1 Modelo Cascata ........................................................................................................... 10

1.5.2 Modelo Espiral ............................................................................................................ 11

1.5.3 Refinamento Sucessivo ............................................................................................... 12

1.5.4 Fluxos Hierárquicos do Projeto................................................................................... 13

1.6 Componentes de Sistemas Embarcados ..................................................................... 14

1.7 Plataforma..................................................................................................................... 14

2. ARQUITETURAS DE MICROCONTROLADORES COMERCIAIS16

2.1 Arquiteturas de Microcontroladores.......................................................................... 16

2.2 Exemplos de Microcontroladores Comerciais........................................................... 18

2.2.1 Arquitetura do Microcontrolador PIC16F628............................................................. 18

2.2.2 Arquitetura do Microcontrolador Rabbit 3000............................................................ 19

2.2.3 Arquitetura do Microcontrolador 8051 ....................................................................... 21

2.2.4 Resumos dos Microcontroladores Comerciais............................................................ 22

2.3 Aplicações de Microcontroladores.............................................................................. 22

2.3.1 Microcontroladores para Automóveis......................................................................... 22

2.3.2 Tranca Microcontrolada .............................................................................................. 24

2.3.2 Robótica ...................................................................................................................... 24

3. O MICROCONTROLADOR PIC16F628 ...............................................25

3.1 Interface ........................................................................................................................ 25

3.2 Estrutura interna.......................................................................................................... 27

3.3 Organização da memória............................................................................................. 28

3.4 Conjunto de instruções ................................................................................................ 31

4. ENTRADA-E-SAÍDA ................................................................................33

4.1 Barramentos de Entrada–e–Saída Seriais ................................................................. 34

4.2 Barramento I2C ............................................................................................................ 35

4.2.1 Características ............................................................................................................. 36

4.2.2 Definições básicas ....................................................................................................... 36

4.2.3 Transferência de dados no Barramento I2C................................................................. 37

4.2.4 O endereçamento no I2C ............................................................................................. 38

4.2.5 Dispositivos I2C........................................................................................................... 39

4.3 Display de Cristal Líquido – LCDs ............................................................................. 40

4.4 Motor de Passo ............................................................................................................. 42

4.5 Teclado Matricial ......................................................................................................... 46

4.6 Conversor Analógico-Digital (ADC)........................................................................... 47

4.7 Memória EEPROM...................................................................................................... 50

5. DRIVERS DE DISPOSITIVO ..................................................................53

III. DESENVOLVIMENTO......................................................... 57

iv

1 VISÃO GERAL ...........................................................................................57

2 MODELAGEM............................................................................................58

2.1 Análise de Requisitos ................................................................................................... 58

2.2 Especificação................................................................................................................. 59

2.3 Projeto Arquitetural .................................................................................................... 59

2.3.1 Arquitetura de Hardware............................................................................................. 59

2.3.2 Arquitetura de Software .............................................................................................. 62

3.1 Implementação ............................................................................................................. 75

3.2 Validação....................................................................................................................... 80

3.3 Uso dos Drivers Desenvolvidos.................................................................................... 84

3.4 Considerações sobre a Implementação dos Drivers para outros

Microcontroladores e Dispositivos.................................................................................... 87

IV – CONCLUSÕES E RECOMENDAÇÕES ........................... 89

BIBLIOGRAFIA........................................................................... 91

v

LISTA DE ABREVIATURAS E SIGLAS

A/D Analógico / Digital

ABS Antilock Braking System

BUS Barramento

CISC Complex Instruction Set Computers

CPU Unidade Central de Processamento

D/A Digital / Analógico

DSP Digital Signal Processors

E/S Entrada e Saída

EEPROM Electrically Erasable Programmable Read-Only Memory

EPROM Erasable Programmable Read-Only Memory

FSR File Select Register

GPS Sistema de Posicionamento Global

LCD Liquid Crystal Display

LSED Laboratório de Sistemas Embarcado e Distribuídos

MPEG Moving Picture Experts Group

MP3 MPEG Audio Layer 3

PDIP Plastic Dual In-Line Package

RAM Random Access Memory

RISC Reduced Instruction Set Computer

SOIC Small Outline Integrated Circuit

SSOP Small Shrink Outline Package

ULA Unidade Lógica Aritmética

UML Unified Modeling Language

UNIVALI Universidade do Vale do Itajaí

USART Universal Synchronous/Asynchronous Receiver/Transmitter

RS232 Protocolo de Comunicação Serial

DDs Device Drivers

SPI Serial Peripheral Interface

LIN Local Interconnect Network

CAN Controller Área Network

LISTA DE FIGURAS

Figura 1. Exemplo de sistema embarcado............................................................................................8

Figura 2. Modelo de desenvolvimento de software – Cascata...........................................................10

Figura 3. Modelo de projeto de Software – Espiral ...........................................................................11

Figura 4. Modelo de desenvolvimento Refinamento Sucessivo ........................................................12

Figura 5. Metodologia de projeto de um simples Hardware/Software. .............................................13

Figura 6. Arquiteturas de computadores: (a) Von-Neumann; (b) Harvard. .......................................17

Figura 7. Estrutura do Microcontrolador PIC16F628 ........................................................................19

Figura 8. Estrutura interna do Microcontrolador RABBIT 3000.......................................................20

Figura 9. Estrutura interna do Microcontrolador 8051. .....................................................................21

Figura 10. Uso de microcontroladores em automóveis nos países desenvolvidos.............................23

Figura 11. Diagramas de pinos para os encapsulamentos PDIP e SOIC. ..........................................25

Figura 12. Diagramas de pinos para os encapsulamentos PDIP e SSOP...........................................26

Figura 13. Estrutura interna do Microcontrolador PIC16F628 ..........................................................28

Figura 14. Mapa da memória de programa ........................................................................................29

Figura 15. Mapa da memória de Dados do Microcontrolador PIC16F628........................................30

Figura 16. Exemplo de configuração de barramento I2C ...................................................................37

Figura 17. Transferência de bit no barramento I2C............................................................................37

Figura 18. Condição de Inicio e de Parada.........................................................................................38

Figura 20. Diagrama de comunicação com LCD...............................................................................40

Figura 21. Teclado matricial ..............................................................................................................46

Figura 22. Pinagem do ADC0808 ......................................................................................................48

Figura 23. Interface do ADC0808 Temporização..............................................................................49

Figura 24. Diagrama de blocos do ADC0808 ....................................................................................50

Figura 25. Temporização de uma operação de escrita na EEPROM. ................................................52

Figura 26. Gerência de dispositivos ...................................................................................................54

Figura 27. Device Driver....................................................................................................................55

Figura 28. Visão geral do trabalho .....................................................................................................57

Figura 29. Diagrama de blocos da Arquitetura de Hardware.............................................................59

Figura 30. Diagrama de blocos da Arquitetura de Software ..............................................................62

Figura 31. Detalhamento das duas camadas inferiores da Arquitetura de Software..........................63

Figura 32. Diagrama de classes..........................................................................................................64

Figura 33. Diagrama de seqüência de inicialização dos Device Drivers. ..........................................67

Figura 34. Diagrama de seqüência de escrita em um LCD................................................................68

Figura 35. Diagrama de seqüência de escrita e leitura em uma memória EEPROM.........................69

Figura 36. Diagrama de seqüência de escrita em um Motor de Passo. ..............................................70

Figura 37. Diagrama de seqüência de escrita no Display de 7 Segmentos. .......................................71

Figura 38. Diagrama de seqüência de escrita e leitura em um Teclado Matricial. ............................72

Figura 39. Diagrama de seqüência de leitura em um Conversor AD.................................................73

Figura 40. Plataforma de Teste. .........................................................................................................76

Figura 41. Componente 74LS138 ......................................................................................................77

Figura 42. Componente 74LS373. .....................................................................................................78

Figura 43. Portas lógicas: (a) 74LS04, porta not; (b) 74HC32 ou porta lógica “or”. ........................78

Figura 44. Portas lógicas: (a) 74HC00, porta nand; (b) 74HC08, porta and ....................................78

Figura 45. Componente ULN2003A..................................................................................................79

Figura 46. Componente 74LS241, buffer tri-state .............................................................................79

Figura 47. AC Volter..........................................................................................................................80

Figura 48. Display de 7 segmentos. ...................................................................................................80

Figura 49. Motor de passo..................................................................................................................81

Figura 50. Memória Externa EEPROM (a), Memória Interna EEPROM (b)....................................81

Figura 51. Conversor ADC (a), Potenciômetros (b) .........................................................................82

Figura 52. Teclado Matricial (a), Display de 7 Segmentos (b) ..........................................................82

Figura 53. Arquivos de cabeçalho......................................................................................................84

Figura 54. Definições de uso dos dispositivos ...................................................................................85

Figura 55. Definição da estrutura struct_d7s e declaração do vetor device_d7s (incluídos no arquivo

drivers.h) ....................................................................................................................................86

Figura 56. Definição do número de instâncias...................................................................................86

Figura 57. Definições de mapas de endereço.....................................................................................86

Figura 58. Codificação dos pinos para o sistema baseado no PIC16F628.........................................87

viii

LISTA DE TABELAS

Tabela 1. Características dos microcontroladores PIC16F628, Rabbit 3000 e 8051. ........................22

Tabela 2. Descrição da interface do PIC16F628................................................................................26

Tabela 3. Instruções para operações com registradores orientadas a byte. ........................................31

Tabela 3. Instruções para operações com registradores orientadas a byte (continuação). .................32

Tabela 4. Instruções para operações com registradores orientadas a bit............................................32

Tabela 5. Instruções para operações com literais. ..............................................................................32

Tabela 6. Instruções de controle e desvio. .........................................................................................32

Tabela 6. Instruções de controle e desvio (continuação). ..................................................................33

Tabela 7. Resumo do catálogo de produtos I2C da Philips Semiconductors......................................39

Tabela 8. Pinagem do Módulo LCD ..................................................................................................41

Tabela 9. Seqüência de uma fase. ......................................................................................................44

Tabela 10. Seqüência de duas fases. ..................................................................................................44

Tabela 11. Seqüência de uma-duas fases. ..........................................................................................45

Tabela 11. Seqüência de uma-duas fases (continuação). ...................................................................45

Tabela 12. Códigos para varredura do teclado. ..................................................................................47

Tabela 14. Tabela-verdade da EEPROM ...........................................................................................51

Tabela 15. Sinais do barramento paralelo ..........................................................................................60

Tabela 16. Sinais do barramento I2C..................................................................................................60

Tabela 17. Dispositivos conectados ao barramento paralelo. ............................................................61

Tabela 18. Interfaces definidas pela camada Chamada de Dispositivo .............................................65

Tabela 18. Interfaces definidas pela camada Chamada de Dispositivo (continuação) ......................66

Tabela 19. Tamanho das funções implementadas. .............................................................................83

Tabela 20. Comparativo do tamanho das funções implementadas ....................................................84

RESUMO

No desenvolvimento do software de um sistema embarcado microcontrolado, muitas vezes,

é necessário que o projetista programe rotinas de interface com alguns dispositivos externos. Isso

exige que ele estude o protocolo de acesso ao dispositivo, desenvolva a rotina de interface e efetue a

validação da mesma. Essas tarefas consomem tempo e reduzem a produtividade. Para evitar esse

problema, em sistemas computacionais de uso geral, a interface com os dispositivos é feita através

de drivers, os quais são rotinas desenvolvidas especificamente para determinados dispositivos e que

aceitam solicitações abstratas de camadas superiores de software a fim de realizar o interfaceamento

com o dispositivo. Este trabalho insere-se nesse contexto e visa o desenvolvimento de drivers para

dispositivos a serem integrados em uma plataforma de sistema embarcado microcontrolado. Para

isso, foi realizada uma revisão bibliográfica sobre sistemas embarcados, microcontroladores,

dispositivos de entrada-e-saída e drivers de dispositivos. Este estudo serviu de apoio para o projeto

de uma plataforma de sistema embarcado baseada no microcontrolador PIC16F628 e em

dispositivos de entrada-e-saída comumente encontrados em tais sistemas (ex. LCD, ADC,

EEPROM, motor de passo, e outros). A plataforma de hardware projetada estabeleceu restrições a

partir das quais foram feitos os drivers. A metodologia de projeto utilizada inclui a análise de

requisitos, a especificação, o projeto arquitetural, o projeto de componentes e a integração dos

mesmos. Os drivers foram codificados em linguagem C e validados pela simulação da execução dos

mesmos na plataforma descrita em um simulador de sistemas eletro-eletrônicos.

Palavras-chaves: Sistemas Embarcados. Microcontroladores. Drivers de Dispositivos.

ABSTRACT

In the development of software for a microcontroller-based embedded system, many times it

is necessary that the designer programs interface routines for some external I/O devices. This

requires that he or she studies the access protocols to the devices, by developing and validating the

interface routines. These tasks require time and reduce design productivity. To avoid this problem,

in general purpose computer systems, the interface with devices is done by means of device drivers,

which are routines specially developed to specific devices, and which accept abstract calls from

higher level software layers in order to make the interfacing with the device. This work is inserted

in this context and aims the development of drivers to I/O devices to be integrated into a

microcontroller-based embedded system platform. To meet this goal, it was done a study about

embedded systems, microcontrollers, I/O devices and device drivers. This study was applied in the

development of an embedded system platform based on the PIC16F628 microcontroller and on I/O

devices commonly used in such kind of systems (ex. LCD, ADC, EEPROM, step motor, and others).

The hardware platform established constraints for the drivers. The used design methodology

included the analysis of requirements, the specification, the architectural design, the design of

components and the system integration. The device drivers was code in C language and validated

by means of the simulation of its execution on the hardware platform described in a simulator of

electronic systems.

Keywords: Embedded Systems. Microcontrollers. Device Drivers.

I. INTRODUÇÃO

1. APRESENTAÇÃO

Um sistema computacional embarcado pode ser definido como qualquer computador que

compõe um sistema maior e que se baseia em seu próprio microprocessador (WOLF, 2002).

Exemplos de sistemas computacionais embarcados são encontrados em fornos de microondas,

máquinas de lavar, aparelhos de telefonia móvel e em diversas outras aplicações nas áreas de

telecomunicações, automação e eletrônica de consumo. Os sistemas computacionais embarcados

apresentam requisitos de custo, consumo de energia e desempenho diferentes daqueles encontrados

em sistemas computacionais de uso geral (ex. computadores pessoais). Eles requerem em geral

unidades de processamento com menor poder computacional, com baixo custo e com o mínimo

consumo de energia (no caso de aplicações baseadas em baterias). Além disso, a maioria dos

sistemas embarcados integra equipamentos portáteis, nos quais características como peso e volume

são de vital importância. Por esses motivos, os sistemas embarcados são tipicamente baseados em

microcontroladores. Um microcontrolador é um sistema integrado que inclui, em uma única

pastilha, uma unidade central de processamento, memórias de programa e de dados, e também

alguns dispositivos periféricos, como, por exemplo, temporizadores, conversores A/D (Analógico

Digital) e portas de comunicação (SOUZA, 2000). Em muitos sistemas embarcados, alguns

periféricos não são integrados na mesma pastilha do microcontrolador, como, por exemplo,

dispositivos de interface com o usuário (teclado e Display) e memórias de maior capacidade.

Enquanto que o acesso aos periféricos integrados é bastante facilitado, pois é feito através dos

barramentos internos, o acesso aos dispositivos externos requer o uso de protocolos mais

complexos.

No desenvolvimento do software de um sistema embarcado microcontrolado, muitas vezes,

é necessário que o projetista programe rotinas de interface com alguns dispositivos externos. Isso

exige que o projetista estude o protocolo de acesso ao dispositivo, desenvolva a rotina de interface e

efetue a validação da mesma. Essas tarefas consomem tempo e reduzem a produtividade. Para evitar

esse problema, em sistemas computacionais de uso geral, a interface com os dispositivos é feita

através de drivers, os quais são rotinas desenvolvidas especificamente para determinados

dispositivos e que aceitam solicitações abstratas de camadas de software superiores a fim de realizar

o interfaceamento com o dispositivo (MACHADO e MAIA, 1992). O mesmo conceito pode e deve

ser aplicado em sistemas embarcados de modo a facilitar o desenvolvimento de software para esses

sistemas.

Este Trabalho de Conclusão de Curso insere-se nesse contexto, visando o desenvolvimento

de drivers para dispositivos de entrada-e-saída comumente utilizados em sistemas computacionais

embarcados baseados em microcontrolador. Nas seções a seguir, busca-se apresentar a justificativa

para a realização deste trabalho e destaca-se a sua importância. Após isso, são enumerados os seus

objetivos e é descrita a metodologia utilizada no seu desenvolvimento.

2. JUSTIFICATIVA

O presente trabalho permitirá a aplicação de conceitos estudados em diferentes disciplinas

no decorrer do Curso de Ciência da Computação. Mais especificamente, ele envolverá aspectos

estudados nas disciplinas das áreas de Arquitetura de Computadores, Sistemas Operacionais,

Programação e Análise e Projeto de Sistemas, permitindo a consolidação de um conjunto de

conhecimentos já adquiridos e a obtenção de novos conceitos não abordados no decorrer do curso

de graduação.

3. IMPORTÂNCIA

A disponibilidade de drivers para os dispositivos mais comumente utilizados em sistemas

computacionais embarcados facilitará o projeto de novos sistemas, pois, ao projetista, caberá

somente o desenvolvimento das rotinas de processamento das informações trocadas com os

dispositivos de entrada-e-saída. O projetista precisará apenas integrar o código dos drivers à sua

aplicação e não precisará se preocupar com detalhes dos protocolos de cada dispositivo utilizado.

Os resultados deste trabalho poderão ser reaproveitados no desenvolvimento de novos sistemas

computacionais embarcados, especialmente nos que serão desenvolvidos no escopo do Laboratório

de Sistemas Embarcados e Distribuídos (LSED) da UNIVALI, no qual este projeto será realizado.

2

4. OBJETIVOS DO TRABALHO

4.1 Objetivo Geral

O objetivo geral deste projeto é o desenvolvimento de drivers para dispositivos de entrada-e-

saída comumente utilizados em sistemas computacionais embarcados baseados em

microcontrolador.

4.2 Objetivos Específicos

Os objetivos específicos deste trabalho são:

1. Possuir uma base de conceitos sobre projeto de sistemas computacionais embarcados;

arquiteturas de microcontroladores e aplicações; arquitetura do microcontrolador

PIC16F628; barramentos e dispositivos de entrada-e-saida de sistemas computacionais

embarcados; e drivers para dispositivos de E/S.

2. Selecionar os dispositivos de E/S mais adequados para as aplicações que serão utilizadas

no LSED (Laboratório de Sistemas Embarcados e Distribuídos);

3. Disponibilizar uma plataforma baseada no microcontrolador PIC16F628 e no conjunto

de dispositivos de entrada-e-saída selecionados para validar os drivers projetados;

4. Projetar e desenvolver os drivers para os dispositivos de entrada-e-saída com base nas

restrições arquiteturais definidas pela plataforma;

5. Com base na experiência adquirida fazer uma análise de requisitos para implementação

de device drivers para outro microcontrolador e para outros tipos de dispositivos.

3

5. METODOLOGIA

5.1 Revisão Bibliográfica

Foi realizado um levantamento bibliográfico com o objetivo de identificar referências que

permitam fundamentar os conceitos necessários ao desenvolvimento deste trabalho. Este

levantamento bibliográfico foi baseado em livros e em artigos técnico-científicos. Essas referências

forma obtidas através da biblioteca da UNIVALI (Universidade do Vale do Itajaí), e também na

biblioteca do LSED (Laboratório de Sistemas Embarcados e Distribuídos), bem como em sites de

fabricantes de microcontroladores e publicações disponibilizadas na Internet. Em paralelo ao estudo

dos textos pesquisados, foi realizada uma revisão bibliográfica sobre assuntos relacionados ao

trabalho, a partir da qual elaborou-se este texto, cuja parte de revisão é estruturada com os seguintes

capítulos: (i) sistemas computacionais embarcados; (ii) arquiteturas de microcontroladores

comerciais de 8 bits; (iii) microcontrolador PIC16F628; (iv) conjunto de dispositivos de entrada-e-

saida para sistemas computacionais embarcados; (v) drivers de dispositivos.

No capítulo sobre sistemas computacionais embarcados, buscou-se descrever conceitos

sobre esses sistemas e metodologias associadas ao seu projeto. O capítulo foi baseado na leitura dos

textos obtidos no levantamento bibliográfico, porém, já se dispõe de duas referências que servirão

de base ao estudo associado: o livro “Computer as Components” (WOLF, 2002) e o capítulo

“Sistema Computacionais Embarcados” do livro “XXII Jornadas de Atualização em Informática”

escrito por Carro e Wagner (2003).

O capítulo sobre microcontroladores apresenta os principais conceitos associados a esse tipo

processador, buscando-se enfatizar as características do microcontroladores comerciais de 8 bits,

bem como exemplos de aplicação desses microcontroladores. O estudo associado foi baseado na

leitura dos textos levantados, sendo que, por hora, já foram feitas leituras iniciais do livro

“Handbook of Microcontrollers” (PREDKO, 1998), “Desbravando o PIC” (SOUZA, 2000) e

“Microcontroladores PIC: Programação em C” (PEREIRA, 2003). Além desses textos, serão

considerados datasheets e livros sobre outros microcontroladores, bem como artigos técnico-

científicos sobre aplicações baseadas em microcontroladores.

4

O capítulo posterior, sobre o microcontrolador PIC, apresenta os principais conceitos

associados a essa família de microcontroladores, e, principalmente, os detalhes arquiteturais do

modelo PIC16F628 que sejam mais relevantes a este trabalho. O estudo associado foi baseado na

leitura de manuais técnicos disponibilizados pela Microchip e de livros específicos sobre o PIC

(SOUZA, 2000).

No capítulo sobre dispositivos de entrada-e-saída para sistemas computacionais embarcados

foram descritos conceitos sobre esses dispositivos, incluindo suas interfaces e princípio de

funcionamento. Com o estudo realizado, foi possível definir precisamente quais dispositivos serão

usados no desenvolvimento do projeto, em geral o critério de seleção a ser utilizado será baseado

nos projetos desenvolvidos no LSED de forma que a utilização destes dispositivos se adequem mais

as necessidades do laboratório. O estudo associado foi baseado na leitura de artigos de revistas

técnicas disponíveis na biblioteca do LSED e em textos publicados na Internet. Também buscou-se

descrever conceitos, características e trabalhos relacionados.

O capitulo sobre drivers de dispositivos apresenta os principais conceitos associados ao

tema visando complementar a formação já obtida na disciplina de Sistemas Operacionais. A redação

deste capítulo foi baseada na leitura de livros disponibilizados nas bibliotecas da UNIVALI e do

LSED (TANENBAUM, 2000), (MACHADO, 1992) e (SILBERCHATZ, 2000), além de

referências as quais foram obtidas com a pesquisa bibliográfica.

5.2 Desenvolvimento

Após a revisão bibliográfica, foi feito o desenvolvimento do trabalho, o qual iniciou com a

pré-modelagem do sistema realizada ainda na primeira fase do trabalho de conclusão de curso. Essa

pré-modelagem orientou os estudos e experimentos que seriam necessários para consolidar os

conhecimentos adquiridos com a revisão bibliográfica. Tais experimentos foram baseados no uso do

compilador C da CCS para microcontroladores PIC e do simulador Proteus da Labcenter

Electronics para a simulação de sistemas eletro-eletrônicos.

Inicialmente buscou-se fazer a implementação dos drivers sob a forma de rotinas de entra-e-

saída independentes entre si visando verificar o funcionamento das ferramentas de

desenvolvimento. Nesse contexto, assumiu-se que os dispositivos eram conectados diretamente ao

5

microcontrolador, ou seja, sem uso de barramentos. Após, foi feita a modelagem de um sistema

baseado no PIC16F877, que permitiu trabalhar com um barramento de dados de 8 bits.

Com o conhecimento adquirido nesses experimentos fez-se uma revisão da pré-modelagem

e então iniciou-se o desenvolvimento da plataforma baseada no microcontrolador PIC16F628. Essa

plataforma contém dois barramentos: um barramento serial I2C de dois fios e um barramento

paralelo de 4 bits com dados e endereços separados (11 fios = dados + endereço + controle).

Uma vez definida a plataforma, foram então desenvolvidos os drivers para os dispositivos

selecionados, os quais incluíram: dispositivo I2C (memória EEPROM), teclado matricial (tipo

telefone), conversor A/D de 8 canais, motor de passo e displays de 7 segementos e de cristal

líquido.

A metodologia de projeto utilizada baseou-se na análise de requisitos, especificação, projeto

arquitetura, projeto de componentes e integração. A modelagem foi feita utilizando UML (Unified

Modeling Language) (FURLAN, 1998) e os drivers foram codificados em linguagem C. A

validação baseou-se na simulação da execução dos drivers na plataforma utilizando o simulador

Proteus.

6

II – REVISÃO BIBLIOGRÁFICA

1. SISTEMAS EMBARCADOS

Um sistema embarcado pode ser brevemente definido como qualquer computador que é

componente de um sistema maior e que possui o seu próprio microprocessador (WOLF, 2002).

Outros autores definem um sistema embarcado como sendo um sistema computacional que foi

incluído em um outro sistema com a finalidade outra que a de fornecer processamento genérico. Ou

seja, um pequeno computador que foi embutido em um sistema maior (ZELENOVSKY e

MENDONÇA, 2003).

Na literatura, em inglês, os sistemas embarcados são denominados embedded systems

(WOLF, 2003), enquanto que, na literatura em português, diversos autores utilizam termos

diferentes para esses sistemas computacionais, como sistemas embutidos e sistemas acoplados

(OYAMADA e WAGNER, 1999), ou, ainda, sistemas dedicados.

Neste capítulo são apresentados alguns conceitos básicos sobre sistemas embarcados,

incluindo: características, aplicações, metodologias de projetos e componentes utilizados na

construção desses sistemas, entre outros assuntos.

1.1 Características dos sistemas embarcados

Os sistemas embarcados caracterizam-se por, na maioria das vezes, trabalharem de forma

reativa, podendo ainda possuir restrições de tempo real (OLIVEIRA, 2003). Geralmente, um

sistema embarcado realiza uma única função ou mesmo um conjunto pequeno e coeso de funções.

Seu uso é de propósito especifico, sendo o seu projeto fortemente influenciado pelo consumo de

energia, custo do hardware e confiabilidade. Possui ainda uma diversidade variada de processadores

e soluções de hardware, e, no seu projeto, é utilizada uma plataforma baseada em um computador

de propósito geral, mas sua execução é feita em um computador de propósito específico. Na Figura

1 é mostrado um exemplo de Sistema Embarcado.

Além da variedade de processadores, são utilizados diferentes tipos e modelos sistemas

operacionais. No caso de ocorrência de falhas, suas implicações são muito mais sérias do que as

decorridas em um computador de mesa. Isso se dá devido à tolerância do usuário ser muito menor

do que em sistemas computacionais de uso geral (OLIVEIRA, 2003), por exemplo:

A ocorrência de uma falha em um sistema computacional embarcado, como no caso de um

microcontrolador que controla o freio ABS de um carro, causaria muitas complicações, em

contrapartida se a mesma falha ocorresse em seu computador, não causaria tantos danos.

Memória dePrograma

Memória de Dados

Periféricos e E/S - Relógio de tempo-real - Temporizadores - Memória EEPROM - Conversor A/D - . . .

CPU

Figura 1. Exemplo de sistema embarcado

1.2 Aplicações dos sistemas embarcados

Conforme Carro e Wagner (2003), “os sistemas embarcados estão presentes em

praticamente todas as atividades humanas, e, com os baixos custos tecnológicos atuais, tendem a

aumentar sua presença no cotidiano das pessoas”.

Os sistemas embarcados são encontrados em diferentes equipamentos, como telefones que

discam por comandos de voz, televisores que se conectam à Internet, microondas operados

remotamente, máquinas fotográficas que não usam filmes e automóveis que estacionam sozinhos

(ZELENOVSKY e MENDONÇA, 2003). Eles podem ser utilizados em sistemas de grande porte,

como em aviões e automóveis, ou em sistemas de pequeno porte, como em tocadores de MP3 e

medidores de pressão sangüínea (OLIVEIRA, 2003).

8

1.3 Projeto de Sistemas Embarcados

O projeto de sistemas embarcados é tipicamente baseado na aplicação de alguma

metodologia que visa facilita a execução do projeto. Segundo Carro e Wagner (2003), Devido à

possível complexidade da arquitetura de um sistema embarcado, contendo múltiplos componentes

de hardware e software em torno de uma estrutura de comunicação, e à grande variedade de

soluções possíveis visando o atendimento de requisitos de projeto, como desempenho, consumo de

potência e área ocupada, é essencial o projeto do sistema em níveis de abstração elevados e

utilizando ferramentas que automatizem ao máximo as diversas etapas de uma metodologia

consistente com os desafios existentes.

O projeto de um sistema embarcado é iniciado usualmente por uma especificação da

funcionalidade desejada, feita através de uma linguagem ou formalismo adequado (CARRO e

WAGNER, 2003). Na realização de um projeto de sistema embarcado, o projetista pode se deparar

com alguns problemas importantes, entre os quais destacam-se: a disponibilidade de alternativas

para a escolha dos componentes de hardware; a definição de como os requisitos estabelecidos serão

alcançados; o estabelecimento de estratégias de minimização do consumo de energia; a garantia de

que a plataforma desenvolvida possa ser reutilizada e/ou estendida para diferentes projetos; e a

possibilidade de se obter um sistema confiável (WOLF, 2002).

1.4 Requisitos

Antes de iniciar o projeto, necessita-se capturar as informações para usar na criação de

componentes e da arquitetura. Segundo Wolf (2002), os requisitos podem ser classificados como

funcionais e não-funcionais. Os requisitos não funcionais típicos são: desempenho, custo, consumo

de energia, tamanho físico e peso. O desempenho do sistema é a maior consideração para a

aplicação do mesmo e para o seu custo final. Na maioria dos sistemas embarcados, gasta-se um

tempo significativo controlando dispositivos ou processando dados e, por isso, é importante que os

requisitos de desempenho sejam identificados cedo. O custo tem dois componentes maiores: o custo

de fabricação (inclui o custo dos componentes de hardware e software) e o custo do produto. O

consumo de energia é extremamente importante em sistemas alimentados por baterias. A energia

consumida pode ser especificada no estágio de requisitos em termos de duração da bateria. Deve-se

ter uma idéia de quanto de energia o sistema vai consumir, sendo que a decisão mais importante é

9

se a máquina será alimentada por uma bateria ou pela rede elétrica. Por fim, os aspectos físicos

podem variar dependendo da aplicação. Deve-se dar indicações do tamanho físico do sistema para

servir de guia em decisões de arquitetura

1.5 Metodologias de Projeto

O processo de uso da metodologia de projeto é importante porque sem ele, não se pode

confiar a entrega o produto que será produzido. Wolf (2002) descreve cinco modelos de fluxo de

projeto possíveis de serem adotados em metodologias de projeto de sistemas embarcados, quatro

dos quais são resumidos nesta seção, com base no texto original de Wayne Wolf.

1.5.1 Modelo Cascata

O modelo cascata, ilustrado na Figura 2, foi introduzido por Pressman (1995) e é

considerado o primeiro modelo proposto para o processo de desenvolvimento de software.

Figura 2. Modelo de desenvolvimento de software – Cascata Fonte: Pressman (1995)

10

Nesse modelo, os principais subprocessos são executados em estrita seqüência, o que

permite demarcá-las com pontos de controle bem definidos, facilitando a gestão do projeto e

deixando confiável a sua utilização em projeto de qualquer escala (PAULA FILHO, 2001). Ele

consiste de cinco fases principais: (i) determinação dos requisitos, a qual define as características

básicas do sistema; (ii) projeto da arquitetura, o qual decompõe a funcionalidade do sistema em

componentes principais; (iii) codificação, na qual os componentes são implementados e integrados;

(iv) teste, na qual são identificados os possíveis erros; e (v) manutenção, fase em que são feitas as

correções dos erros e as atualizações.

1.5.2 Modelo Espiral

O modelo espiral, ilustrado na Figura 3, supõe que diversas versões do sistema estão sendo

construídas, enquanto que o modelo Cascata supõe que o sistema está construído em uma única vez.

Figura 3. Modelo de projeto de Software – Espiral Fonte: Wolf (2002)

11

O modelo espiral é mais utilizado em sistemas complexos que possuem uma característica

de desenvolvimento de projeto em níveis. Em cada nível do projeto, os projetistas atravessam as

fases de análise de requisitos, construção e teste. Em estágios mais posteriores, quando uma versão

mais completa do sistema é construída, cada fase requer mais trabalho, alargando a espiral do

projeto. Esta abordagem baseada em refinamentos sucessivos ajuda o projetista a compreender o

sistema em que está trabalhando através de uma série de ciclos do projeto. O modelo espiral é mais

realista do que o modelo de cascata porque as interações múltiplas são freqüentemente necessárias

adicionando mais detalhes para o término do projeto (WOLF, 2002).

1.5.3 Refinamento Sucessivo

A metodologia de projeto usando refinamento sucessivo é demonstrada na Figura 4. Nessa

abordagem, o sistema é construído em diversas iterações. Na primeira delas, o sistema é utilizado

como um protótipo menos detalhado, sendo que nos modelos obtidos nas iterações sucessivas o

sistema vai ficando mais refinado. Essa metodologia faz sentido quando não se tem experiência

com o domínio da aplicação para qual se está construindo o sistema. O refinamento é feito através

da construção de versões cada vez mais complexas, o que permite ao projetista testar outras

arquiteturas e técnicas de projeto (WOLF, 2002).

Figura 4. Modelo de desenvolvimento Refinamento Sucessivo Fonte: Adaptado de Wolf (2002)

12

1.5.4 Fluxos Hierárquicos do Projeto

O fluxo hierárquico de projeto, mostrado na Figura 5, combina metodologias de projeto de

hardware e de software. Atividades tais como a especificação e arquitetura são simultâneas e

consideram aspectos do hardware e do software. Similarmente, a integração final testa e considera o

sistema inteiro. No meio, entretanto, os desenvolvimentos dos componentes de hardware e de

software podem ser relativamente independentes, enquanto que o teste requer que todos os

componentes estejam prontos.

Figura 5. Metodologia de projeto de um simples Hardware/Software Fonte: Wolf (2002)

De fato, muitos sistemas embarcados complexos são constituídos por projetos mais simples.

Os sistemas completos podem requer o projeto de componentes de software, circuitos integrados de

aplicação específica, e assim por diante, e esses, por sua vez, podem ser construídos com base em

componentes menores que necessitam ser projetados.

13

1.6 Componentes de Sistemas Embarcados

Um sistema embarcado pode ser constituído por diferentes componentes de hardware,

incluindo ao menos uma unidade de processamento, memória e alguns dispositivos de entrada-e-

saída (E/S). Entre as unidades de processamento, tipicamente, são utilizados microcontroladores

e/ou processadores de sinais digitais (DSPs – Digital Signal Processors). A memória é baseada em

dispositivos semicondutores (chips) e armazena instruções de programas e os dados processados.

Os dispositivos de entrada-e-saída realizam a interface com o mundo externo e incluem teclados,

mostradores, sensores e atuadores (ex. motor de passo). Em geral, são necessários circuitos de

conversão analógico-digital (A/D) e/ou digital-analógico (D/A), assim como circuitos de potência.

Quanto aos componentes de software, um sistema computacional embarcado pode ser

baseado em um único código escrito para a aplicação. Contudo, em sistemas mais complexos, o

software pode ser estruturado, incluindo o código da aplicação, um sistema operacional e drivers

para os dispositivos de entrada-e-saída. O sistema operacional, por sua vez, pode ter características

que garantam a execução de tarefas em tempo-real, ou seja, que respeitem limites de tempo de

execução estabelecidos.

1.7 Plataforma

Com o avanço tecnológico, tem sido possível o desenvolvimento aplicações embarcadas

cada vez mais sofisticadas, porém os sistemas computacionais utilizados tornam-se ainda mais

complexos. Para lidar com essa complexidade crescente e assegurar o cumprimento de metas de

mercado, uma nova metodologia de projeto tem sido utilizada. Essa metodologia, denominada

“Projeto Baseado em Plataforma”, estabelece uma arquitetura de hardware e software específica

para um domínio de aplicação, mas altamente parametrizável (DEMMELER & GIUSTO, 2001;

DUTTA, JENSEN & RIECKMANN, 2001; PAULIN et al., 1997 apud ZEFERINO 2003).

Segundo Zeferino (2003),

Uma plataforma inclui ferramentas de apoio ao projeto e bibliotecas com componentes de hardware (ex. processadores, memórias, dispositivos de E/S) e de software (ex. drivers de dispositivos, sistemas operacionais de tempo-real e códigos de aplicação), os quais podem ser parametrizados para atender aos requisitos do sistema alvo. A idéia básica é que uma arquitetura adequada e eficiente para uma aplicação também será adequada e eficiente para muitas aplicações similares.

14

O uso da mesma arquitetura para o desenvolvimento de uma aplicação não apenas acelera o

projeto da aplicação como também reduz o seu tempo de verificação (KUMAR et al. 2002 apud

ZEFERINO, 2003).

Um exemplo de plataforma de sistema embarcado pode ser baseado em uma família de

microcontroladores (ex. PIC16) e um conjunto de periféricos e dispositivos de entrada-e-saída,

incluindo:

teclado matricial de telefone para interface de entrada com o usuário; •

•

•

•

•

•

Display de cristal líquido para interface de saída com o usuário;

memória EEPROM externa para armazenamento permanente de grandes quantidades de

dados;

motor de passo para acionamento de dispositivos mecânicos;

conversor A/D para captura de sinais analógicos obtidos via sensores;

e outros.

O uso de uma única família de microcontrolador nessa plataforma facilita o reuso dos

códigos, pois todos os modelos dessa família possuem o mesmo conjunto de instruções, embora

possam ter memórias de tamanhos diferentes e periféricos internos variados. Por exemplo, na

família PIC16, existem dois modelos denominados PIC16F84 e PIC16F628. Ambos utilizam a

mesma arquitetura (conjuntos de instruções e modos de endereçamento), mas o PIC16F628 possui

memória internas maiores e periféricos de maior capacidade ou até inexistente no PIC16F84 (ex.

porta de comunicação serial).

O tempo e o custo para desenvolvimento de uma plataforma com essa podem ser grandes,

contudo, uma vez disponibilizada, o projeto de sistemas embarcados baseados nessa plataforma

tende a ser rápido e de baixo custo, uma vez que tanto o hardware como o software já tenham sido

projetados e verificados. Cada sistema baseado nessa plataforma pode utilizar diferentes

dispositivos ou mesmo modelo de microcontrolador da mesma família, de modo que só serão

utilizados no produto final os dispositivos necessários e o modelo de microcontrolador de menor

custo.

15

2. ARQUITETURAS DE MICROCONTROLADORES COMERCIAIS

Um microcontrolador pode ser definido como um sistema computacional auto-contido em

que o processador, o sistema de suporte, a memória e a entrada-e-saída são todos integrados em um

único encapsulamento (PREDKO, 1998).

Segundo Souza (2000) pode-se definir um microcontrolador “como um ‘pequeno’

componente eletrônico, dotado de uma ‘inteligência’ programável, utilizado no controle de

processos lógicos”.

Assim como um computador pessoal (PCs – Personal Computers), um microcontrolador é

um sistema computacional que, a partir de dados de entrada, executa algum processamento,

mediante um programa armazenando em uma memória, e gera uma saída. Contudo, um

microcontrolador é um sistema computacional integrado em uma única pastilha de silício e possui

requisitos de tamanho, custo, energia e desempenho diferentes dos PCs. Além disso, um

microcontrolador tem como função principal o controle de processo lógicos, enquanto que os

microprocessadores são projetados visando o processamento de dados.

2.1 Arquiteturas de Microcontroladores

Como qualquer sistema computacional, o desempenho de um microcontrolador é fortemente

dependente da sua estrutura interna, normalmente referenciada pelo termo “arquitetura”. Além

disso, o desempenho depende de como o software foi implementado (MARINHO e MARINHO,

2001).

Uma grande parte dos microcontroladores utilizam um tipo de arquitetura denominada Von-

Neumann (ou Princeton), enquanto que uma pequena parcela utiliza uma arquitetura chamada de

Harvard. Souza (2000) identifica a diferença básica entre esses dois tipo de arquitetura. Segundo

esse autor,

A diferença está na forma como os dados e o programa são processados pelo microcontrolador. Na arquitetura tradicional, tipo Von-Neumann, existe apenas um barramento (bus) interno (geralmente de 8 bits), por onde passam as instruções e os dados.

16

Já na arquitetura tipo Harvard existem dois barramentos internos, sendo um de dados e outro de instruções.

Marinho e Marinho (2001) complementam esse conceito, afirmando que.

Na arquitetura do tipo Von-Neumann, os barramentos de dados e endereços são compartilhados entre memória de programa e memória de dados na comunicação com a CPU. [...] Neste tipo de arquitetura, quando a CPU está acessando a memória de programas não pode acessar a memória de dados, por que usa os mesmos barramentos para as duas memórias.

Na Figura 6.a, é ilustrado um exemplo de arquitetura Von-Neumann na qual observa-se a

existência de um único barramento para acesso a dados e a instruções de programa. Já na Figura

6.b, é mostrada uma arquitetura Harvard em que a existência de barramentos separados para dados e

instruções que permite que no instante em que uma instrução é executada, outra seja obtida da

memória, tornando o processamento mais rápido.

CPU

Program a Dados

E/SCPU

Program a Dados

E/S

(a) (b)

Figura 6. Arquiteturas de computadores: (a) Von-Neumann; (b) Harvard

Os microcontroladores podem, ainda, ser baseados em uma arquitetura CISC (Complex

Intruction Set Computers) ou RISC (Reduced Instruction Set Computer). Algumas diferenças

básicas entre essas duas arquiteturas podem ser enumeradas. Primeiramente, as máquinas CISC

possuem um conjunto de instruções bastante amplo (centenas), com vários modos de

endereçamento, formatos e tamanhos de instrução. Já as máquinas RISC possuem um conjunto

pequeno de instruções (dezenas), suportam poucos modos de endereçamento a suas instruções

possuem o mesmo tamanho e baseiam-se em poucos formatos de instrução. Uma diferença

importante está na implementação do conjunto de instruções. Nos processadores CISC, as

instruções de máquina são implementas sob a forma de microprogramas, os quais são interpretados

durante a execução das instruções. Já nos processadores RISC, cada instrução é implementada

17

diretamente em hardware (hardwired), perdendo em flexibilidade, mas ganhando em desempenho.

Continuando, os processadores CISC possuem poucos registradores (ex: 8 a 16) enquanto que os

RISCs incluem várias dezenas de registradores (MONTEIRO, 2001; TANEMBAUM, 2001).

2.2 Exemplos de Microcontroladores Comerciais

2.2.1 Arquitetura do Microcontrolador PIC16F628

O PIC16F628 da Microchip (2002) é um microcontrolador de 8 bits que possui uma

arquitetura Harvard/RISC com 35 instruções. Internamente, ele inclui uma memória FLASH com

2048 palavras de instrução de 14 bits de largura, uma memória RAM de dados com 224 bytes e

uma memória EEPROM com 128 bytes. Quanto aos periféricos internos, o PIC16F628 integra três

temporizadores, uma USART (Universal Synchronous/Asynchronous Receiver/Transmitter), dois

comparadores analógicos e 15 pinos de E/S. Na Figura 7, é apresentado o diagrama de blocos

interno do PIC16F628.

18

Figura 7. Estrutura do Microcontrolador PIC16F628 Fonte: Microchip (2002)

2.2.2 Arquitetura do Microcontrolador Rabbit 3000

O Rabbit 3000 da Rabbit Semiconductors (2003) é um microcontrolador de 8 bits baseado

em uma arquitetura Von Neumann/CISC com um amplo conjunto de instruções. As memórias de

programa e dado são externas, o que permite a inclusão de um grande número de periféricos

internos, incluindo seis portas seriais, 56 pinos de E/S (de um total de 128 pinos), dez

temporizadores de 8 bits e um de 10 bits, um relógio de tempo real e uma unidade de gerenciamento

de memória externa que suporta 1 MB de espaço de dados e programa, além de outros periféricos.

19

O Rabbit 3000 inclui ainda hardware e software adicional disponibilizados na forma de uma

plataforma para desenvolvimento de sistemas embarcados com conectividade à Internet, incluindo

as bibliotecas para os protocolos mais utilizados.

Na Figura 8 é apresentado o diagrama de blocos interno do Rabbit3000.

Figura 8. Estrutura interna do Microcontrolador RABBIT 3000 Fonte: Rabbit Semiconductor (2003)

20

2.2.3 Arquitetura do Microcontrolador 8051

O 8051 é um microcontrolador de 8 bits com 32 linhas de E/S bidirecionais endereçáveis

individualmente, 128 bytes de RAM interna destinada a dados e 4 Kbytes de memória de programa

interna (ROM ou EPROM), sendo que os espaços de endereçamento de memória de dados e de

programa são iguais a 64 Kbytes, os quais podem ser explorados por meio do uso de memórias

externas. Além disso, o 8051 inclui dois temporizadores/contadores de 16 bits, cinco fontes de

interrupção e porta serial programável (INTEL, 1995). Na Figura 9, é apresentado o diagrama de

blocos interno do 8051.

Figura 9. Estrutura interna do Microcontrolador 8051

Fonte: Intel (2003)

21

2.2.4 Resumos dos Microcontroladores Comerciais Na Tabela 1, são resumidas as características dos microcontroladores descritos acima.

Tabela 1. Características dos microcontroladores PIC16F628, Rabbit 3000 e 8051.

Características PIC16F628 Rabbit 3000 8051

Palavras de Dados (bits) 8 8 8

Memória de Dados

(palavras) RAM

224 Externa 128

Palavra de instrução

(bits)

14 Variável (8,16) 8 a 24

Memória de Programas

(palavra)

FLASH

2048

FLASH

512

ROM

4096

Pinos de E/S 16 56 / 128 32

Portas Serial 6 portas seriais IrDA Serial

Freqüência 20MHz 54 MHz 12 MHz

Temporizadores 3 +WDT 1 de 8 bits e outro de

10 bits

2 de 16 bits

Funções Analógicas 1 PWM

2 Comparadores

1 PWM

1 A/D

−×−

EEPROM 128 Externa −×−

Nº de Instruções 35 258 Mais de 100

Arquitetura Interna Harvard

RISC

Von-Neumann

CISC

Von- Neumann

CISC

Fonte: Adaptado de Microchip (2002), Intel (2003), Rabbit Semiconductor (2003)

2.3 Aplicações de Microcontroladores

2.3.1 Microcontroladores para Automóveis

Segundo Ross Bannatyne (2003) da Motorola, nos próximos dez anos será observado um

crescimento em no uso sistemas eletrônicos automotrizes equivalente ao que foi visto na última

década. A Figura 10 ilustra o crescimento da aplicação dos microcontroladores nos automóveis em

22

paises desenvolvidos. Três categorias são mostradas; veículos de baixo e de médio custos, assim

como veículos luxuosos. Tipicamente, os sistemas são introduzidos primeiramente em veículos

luxuosos e, eventualmente, migram para os de baixo custo. O tempo para a migração para os

automóveis de baixo custo depende de quão rapidamente o sistema pode ter seu custo reduzido e

dos opcionais requeridos pelos consumidores (ex. Freio ABS, ar-condicionado inteligente, airbag).

0

20

40

60

80

100

120

1998 2000 2002

Ano

Núm

ero

de m

icro

cont

rola

dore

s

Baixo custoMédio custoLuxuoso

Figura 10. Uso de microcontroladores em automóveis nos países desenvolvidos

Fonte: Adaptado de Bannatyne (2003)

Os sistemas de controle eletrônico para automóveis utilizados atualmente estão sendo

aperfeiçoados. Por exemplo, considerando os sistemas de airbag espera-se que os dois airbags

frontais que são hoje comuns estarão associados a airbags laterais, inferiores (pés, joelhos) e airbags

traseiros (para os passageiros), com funções avançadas para detectar a posição do ocupante.

Similarmente, as funções de controle de frenagem bem como de direção e de tração serão

desenvolvidos executando em sistemas eletrônicos mais avançados. Assim como aumenta a

complexidade dos sistemas já existentes, muitos sistemas completamente novos serão adicionados.

Em poucos anos serão introduzidos (ou popularizados) sistemas para navegação GPS, gerência da

estabilidade, frenagem, direção, reconhecimento e aviso da colisão, voz, acesso a Internet e realce

da visão noturna. Dados relevantes dos automóveis podem ser usados como um back-up sob

determinadas circunstâncias. Por exemplo, a velocidade da roda e a informação direcional do

veículo usada em um sistema de gerência da estabilidade poderiam ser usadas para suplementar o

sistema de navegação, caso o GPS o perca.

23

2.3.2 Tranca Microcontrolada

Em um projeto de implementação de uma tranca microcontrolada utilizam-se alguns

componentes como um teclado de dezesseis teclas padrão telefônico e um mostrador de cristal

líquido (LCD - Liquid Cristal Display) para interface com o usuário. A senha pode ser alterada

facilmente através do próprio teclado, mas isso só pode ser feito se o usuário conhecer também uma

outra senha, chamada de senha “Master”. Essa senha Master não pode ser mudada sem se mexer no

programa do microcontrolador, já a senha de acesso é armazenada em uma memória EEPROM, que

pode ser modificada via teclado. A principal vantagem desse tipo de projeto é a possibilidade de se

trocar à senha sem a necessidade de se desmontar o circuito, o que é necessário a outros

equipamentos não microcontrolados.

2.3.2 Robótica

Outras aplicações utilizando microcontroladores também podem ser encontradas, com é o

caso de controles de robôs ex um robô detector de minas.

As Minas Terrestres podem estar em diferentes tipos de ambientes que podem variar de um

relevo acidentado, areia e até mesmo pântanos. Estas situações variadas de ambientes tem que ser

levadas em consideração na construção de um robô detector de Minas Terrestres. O hardware do

robô precisa ser bastante completo e equipado com sensores de forma que o robô possa interagir

com o ambiente e tomar decisões a partir destas interações. O robô também necessita de um

processamento local para que os dados dos sensores sejam interpretados e o robô possa através

disso tomar decisões que permitam a detecção da Mina Terrestre.

O projeto denominado Handy Board é uma placa que usa como processador local, o

microcontrolador MC68HC11A1 da Motorola que é bastante versátil por possuir diversas

características de hardware tais como vários pinos de I/O, comunicação serial, conversores A/D,

etc. A placa também possui 32K de memória RAM que mantém seus dados armazenados por estar

ligado diretamente à bateria que alimenta a placa. Para acionamento dos motores, a Handy Board

possui dois chips SN754410NE que permitem o acionamento de 4 motores. Estes chips são duas

pontes H que permitem o controle do motor por Modulação em Largura de Pulso (PWM).

24

3. O MICROCONTROLADOR PIC16F628

O PIC16F628 da Microchip é um dos microcontroladores da vasta família de dispositivos

oferecidos pela Microchip. Conforme foi introduzido no capítulo anterior, ele possui palavra de

dado de 8 bits com 35 instruções RISC de tamanho fixo (14 bits) e suporta três modos de

endereçamento: direto, indireto e relativo (MICROCHIP, 1999). Ele integra uma memória de

programa Flash, uma memória de dados RAM e uma memória de dados EEPROM, além de um

conjunto de periféricos e pinos de entrada e saída. Neste capítulo é apresentada uma descrição mais

detalhada desse microcontrolador sem, contudo, ser exaustiva. Inicialmente, apresenta-se a interface

do PIC16F628 e a sua estrutura interna. Após, é apresentada a organização do seu espaço de

memória e o seu conjunto de instruções.

3.1 Interface

O microcontrolador PIC16F628 é disponibilizado em encapsulamentos com 18 ou com 20

pinos, ilustrados nas Figuras 11 e 12. Uma diferença básica entre os dois tipos é que no modelo com

20 pinos existem dois pinos a mais para alimentação.

Figura 11. Diagramas de pinos para os encapsulamentos PDIP e SOIC Fonte: Microchip (2002)

25

26

Figura 12. Diagramas de pinos para os encapsulamentos PDIP e SSOP Fonte: Microchip (2002)

Os pinos da interface do PIC16F628 são, em sua maioria, multifuncionais e podem ser

configurados para cumprir uma outra função, conforme pode ser observado na Tabela 2, que

descreve a interface desse microcontrolador.

Tabela 2. Descrição da interface do PIC16F628.

Nome Definição RA0/AN0 Porta de E/S bidirecional

Entrada do comparador analógico RA1/AN1 Porta de E/S bidirecional

Entrada do comparador analógico RA2/AN2/Vref Porta de E/S bidirecional

Entrada do comparador analógico Tensão de referência de saída

RA3/AN3/CMP1 Porta de E/S bidirecional Entrada do comparador analógico Saída do comparador

RA4/T0CKI/CMP2 Porta de E/S bidirecional Entrada de relógio do temporizador 0 Saída do comparador

RA5/MCLR/THV Porta de entrada Sinal de reset Entrada de tensão para programação

RA6/OSC2/CLKOUT Porta de E/S bidirecional Saída do oscilador de cristal

RA7/OSC1/CLKIN Porta de E/S bidirecional Entrada do oscilador de cristal

RB0/INT Porta de E/S bidirecional Interrupção externa

Tabela 2. Descrição da interface do PIC16F628 (continuação). Nome Definição RB1/RX/DT Porta de E/S bidirecional

Pino de recepção USART ou E/S de dados síncrona RB2/TX/CK Porta de E/S bidirecional

Pino de transmissão USART Relógio síncrono

RB3/CCP1 Porta de E/S bidirecional Entrada e Saída CCP

RB4/PGM* Porta de E/S bidirecional Pino de entrada de programação com voltagem baixa

RB5* Porta de E/S bidirecional RB6/T10SO/T1CKI* Porta de E/S bidirecional

Saída do oscilador do temporizador 1 Entrada de relógio do temporizador 1

RB7/T1OSI* Porta de E/S bidirecional Entrada do oscilador do temporizador 1

* Uma mudança de nível nesses pinos retira o PIC do modo de economia de energia (SLEEP)

3.2 Estrutura interna

Internamente, o PIC16F628 possui um barramento de dados e um barramento de programas,

conforme a filosofia da arquitetura Harvard (Figura 13). O barramento de dados interliga os

periféricos, as portas de entrada-e-saida, as memórias de dados, a ULA (Unidade Lógica

Aritmética) e alguns registradores de propósito específico, como o acumulador (W reg) e o

registrador de estado (Status reg). O barramento de programa interliga a memória de programa ao

registrador de instruções. Além disso, existe uma série de blocos de sistema, como, por exemplo, o

temporizador de power-up e o temporizador de watchdog.

27

Figura 13. Estrutura interna do Microcontrolador PIC16F628 Fonte: Microchip (2002)

3.3 Organização da memória

A memória do PIC16F628 é organizada num mapa de memória de programa e um mapa de

memória de dados. O mapa de memória de programas e estruturado como mostra a Figura 14. Ele

inclui: (i) o contador de programa (PC – Program Counter); (ii) uma pilha com oito níveis

conectada ao PC; (iii) um vetor de reset para o qual o contador de programas aponta sempre que o

microcontrolador for reinicializado; (iv) um vetor de interrupções para o qual o contador de

programa aponta sempre que ocorre uma interrupção; e (v) uma região onde é armazenado o

programa a ser executado.

28

Figura 14. Mapa da memória de programa

Fonte: Microchip (2002)

A memória de dados é organizada em quatro bancos que contêm os registradores de

propósito geral e os registradores de propósito específico. Os registradores de propósito específico

são localizados nos primeiros 32 endereços de cada banco (nas localizações do endereço 00h-1Fh,

80h-9Fh, 100h-11Fh e 180h-189h. As outras faixas de endereço são utilizadas pelos registradores

de uso geral implementados com memória RAM. As posições dos bancos de registradores possuem

podem ser acessadas diretamente ou indiretamente através do registrador chamado FSR (File Select

Register).

29

Figura 15. Mapa da memória de Dados do Microcontrolador PIC16F628 Fonte: Microchip (2002)

30

3.4 Conjunto de instruções

O microcontrolador PIC16F628 possui 35 instruções de 14 bits, as quais são baseadas em

quatro formatos diferentes: (i) operações com registradores orientadas a byte; (ii) operações com

registradores orientadas a bit; (iii) operações com literais e de controle; (iv) instruções de desvio.

Nas tabelas a seguir, são apresentadas breves descrições sobre as instruções em linguagem

de montagem do PIC16F628. Em cada tabela, a primeira coluna mostra os mnemônicos das

instruções, a segunda coluna lista os seus argumentos e a terceira apresenta uma descrição baseada

nos operadores aritméticos, lógicos, bit a bit e relacionais da linguagem C (KELLY-BOOTLE,

1989) Descrições mais detalhadas dessas instruções estão disponíveis na literatura (MICROCHIP,

2002; SOUZA, 2000). Na tabelas, os argumentos utilizados baseiam-se nos seguintes códigos:

• f: Registra o arquivo no endereço (0x00 até 0x7F)

• d: destino da operação; se d = 0 o resultado é colocado no registrador W

• k: representa oito ou nove bits constante, valores literais

• b: bit de endereçamento com arquivo de registrador de 8 bits

Tabela 3. Instruções para operações com registradores orientadas a byte.

Instrução Argumentos Descrição

ADDWF f, d d = W + f

ANDWF f, d d = W & f

CRLF F F = 00h

COMF f, d F = ~f

DECF f, d d = f – 1

DECFSZ f, d d = f – 1 e pula a próxima instrução se resultado = 0

INCF f, d d = f + 1

INCFSZ f, d d = f + 1 e pula a próxima instrução se resultado = 0

IORWF f, d d = W | f

MOVF f, d d = f

MOVWF F F = W

RLF f, d d = f << 1 com rotação através do bit C do Status

RRF f, d d = f >> 1 com rotação através do bit C do Status

31

Tabela 3. Instruções para operações com registradores orientadas a byte (continuação).


SUBWF f, d d = f – W

SWAPF f, d f[3-0] = f[7-4]; f[7-4] = f[3-0]

XORWF f, d d = W ^ f

Tabela 4. Instruções para operações com registradores orientadas a bit.


BCF f, b f[b] = 0

BSF f, b f[b] = 1

BTFSC f, b Se (f[b] == 0) pula a próxima instrução

BTFSS f, b Se (f[b] == 1) pula a próxima instrução

Tabela 5. Instruções para operações com literais.


ADDLW K W = W + k

ANDLW K W = W & k

IORLW K W = W | k

MOVLW K W = k

SUBLW K W = k – W

XORLW K W = W ^ k

Tabela 6. Instruções de controle e desvio.


CLRW - W = 00h

NOP - Gasta um ciclo de maquina sem fazer nada

CALL K Chamada para rotina localizada no endereço R

CLRWDT - WDT = 00h

GOTO K Desvio incondicional para o endereço R

RETFIE - Retorna da rotina de atendimento de interrupção

32

Tabela 6. Instruções de controle e desvio (continuação).


RETLW K Retorna de uma rotina com W = k

RETURN - Retorna de uma rotina sem afetar W.

SLEEP - Entra no modo SLEEP para economia de energia

4. ENTRADA-E-SAÍDA

A entrada-e-saída (E/S ou I/O – Input/Output) realiza a interface entre o microcontrolador e

o mundo externo (usuário ou outros componentes de um sistema embarcado), incluindo

componente de hardware como controladores e dispositivos de E/S (ex. teclado, leds, LCD,...).

Alguns dispositivos E/S podem incluir circuitos controladores integrados, os quais

gerenciam a operação do dispositivo e a comunicação com o microcontrolador, como, por exemplo,

em um display de cristal líquido. Outros dispositivos, porém, não incluem qualquer circuito de

controle, sendo que sua operação é controlada diretamente pelo microcontrolador (ex: teclado

matricial de telefone).

A transferência de informação entre o microcontrolador e um dispositivo de E/S pode ser

baseada em blocos ou em caracteres, sendo feita através de um ponto de conexão chamado de porta

(MACHADO & MAIA,1999; SILBERCHATZ & GALVIN, 2000).

Segundo MACHADO & MAIA (1999), em dispositivos de E/S com armazenamento, “em

função da forma com que os dados são armazenados, os dispositivos de E/S podem ser classificados

em duas categorias: dispositivos estruturados e dispositivos não-estruturados”. Os primeiros,

também denominados block devices, caracterizam-se por armazenarem informações em blocos de

tamanho fixo, cada um possuindo um endereço (ex. EEPROM). Já os dispositivos não-estruturados

(character devices) enviam ou recebem uma seqüência de caracteres sem ser estruturada no formato

de um bloco, sendo que essa seqüência não é endereçável, ou seja, não pode ser acessada após a

transmissão (MACHADO & MAIA, 1999).

33

No que tange à comunicação física entre o microcontrolador e os dispositivos, ela pode ser

implementada através de canais ponto-a-ponto dedicados à cada dispositivos ou através de canais

multiponto compartilhados, também denominados barramentos. A transferência de dados nesses

canais (ponto-a-ponto ou compartilhados) pode ocorrer de forma paralela (vários bits

simultaneamente) ou serial (bit a bit). Em sistemas embarcados microcontrolados, existem

restrições de custo e volume que exigem a aplicação de comunicação serial, pois permite o uso

microcontroladores com menor número de pinos de E/S. Com base nisso e para facilitar o

interfaceamento com os dispositivos de E/S, existem protocolos de comunicação serial

padronizados pelos quais pode-se construir um barramento compartilhado por múltiplos

dispositivos, como, por exemplo, o barramento I2C (PHILIPS SEMICONDUCTOS, 2000).

Quanto às metodologias utilizadas para a comunicação entre o microcontrolador e os

dispositivos, destacam-se a entrada-e-saída programada (ou polling) e a entrada-e-saída controlada

por interrupção. Segundo Murdocca e Heuring (2000), na primeira metodologia, a CPU consulta o

dispositivo para verifica se o mesmo precisa de atendimento (ou se completou a tarefa que lhe foi

solicitada). Já na segunda metodologia, o dispositivo deve sinalizar à CPU quando necessitar de

atendimento, o que é feito através de um sinal de físico específico denominado linha de interrupção.

Ao perceber a ativação dessa linha, a CPU completa a instrução que estiver executando e desvia o

seu fluxo de execução para uma rotina de que faça o atendimento dessa interrupção. A vantagem

desse método sobre o outro é que, no primeiro, a CPU fica em espera ocupada, consumindo tempo e

energia ao manter-se consultando o dispositivo, enquanto que, no segundo, ela pode dedicar-se à

execução de outra tarefa ou reduzir sua atividade até ser interrompida, economizando energia.

Na próxima seção é apresentada uma breve descrição sobre barramentos de E/S seriais para

sistemas embarcados (com destaque ao barramento I2C), após a qual são descritos alguns

dispositivos (com interface paralela e/ou serial) comumente encontrados em sistemas embarcados

microcontrolados.

4.1 Barramentos de Entrada–e–Saída Seriais

Entre os barramentos utilizados para interconexão de microcontroladores com dispositivos

de entrada-e-saída destacam-se alguns modelos padronizados de barramentos seriais, os quais são

listados a seguir:

34

• SPI (Serial Peripheral Interface – Interface Serial de Periféricos): desenvolvido pela

Motorola, é um protocolo de comunicação síncrona de alta velocidade utilizado em

memórias, conversores A/D, etc.

• 1-Wire: desenvolvido pela Dallas Semiconductors a fim de permitir a construção de

dispositivos com um uso mínimo de recursos tanto de hardware como de software.

Sua estrutura é baseada em uma estrutura mestre-escravo através de fatias de tempo

em um barramento do tipo half-duplex.

• LIN (Local Interconnect Network): rede implementada através de uma única linha

bidirecional com velocidade de 20 Kbits/s aplicada à área automotiva. O LIN foi

desenvolvido por algumas dos maiores fabricantes da indústria automobilística

mundial como: Audi, BMW, Volvo, etc.

• CAN (Controller Área Network): foi desenvolvido pela Bosch para possibilitar a

comunicação de alta velocidade e de forma confiável em aplicações automotivas.

• I2C (Inter–Integrated Circuit): foi desenvolvido pela Philips Semiconductors como

uma rede para interconexão de circuitos integrados e outros sistemas eletrônicos.

O barramento I2C será descrito posteriormente de uma forma mais detalhada, pois o mesmo

será utilizado no desenvolvimento deste projeto.

4.2 Barramento I2C

O barramento I2C foi originalmente projetado para a realização de operações de

transferência de dados entre componentes montados sobre uma mesma placa de circuito impresso.

O barramento I2C é constituído por dois fios que transportam informação entre os dispositivos a ele

conectados. Um fio é utilizado para transportar os dados e o outro é utilizado para transporta o sinal

de relógio. Uma vantagem desse barramento serial é que ele permite reduzir a área de placa e os

custos, propiciando o uso de circuitos integrados com menor número de pinos e empacotamentos

menores, o que também reduz a complexidade da interconexão. Atualmente é encontrada uma

variedade de dispositivos disponíveis e com interface compatível com o I2C, incluindo

microcontroladores, memórias, relógios de tempo real, controladores de LCD e conversores A/D.

35

4.2.1 Características Algumas características do barramento I2C incluem:

• É um barramento serial de dois fios (Serial Data – SDA e Clock – SCL), sendo que, para

uma operação confiável, é recomendada inclusão de uma terceira linha de terra comum.

• Existem três tipos de barramentos I2C com diferentes taxas de transferência: clássico

(100 Kbit/s), rápido (400 Kbit/s) e de velocidade alta (3,4 Mbit/s).

• Possui uma única condição de inicio (Start) e de parada (Stop),

• Inclui um protocolo para seleção de escravos com base em um endereço de sete bits,

sendo que a especificação do barramento permite uma extensão para até dez bits

• A transferência de dados é bidirecional e cada byte transferido deve ser reconhecido

(acknowledgment) pelo receptor

• As transferências não têm tamanho limitado

• Possui capacidade multi-mestre baseada na sincronização de relógios e em

procedimentos de arbitragem.

4.2.2 Definições básicas

Na terminologia do barramento I2C os dispositivos podem ser classificados como do tipo

mestre ou do tipo escravo. Um dispositivo mestre é aquele que inicia uma transferência, gerando o

sinal de relógio, definindo a condição de início, transmitindo o endereço do escravo, o tipo de

operação a ser realizada (leitura ou escrita), injetando os dados (no caso de uma escrita) e

estabelecendo a condição de parada. Já o dispositivo escravo somente responde quando for

endereçado e sua temporização é controlada pela linha de relógio.

Um exemplo de configuração de barramento I2C é mostrado na Figura 16, na qual se tem

dois microcontroladores e vários dispositivos conectados ao barramento de dois fios, como um

controlador de Display de cristal liquido (LCD driver), uma memória (RAM estática EEPROM),

um conversor A/D e um circuito dedicado (Gate Array). Ou seja é um sistema com múltiplos

dispositivos escravos e dois dispositivos mestres: microcontrolador A e microcontrolador B. No

barramento I2C ilustrado, os mestres podem ser apenas transmissores ou transmissores e receptores,

enquanto que os escravos podem ser somente receptores ou transmissores e receptores.

36

Figura 16. Exemplo de configuração de barramento I2C Fonte: Adaptado de Embedded System Academy (2000)

A especificação do barramento I2C (PHILIPS SEMICONDUCTORS, 2000) define uma

série de detalhes de hardware que tangem ao funcionamento elétrico, mas as descrições das mesmas

fogem do escopo deste texto.

4.2.3 Transferência de dados no Barramento I2C

Durante a transferência de um dado, a linha de dado (SDA) apenas pode mudar de estado

quando o relógio (SCL) está no nível baixo, pois, quando SCL está em 1, é considerado que o dado

em SDA é estável e válido (conforme é ilustrado na Figura 17).

Figura 17. Transferência de bit no barramento I2C Fonte: Adaptado de Philips Semiconductors (2000)

37

O enquadramento de uma transferência de dados é feito através de transições na linha de

dados SDA enquanto que a linha de relógio é alta. O início da transferência (Start) é sinalizado por

uma transição de descida na linha SDA enquanto que o fim da transferência (condição de parada ou

Stop) é indicado por uma transição de subida na linha de dados. O barramento é dito estar ocupado

entre um Start e um Stop, e ocioso entre um Stop e um Start. A Figura 18 ilustra as condições de

inicio e de parada de uma transferência. No momento em que SCL está em 1, ocorre uma transição

de 1 para 0 em SDA, caracterizando uma condição de inicio. Após a transferência dos dados,

quando SCL está em 1, ocorre uma transição de 0 para 1, caracterizando uma condição de parada.

Figura 18. Condição de Inicio e de Parada Fonte: Adaptado de Philips Semiconductors (2000)

4.2.4 O endereçamento no I2C

Cada dispositivo conectado ao barramento I2C tem um endereço único de 7 bits (ou de 10

bits no modelo estendido), sendo que os periféricos utilizados freqüentemente, têm endereços já

definidos.

Em uma transferência, após a condição de início, o primeiro byte transferido no barramento

I2C define o endereço do destinatário (sete bits mais significativos) e o se a operação será de escrita

ou de leitura (bit menos significativo igual a 0 ou a 1, respectivamente). Um nono bit adicional,

após a transferência do byte, é utilizado para o reconhecimento de que a transferência ocorreu com

sucesso, sendo denominado ACK.

38

4.2.5 Dispositivos I2C

O I2C foi desenvolvido pela Philips Semiconductors, a qual oferece dezenas de produtos

com esta interface. Ele tem sido adotado por mais de 50 licenciados, sendo que existem mais de

1000 dispositivos diferentes compatíveis com o I2C. Por exemplo, na Tabela 7 é mostrado um

resumo do catálogo de produtos I2C da Philips Semiconductors (2003). Observa-se, que são

oferecidos 24 modelos diferentes de dispositivos para acionamento de mostradores (I2C Display

Drivers), sendo 4 desses são para mostradores de cristal líquido baseados em caracteres.

Tabela 7. Resumo do catálogo de produtos I2C da Philips Semiconductors.

Categoria Qtd. de modelos

I²C Analog to Digital Converters 1

I²C Bus Controllers 2

I²C Bus Repeaters/Hubs/Extenders 5

I²C Clock/Calendar 5

I²C Dip Switch 5

I²C Display Drivers 24

LCD Character Driver 4

LCD Graphic Black/White Driver 6

LCD Graphic Color STM 3

LCD Graphic Gray Scale Driver 2

LCD Segment Driver 9

I²C DTMF/Modem/Musical Tone Generators 2

I²C General Purpose I/O 12

I²C LED Display Control 6

I²C Multiplexers/Switches 7

I²C Serial EEPROM/RAM 9

I²C Temperature/Voltage Monitors 5

I²C Voltage Level Translators 3

Fonte: Adaptado de Philips Semiconductors (2003)

39

Nas seções a seguir, serão descritos alguns dispositivos de entrada-e-saída, incluindo

definições, funcionamento e uma descrição de como operam suas interfaces (com ênfase às

interfaces paralelas). Assume-se que, uma vez descrito o barramento I2C, os dispositivos

compatíveis com esse barramento I2C utilizam o protocolo apresentado nesta seção, sendo

desnecessário descrever o mesmo a cada dispositivo.

4.3 Display de Cristal Líquido – LCDs Os displays de cristal líquido ou LCDs (Liquid Crystal Dysplays), são amplamente

utilizados em sistemas embarcados microcontrolados como dispositivos de saída para interface com

o usuário. Os LCDs podem ser divididos em duas classes: gráficos e orientados a caracter. Os

módulos LCD gráficos geralmente estão disponíveis com 20 (vinte) pinos para conexão e são

encontrados com resoluções de 122×32, 128×64, 240×64 e 240×128 dots pixel.

Para permitir a integração dos LCDs em sistemas microcontrolados, esses dispositivos já

possuem associado um controlador específico com uma interface definida pela qual o

microcontrolador envia palavras de controle e dado com base no protocolo de comunicação do

controlador do LCD, conforme é ilustrado na Figura 16. Esse protocolo pode ser baseado em uma

especificação proprietária (geralmente com comunicação em paralelo) ou em uma especificação

padrão, como, por exemplo, o protocolo de comunicação serial I2C.

Figura 20. Diagrama de comunicação com LCD Fonte: Perez (1999)

As interfaces de LCDs, como o ilustrado na Figura 16, incluem um barramento de dados

(paralelo) e um barramento de controle. O primeiro pode ser configurado para operar com largura

40

de oito ou quatro bits, enquanto que o segundo inclui linhas de controle como, por exemplo, as

linhas RS (Seleção de Registrador), W/R (Gravação/Leitura) e (Habilitação). Na Tabela 8, é

descrita a pinagem que compõe a interface de um modelo de LCD com canais de dado e controle

separados, sendo que o canal de dados possui largura de 8 bits. Na primeira coluna da tabela, é

indicado o número de cada pino, enquanto que os nomes dos pinos e suas funções são listados na

segunda e na terceira coluna, respectivamente.

Tabela 8. Pinagem do Módulo LCD

Pino Nome Função

1 GND ou Terra Alimentação

2 VCC ou + 5V Alimentação

3 V0 Tenção para ajuste de contraste

4 RS Seleção de registro: 1 = Dado; 0 = Instrução

5 R/W Seleção de operação: 1 = Leitura; 0 = Escrita

6 E Habilitação do chip: 1 = Habilita; 0 = Desabilita

7 B0

8 B1

9 B2

10 B3

11 B4

12 B5

13 B6

14 B7

Dado (8 bits)

15 A Anodo p/ LED backlight (quando existir)

16 K Catodo p/ LED backlight (quando existir)

Segundo PEREZ (1999), todo LCD possui dois registradores importantes. O primeiro é o

registrador de instrução IR (Instruction Register), o qual possui a função de armazenar as operações

que o controlador do LCD deve executar, como, por exemplo, apagar o mostrador, deslocar a

mensagem tanto para a direita quanto para a esquerda, ligar/desligar o cursor, entre outras. O

segundo é o registrador de dados DR (Data Register), o qual é responsável por armazenar

temporariamente os dados das mensagens a serem visualizadas no LCD. Para a seleção desses

41

registros é utilizado o sinal de controle do pino RS (Register Select). Um nível alto seleciona o DR,

enquanto que um nível baixo seleciona o IR. Esses registradores podem ser lidos ou gravados

através da linha de controle do pino R/W (Read/Write), sendo que um nível alto lerá o conteúdo do

registrador selecionado, enquanto que um nível baixo gravará um dado no registrador.

Conforme PEREZ (1999), “para gravar uma instrução ou dado no LCD carrega-se o

respectivo byte no barramento de dados, e o pino R/W se mantém em nível baixo para gravação.

Depois, com o pino RS seleciona-se o registro a gravar e, por último, faz-se a habilitação com um

pulso de nível baixo no pino de controle E (Enable) do LCD. Para a operação de leitura são

seguidos os mesmos passos anteriores, mas R/W é mantido em nível alto.”

Nos LCDs, as mensagens a serem visualizadas são armazenadas numa RAM interna. Um

controlador decodifica cada byte usando um gerador de caracteres ASCII 7x5 baseado em uma

ROM de integrada no controlador. A RAM interna possui capacidade para armazenar 80 bytes, do

quais apenas 32 são visualizados simultaneamente, ou seja, 16 por linha em um LCD com duas

linhas. As demais posições da RAM são utilizadas para deslocar a mensagem.

4.4 Motor de Passo

Segundo Costa Leite et al. (2003), um motor de passo é um transdutor responsável por

converter energia elétrica em movimento controlado através de pulsos, possibilitando o

deslocamento através de passos, sendo que um passo é o menor deslocamento angular possível.

Os motores de passo são ideais para a construção de mecanismos onde são requeridos

movimentos muito precisos. A característica principal está em seu eixo, pois pode-se mover um

passo de cada vez para cada pulso que se é aplicado. Esse passo pode variar de 90º a pequenos

movimentos de 1.8º ou menores. Para se obter um giro de 360º, são necessários 4 passos no

primeiro caso e 200 no segundo (COSTA LEITE et al., 2003).

Os motores de passo possuem 3 estágios de operação: parados, ativados, ou com o rotor (um

conjunto eixo-imã que rodam solidariamente na parte móvel do motor) travado (bobinas

energizadas) ou girando em etapas. Seu movimento pode ser variado, sendo forte ou fraco,

dependendo da freqüência e da amplitude dos passos em relação à inércia em que ele se encontre.

42

Sua utilização é muito variada e são encontrados em periféricos de computadores que os

usam em inúmeras aplicações, como mesas gráficas, unidades de disco, plotters e etc. Também são

encontrados na robótica, em sistemas de movimentação de braços mecânicos, entre outros.

Neste estudo serão considerados dois tipos de motores de passo: unipolar e bipolar. Os mais

usados são os unipolares, com geralmente 4 bobinas. Os motores de passo unipolares possuem um

center-tape entre o enrolamento de suas bobinas, o qual é utilizado para alimentar o motor, que é

controlado aterrando-se as extremidades dos enrolamentos. Já os motores de passo bipolares

possuem enrolamentos separados, o que lhes proporciona um maior torque. Contudo, eles requerem

uma polarização reversa durante a operação para que o deslocamento possa acontecer (COSTA

LEITE et al., 2003).

Para que se tenha o funcionamento de um motor de passo é necessário que se energize uma

bobina de cada vez, o que proporciona um pequeno deslocamento no rotor (o passo). Segundo

Costa Leite et al. (2003), “este deslocamento ocorre simplesmente pelo fato de o rotor ser

magneticamente ativo e a energização das bobinas criar um campo magnético intenso que atua no

sentido de se alinhar com as pás do rotor”. Dessa forma, se as bobinas forem polarizadas

corretamente, é possível movimentar o rotor somente entre as bobinas (passo inteiro), ou entre as

bobinas e alinhadas com as mesmas.

Os motores de passo mais comuns são os de quatro bobinas que podem ser controladas por

diferentes tipos de seqüência. Na seqüência de uma fase, cada bobina é energizada individualmente

de acordo com o sentido do movimento desejado (Tabela 9).

43

Tabela 9. Seqüência de uma fase.

Passo

1 2 3 4 Bobina 4 1 0 0 0 Bobina 3 0 1 0 0 Bobina 2 0 0 1 0 Bobina 1 0 0 0 1

Fonte: Adaptado de Braga (1999)

Na seqüência de duas fases, as bobinas são energizadas duas a duas, de modo que o rotor

possa parar em posições intermediárias (Tabela 10).

Tabela 10. Seqüência de duas fases.

Passo

1 2 3 4 Bobina 4 1 0 0 1

Bobina 3 1 1 0 0

Bobina 2 0 1 1 0

Bobina 1 0 0 1 1


44

Na seqüência uma-duas fases, é possível energizar uma ou duas bobinas alternadamente,

obtendo uma melhor resolução com um menor passo (Tabela 11).

Tabela 11. Seqüência de uma-duas fases.

Passo

1 2 3 4 Bobina 4 1 1 0 0

Bobina 3 0 1 1 1

Bobina 2 0 0 0 1

Bobina 1 0 0 0 0


Tabela 11. Seqüência de uma-duas fases (continuação).

Passo

5 6 7 8 Bobina 4 0 0 0 1

Bobina 3 0 0 0 0

Bobina 2 1 1 0 0

Bobina 1 0 1 1 1


Além dessas três seqüências, existe a do tipo micro-passo, a qual baseia-se em níveis de

tensão diferenciados nas bobinas, o que permite reduzir ainda mais o passo do motor (BRAGA,

1999).

45

4.5 Teclado Matricial

Um teclado matricial é um conjunto de interruptores (teclas ou chaves) organizados na

forma de uma matriz de interconexão. Esse tipo de teclado é utilizado em aparelhos telefônicos, nos

quais são tipicamente encontradas matrizes de teclas 4×3 ou 5×3. Na Figura 21, é ilustrada uma

aplicação de um teclado de telefone 4×3 como interface de entrada. No exemplo, um circuito é

montado de modo que o teclado possua três sinais de entrada denominados Y(2..0) e quatros sinais

de saída denominados X(3..0). Os sinais Y(2..0), são conectados em colunas às chaves do teclado,

enquanto que os sinais X(3..0) são conectados em linhas, sendo que essas saídas são ligadas ao

nível 1 lógico através de resistores de pull-up. Dessa forma, quando nenhuma tecla é pressionada

X(3..0) = “1111”.

1 2 3

4 5 6

7 8 9

* 0 #

Y2

Y0Y1

X0

X1

X2

X3

+ 5 V

Figura 21. Teclado matricial

No circuito da Figura 21, para determinar se uma tecla está pressionada, deve-se efetuar uma

varredura cíclica coluna por coluna, aplicando-se um padrão binário particular para varrer cada uma

das colunas da matriz de teclas. Por exemplo, inicialmente, faz-se Y(2..0) = “011” (onde Y2 = 0,

Y1 = 1 e Y0 = 1) e lê-se as saídas X(3..0). Caso uma das teclas da coluna Y2 esteja pressionada (ou

46

seja, teclas 3, 6, 9 ou #), X(3..0) terá ao menos um bit em zero, sinalizado que a tecla da coluna

correspondente ao bit em 0 está pressionada. Se a tecla 3 estiver sendo pressionada, a saída será

igual a “1110”, ou seja, X3 = 1, X2 = 1, X1 = 1 e X0 = 0.

Existe, portanto um par de padrões de códigos de entrada e de saída associados a cada tecla

pressionada individualmente, conforme é ilustrado na Tabela 12. Observa-se, por exemplo, que a

combinação de códigos para identificação de que a tecla 3 foi pressionada é Y(2..0) = “011” e

X(3..0) = “1110”.

Tabela 12. Códigos para varredura do teclado.

X(3..0) Y(2..0)

0111 1011 1101 1110

011 3 6 9 #

101 2 5 8 0

110 1 4 7 *

4.6 Conversor Analógico-Digital (ADC)

Segundo Bonfim (2002), o conversores analógico-digital e digital-analógico (A/D e D/A)

são a base de todo o interfaceamento eletrônico entre o mundo analógico e o mundo digital. Eles

estão presentes na grande maioria dos instrumentos de medida atuais e são os responsáveis pelo

aumento significativo nos níveis de precisão e exatidão assim como o barateamento e popularização

de instrumentos de medida digitais. São também a base de interface entre o computador e o mundo,

permitindo ao computador monitorar e controlar uma variável física.

Neste trabalho, tem-se interesse especial pelos conversores A/D, os quais são aplicados em

sistemas embarcados para o monitoramento de sensores analógicos. Um conversor A/D típico é o

ADC0808, o qual possui 8 canais de entrada analógica. Sua interface é ilustrada na Figura 22 e

descrita na Tabela 13.

47

Figura 22. Pinagem do ADC0808 Fonte: National Semiconductor (2002)

Tabela 13. Descrição dos sinais da interface do ADC0808.

Nome Direção Função

IN (7..0) Entrada Canais de entrada analógicas

ADD (A, B, C) Entrada Endereço de canal de entrada analógica

ALE Entrada Comando para leitura do endereço do canal a

ser monitorado

START Entrada Comando de início de conversão A/D

EOC Saída Indicação de final de conversão AD

OUTPUT ENABLE Entrada Habilitação da saída de dados do ADC

2-1, 2-2, 2-3, 2-4, 2-5, 2-6, 2-7, 2-8 Saída Saídas de dado

VCC e GND Entrada Tensões de alimentação

VREF(+) e VREF(−) Entrada Tensões de referência

CLOCK Entrada Relógio

Fonte: Adaptado de National Semiconductor (2002)

48

A operação dos conversores ADC0808 segue, basicamente, os seguintes passos, ilustrados

na Figura 23:

1. O canal a ser monitorado é selecionado através das linhas de endereço;

2. O endereço é registrado em um latch através de um comando ALE = 1;

3. A conversão é iniciada com um pulso positivo na entrada START, fazendo a linha EOC

ir para 0;

4. A conversão é concluída quando EOC retorna para 1 (esse sinal pode ser utilizado como

entrada de interrupção);

5. Para leitura do valor digital, deve ser aplicado um nível lógico 1 na entrada OUTPUT

ENABLE, o que habilita as saídas de dado, a quais estão normalmente em alta-

impedância (tri-state).

Figura 23. Interface do ADC0808 Temporização Fonte: National Semiconductor (2002)

49

Internamente, quando a linha START é ativada, um registrador de aproximações sucessivas

(S.A.R.) é acionado e sua atualização é realizada bit-a-bit em cada ciclo de relógio até que a tensão

de saída da rede de resistores seja equivalente à tensão de entrada do canal endereçado, finalizando

a conversão A/D. O dado de saída é então obtido diretamente do estado corrente do registrador

S.A.R.. Na Figura 24, é apresentado o diagrama de blocos do conversor ADC0808, na qual são

observados os componentes que fazem parte do conversor.

Figura 24. Diagrama de blocos do ADC0808 Fonte: National Semiconductor (2002)

4.7 Memória EEPROM

Uma EEPROM é uma memória não volátil, que mantém indefinidamente os dados

armazenados. As principais características da EEPROM são as de poder ser apagada eletricamente

e de permitir apagar e reescrever bytes individuais na matriz de memória (diferentemente das

EPROM, nas quais todas as posições são apagadas ao mesmo tempo). Durante a operação de

escrita, as células endereçadas são apagadas através dos circuitos internos, o que ocorre antes da

escrita dos dados. Essa capacidade de apagar os bytes individualmente torna a tarefa de modificar e

armazenar os dados na EEPROM bem mais simples. Outra característica é a capacidade de uma

EEPROM ser programada mais rapidamente de que muitas EPROMs.

50

As EEPROMs podem ser aplicadas nas mais diversas áreas, como na de eletrônica de

consumo (em TVs, CD-players e câmeras de vídeo), na automotiva (em airbags e em freios ABS) e

na de automação de escritório (em impressoras, faxes, modems...).

Abaixo, é apresentado um exemplo de EEPROM organizada sob a forma de um arranjo

8K×8 (8192 palavras de 8 bits) possuindo 13 entradas de endereço (213 = 8.192) com oito pinos de

estrada-e-saida de dados. Ela possui três entradas de controle ativas em 0: Chip Enable, Write

Enable e Output Enable (/CE, /WE e /OE, respectivamente), as quais determinam o modo de

operação de acordo com a Tabela 14. Quando /CE = 1, o chip está no modo de economia de energia

(standby), nenhuma operação é realizada em qualquer posição de memória e os pinos de dados

estão em alta impedância. Portanto, os demais sinais são irrelevantes (/OE = /WE = X). Quando /CE

= 0, se /OE = 0 e /WE = 1, o conteúdo da célula endereçada é apresentado nos pinos de dados. Por

outro lado, se /CE = 0, /OE = 1 e /WE = 0, então o dado nos pinos de entrada é escrito na célula

endereçada.

Tabela 14. Tabela-verdade da EEPROM

Entradas Modo

/CE /OE /WE Pinos de dados

LEITURA 0 0 1 Saída

ESCRITA 0 1 0 Entrada

STANDBY 1 X X Alta impedância

Segundo Tocci e Widmer (2000),

Para que uma posição de memória seja lida, o endereço da posição desejada deve ser aplicando aos pinos de endereço. /CE é colocado em BAIXO e o pino de habilitação da saída, /OE, é colocado em nível BAIXO, habilitando os buffers da saída de dados. O pino que habilita a escrita, /WE, é mantido em ALTO durante a operação de leitura. Para que a posição de memória seja escrita (programa), os buffers da saída devem ser desabilitados para que o dado que será escrito possa ser aplicado como entrada nos pinos de entrada/saída.

51

A operação de escrita pode ser visualizada na Figura 25. No exemplo, o dispositivo está em

modo standby e, no instante t1, é fornecido um novo endereço. No instante t2, as entradas /CE e /WE

são colocadas em 0 para iniciar uma operação de escrita. A entrada /OE está em 1, e, portanto os

pinos de dados permanecerão em alta impedância. O dado é aplicado aos pinos de entrada-e-saída,

em t3, e é escrito na posição selecionada pelo endereço na subida de /WE, em t4. O dado é retirado

dos pinos de entrada em t5.

ENDEREÇO ESTÁVEL

DadosVálidos

��

��

Standby Modo de Escrita Standby

Tipicamente 200 ns

Operações dearmazenamento e

apagamento;tipicamente 5 ms.

t1 t2 t3 t4 t5

Endereço

/CE

/WE

/OE

DadosE/S

Figura 25. Temporização de uma operação de escrita na EEPROM. Fonte: Adaptado de Tocci e Widmer (2000)

O dado escrito na EEPROM é armazenado em um registrador e nele é mantido até que um

outro circuito realize a operação de apagamento da posição de memória selecionada. Após, o byte

de dados é transferido do registrador e armazenado na posição de memória. O processo de

armazenar e apagar a memória dura cerca de 5 ms. Quando /CE retorna ao nível 1, em t4, o chip

retorna ao modo standby, enquanto as operações de armazenamento e apagamento são completadas.

52

5. DRIVERS DE DISPOSITIVO

Nos sistemas computacionais de uso geral, a introdução e a evolução dos sistemas

operacionais foi fundamental para facilitar o desenvolvimento de software e massificar o uso dos

computadores. Uma das tarefas fundamentais desses sistemas operacionais consiste em facilitar o

acesso aos dispositivos de entrada-e-saída, tornando transparente ao programador de aplicação uma

série de detalhes a respeito dos dispositivos utilizados. Essa abstração é dada por uma parte do

sistema operacional denominada gerência de dispositivos, a qual, segundo Machado e Maia (1997)

“é uma das principais e mais complexas funções exercidas por um sistema operacional”. A gerência

de dispositivos é tipicamente implementada em camadas de software e hardware, nas quais as

camadas inferiores escondem características dos dispositivos das camadas superiores. Conforme

Machado e Maia (1997), “desta forma é possível oferecer uma interface simples e confiável ao

usuário e suas aplicações”.

Uma das camadas da estrutura da gerência de dispositivos é constituída pelos drivers de

dispositivos, ou device drivers (DDs), os quais “têm como função principal a comunicação com os

dispositivos de E/S em nível de hardware, geralmente através de controladores, especificando

características físicas em cada dispositivo”. Acima dos DDs fica o subsistema de E/S, o qual trata

de funções relacionadas a todos os dispositivos, enquanto os DDs tratam apenas dos seus aspectos

particulares (Figura 26). Ao realizar uma operação de E/S, o sistema deve tornar uma tarefa o mais

simples possível, tanto para a aplicação quanto para o usuário. O conceito de independência de

dispositivo vem da capacidade de qualquer dispositivo conectar-se com o hardware e efetuar a

comunicação com o sistema.

Segundo Machado e Maia (1999) “O subsistema de entrada/saída é responsável por realizar

as funções que são comuns a todos os dispositivos, ficando os aspectos específicos de cada

periférico a cargo dos device drivers”.

Uma das funções de um subsistema de E/S é a de mapear o nome do dispositivo com o seu

respectivo driver. Para ter acesso aos periféricos, as camadas superiores devem conhecer o nome do

dispositivo. Cada dispositivo trabalha com informação de tamanhos diferentes, como registros,

caracteres, bytes ou blocos. “O subsistema de E/S é responsável por criar uma unidade lógica de

informação independente do dispositivo e repassá-la para os níveis superiores”. O subsistema de

53

E/S também pode tratar certos erros, reportados de forma uniforme independente do dispositivo.

Mas normalmente esses erros são tratados nas operações de E/S que são realizados pelas camadas

mais próximos ao do hardware.

Os controladores ou interfaces são componentes eletrônicos (hardware) responsáveis por

manipular diretamente os dispositivos de E/S. O controlador possui memória e registradores

próprios para a execução de instruções enviadas pelo device driver. Os device drivers comunicam-

se com os dispositivos através dos controladores. Em geral, o controlador possui registradores e

memória próprios, para executar instruções enviadas pelos device drivers. Essas instruções de baixo

nível estabelecem a interface entre o dispositivo e o controlador. O controlador armazena em seu

buffer uma seqüência de bits vindo do dispositivo e verifica a ocorrência de erros, não possuindo

erros é transferido para a memória principal.

Aplicação do usuário

Subsistema de E/S

Independente do Dispositivo

Drivers de dispositivos Software

Manipuladores de Interrupção

Controladores

Dependente do Dispositivo

Hardware Dispositivos

Figura 26. Gerência de dispositivos Fonte: Adaptado de Machado e Maia (1997) e Tanenbaum e Wodhull (2000)

Cada driver é responsável por um tipo de dispositivo ou por um grupo de dispositivos

semelhantes. Ele recebe comandos gerais e transforma-os em comandos específicos que poderão ser

executados pelos controladores. Segundo Machado e Maia (1997), “o driver está interligado

diretamente nas funções do controlador. Ele é o componente do sistema que reconhece o hardware,

ou seja, sabe quantos registradores um controlador possui, para que eles servem, como são

utilizados e quais são seus comandos”, bem como seus endereços também.

Em termos gerais, o trabalho de um device driver é aceitar pedidos do subsistema de E/S

(independente de dispositivo) e verificar quais requisitos são necessários para ser executado. Um

tipo de requerimento é o de leitura de um bloco. Se o driver está ocioso, ele começa realizar o

54

pedido imediatamente. Se, entretanto, já estiver ocupado, incorporará o pedido em uma fila de

pedidos pendentes para ser tratado o mais cedo possível.

Um exemplo clássico na literatura é o driver para disco, onde “o driver recebe o comando de

leitura de um determinado bloco e informa o controlador em qual disco, cilindro, trilha e setor o

bloco se localiza iniciando-se desta forma a leitura. Enquanto se realiza a leitura, o processo que

solicitou a operação é colocado no estado de espera até que o controlador avise de seu término.

Completada a operação, o controlador gera uma interrupção que, por sua vez, ativa novamente o

device driver. Após verificar a existência de erro, o device driver passa as informações para a

camada superior” (MACHADO e MAIA, 1997).

Cada driver é responsável por um tipo de dispositivo, ou na maioria, uma classe de

dispositivos fortemente relacionados. Por exemplo, considerando dois modelos de um mesmo

dispositivo com protocolos de comunicação diferentes (serial e paralelo). Um mesmo driver pode

receber um comando geral para essa classe de dispositivos e, a partir de um identificador, acionar o

protocolo de comunicação adequado a cada dispositivo, como o device driver 1 da Figura 27.

D e v iceD rive r

1

D e v iceD rive r

2

D isp o s itivo1

D isp o s itivo2

D isp o s itivo3

Figura 27. Device Driver Fonte: Adaptado de Machado e Maia (1997)

Em sistemas computacionais embarcados microcontrolados, o uso de device drivers permite

reduzir o tempo de projeto, pois caberá ao desenvolvedor apenas integrar os drivers ao seu sistema

sem se preocupar com a verificação dos mesmos (assumindo que eles já tenham sido validados).

Contudo, é importante que um device driver ocupe o mínimo de memória de programa e de

memória de dados para não aumentar o custo do produto. Por isso, é recomendável que os devices

drivers sejam desenvolvidos em assembly ou em uma linguagem de alto nível com um compilador

que permita realizar otimizações em nível de código. Embora a linguagem assembly seja a

alternativa preferencial, a programação em linguagem C com o uso de um bom compilador pode

55

proporcionar uma série de vantagens, das quais destacam-se as facilidades de programação e de

manutenção, assim como a portabilidade do código desenvolvido para uma família de

microcontroladores (ex. PIC16) para uma outra família com arquitetura diferente (ex. PIC18).

Atualmente, devido a evolução das técnicas de compilação e de otimização, programas em

alto nível geram código executável mais otimizado do que se fosse programado em assembly.

56

III. DESENVOLVIMENTO Na parte anterior foi apresentada uma revisão bibliográfica a respeito de sistemas

computacionais embarcados microcontroladores (com ênfase ao PIC16F628), dispositivos de

entrada-e-saída e drivers de dispositivos. Esse estudo foi feito visando obter e consolidar

conhecimentos a respeito de conceitos necessários ao desenvolvimento de drivers de dispositivos

para sistemas computacionais embarcados baseados no PIC16F628 e nos dispositivos estudados.

Embora o estudo não tenha sido exaustivo, ele permitiu estabelecer as bases que se entende

necessárias para este projeto, através das quais foi realizada a modelagem e a implementação dos

drivers de dispositivos, conforme é descrito nas seções a seguir.

1 VISÃO GERAL

Em uma visão simplificada, o trabalho desenvolvido insere-se no contexto ilustrado na

Figura 28, no qual foi modelada uma plataforma de hardware (PIC16F628 + dispositivos de entrada

e saída) e desenvolvido um conjunto de drivers de dispositivos validados por meio de aplicações de

teste.

Aplicações de Teste

Drivers de Dispositivos

PIC

Dispositivos

Software

Hardware

Figura 28. Visão geral do trabalho

Em outras palavras, o foco do trabalho consistiu no desenvolvimento de drivers para um

conjunto de dispositivos de entrada-e-saída conectados a um microcontrolador. O desenvolvimento

dos drivers teve de obedecer as restrições impostas pelo modelo de microcontrolador escolhido

(PIC16F628), o qual possui capacidade limitada de E/S. Isso permitiu modelar uma arquitetura em

pequena escala que representa alguns dos problemas enfrentados por projetistas quando a

capacidade de E/S do modelo de microcontrolador disponível é menor que a exigida pela

aplicação-alvo.

Na seção a seguir, apresenta-se a modelagem da arquitetura de hardware e dos drivers

desenvolvidos neste trabalho.

2 MODELAGEM

No desenvolvimento deste trabalho, foi utilizado o modelo baseado no refinamento

sucessivo em uma metodologia constituída de etapas de análise de requisitos, especificação, projeto

arquitetural, projeto de componentes, integração e teste (para validação). Devido ao refinamento

sucessivo, essas etapas foram percorridas repetidamente durante o desenvolvimento. Nas subseções

a seguir, são apresentadas descrições das etapas relativas à modelagem, ou seja, a análise de

requisitos, a especificação e o projeto arquitetural.

2.1 Análise de Requisitos Os requisitos pré-estabelecidos para os drivers de dispositivos são listados abaixo:

• Nome do projeto: DD2PIC (Device Drivers to PIC).

• Finalidade: A finalidade deste projeto é a de prover drivers de dispositivos para

interfaceamento entre dispositivos de entrada-e-saida com o microcontrolador

PIC16F628.

• Entradas:

o Físicas: sinais obtidos pelos dispositivos de entrada que são tratadas pelo drivers;

o Lógicas: comandos e dados fornecidos pela aplicação;

• Saídas:

o Físicas: Tratamento dos sinais obtidos pela entrada efetuando a comunicação

com o dispositivo;

o Lógicas: Tratamento dos comandos e dados fornecidos pela aplicação;

• Desempenho: o driver deve garantir que a comunicação seja rápida o suficiente para o

bom funcionamento da interface do dispositivo com o microcontrolador.

• Custo de Fabricação: do driver deve ter o mínimo de linhas de código de modo a não

ultrapassar a capacidade de armazenamento do microcontrolador.

58

2.2 Especificação

O propósito específico deste projeto está na comunicação dos dispositivos de entrada-e-

saida, como o microcontrolador PIC16F628, através de device drivers. Os drivers devem permitir a

comunicação do microcontrolador com a EEPROM, podendo gravar e ler dados. Permitir a

utilização do protocolo de comunicação com os dispositivos de E/S utilizando I2C. Garantir que o

microcontrolador acione um motor de passo, bem como obter dados de um conversor ADC0808. Os

drivers também devem estabelecer o interfaceamento do microcontrolador com um LCD e com um

displays de 7 segmentos.

2.3 Projeto Arquitetural 2.3.1 Arquitetura de Hardware

A arquitetura é o guia para a estrutura do sistema que é utilizado no projeto de componentes.

Na Figura 29 é mostrado o diagrama de blocos da Arquitetura de Hardware, o qual inclui o

microcontrolador PIC16F628, o barramento I2C ao qual é conectada uma memória EEPROM e um

barramento paralelo ao qual são conectados um LCD, um ADC, um teclado matricial, um motor de

passo e um display de 7 segmentos.

Figura 29. Diagrama de blocos da Arquitetura de Hardware

59

Os dispositivos conectados ao barramento paralelo requerem a inclusão de circuitos digitais

adicionais, os quais cumprem o papel de “colar” os dispositivos ao barramento, sendo por isso

denominados de “lógica de cola”. Na Figura 29, essa lógica de cola é omitida para garantir uma

maior legibilidade ao diagrama, e será ilustrada mais adiante.

O barramento paralelo é constituído por onze sinais: quatro para dados, quatro para endereço

do dispositivo, um para habilitação da transferência do dado com o dispositivo endereçado, um para

definição do tipo de operação de transferência (leitura e escrita) e outro utilizado para

implementação de um mecanismo de espera ocupada (ou pooling) ou de interrupção. Esses sinais

são descritos na Tabela 15, a qual inclui o nome do sinal, sua direção (em relação ao

microcontrolador), os pinos utilizados da interface do PIC e sua função. Já o barramento I2C possui

apenas dois sinais (SDA e SCL), conforme é descrito na Tabela 16.

Tabela 15. Sinais do barramento paralelo

Sinal Direção Interface do PIC Função data[3..0] Bidirecional RB[7..4] Barramento de dados addr[3..0] Saída RA[3..0] Barramento de endereço de dispositivo Ena Saída RA4 Habilitação da transferência Rw Saída RB3 Tipo de operação (1=Leitura, 0= Escrita) Read Entrada RB0 Sinaliza que o dispositivo completou a

operação solicitada (pode ser utilizado como flag ou sinal de interrupção)

Tabela 16. Sinais do barramento I2C

Sinal Direção Interface do PIC Descrição Sda Bidirecional RB2 Informação serial (endereço, dado) Scl Saída RB1 Relógio Os dispositivos conectados ao barramento paralelo são mapeados a um espaço de endereços

de 4 bits, resultando em um total de 16 posições (de 0 a 15) . Um dispositivo pode ocupar uma ou

mais posições para permitir a realização de diferentes operações. Por exemplo, como o barramento

de dados possui apenas 4 bits, um display de 7 segmentos requer dois latches que armazenam o

dígito a ser mostrado. Cada dígito é composto por uma informação de 7 bits. Quatro desses bits são

armazenados em um latch e os outros três em um segundo latch. Cada latch é mapeado em um

endereço que é denominado port, sendo que o primeiro é denominado port_0 e o segundo port_1.

Dessa forma, para comandar o display a mostrar um determinado dígito, deve-se enviar uma parte

60

do mesmo ao port_0 e a outra parte ao port_1, através de operações de escrita. Outros dispositivos,

porém, permitem que o mesmo port seja utilizado para realizar diferentes operações: leitura, escrita

ou inicialização de uma tarefa (ex. conversão analógico-digital no ADC). A Tabela 17 apresenta os

ports associados a cada dispositivo e a função realizada conforme a operação definida pelo sinal rw.

Tabela 17. Dispositivos conectados ao barramento paralelo.

Dispositivo port rw Função 0 0 Aciona os segmentos a, b, c, d (associados aos sinais data

0, 1, 2 e 3, respectivamente) Display de 7 segmentos

1 0 Aciona os segmentos e, f, g (associados aos sinais data 0,

1 e 2, respectivamente)

Motor de Passo 0 0 Gira o motor de passo conforme o código definido em

data[3..0]

0 0

Escreve código de seleção de coluna Teclado

0 1

Lê estado das linhas para a coluna selecionada

0 0 Seleção de canal analógico e inicialização da conversão

0 1 Leitura do nibble mais significativo do resultado da

conversão A/D (sinais OUT[5..8] do ADC)

1 0 Inicialização da conversão A/D

ADC

1 1 Leitura do nibble menos significativo do resultado da conversão A/D (sinais OUT[1..4] do ADC)

0 0 Escreve comando ou dado a ser enviado no LCD (nibble a nibble)

LCD

1 0

Escreve nos sinais de controle ena, rw e rs do LCD (associados aos sinais data 0, 1 e 2, respectivamente)

É importante destacar que alguns ports são utilizados para registrar códigos de controle que

definem um padrão de sinais de controle aplicados ao dispositivo. Por exemplo, o LCD possui três

sinais de controle denominados ena, rw e rs. Para enviar um nibble de uma palavra de dado ao

LCD, deve escrever esse nibble no port_0 do LCD e, após, enviar a seguinte seqüência de código ao

port_1: 0x5 (rs = 1, rw = 0, ena = 1) e 0x4 (rs = 1, rw = 0, ena = 1). Destaca-se ainda que esse sinal

rw difere do sinal de mesmo nome do barramento paralelo.

A definição dos endereços de cada port depende da implementação, conforme será mostrado

mais tarde na descrição da plataforma implementada.

61

2.3.2 Arquitetura de Software

Na Figura 30 é mostrado o diagrama de blocos da Arquitetura de Software, descrevendo

estrutura de software em quatro camadas (ou níveis): aplicação, chamada do dispositivo, driver do

dispositivo e protocolo de comunicação, as quais são executadas sobre uma estrutura de hardware

(PIC+dispositivos).

Aplicação

Chamada de Dispositivo

PIC

Dispositivos

Software

Hardware

Driver do Dispositivo

Protocolo I2C ou Paralelo

Figura 30. Diagrama de blocos da Arquitetura de Software

A camada de aplicação utiliza as interfaces definidas pela camada da chamada do

dispositivo para invocar serviços dos drivers que são responsáveis pelo acionamento dos

dispositivos através de chamadas de funções descritas nos protocolo I2C e paralelo. Estas funções

implementam tarefas como enviar ou receber um byte, por exemplo.

A Figura 31 apresenta um detalhamento da Figura 30, na qual são identificados os drivers

desenvolvidos e os protocolos de barramentos.

62

Driver doDispostivo

Protocolos

Aplicação

Chamada de Dispositivo

DriverDisplay de

7Segmento

DriverMotor de

Passo

DriverTecladoMatricial

DriverLCD

DriverConversor

ADC

DriverEEPROM

Protocolo do Barramento ParaleloProtocolo doBarramento

I2C Figura 31. Detalhamento das duas camadas inferiores da Arquitetura de Software

A Arquitetura de Software foi modelada utilizando UML (Unified Modeling Language.).

Entretanto a implementação da mesma foi feita utilizando linguagem C estruturada. Cada classe do

modelo UML corresponde a uma camada (chamada do dispositivo, drivers e protocolos), sendo que

também foi modelada uma classe para cada driver e protocolo. Cada método de uma classe do

modelo corresponde a uma função associada ao componente modelado. Os atributos de uma classe

referem-se aos parâmetros utilizados pelas funções modeladas como métodos, sendo que nem todos

os atributos (parâmetros) de cada classe são utilizados por todos os métodos (funções) da classe.

Na Figura 32 é mostrado o diagrama de classes para a Arquitetura de Software. A classe

Device_call representa a camada Chamada de Dispositivo da Arquitetura de Software e seus

métodos definem a interface utilizada para comunicação com a camada Aplicação. As classes de

mais baixo nível, Parallel_bus e I2c_bus, representam os protocolos paralelo e I2C,

respectivamente, da camada de protocolos. As classes intermediárias representam os drivers

desenvolvidos. Cada classe possui pelo menos dois métodos: um para inicialização (_init_) e outro

para transferência (escrita e/ou leitura) de informação (dado ou instrução). Além desses métodos, é

prevista a possibilidade de se incluir, futuramente, um tipo de método para execução de ações

diferentes das listadas acima. Esse tipo, que deverá ser denominado bus_execute_ ou i2c_execute_,

não é ilustrado no diagrama UML pois não foi incluído na implementação corrente dos drivers.

63

i2c_bus

addrdata

i2c_write()i2c_read()

Parallel_busaddrdata

bus_write()bus_read()

lcd_driverdevice_idinsaddr_port0addr_port1cursor_statedelaydata

bus_inir_lcd()bus_write_lcd_data()bus_write_lcd_ins()

d7s_driverdevice_idaddr_port0addr_port1data

bus_init_d7s()bus_write_d7s()

sm t_driverdevice_idaddr_port0sequence_typedelay_smtstep_offset

bus_init_smt()bus_write_smt()

i2c_driver

device_idaddr_port0

i2c_init_dev()i2c_writ e_dev()i2c_read_dev()

kbd_driverdevice_idaddr_port0hold_cycles

bus_init_kbd()bus_read_kbd()

adc_driveradevice_idaddr_port0addr_port1io_typeaddr

bus_init_adc()bus_read_adc()

Device_calldevice_idaddrdata

dev_write()dev_read()

Figura 32. Diagrama de classes.

Para cada driver foi estabelecida uma estrutura de dados que mantém informações a respeito

de uma instância da classe associada. Essas informações incluem o endereço(s) de E/S aos quais o

dispositivo associado está mapeado e parâmetros ou variáveis de estado específicas a cada

dispositivo (ex. posição corrente do motor de passo).

Para cada classe (ou driver), é utilizado um vetor cujos elementos são as instâncias da classe

e são acessados por meio de um identificador de dispositivo (device_id). Por exemplo, o driver do

display de 7 segmentos possui associada a estrutura struct_d7s que possui dois campos: port0 e

port1. O primeiro refere-se ao endereço do latch que armazena o nibble mais significativo do

código a ser utilizado para acionar o display, enquanto que o segundo está associado ao latch que

armazena o nibble menos significativo. Em uma implementação com dois displays de 7 segmentos,

deve haver um vetor do tipo struct_d7s de dimensão igual a 2 (denominado device_d7s[2]). Para

64

acionar um ou outro display, deve-se chamar a função (método) de escrita no display, passando,

como parâmetro, um identificador (device_id) que é utilizado pela função para selecionar o

elemento correspondente do vetor device_d7s.

As funções de inicialização foram implementadas para que as funções de escrita e leitura nos

dispositivos tivessem uma interface simplificada. Elas são chamadas uma única vez, no início da

aplicação, para configurar os campos de cada “instância” das estruturas de dados associadas aos

dispositivos utilizados. Principalmente, elas efetuam o mapeamento dos dispositivos ao espaço de

endereços de E/S do sistema. Uma vez inicializadas as estruturas, os únicos parâmetros necessários

às funções de escrita e de leitura são: (i) o identificador do dispositivo (device_id – utilizado para

selecionar um elemento do vetor da estrutura para o tipo de dispositivo associado); (ii) o endereço

(addr – necessário quando o dispositivo possui elementos internos a serem endereçados, como as

posições da memória e os canais do ADC); e (iii) o dado (data – utilizado apenas na função de

escrita).

Na Tabela 18, são descritas as interfaces definidas pela camada Chamada do Dispositivo, as

quais incluem as funções implementadas nos drivers e acessíveis às camadas superiores.

Tabela 18. Interfaces definidas pela camada Chamada de Dispositivo

Dispositivo Interface de Comunicação bus_init_d7s(device_id,addr_port0,addr_port1) Define os endereços de E/S (addr_port0 e addr_port1) da instância de display de 7 segmentos identificada por device_id Display de 7

segmentos bus_write_d7s(device_id,data) Envia data ao display de 7 segmentos bus_init_smt(device_id,addr_port0,sequence_type,delay_sm) Define o endereço de E/S (addr_port0) da instância de motor de passo identificada por device_id, bem como o tipo de seqüência a ser utilizada (sequence_type = uma fase, duas fases, uma-duas fases) e o tempo entre dois passos do motor (delay_sm)

Motor de Passo

bus_write_smt(device_id,data) Envia data (número de passos) ao motor de passos bus_init_kbd(device_id,addr_port0,hold_cycles) Define o endereço de E/S (addr_port0) da instância de teclado identificada por device_id, assim como o número de ciclos mínimos que uma tecla deve ser pressionada para ser confirmada Teclado bus_read_kbd(device_id) Realiza um ciclo de varredura no teclado e recebe código para tecla pressionada bus_init_adc(device_id,addr_port0,addr_port1,io_type) Define os endereços de E/S (addr_port0 e addr_port1) da instância de ADC identificada por device_id, assim como o tipo de mecanismo de E/S utilizado (io_type = espera ocupada ou interrupção). ADC bus_read_adc(device_id,addr) Comanda o ADC a fazer uma conversão no canal identificado por addr e retorna com o valor convertido

65

Tabela 18. Interfaces definidas pela camada Chamada de Dispositivo (continuação)

Dispositivo Interface de Comunicação bus_init_lcd(device_id,addr_port0,addr_port1,cursor_state,delay) Define os endereços de E/S (addr_port0 e addr_port1) da instância de LCD identificada por device_id, assim como o estado do cursor (cursor_state = ligado ou desligado) e o tempo entre a exibição de caracteres (delay). bus_write_lcd_ins(device_id,ins) Envia ins (instrução ou comando) ao LCD, permitindo a execução de diferentes configurações além da que pode ser realizada pela função de inicialização

LCD

bus_write_lcd_data(device_id,data) Envia data (caracter) ao LCD i2c_init_dev(device_id,addr_port0) Define o endereço de E/S (addr_port0) de uma instância de dispositivo I2C i2c_write_dev(device_id,addr,data) Envia data ao dispositivo I2C para ser escrito no endereço addr (ex. Memória EEPROM) I2C i2c_read_dev(device_id,addr) Faz a leitura de um dado do endereço addr do dispositivo I2C (ex. Memória EEPROM)

Na Figura 33, são mostrados os diagramas de seqüência de todas as funções de inicialização.

No diagrama são representadas as três primeiras camadas de uma implementação: (i) Aplicação; (ii)

Chamada de Dispositivo (classe Device_call) e (iii) Driver do Dispositivo. As outras camadas,

denominadas Protocolo do Barramento, Barramento e Dispositivo, são acessadas apenas nas

funções de escrita e de leitura (conforme será mostrado posteriormente). Por exemplo, para o driver

i2c_driver, a camada Aplicação executa a função i2c_init_dev passando, diretamente, para a

camada Driver do Dispositivo, os parâmetros: device_id (identificador do dispositivo) e addr_port0,

o qual será utilizado pelas funções de leitura e escrita para acessar o dispositivo.

66

Aplicação Chamada de Disposi tivo

Driver do Disposi tivo

1: i2c_init_dev(device_id, addr_port0); i2c_driver

2: bus_init_smt(device_id, addr_port0, sequence_type, delay_smt); smt_driver

3: bus_init_d7s(device_id, addr_port0, addr_port1); d7s_driver

4: bus_ ini t_kbd(device_id , addr_port0, hold_cycles); kbd_driver

5: bus_init_adc(device_id, addr_port0, addr_port1, io_type); adc_driver

6: bus_init_lcd(device_id, addr_port0, addr_port1, delay, cursor_state); lcd_driver

Figura 33. Diagrama de seqüência de inicialização dos Device Drivers.

Na Figura 34 é mostrado o diagrama de seqüência de acionamento do LCD.

Subseqüentemente, na Figura 35, é mostrado o diagrama de seqüência de execução de escrita e

leitura em uma memória EEPROM. Já na Figura 36, é apresentado o diagrama de seqüência de

acionamento de um motor de passo, Na Figura 37, mostra-se o diagrama de seqüência de escrita em

um display de 7 segmentos, e, na Figura 38, é apresentado o diagrama de seqüência de Escrita e

leitura em um teclado matricial, e por ultimo na Figura 39, é mostrado o diagrama de seqüência de

leitura em um conversor AD.

67

Ap

lica

ção

Ch

am

ad

a d

o

Dis

po

siti

voD

rive

rd

o D

isp

osi

tivo

Pro

toco

lo d

e

Ba

rra

me

nto

Ba

rra

me

nto

Dis

po

siti

vo

1:

de

v_w

rite

(de

vice

_id

,0,d

ata

)2

: b

us_

wri

te_

lcd

_d

ata

(de

vice

_id

,da

ta)

3:

bu

s_w

rite

(ad

dr,

da

ta)

5:

bu

s_w

rite

(ad

dr,

da

ta)

4:

en

via

o n

ibb

le m

en

os

sig

nif

ica

tivo

de

da

ta

6:

ha

bil

ita

esc

rita

7:

Esc

reve

nib

ble

no

LC

D

8:

bu

s_w

rite

(ad

dr,

da

ta)

9:

de

sab

ilit

a e

scri

ta

10

: b

us_

wri

te(a

dd

r,d

ata

)

11

: e

nvia

o n

ibb

le m

ais

sig

nif

ica

tivo

de

da

ta

12

: b

us_

wri

te(a

dd

r,d

ata

)1

3:

ha

bil

ita

esc

rita

14:

Esc

reve

nib

ble

no

LC

D

15

: b

us_

wri

te(a

dd

r,d

ata

)1

6:

de

sab

ilit

a e

scri

ta

Figu

ra 3

4. D

iagr

ama

de se

qüên

cia

de e

scrit

a em

um

LC

D.

68

1:

de

v_w

rite

(de

vice

_id

,0,d

ata

)

Ap

lica

ção

Ch

am

ad

a d

o

Dis

po

siti

voD

rive

rd

o D

isp

osi

tivo

Pro

toco

lo d

e

Ba

rra

me

nto

Ba

rram

en

toD

isp

osit

ivo

6:

de

v_re

ad

(de

vice

_id

,0)

7:

i2c_

rea

d_

de

v(a

dd

r)8

: b

us_

rea

d(a

dd

r)

9:

colo

ca o

po

nte

iro

da

me

mo

ria

no

en

de

reço

10

: L

ê d

a M

em

óri

a

11

: R

eto

rna

va

lor

exi

ste

nte

no

en

de

reço

da

me

mó

ria

12

: C

olo

ca o

va

lor

no

ba

rra

me

nto

13

: d

rive

r re

ceb

e d

o b

arr

am

en

to

2:

i2c

_w

rite

_d

ev(d

ev

ice

_id

, a

dd

r,da

ta)

3:

bu

s_w

rite

(ad

dr,

da

ta)

4:

pa

ssa

en

de

reço

e v

alo

r a

se

r e

scri

to n

a i

2c

5:

Esc

reve

na

i2

c

14

: R

eto

rna

da

do

lid

o

15

: R

eto

rna

da

do

lid

o

Fi

gura

35.

Dia

gram

a de

seqü

ênci

a de

esc

rita

e le

itura

em

um

a m

emó

a EE

PRO

M.

69

69
ri

Aplic

ação

Cham

ada

do

Disp

ositi

vo :

Devi

ce_

Driv

erdo

Disp

ositi

voPr

otoc

olo

de

Barra

men

toBa

rram

ento

Disp

ositi

vo

1: d

ev_w

rite(

devi

ce_i

d,0,

data

)

2: b

us_w

rite_

smt(d

evic

e_id

,dat

a)

3: b

us_w

rite(

devi

ce_s

mt[d

evic

e_id

].por

t0,d

ata)

4: e

nvia

nib

ble

men

os si

gnifi

cativ

o de

dat

a

5: g

ira m

otor

6: E

nvia

nib

ble

men

os si

gnifi

cativ

os d

e da

ta7:

gira

mot

or

8: E

nvia

nib

ble

men

os si

gnifi

cativ

o de

dat

a9:

gira

mot

or

. . .

Fi

gura

36.

Dia

gram

a de

seqü

ênci

a de

esc

rita

em u

m M

otor

de

Pass

o

70

70

.

Apl

icaç

ãoCh

amad

a do

D

ispo

sitiv

oD

river

do D

ispo

sitiv

oP

roto

colo

de

Bar

ram

ento

Bar

ram

ento

Dis

posi

tivo

1: d

ev_w

rite(

devic

e_id

,0,d

ata)

2: b

us_w

rite_

d7s(

devic

e_id

,dat

a)

3: b

us_w

rite(

addr

,dat

a)

4: e

nvia

o n

ibbl

e m

enos

si

gnifi

cativ

o de

dat

a

7: e

nvia

o n

ibbl

e,m

ais

sign

ifica

tivo

de d

ata

5: e

scre

ve n

o di

spla

y de

7

segm

ento

8: E

scre

ve n

o di

spla

y de

7

segm

ento

6: b

us_w

rite(

addr

,dat

a)

Figu

ra 3

7. D

iagr

ama

de se

qüên

cia

de e

scrit

a no

Dis

play

de

7 Se

gmen

tos.

71

71

13:

Ret

orna

cód

igo

Apl

icaç

ãoC

ham

ada

do

Dis

posi

tivo

Driv

erdo

Dis

posi

tivo

Pro

toco

lo d

e B

arra

men

toB

arra

men

toD

ispo

sitiv

o

1: d

ev_r

ead(

dev

ice_

id,0

)2:

bus

_rea

d_kb

d(de

vic

e_id

,0)

3: b

us_w

rite(

dev

ice

_kb

d[de

vic

e_

id].

port

0,co

lum

n)

4: E

nvia

cód

igo

de s

eleç

ão d

e co

luna

5: S

elec

iona

col

una

7: S

olic

ita a

leitu

ra d

o có

dig

o d

e lin

ha p

ara

a c

olun

a se

leci

onad

a8:

Lê

códi

go d

e lin

ha p

ara

a co

luna

sel

ecio

nada

9: R

etor

na c

ódig

o de

linh

a pa

ra a

co

luna

sel

ecio

nada

10:

Ret

orna

cód

igo

de li

nha

para

a c

olun

a se

leci

onad

a

12:

Ret

orna

cód

igo

6: b

us_r

ead(

dev

ice_

kbd[

dev

ice_

id].

port

0)

11:

Ret

orna

cód

igo

lido.

Se

códi

go

for

dife

rent

e de

tec

la n

ão

pres

sion

ada,

rep

ete

a le

itura

ho

ld_c

ycl

es v

ezes

par

a co

nfirm

ar

o pr

essi

onam

ento

da

tecl

a.

Apó

s, r

etor

na o

cód

igo

da t

ecla

. C

aso

a te

cla

seja

libe

rada

ant

es

de h

old_

cycl

es le

itura

s, r

etor

na

códi

go d

e te

cla

não

pres

sion

ada

Fi

gura

38.

Dia

gram

a de

seqü

ênci

a de

esc

rita

e le

itura

em

um

Tec

lad

Mat

ricia

l.

72

72
o

25:

Ret

orna

by

te d

o da

do c

onv

ertid

o

Apl

icaç

ãoC

ham

ada

do

Dis

posi

tivo

Driv

erdo

Dis

posi

tivo

Pro

toco

lo d

e B

arra

men

toB

arra

men

toD

ispo

sitiv

o

1: d

ev_r

ead(

dev

ice_

id,a

ddr)

2: b

us_

read

_adc

(dev

ice_

adc

[de

vic

e_i

d].

port

0, a

ddr)

3: b

us_w

rite

(add

r,da

ta)

OB

S:

addr

= p

ort0

data

= a

ddr

= ca

nal d

o A

DC

4: s

elec

iona

can

al

6: b

us_w

rite(

addr

,0)

OB

S:

addr

= p

ort1

7: in

icia

con

ver

são

10:

Se

io_t

ype

= 0

, fi

ca e

m

espe

ra o

cupa

da a

guar

dand

o fi

m d

e c

onv

erão

. S

e fo

r ig

ual

1, u

tiliz

a in

terr

upçã

o pa

ra

sina

lizar

fim

de

conv

ersã

o

5: s

ele

cio

na

can

al

8: I

nici

a co

nver

são

9: R

etor

na s

inal

de

fim

de

conv

ersã

o

11:

Sin

aliz

a fi

m d

e co

nver

são

12:

bus_

read

(add

r)

OB

S:

addr

= p

ort1

13:

Lê o

nib

ble

mai

s si

gnif

icat

ivo

do r

esul

tado

da

conv

ersã

o14

: Lê

res

ulta

do

da c

onv

ersã

o

18:

bus_

read

(add

r)

OB

S:

addr

= p

ort0

19:

Lê o

nib

ble

men

os s

igni

fica

tivo

do r

esul

tado

da

conv

ersã

o20

: Lê

res

ulta

do d

a co

nver

são

15:

Ret

orna

nib

ble

16:

Ret

orna

nib

ble

17:

Ret

orna

nib

ble

21:

Ret

ona

nibb

le22

: R

etor

na n

ibbl

e23

: R

etor

na n

ibbl

e

24:

Ret

orna

by

te

Fi

gura

39.

Dia

gram

a de

seqü

ênci

a de

leitu

ra e

m u

m C

onve

rsor

AD

.

73

73

3. IMPLEMENTAÇÃO E VALIDAÇÃO

O sistema foi implementado utilizando a linguagem C para microcontroladores PIC, o que

facilita a sua implementação e também futuras correções e atualizações. Para efetuar a compilação

do código, foi utilizado o compilador CCS. Para validar os device drivers utilizou-se a ferramenta

Proteus/Isis, a qual é um simulador de circuito interativo em ambiente de projeto que possibilita

uma simulação do funcionamento dos dispositivos. Alguns drivers foram também validados

utilizando-se dispositivos físicos.

Conforme já foi apresentado na descrição da metodologia deste trabalho, devido à

necessidade de consolidar alguns conceitos sobre as ferramentas e tecnologias utilizadas, os drivers

foram inicialmente implementados como rotinas para acionamento de dispositivos conectados

diretamente ao microcontrolador. Após isso, foi feita a modelagem de um sistema baseado no

PIC16F877, que permitiu trabalhar com um barramento de dados mais largo (8 bits) simplificando a

implementação da lógica de cola (latches e buffers tri-state) e das rotinas de acesso. Uma vez

adquirida a experiência necessária, fez-se então a revisão da modelagem da arquitetura baseada no

PIC16F628, conforme havia sido proposto originalmente.

Desses experimentos, pode-se verificar o efeito das restrições impostas pela capacidade

limitada de E/S do PIC16F628 se comparada com a capacidade de E/S do PIC16F877. A falta de

pinos de E/S para se implementar um barramento de dados mais largo exige circuitos adicionais

para serialização de palavras de 8 bits, além de instruções nos drivers que comandem essa

serialização. Ou seja, tanto o hardware como o software são mais caros. Logo, essa experiência foi

de grande valia para entender essa relação e ao mesmo tempo para aprender como buscar soluções

para implementações submetidas a restrições semelhantes às encontradas.

Não é objetivo deste texto apresentar aspectos adicionais da realização desses experimentos

e, portanto, a modelagem mostrada anteriormente descreveu apenas o sistema final. Da mesma

forma, nesta seção, apresentam-se detalhes de implementação e da validação dos drivers

desenvolvidos para a plataforma baseada no PIC16F628.

74

3.1 Implementação

Com base nas restrições impostas pela plataforma definida, buscou-se implementar drivers

de forma a minimizar o custo do código, mas, ao mesmo tempo, garantir um nível adequado de

flexibilidade e de facilidade de uso (ou seja, drivers leves, eficientes, de fácil utilização e

manutenção).

Eles foram organizados em funções que serão carregadas pelo programador, através de um

arquivo de cabeçalho (.h), no qual o programador da aplicação deve, necessariamente, configurar as

seguintes definições:

• dispositivos utilizados (ex: #define USE_I2C)

• endereços de E/S dos dispositivos (ex: #define i2c_addr_dev_0_port0 0xa0)

• número de instâncias de cada dispositivo (ex: #define num_i2c_dev 1)

Os códigos em linguagem C dos drivers e das funções das camadas de Chamada de

Dispositivo e Protocolo de Barramento foram exaustivamente testados na ferramenta Proteus como

forma de validação de seu funcionamento. Através de observações, verificou-se a correção dos

mesmos. Alguns drivers como é o caso do LCD, Display de 7 segmentos, motor de passo, também

foram implementados e testados na forma física.

Como os drivers foram implementados de forma a utilizar a Arquitetura de Hardware

descrita anteriormente, para os dispositivos que utilizam comunicação em oito bits (LCD, display

de 7 segmentos e conversor AD), foi necessária a serialização dos bits, os quais são transferidos

nibble a nibble.

Na Figura 40 é mostrada a plataforma de teste implementada no ambiente da ferramenta

Proteus/Isis. Com exceção da memória EEPROM, os demais componentes são conectados ao

microcontrolador através de um barramento de dados de quatro bits (data[3..0]), sendo que os bits

de endereço (addr[3..0]) são decodificados e a partir deles são gerados sinais de seleção (sel[9..0]),

para cada port do espaço de endereçamento definido. Logo a seguir, serão descritas algumas das

principais características de todos os componentes utilizados na plataforma de teste.

75

Figura 40. Plataforma de Teste.

Os componentes utilizados nessa plataforma incluem:

• 1 microcontrolador PIC16F628;

• 1 motor de passo;

• 1 LCD (paralelo);

• 1 teclado matricial;

• 1 memórias EEPROM (serial);

• 1 ADC0808;

• 1 porta lógica “nor”, componente 74HC00;

• 5 portas lógicas “or”, componente 74HC08;

• 1 porta lógica “and”, componente 74HC32;

• 15 portas lógica “not”, componente 74HC04;

• 6 latches, componentes 74LS373;

• 1 buffers tri-state, componentes 74LS241;

76

• 2 decodificadores, componentes 74LS138;

• 1 componente ULN2003A;

• 8 resistores;

• 2 capacitores;

• 1 cristal;

• 2 voltímetros (AC Volter);

• 2 potenciômetros.

O componente 74LS138, mostrado na Figura 41, foi utilizado na plataforma de hardware

para a seleção de dispositivos. Para o seu funcionamento utilizou-se três pinos do microcontrolador

que realizam a função de endereçamento dos dispositivos, e outro pino para habilitação do pino

“enable” dos componentes 74LS138. Assim, quando é enviado o sinal “00000111” no port A do

microcontrolador, isso corresponde ao endereço 7, e, dessa forma, será enviado um sinal para o

dispositivo que estiver mapeado nesse endereço. Da mesma forma para todos os outros dispositivos.

Figura 41. Componente 74LS138

Na construção da plataforma de teste foi necessária a utilização de alguns latches do tipo

“74LS373”, mostrado na Figura 42, cuja sua função, quando habilitado é de armazenamento do

valor que é enviado no barramento. Assim, pode-se utilizar o barramento para habilitar outra função

sem perder o sinal enviado anteriormente ao dispositivo.

77

Figura 42. Componente 74LS373.

O componente 74LS04 (mostrado na Figura 43.a) representa uma porta lógica not que

inverte o nível lógico do sinal. Na utilização do ADC também houve a necessidade de usar uma

porta lógica or a qual está mostrada na Figura 43.b.

(a)

(b)

Figura 43. Portas lógicas: (a) 74LS04, porta not; (b) 74HC32 ou porta lógica “or”.

A Figura 44 mostra outras portas lógicas utilizadas na plataforma de teste para a construção

de dispositivos como teclado matricial e conversor AD: 74HC00 (porta nand) e 74HC08 (porta

and).

(a)

(b)

Figura 44. Portas lógicas: (a) 74HC00, porta nand; (b) 74HC08, porta and

78

O componente ULN2003A, mostrado na Figura 45 é responsável por amplificar o sinal

usado para o acionamento do motor de passo. Na plataforma de teste ele recebe uma tensão de 5V e

é ampliada para 8,33 V.

Figura 45. Componente ULN2003A

Na Figura 46 é mostrado o componente 74LS241 que é um buffer tri-state que é utilizado

para a conexão das saídas dos dispositivos ao barramento. A cada leitura, apenas um desses

dispositivos é acionado, em função do endereço selecionado.

Figura 46. Componente 74LS241, buffer tri-state

79

O componente ilustrado na Figura 47 é um voltímetro que foi utilizado para a medição de

níveis de tensão analógica quando do uso do conversor A/D.

Figura 47. AC Volter

3.2 Validação

Na validação do driver do display de 7 segmentos, mostrado na Figura 48, observou-se se o

dado passado era realmente o dado impresso no display. Os parâmetros enviados pelo driver ao

dispositivo foram: o identificador representado por id_d7s, endereço no dispositivo (0, pois não há

endereçamento interno no dispositivo) e o valor a ser impresso no display de 7 segmentos,

representada sua estrutura abaixo como chamada.

dev_write(id_d7s_0,0,2); Figura 48. Display de 7 segmentos.

80

Na validação do dispositivo motor de passo, mostrada na Figura 49, verificou-se a seqüência

de passos foram devidamente executadas pelo Motor. Foram enviados números de passos a serem

executados, onde números positivos provocam um giro a direita, e negativos provocam giros para a

esquerda. O driver também foi implementado de forma a garantir que o motor execute diferentes

seqüências de fases, podendo ser executado com uma fase , duas fase ou uma-duas fases conforme

descrito no capítulo “4.3 Motor de Passo”, também foi implementada na função de inicialização a

opção de inclusão da velocidade com que ocorre o giro do motor de passo.

dev_write(id_smt_0,0,4) dev_write(id_smt_0,0,-4)

Figura 49. Motor de passo

Para validar a memória externa EEPROM foi feita à gravação de um valor no endereço 0x00

da memória externa (I2C Memory - Internal Memory), mostrada na Figura 50.a, e, posteriormente,

foi feita uma verificação visual procurando verificar se o devido valor encontrava-se no endereço

desejado. Para validar sua leitura, foi requisitada a leitura no endereço 0x00 da memória externa

EEPROM e após sua leitura foi envido e gravado o valor adquirido no endereço 0x01 de memória

interna do microcontrolador, visto na Figura 50.b.

dev_write(id_i2c_0,0x00,00)

(a)

write_eeprom(0x01,dev_read(id_i2c_0,0x00)

(b)

Figura 50. Memória Externa EEPROM (a), Memória Interna EEPROM (b)

81

Já para validar o conversor A/D foram incluídos um potenciômetros visto na Figura 51.b,

um sinal em forma de senoide no pino 3 e uma onda quadrada no pino 7 do conversor A/D vistos

na Figura 51.a. Quando é feita uma requisição ao conversor A/D, o canal selecionado é lido pelo

A/D e o valor convertido é retornado, nibble a nibble. Esse valor foi então visualizado com a escrita

do mesmo em uma posição da EEPROM interna, e mostrados no display de LCD.

dev_read(id_adc_0,3) dev_read(id_adc_0,7)

(a)

dev_read(id_adc_0,0)

(b) Figura 51. Conversor ADC (a), Potenciômetros (b)

Para validação do device driver do teclado foi pressionada uma tecla e a função de varredura

do retorna o valor correspondente, o qual é enviado ao driver de sete segmentos, onde será impresso

o valor retornado pelo teclado matricial. Nas figuras a seguir, é exemplifica a execução do driver do

teclado, onde é pressionada a tecla 2 e impressa no display de 7 segmentos.

tecla = dev_read(id_kbd_0,0);

(a)

dev_write(id_d7s_0,0,tecla);

(b)

Figura 52. Teclado Matricial (a), Display de 7 Segmentos (b)

82

A Tabela 19 lista os tamanhos, em palavras de instrução, de todas as funções implementadas

para as camadas definidas. Verifica-se que as funções de maior custo são aquelas que realizam

algum algoritmo mais elaborado (ex: varredura de teclado na bus_read_kbd) ou que oferecem

flexibilidade para opções de implementação (ex: bus_write_smt). As funções de escrita e leitura no

barramento paralelo também possuem alto custo, uma vez que o acesso aos canais de dado e de

endereço devem ser feitos bit a bit, pois, a mesma porta é utilizada para enviar sinais de diferentes

características (ex. dado e controle), sendo que rotinas mais “baratas” (em termos de código) da

linguagem C (ex. outport_b( ) e inport_b( )) não podem ser utilizadas pois modificam a direção de

todos os bits do port acessado.

Tabela 19. Tamanho das funções implementadas.

Camada Função No. de Instruções

dev_write 47 Chamada de Dispositivo dev_read 40 bus_init_adc 36 bus_read_adc 86 bus_init_smt 43 bus_write_smt 334 bus_init_d7s 14 bus_write_d7s 33 bus_init_kbd 25 bus_read_kbd 258

i2c_init_dev 10 i2c_write_dev 112 i2c_read_dev 77 bus_init_lcd 108

Driver de Dispositivo

bus_write_lcd_data 106 bus_write 101 Protocolo de barramento bus_read 96

83

A Tabela 20 mostra um comparativo do custo de implementação dos drivers em outro

microcontrolador PIC com uma maior número de pinos, o que permite o uso de rotinas de

acionamento de ports mais baratas. O modelo escolhido (PIC16F877) possui cinco ports de E/S,

sendo que um deles foi reservado para a implementação do barramento de dados com 8 bits. Como

é mostrado na tabela, a versão com 4 bits. Verifica-se que o principal impacto em termos de

redução de custo está nas rotinas do protocolo do barramento.

Tabela 20. Comparativo do tamanho das funções implementadas

Camada Função PIC16F628 (4 bits)

PIC16F877 (8 bits)

dev_write 47 47 Chamada de

Dispositivo dev_read 40 34 bus_init_adc 36 38 bus_read_adc 86 66 bus_init_smt 43 45 bus_write_smt 334 334 bus_init_d7s 14 8 bus_write_d7s 33 13 bus_init_kbd 25 27 bus_read_kbd 258 258

bus_init_lcd 108 85

Driver de

Dispositivo

bus_write_lcd_data 106 57 bus_write 101 30 Protocolo de

barramento bus_read 96 33

3.3 Uso dos Drivers Desenvolvidos

Para a utilização dos drivers em aplicações, é necessário que o programador inclua os

arquivos de cabeçalho (drivers.h e dd_map.h) em seu código (Anexo I). Ilustrado na figura 53.

#include<drivers.h> #include<dd_utils.h>

Figura 53. Arquivos de cabeçalho

84

O arquivo driver.h inclui as rotinas de chamada de dispositivo (dev_write e dev_read), dos

drivers e das camadas de protocolo de barramento (bus_write, bus_read, i2c_write e i2c_read). Ele

inclui também definições necessárias aos drivers, como, por exemplo, códigos de representação de

teclas do teclado, sendo que, em princípio, essas definições não devem ser modificadas pelo

projetista.

Já arquivo dd_map.h inclui definições que podem ser editadas a cada novo projeto, pois

determinam quais e quantos dispositivos serão utilizados e o mapa de endereços desses dispositivos.

Ela inclui também definições para a pinagem dos barramentos, os quais não necessitam ser

modificadas, exceto se for preciso mudar os ports utilizados no microcontrolador.

Na Figura 54 estão listadas as definições de uso dos dispositivos. Por exemplo, a definição

#define use_i2c habilita o compilador a incluir o driver para acionamento de dispositivos I2C. Já a

definição #define use_d7s é habilita a inclusão das rotinas correspondentes as chamadas desse tipo

de dispositivo.

#define use_i2c #define use_smt #define use_adc #define use_lcd #define use_kbd #define use_d7s

Figura 54. Definições de uso dos dispositivos

Caso a utilização de algum driver não seja necessária, pois o sistema não inclui o dispositivo

associado, basta apenas comentar, no dd_map.h, a definição correspondente. Quando o programa é

compilado, o mesmo não é incluído no código gerado, evitando o uso desnecessário de espaço na

memória.

Para cada driver, existe, no arquivo drivers.h, um vetor para uma estrutura de dados definida

de modo a manter as informações de endereçamento e de configuração (se necessário) das

instâncias do dispositivo associado. Esse vetor é declarado apenas se o tipo de dispositivo

correspondente é utilizado, conforme é ilustrado na Figura 55 para o driver do display de

7 segmentos. No exemplo dessa figura, mostra-se que a estrutura struct_d7s tem dois campos de

endereço, denominados port0 e port1. Com base nessa estrutura, é declarado um vetor para todas as

85

instâncias do display de 7 segmentos, sendo que o número de instâncias (ou seja, o tamanho do

vetor), é definido pelo parâmetro num_d7s_dev, defindo no arquivo dd_map.h, conforme é

mostrado na Figura 56.

#ifdef use_d7s struct struct_d7s { int8 port0; int8 port1; } device_d7s[num_d7s_dev]; #endif

Figura 55. Definição da estrutura struct_d7s e declaração do vetor device_d7s (incluídos no arquivo drivers.h)

#define num_d7s_dev 2 #define num_i2c_dev 1 #define num_smt_dev 1 #define num_kbd_dev 1 #define num_lcd_dev 1 #define num_adc_dev 1

Figura 56. Definição do número de instâncias

O arquivo dd_map.h inclui as definições do espaço de endereçamento de entrada-e-saída

utilizadas na inicialização dos campos do tipo port das estruturas de dado. A Figura 57 ilustra as

definições para o mapa de endereços utilizado neste trabalho. Observa-se que os ports das duas

instâncias de display de 7 segmentos (bus_addr_d7s_0 e bus_addr_d7s_1) utilizam endereços

diferentes (1 e 2 para a instância 0, e 9 e 10 para a instância 1).

#define bus_addr_smt_0_port0 0b00000000 // 0 #define bus_addr_d7s_0_port0 0b00000001 // 1 #define bus_addr_d7s_0_port1 0b00000010 // 2 #define bus_addr_kbd_0_port0 0b00000011 // 3 #define bus_addr_lcd_0_port0 0b00000100 // 4 #define bus_addr_lcd_0_port1 0b00000101 // 5 #define bus_addr_adc_0_port0 0b00000110 // 6 #define bus_addr_adc_0_port1 0b00000111 // 7 #define bus_addr_d7s_1_port0 0b00001001 // 9 #define bus_addr_d7s_1_port1 0b00001010 // 10 #define i2c_addr_dev_0_port0 0xa0

Figura 57. Definições de mapas de endereço

86

O arquivo dd_map.h é também responsável pela definição dos pinos utilizados pelo

microcontrolador, deixando o programador com uma flexibilidade na sua utilização. Na Figura 58 é

listada uma configuração de pinos para o sistema baseado no PIC16F628, modelado neste trabalho.

#define bus_ena pin_a4 #define bus_addr3 pin_a3 #define bus_addr2 pin_a2 #define bus_addr1 pin_a1 #define bus_addr0 pin_a0 #define bus_data3 pin_b7 #define bus_data2 pin_b6 #define bus_data1 pin_b5 #define bus_data0 pin_b4 #define bus_rw pin_b3 #define bus_busy_int pin_b0 #define i2c_scl pin_b2 #define i2c_sda pin_b1 Figura 58. Codificação dos pinos para o sistema baseado no PIC16F628

3.4 Considerações sobre a Implementação dos Drivers para outros

Microcontroladores e Dispositivos

A partir da experiência adquirida com o desenvolvimento deste trabalho, pode-se verificar o

impacto das características do microcontrolador utilizado na implementação dos drivers. Conforme

já relatado, foram feitos experimentos no sentido de se implementar rotinas similares em um

modelo de PIC com maior capacidade de E/S. Desses experimentos, concluiu-se que o modelo

utilizado neste trabalho é excessivamente restritivo e que uma plataforma como a que foi proposta,

com um barramento serial e um barramento paralelo, seria mais eficiente se implementada com

base em um modelo que permitisse utilizar um barramento de 8 bits exclusivo para os dados. Com

isso, as rotinas da Camada de Protocolo seriam mais leves (com cerca de 40 instruções assembly,

conforme experimentos realizados), pois a escrita e a leitura dos dados não precisariam ser feitas

bit-a-bit. Além de reduzir o custo em termos de uso da memória de programa, isso também

reduziria o custo quanto ao consumo de energia, pois uma menor quantidade de ações precisam ser

tomadas para executar uma mesma tarefa. Além disso, nos drivers em que são manipuladas palavras

de oito bits (ex. ADC e displays), não seria mais necessário fazer a serialização e desserialização de

nibbles, resultando, também, na redução de custos. Uma outra vantagem da utilização de um

87

microcontrolador com maior capacidade de E/S está na simplificação da lógica de cola, pois uma

menor quantidade de latches, buffers e portas lógicas seriam necessárias.

Quanto a novos dispositivos, os drivers desenvolvidos neste trabalho podem ser facilmente

estendidos para o acionamento de dispositivos com características de E/S similares, pois a

estruturação dos drivers em camadas e o uso dos barramentos provê uma boa flexibilidade tanto

para a conexão do dispositivo quanto à implementação das funções de acionamento via software.

Por exemplo, um relógio de tempo real com interface I2C pode ser conectado ao mesmo barramento

serial requerendo apenas que sejam desenvolvidas funções de mais alto nível para a manipulação de

data e hora, já que as mesma rotinas de inicialização, escrita e leitura da camada Drivers de

Dispositivo aplicadas à EEPROM serviram a outros dispositivos I2C.

88

IV – CONCLUSÕES E RECOMENDAÇÕES

Para o desenvolvimento deste trabalho foram realizados estudos na área de sistemas digitais

sistemas computacionais embarcados, microcontroladores, bem como estudos nas ferramentas de

desenvolvimento C para PIC, compilador CCS e ferramenta de simulação de circuito para fins de

validação do modelo.

O trabalho realizado constituiu-se no desenvolvimento de device drivers para o

microcontrolador PIC16F628 utilizando um barramento ao qual foram conectados um motor de

passo, um display de 7 segmentos, um teclado matricial, um conversor A/D e um LCD. Também foi

definido um barramento I2C ao qual foi conectada uma memória EEPROM.

A plataforma de teste desenvolvida para simulação dos device drivers foi projetada em uma

ferramenta de simulação de circuito, onde foram testados e validados todos os drivers

desenvolvidos, primeiramente de forma individual e, após, integrados à plataforma de hardware no

proteus.

Algumas dificuldades foram encontradas no desenvolvimento deste trabalho, as quais estão

listadas abaixo:

• Limitações de recursos de laboratório para a validação física completa dos device

drivers.

• Falta de embasamento teórico durante o decorrer do curso para a área de sistemas

embarcados,

• Falta de experiência prévia sobre as ferramentas utilizadas durante o projeto.

• Necessidade de compreender melhor o funcionamento do microcontrolador e dos

dispositivos selecionados

Destaca-se que foi publicado um resumo no Congresso de Iniciação Científica e

Tecnológica em Engenharia (CRICTE’2003), conforme Anexo II. Além disso, deve-se destacar que

este trabalho está vinculado ao Projeto ProPIC, em desenvolvimento na UNIVALI, o qual, sob o

apoio do FUNCITEC, pretende desenvolver uma plataforma hardware-software para integração de

sistemas microcontrolados em FPGA. Um resumo estendido sobre este projeto foi submetido para

publicação no Student Forum on Microelectronics (SFM’2004) (Anexo III).

Por fim, levando-se em conta os objetivos estabelecidos na proposta deste trabalho,

considera-se que os mesmos foram cumpridos. Como continuidade, sugere-se a elaboração de

drivers para um leque maior de dispositivos e a adaptação desses drivers para plataformas baseadas

em modelos de PIC com maior capacidade de E/S, o que deve levar a uma redução dos tamanhos

dos drivers desenvolvidos neste trabalho.

90

BIBLIOGRAFIA

ALCÂNTARA FILHO, R. P. D. Estudo do motor de passo e seu controle digital. Eletrônica.Org.

Disponível em: <http://www.eletronica.org/modules.php?name=News&file= article&sid=15>

Acesso em: 19 nov. 2003.

ANIDO, M, L. Sistemas embutidos. Disponível em: <http://labase.nce.ufrj.br/

sistemas_embutidos/> Acesso em: 22 set. 2003.

BANNATYNE, R. Microcontrollers for the automobile. Transportation Systems Group,

Motorola Inc.. 2003 Micro Control Journal. Disponível em: <http://www.mcjournal.com/

articles/arc105/arc105.htm>. Acesso em: 22 out 2003.

BONFIM, M. Medidas elétricas. Disponível em: <http://www.eletrica.ufpr.br/marlio/medidas

/apostila/apostila3b.pdf>. Acesso em: 29 out. 2003.

BRAGA, N. Motores de passo. Saber Eletrônica, n. 323, p.4-6, 1999.

CARRO, L.; WAGNER, F. R. Sistemas computacionais embarcados. In: JAI’03 – XXII

JORNADAS DE ATUALIZAÇÃO EM INFORMÁTICA, Capítulo 2, ago. 2003.

COSTA LEITE, B. H. F. et al. Estudo do motor de passo e seu controle digital. Eletrônica.org.

Disponível em: <http://www.eletronica.org/modules.php?name=News&file=article&sid=15>.

Acesso em: 10 out. 2003.

DEMMELER, T.; GIUSTO, P. A. Universal communication model for an automotive system

integration platform. In: DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCE

AND EXHIBITION, DATE, Munich, 2001. Proceedings... Los Alamitos: IEEE Computer Society,

2001. p. 47-53.

DUTTA, S.; JENSEN, R.; RIECKMANN, A. Viper: a multiprocessor SOC for advanced set-top

box and digital tv systems. IEEE Design and Test of Computers, [S.l.], v. 18, n. 5, p. 21-31,

Sept.-Oct. 2001.

EMBEDDED SYSTEM ACADEMY. Introduction to I2C. 2000. Disponível em:

<http://www.esacademy.com/myacademy/classes/I2CIntro/I2CIntro_files/frame.htm?category=&>.

Acesso em: 10 nov. 2003.

FURLAN. J. D. Modelagem de objetos através da UML – the unified modeling language. São

Paulo: Makron Books do Brasil, 1998.

INTEL. MCS 51 Microcontroler family user’s manual. Arizona, 2003. 334 p.

KELLY-BOOTLE, S. Dominando o Turbo C. 2. ed. Rio de Janeiro: Ciência Moderna, 1989.

KUMAR, S. et al. A Network on Chip architecture for System-on-Chip. In: SYMPOSIUM ON

INTEGRATED CIRCUITS AND SYSTEM DESIGN, 14, 2001, Pirinópolis – Brasil.

Proceedings… Los Almitos: IEEE Computer Society, 2001. p.14-19.

MACHADO, B. M; MAIA, L. P. Arquitetura de sistemas operacionais. 2 Ed, Rio de Janeiro:

LTC, 1997.

MACHADO, F. B.; MAIA, L. P. Arquitetura de sistemas operacionais. 2. ed. Rio de Janeiro:

LTC, 1999.

MARINHO, J, E, S; MARINHO, E, S. Mini-Curso de Microcontrolador. Saber Eletrônica

Especial nº 2, jan de 2001.

MICROCHIP. FLASH-based 8-bits CMOS microcontroller. Arizona, 2003. 161 p.

NATIONAL SEMICONDUCTORS. 8-Bit up compatible A/D converters with 8-channel

multiplexer. Disponível em: <http://www.national.com/ds/AD/ADC0808.pdf>. Acesso em: 25 out.

2003.

OLIVEIRA, R S. Sistemas embutidos (embedded systems). Disponível em:

<http://www.das.ufsc.br/~montez/Disciplinas/DAS5321/Embutidos.pdf> Acesso em: 22 set 2003.

92

OYAMADA, M S; WAGNER, F R. Co-simulação de sistemas eletrônicos embarcados. In:

SEMANA ACADÊMICA DO PPGC, 4.,1999, Porto Alegre. Anais... Porto Alegre: PPGC da

UFRGS, 1999. p. 347-350.

PAULA FILHO, W. P. Engenharia de software. Rio de Janeiro: LTC. 2001. p. 18-18

PAULIN, P. et al. Embedded software in real-time signal processing systems: application and

architecture trends. Proceedings of the IEEE, [S.l.], v. 85, n. 3, p. 419-454, Mar. 1997.

PEREIRA, F. Microcontroladores PIC: programação em C. São Paulo: Érica, 2003.

PEREZ, A. Visualizador de Mensagens LCD. Saber Eletrônica, São Paulo, n. 319, p. 9-11, ago.

1999.

PHILIPS SEMICONDUCTORS. I2C bus catalog. Disponível em:

<http://www.semiconductors.philips.com/buses/i2c/products/>. Acesso em: 21 nov. 2003.

PHILIPS SEMICONDUCTORS. The I2C bus specification. v. 2.1, jan. 2000. 45 p.

PREDKO, M. Handbook of microcotrollers. New York: McGraw-Hill, 1998.

PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.

RABBIT SEMICONDUCTOR. Rabbit 3000 microprocessor user’s manual. Califórnia, 2003.

273 p.

SILBERCHATZ, A.; GALVIN, P. B. Sistemas operacionais conceitos. 5.ed. São Paulo: Prentice

Hall, 2000.

SOUZA, D.J. Desbravando o PIC: baseado no microcontrolador PIC16F87, São Paulo: Érica,

2000.

93

TANENBAUM, A. S; WOODHULL, A. S. Sistemas operacionais: projeto e implementação.

Porto Alegre: Bookman, 2000.

WOLF, W. What is embedded computing?. IEEE Computer, v.35, n.1, p.136-137, Jan. 2002.

ZEFERINO, C. A. Redes-em-Chip: arquiteturas e modelos para avaliação de área e desempenho.

2003, 242 p. Tese (Doutorado) – Programa de Pós-Graduação em Computação, Universidade

Federal do Rio Grande do Sul, Porto Alegre.

ZELENOVSKY, R; MENDONÇA, A. Introdução aos sistemas embutidos. Disponível em:

<http://www.mzeditora.com.br/artigos/embut.htm>. Acesso em: 22 set. 2003.

94

universidade do vale do itajaÍ centro de …siaibib01.univali.br/pdf/julio cesar fiamoncini.pdf ·...

Documents