31 UPEMS: Unidade de Processamento de Periféricos Específicos

UPEMS: UNIDADE DE PROCESSAMENTO DE PERIFÉRICOS
ESPECÍFICOS PARA MICROCONTROLADORES
Cesar Giacomini Penteado
Edward David Moreno Ordonez
UNIVEM - Centro Universitário Eurípides de Marília
Av Hygino Muzzi Filho 529,CEP 17525-901, Marília, SP
{penteado, edmoreno} @fundanet.br
Abstract  This paper proposes and describes an
architecture that allows the both engineer and
programmer for defining and quantifying which
peripheral of a microcontroller will be important to the
particular project. For each application, it is necessary to
use differents types of peripherals. In this study, we have
verified the possibility for emulating the behavior of
peripheral in specifically CPUs. These CPUs hold a RAM
memory, where code spaces specifically written for them
could represent the behavior of some target peripheral ,
which loaded and executed on it. We believed that the
proposed architecture will provide larger flexibility in the
use of the microcontrollors since this "dedicated
hardware components" don't execute to a special function,
but it is a hardware capable to self adapt to the needs of
each project. This research had as fundament a
comparative study of four current microcontrollers.
Preliminary tests using VHDL and FPGAs was done.
Index Terms  Peripheral, microcontroller, flexibility,
CPUs, VHDL, FPGAs.
1. INTRODUÇÃO
Microcontroladores são chips que estão sendo cada vez
mais utilizados em automação eletrônica. Atuando em
controle de máquinas e em sistemas embarcados,
microcontroladores são requisitados para monitorar e
conduzir o correto fluxo de funcionamento de sistemas
mecânicos conjugados à sistemas eletrônicos.
Um microcontrolador possui características de um
sistema computacional completo em um único chip. São
compostos por uma Unidade Central de Processamento
(CPU) e, em torno desta CPU, alguns módulos chamados
de periféricos, sendo eles: Memória RAM, Memória
EPROM ou EEPROM, Portas de comunicação I/O
selecionáveis por software, Bloco de comunicação como o
SPI (Serial Peripheral Interface), UART (Universal
Synchronous Asynchronous Receiver Transmitter) com
algum protocolo conhecido, Timers, Conversor A/D,
Oscilador interno e outras características que variam de
fabricante a fabricante [1,2,3,4].
Definição do problema: Em diversos projetos, sente-se a
necessidade de que o chip possua uma quantidade maior
de um determinado periférico específico e menor de
outros. Outro grande problema são os periféricos que não
são utilizados no projeto: quando é necessário migrar para
um microcontrolador com mais recursos, muitas vezes se
paga por periféricos que talvez nunca serão utilizados no
projeto - um "hardware dedicado" a uma função que o
projeto talvez nunca executará.
Uma situação comum e problemática é aquela onde é
necessário monitorar e gerar vários sinais simultâneos e
todos os periféricos específicos já estão em utilização. Por
exemplo, quando o chip dispõe de dois periféricos
distintos para geração de pulsos por PWM e a automação
em questão exige quatro ou cinco destes pulsos, uma
solução é migrar para um microcontrolador com mais
periféricos e mais recursos.
De forma similar, sendo necessário o tratamento de
sinais de entrada como, por exemplo, medir o período de
vários pulsos simultâneos e aleatórios, é comum recorrer a
periféricos de captura de sinais. O número de sinais
simultâneos que podem ser capturados também está
diretamente relacionado à quantidade destes periféricos de
captura disponíveis: existindo dois, será possível capturar
dois sinais simultâneos; existindo três, três sinais
simultâneos e assim por diante. O problema surge quando
é necessário a captura de mais sinais e não há outros
periféricos disponíveis.
A motivação para o desenvolvimento deste trabalho
originou-se da possibilidade de emular, com base em
CPUs e programas, o comportamento de alguns
periféricos alvos presente em microcontroladores.
Em um microcontrolador onde o comportamento de
cada periférico é emulado em uma CPU distinta, é
possível adequar as funções de cada CPU às necessidades
da automação em questão. Alterando-se o programa de
cada CPU, pode-se adequar o microcontrolador às
necessidades reais de cada projeto, incluindo, replicando
ou criando novas funções específicas.
2. FLEXIBILIDADE À ARQUITETURA INTERNA
Uma arquitetura interna mais flexível para
microcontroladores pode auxiliar no desenvolvimento do
software de automação, no sentido de permitir que o
programador possa definir, de forma simples, o
comportamento desejado de cada "módulo" periférico.
Também pode existir maior utilização do hardware
interno, pois pode haver a possibilidade de inserir
mudanças radicais das funções de cada módulo,
extinguindo o problema do hardware dedicado.
Assim, a proposta para desenvolver uma arquitetura
flexível, é justamente o desenvolvimento de "módulos"
chamados neste artigo por UPEM (Unidade de
Processamento de Periféricos Específicos para
Microcontroladores) compostos por uma CPU duas
memórias RAM, que permitam emular o comportamento
de alguns dos periféricos mais requisitados em automação.
Em uma memória RAM são carregados programas
diferentes, especificamente escritos para emular o
comportamento de diversos periféricos alvo. A outra
memória RAM é utilizada como memória de trabalho e
registradores endereçáveis.
Para que seja possível a emulação de vários
periféricos simultaneamente, foi necessário replicar os
módulos que contém a UPEM, para que estes operem em
paralelo. Assim, este artigo propõe especificar e projetar
uma CPU específica que emule o comportamento dos
periféricos
mais
usados
e
encontrados
nos
microcontroladores modernos, bem como os programas de
emulação para serem inseridos na memória RAM de
programa de emulação de cada UPEM.
3. JUSTIFICATIVAS
Nos microcontroladores atuais, existe um registrador de
configuração individual para cada periférico, no qual é
definido o comportamento do periférico durante toda a
automação. Para alterar este comportamento, em qualquer
instante, é necessário trocar o valor contido neste
registrador e de outros registradores auxiliares.
Observou-se que esta tarefa exige do programador um
profundo conhecimento da arquitetura interna de um
microcontrolador específico. Na visão dos autores deste
artigo, este é um conhecimento questionável em plena era
dos compiladores de alto nível e perante a vida útil de
cada modelo no mercado.
Uma arquitetura mais flexível pode auxiliar no
desenvolvimento do software de automação, no sentido de
permitir que o programador possa definir, de forma mais
simplificada, o comportamento desejado de cada
periférico. Este comportamento poderá ser emulado e
realizado por unidades de processamento individuais.
Com estas unidades de processamento, acredita-se
que a arquitetura possibilitará maior flexibilidade de
utilização e adequação do hardware interno às
necessidades do projeto em desenvolvimento, pois pode
haver a possibilidade de inserir mudanças radicais das
funções de cada unidade de processamento. Para isto é
somente necessário modificar ou substituir o programa de
emulação de periférico existente em cada memória de
programa destas unidades.
A flexibilidade poderá ser alcançada com a
substituição de alguns periféricos por todo o potencial que
o conjunto CPU, programas e programadores representa.
Atualmente, uma arquitetura flexível que permita ao
programador especificar quais periféricos são relevantes
para um projeto em particular, só é possível com a
utilização de FPGAs. Os FPGAs são dispositivos que
contém uma área interna de “lógica programável”
possibilitando alterações completas em sua arquitetura
interna, assumindo comportamentos diferentes e
oferecendo total flexibilidade. Esta área de “lógica
programável” possui um custo relativamente alto.
Assim, devido ao enfoque de utilização e custo, do
ponto de vista econômico, pode ser inviável utilizar um
dispositivo FPGA para substituir um microcontrolador de
8 bits, em automações onde são tradicionalmente
empregados.
Neste sentido, idealizou-se uma arquitetura que, após
ser descrita em VHDL, possa gerar um ASIC,
(Application Specific Integrator Circuit – circuito
integrado de aplicação específica) similar aos
microcontroladores alvo deste estudo. Para redução de
custo, o possível e idealizado ASIC gerado não possuirá
área de “lógica programável”. A flexibilidade da
arquitetura interna deste ASIC será alcançada com a
utilização de várias unidades de processamento e
programas de emulação de periféricos.
Assim, a proposta para desenvolver uma arquitetura
mais flexível, é justamente o desenvolvimento de
"módulos" compostos por uma CPU reduzida e duas
memórias RAM: uma de programa e outra de trabalho.
Nestes módulos, emular e executar o comportamento de
alguns periféricos de microcontroladores mais usados em
automação.
4. TRABALHOS CORRELATOS
O primeiro trabalho correlato é o projeto CQPIC [5],
onde foi descrita em VHDL uma versão completa da CPU
e periféricos de um microcontrolador, de características e
funcionamento idêntico ao microcontrolador PIC16F84.
O segundo trabalho é o projeto RISC16F84 [6], uma
versão também completa do PIC16F84, escrita em Verilog
e baseada no projeto CQPIC.
Um terceiro trabalho correlato é o PPX16, [7], uma
descrição VHDL completa de um core compatível com os
microcontroladores PIC16C55 e PIC16F84, porém, com
execução de todas as instruções em um único ciclo e,
portanto, quatro vezes mais rápida que os chips originais.
Os dispositivos FPSLIC [8], já disponívies no
mercado, possuem algumas características similares em
relação a arquitetura final proposta neste artigo. Em sua
arquitetura interna, os FPSLIC disponibilizam um
microcontrolador completo (com CPU, memórias RAM,
FLASH e EEPROM e periféricos tradicionais) e uma área
de "lógica programável" equivalente a um dispositivo
FPGA. Assim, combina em um único chip toda a potência
de um microcontrolador com a flexibilidade de um
dispositivo com lógica programável. Não obstante, não
propôs a idéia de executar periféricos em unidades
específicas, somente deixa livre uma área programável em
hardware para inserir quaisquer lógica de interesse na
visão de projetistas.
Na arquitetura final proposta neste artigo, esta área de
lógica programável não existe, sendo a flexibilidade
alcançada através de CPUs, memórias e programas,
especificamente desenvolvidos para emular diversos
periféricos. Acredita-se que esta arquitetura proposta pode
ter, num futuro próximo, um custo final menor que os
dispositivos FPSLIC e FPGAs pois não possuirá área de
lógica programável.
Os trabalhos correlatos apresentados possuem um
enfoque e objetivos diferentes da arquitetura proposta
neste artigo, porém, todos são direcionados a estudos
envolvendo microcontroladores, microprocessadores e
FPGAs.
Existem outros projetos [9] como o T80 e TV80,
compatíveis com os processadores Z80 e 8088, dentre
outros, onde o intuito dos pesquisadores é desenvolver
descrições VHDL ou Verilog, de funcionamento e
características tão próximas quanto possível dos
microcontroladores que estudam.
Apesar de todos os trabalhos correlatos apresentados
focarem microcontroladores implementados e projetados
em FPGAs, diferem da proposta final deste artigo, pois as
arquiteturas desenvolvidas são réplicas exatas de
arquiteturas presente em microcontroladores, não sendo
adicionados novos módulos ou funcionalidades.
Já a proposta final deste artigo provê uma arquitetura
diferenciada, mais flexível e com maior utilização e
adequação de seu hardware interno às características de
cada projeto.
5. METODOLOGIA DE DESENVOLVIMENTO
Objetivando-se levantar quais seriam os periféricos alvo à
serem emulados através das UPEMs, foi realizada uma
detalhada comparação entre quatro microcontroladores do
mercado atual.
Os microcontroladores PIC16F628 [1], da Microchip,
MC68HC908 [2], da Motorola, AT89C51[3], da Atmel e
COP8CCE9 [4], da National, foram escolhidos com base
em: (1) facilidade de obtenção da documentação do
fabricante; (2) disponibilidade de aquisição no mercado
brasileiro; (3) similaridade de arquitetura; (4) quantidade
de portas de E/S equivalente; (5) custo equivalente.
Neste estudo, foram levantados os principais blocos
funcionais de cada microcontrolador, mais relevantes em
automação, as funcionalidades práticas destes blocos e a
possibilidade de reproduzí-las com o auxílio da linguagem
VHDL e dispositivos FPGAs para fins de prototipação.
Na visão do estudo, concluiu-se que os periféricos ou funcionalidades - mais comuns entre os
microcontroladores
estudados
são:
(1)
PWM,
principalmente para controle de motores DC; (2) Captura
de pulsos, para contar eventos em portas de E/S; (3)
Comparação de largura de pulso, para medida de
freqüências; (4) Comunicação com display de caracteres
LCD e; (5) Comunicação serial.
6. EMULANDO PERIFÉRICOS
Uma possibilidade para emular um periférico é substituir
sua funcionalidade por trechos de código executados em
CPUs, de forma similar às instruções presentes no
compilador PICBASIC [10]. Estas instruções, compostas
por algoritmos desenvolvidos e exaustivamente testados
pela equipe da microEngineering Labs [12], que
desenvolve e comercializa o compilador, permitem que a
CPU do microcontrolador PIC emule muitas funções de
periféricos. Algumas destas funções podem ser
visualizadas na tabela 1, que relaciona as instruções do
PICBASIC, sua função e um exemplo de qual seria o
periférico correspondente.
Tabela 1: Instruções do PICBASIC que executam
funções de periféricos
1. PULSIN PORTA.1, 1, VAR
2. COUNT PORTA.1, W
Instrução do 3. SEROUT
PICBASIC 4. PAUSE 1000
5. PWM PORTB.7,127,100
6. PULSOUT 3, 100
1. Mede a largura do pulso
2. Mede a freqüência do pulso
3. Comunicação serial
Função
4. Suspende a execução por 1s
5. Produz um pulso de PWM
6. Produz um pulso à 100Hz, por 3s
Periférico
1. CPP 2. CPP 3. USART 4. TIMER
Equivalente 5. PWM 6. PWM
Para interpretação dos dados da tabela 1, a instrução
PULSIN PORTA.1,1,VAR representa uma função que
mede a largura de um pulso e é realizada pelo periférico
CPP do PIC. Estas instruções, do compilador PICBASIC,
são algoritmos compostos por pequenos trechos assembler
(específico da família PIC) e são executadas integralmente
na CPU do PIC, reproduzindo a funcionalidade do
periférico correspondente à instrução.
Assim, foram pesquisadas alternativas para executar
estas instruções em outro(s) processador(es) de baixo
custo já existente(s) no mercado, ao invés de se utilizar o
próprio microcontrolador PIC.
Porém, para utilizar outro(s) processador(es) é
necessário estudar e compreender seu conjunto e formato
de instruções, modos de endereçamento, número de ciclos
de cada instrução, bem como sua estrutura interna (flags,
pilhas, registradores), objetivando um minucioso
desenvolvimento de pequenas, porém várias, rotinas para
emulação dos periféricos.
Este trabalho minucioso foi desenvolvido pela
microEngineering Labs (específico para a CPU presente
no microcontrolador PIC) e era necessário aproveitá-lo.
Desta forma, idealizou-se um sistema (UPEMs) onde
existe a correspondência direta "um-a-um", do alto nível
(Basic) à execução em hardware.
Projetou-se uma UPEM, capaz de executar instruções
assembler geradas através do compilador PICBASIC. Para
executá-las, o conjunto de instruções da UPEM deve ser
compatível a família PIC16X, de 14 bits.
Para ocupar pouco espaço em chip, é interessante que
uma UPEM seja reduzida em relação ao PIC. Assim,
procurou-se primeiramente os componentes e instruções
que não são necessários e que poderiam ser "retirados" do
PIC, sem prejudicar a execução dos algoritmos do
PICBASIC.
Alguns destes componentes foram: (i) Todo
mecanismo de controle de interrupções e o registrador
INTCON, que às habilita ou não; (ii) Os registradores
PIE1, PIR1 e PCON, que controlam interrupções e reset;
(iii) Prescaler, mecanismo de pull-ups e o registrador
OPTION, que os controla; (iv) Todos os registradores
referentes aos Timers, ao CPP, ao Comparador A/D,
EEPROM e USART; (v) instruções SLEEP e CLRWDT.
Neste sentido, na figura 1 é ilustrada a arquitetura
formada somente pelos registradores e mecanismos
necessários à execução dos algoritmos do PICBASIC.
Na figura 1 destacam-se duas memórias RAM: uma
para armazenar os programas de emulação e outra para ser
utilizada como memória de trabalho. De forma similar ao
PIC, os registradores TRISB e PORTB, juntos, formam as
estruturas de portas de E/S da UPEM.
O registrador STATUS auxilia as operações de ULA,
armazenando os bits de Carry, Zero, Underflow e etc. O
PC é um registrador de oito bits e tem a função de
endereçar a Memória de Programa. O STACK é uma pilha
de até oito níveis para armazenar o endereço de retorno do
PC após uma chamada de rotina.
Com uma primeira versão para arquitetura interna
para uma UPEM, procurou-se desenvolver alguns
programas de emulação de periférico, objetivando agregar
à UPEM, funções e comportamentos idênticos à alguns
periféricos alvo.
Figura 1: Uma UPEM compatível com o PIC
Com a utilização do compilador PICBASIC, foram
desenvolvidos 6 programas de emulação de periféricos,
utilizando-se das instruções listadas na tabela 1 em
conjunto com estruturas de programação - IF THEN
ELSE, WHILE WEND, CASE OF, etc - objetivando
"replicar" a funcionalidade de alguns periféricos alvo.
Dois exemplos destes programas são listados e
comentados nas sessões 4.1 e 4.2
6.1 O PRIMEIRO PROGRAMA DE EMULAÇÃO
O primeiro programa verifica a possibilidade de emular
um periférico de Timer com base na instrução PAUSE do
compilador PICBASIC. Este algoritmo é descrito a seguir:
' ----------------------------------------------' Programa 1: Pisca LED na porta PORTB.2'
' Função: Periférico de Timer
DEFINE NO_CLRWDT 1
'Não insere CLRWDTs
OUTPUT PORTB.2
loop:
PORTB.2 = 1 ' Acende LED
Pause 1000
' Função de Timer
PORTB.2 = 0 ' Apaga LED
Pause 1000
' Função de Timer
GoTo loop
' -----------------------------------------------
Neste programa a PORTB.2 foi definida como saída e
foi conectada a um LED. A instrução PAUSE 1000 faz
com que a execução "espere" em loop (laço) exatamente
1000ms, ou seja 1 segundo. Desta maneira no programa 1,
o LED conectado a PORTB.2 permanece aceso durante 1
segundo e apagado no próximo segundo.
É possível que o programador altere facilmente a base
de tempo deste "Timer emulado", bastando para isto
alterar o valor numérico após a instrução PAUSE. Isto
oferece maior comodidade ao programador, pois, este
ganha tempo e assim desenvolve melhores aplicações.
6.2 O SEGUNDO PROGRAMA DE EMULAÇÃO
O segundo algoritmo foi desenvolvido para testar a
possibilidade de emular um periférico de captura de sinais,
tendo como base a instrução COUNT do PICBASIC. A
instrução COUNT PORTB.1,1000,W conta, durante 1
segundo, quantos pulsos ocorreram na PORTB.1 e retorna
o valor da contagem na variável declarada W.
' ----------------------------------------------'Programa 2: Indica freqüência > 1Khz
'Função: Periférico de Captura
DEFINE NO_CLRWDT 1
Input PORTB.1
Output PORTB.2
W VAR WORD
W = 0
inic: Count PORTB.1,1000,W
IF W > 1000 Then
PORTB.2 = 1
Else
PORTB.2 = 0
EndIF
W = 0
GoTo inic
' -----------------------------------------------
O comportamento deste programa pode também ser
facilmente alterado, trocando-se a porta de origem que a
instrução COUNT monitora, bem como mudar o tempo de
contagem, para medidas mais rápidas. Para alterar o tempo
de contagem, troca-se o valor 1000 por outro desejado,
lembrando que 1000 representa 1000 ms.
7. CONJUNTO ISA PARA CPU DA UPEM
Com os programas de emulação idealizados e escritos, foi
realizado um estudo tendo por base as instruções em
programação de alto nível (BASIC) e o respectivo
assembler resultante que compõem cada instrução e,
consequentemente, todo o programa de emulação.
A figura 2 ilustra o método utilizado neste estudo,
onde pode ser visualizada a tela do software MPLAB[11].
Na figura 2 observa-se um programa exemplo escrito em
basic - com o PICBASIC - e o assembler compatível com
o microcontrolador PIC. O pequeno código basic, no
quadro em destaque à direita na figura 2, emula as ações
de um periférico de PWM.
Um ponto estimulante e positivo para o projeto, foi
quando se concluiu que os códigos assembler gerados para
emular periféricos de PWM, Captura, escrita em LCD,
Timer e Comunicação Serial, ocupam uma área menor que
256 bytes, o que viabiliza carregar os programas de
emulação em uma pequena memória.
Com este estudo foi possível analisar os opcodes
necessários à execução de cada algoritmo e definir um
conjunto ISA para a UPEM.
Figura 2: Opcode a partir do BASIC
Assim, na tabela 2, é ilustrado o conjunto ISA final
da UPEM. O conjunto ISA da CPU presente no
microcontrolador PIC possui 35 instruções. A CPU
proposta utilizou 29 destas instruções.
1
2
3
4
5
6
7
8
Tabela 2: O conjunto ISA da UPEM proposta
addlw 9
call
17
iorwf
25
rrf
addwf 10
clrf
18
movf
26 sublw
andlw 11 comf 19 movlw 27 subwf
andwf 12
decf
20 movwf 28 swapf
bcf
13 decfsz 21
nop
29 xorwf
bsf
14
goto
22
retlw
btfsc 15
incf
23 return
btfss
16 incfsz 24
rlf
Conhecendo-se os trechos assembler de cada
algoritmo de emulação de periféricos alvo do PICBASIC e
com a UPEM descrita em VHDL, implementada e
mapeada em FPGAs, estes códigos poderão ser carregados
nas memórias RAM da respectiva CPU de cada UPEM,
como é ilustrado na figura 3.
Figura 3: Memória RAM com programa de emulação
8. A ARQUITETURA PARA VÁRIAS UPEMS
Na figura 4 é representada a organização idealizada para a
estrutura composta por várias UPEMs em conjunto com
uma CPU de um microcontrolador.
Na figura 4, ressalta-se que os códigos assembler que
simulam periféricos estão carregados na memória RAM
de programa de cada UPEM. Na figura 4, em (A), o
código presente na memória RAM da primeira UPEM faz
com que esta simule as ações de um periférico de PWM.
De forma similar, em (B), o código da memória RAM da
segunda UPEM simula um periférico de captura e em (C),
o código representa um periférico temporizador e assim
por diante para outras possíveis UPEMs.
Replicando-se uma UPEM, bem como suas memórias
RAMs e seus barramentos de dados, será possível emular
quantos periféricos forem necessários e também carregar o
mesmo código de emulação em mais de uma memória
RAM, para que duas ou mais UPEMs possam emular o
mesmo periférico, com parâmetros de funcionamento
(comportamento) idênticos ou não.
O funcionamento idealizado para esta arquitetura com
várias UPEMs, é descrito a seguir:
•
•
•
•
•
•
Os códigos escritos para emulação de periféricos são
carregados nas memórias RAM de programa de cada
UPEM, antes do início da execução do programa
principal;
Cada UPEM inicia seu processamento, executando
seu próprio código de emulação, de forma
independente entre si e da CPU do microcontrolador,
liberando esta para a execução do programa principal
da automação;
A CPU do microcontrolador poderá autorizar ou
suspender o processamento das UPEMs;
A CPU do microcontrolador poderá modificar o
comportamento dos periféricos emulados, trocando o
código presente na memória RAM de programa de
cada UPEM, ou apenas alterando parâmetros deste;
A CPU do microcontrolador poderá ser interrompida
por qualquer UPEM, após um processamento prévio
na própria UPEM indicar a necessidade de alguma
interrupção (este processamento deverá estar incluído
no assembler, o que acarreta modificações nos
algoritmos do PICBASIC).
A execução do programa principal é paralela e
simultânea à execução dos programas nas UPEMs .
ARQUITETURA FINAL PROPOSTA
(A) PWM
UPEM1
PORTAS DE E/S
UPEM2
PORTAS DE E/S
UPEM3
(B) CAPTURA
(C) TEMPORIZAÇÃO
PORTAS DE E/S
Figura 4: Arquitetura final idealizada para várias UPEMs em funcionamento simultâneo
Após validadas, as UPEMs poderão ser adicionada a
um projeto de um microcontrolador existente, pois não
dependem de detalhes de funcionamento da CPU do
microcontrolador – operam de forma autônoma.
A comunicação entre UPEMs (se houver necessidade)
e a CPU do microcontrolador poderá ser realizada por
algum protocolo atualmente existente, considerando que o
volume de dados à serem trocados não requer altas taxas
de transferências.
Para que a arquitetura de uma UPEM venha a se
consolidar e os códigos assembler extraídos dos comandos
do PICBASIC serem utilizados na prática, é necessário
que as UPEMs possuam um conjunto de instruções
totalmente compatível com o PIC.
Também é necessário que as instruções sejam
executadas no mesmo número de ciclos e,
preferencialmente, em tempo equivalente ao que a CPU
do PIC necessita para executá-los (~200ns).
Estes cuidados são imprescindíveis para que não
ocorram distorções nos algoritmos assembler que
compõem cada instrução BASIC.
Assim, não pretende-se modificar estes algoritmos e
sim a descrição VHDL da UPEM até que esta esteja com
o comportamento mais similar quanto for possível em
relação à CPU do PIC.
9. DESCRIÇÃO EM VHDL DA UPEM
Para tornar possível a implementação e testes reais de uma
ou mais UPEMs, é necessário que a UPEMs seja capaz de
ler e interpretar a “lógica” idealizada em cada programa
de emulação escrito em Basic.
Para isto, utilizou-se o ambiente de desenvolvimento
CodeDesigner Lite [12] em conjunto com o compilador
PICBASIC PRO, versão 2.40 [10] e o software hex2vhd
[5], desenvolvido por Sumio Morioka, como parte do
projeto CQPIC. A seqüência utilizada é descrita a seguir:
•
•
•
•
O compilador PICBASIC gera um arquivo
hexadecimal para a configuração do microcontrolador
PIC, a partir do programa fonte no CodeDesigner;
O programa hex2vhd traduz este arquivo para uma
descrição VHDL de uma memória ROM;
É necessário poucas modificações neste VHDL, para
adequá-la às UPEMs e;
Adiciona-se a descrição VHDL desta memória obtida
a um projeto do ambiente de desenvolvimento Xilinx
ISE, juntamente com uma descrição da memória
RAM e da CPU, e obtém-se o arquivo de
configuração do FPGA.
A figura 5 ilustra a forma utilizada neste projeto para
obter-se o arquivo de configuração do FPGA (bit), que
representa e configura o FPGA com uma UPEM que
contém o algoritmo escrito em BASIC, que executará e
realizará a função específica de um periférico.
PICBASICPRO
PICBASICPRO
PROGRAMA
PROGRAMA DE
DE EMULAÇÃO
EMULAÇÃO
ESCRITO
ESCRITO EM
EM BASIC
BASIC
ARQUIVO
ARQUIVO
HEXADECIMAL
HEXADECIMAL
PROGRAMA
PROGRAMA
HEX2VHD
HEX2VHD
MODIFICAÇÕES
MODIFICAÇÕES PARA
PARA
ADEQUAÇÃO
ADEQUAÇÃO
Figura 5: Do programa de emulação ao FPGA
10. RESULTADOS
As UPEMs foram implementadas no FPGA SPARTAN II
2s200eft256-7, com a utilização do software Xilinx ISE
6.1. Os dados de utilização dos recursos do dispositivo são
visualizados tabelas 3, 4 e 5.
Tabela 3: Recursos utilizados do FPGA XC2S200
CPU da UPEM
Recursos
Usado Total % Usada
Nº de Slices
480 2352
(20%)
Nº de Slice Flip Flops
281 4704
(5%)
Nº de 4 Input LUTs
890 4704
(18%)
Nº de bonded IOBs
10
146
(6%)
Nº de GCLKs
1
4
(25%)
Nota-se na tabela 3, que a CPU presente em uma
única UPEM, ocupou 20% dos slices (parâmetro mais
importante para medida ocupação) do FPGA utilizado, o
que possibilita que várias CPUs sejam mapeadas
simultaneamente no mesmo FPGA.
Porém, para validação prática real em FPGAs de
uma UPEM foi necessário descrever e mapear as duas
memórias em conjunto com cada CPU, o que aumentou os
recursos utilizados. A figura 6 ilustra o floorplanning
resultante deste mapeamento
A título de comparação, a tabela 4 ilustra os recursos
utilizados separadamente por cada memória de uma
UPEM. É importante ressaltar que os recursos utilizados
por uma UPEM completa variam de acordo com o
programa de emulação mapeado. Assim, não são listados
dados de ocupação de uma UPEM completa, mas afirmase que uma UPEM completa requer aproximadamente
metade dos slices do FPGA utilizado.
Figura 6: Flooplanning de uma UPEM com CPU e
Memórias RAM e ROM, mapeada no FPGA XC2S200
Figura 7: Flooplanning de duas UPEMs completas
mapeadas no FPGA XC2S200
Tabela 4: Recursos utilizados separadamente
por componentes da UPEM
Tabela 5: Recursos utilizados por duas UPEMs completas
mapeadas no FPGA XC2S200
Recursos do FPGA
XC2S200
Memória RAM
Memórias ROM:
Temporiza 1 s
Indica 1K
Frequencímetro
PWM
LCD
PIC e FPGA
Total disponível
Slices
502 (21%)
36 (1%)
65 (2%)
133 (5%)
65 (2%)
98 (4%)
256 (10%)
2352
Slice Flip
Flops
537 (11%)
4704
4 input
LUTs
928 (19%)
68 (1%)
124 (2%)
243 (5%)
126(2%)
181 (3%)
481 (10%)
4704
Uma alternativa seria utilizar memórias externas, ao
invés de mapeá-las no FPGA. Esta alternativa foi
descartada, pois são memórias específicas (com palavra de
13bits)
e
exclusivamente
projetadas
para
o
microcontrolador PIC. Para manter a compatibilidade
entre a UPEM e o assembler gerado pelo PICBASIC para
o PIC, é necessário manter esta memória com palavra de
13 bits. Cada memória ocupa, individualmente, uma parte
significativa do chip FPGA utilizado. Por este motivo, não
foi possível mapear mais que duas UPEMs completas no
mesmo FPGA.
Foi possível mapear duas UPEMs em um mesmo
FPGA. Em cada memória de programa de cada UPEM foi
mapeado um programa de emulação diferente. Foram
mapeados dois programas de emulação de periféricos:
captura e PWM.
Para este teste prático, foi desenvolvido um código
VHDL que une duas UPEMs em uma única descrição, as
quais funcionaram corretamente no FPGA, de forma
independente e simultânea, indicando a viabilidade de
mapear mais de um programa e mais de uma UPEM em
um mesmo FPGA.
Os dois programas, mapeados simultaneamente,
apresentaram exatamente o mesmo comportamento de
quando mapeados de forma independente.
A figura 7, ilustra a área ocupada por duas UPEMs
completas simultaneamente mapeadas no FPGA. Nota-se
que os recursos do FPGA foram amplamente utilizados. A
tabela 5 resume os recursos utilizados do FPGA.
Recurso
Nº de SLICEs
Nºde GCLKs
Nºde TBUFs
Nº de External GCLKIOBs
Nº de External IOBs
Nº de LOCed External IOBs
Usado
2036
1
16
1
20
20
Total
2352
4
2464
4
142
20
% Usada
86%
25%
1%
25%
14%
100%
Um ambiente de testes práticos foi proposto e
montado para os testes reais das UPEMs e dos programas
de emulação de periféricos. A figura 8 mostra as ligações.
CLOCK 50MHz
GERADOR DE
FUNÇÕES
GND
SAÍDA DE
SINAL
KIT PIC
PIC16F628
GND
PORTB.6
REF. CLOCK 4MHz
REF. CLOCK 4x
P176
P163
P179
D2E
LCD_RS
LCD_RW
LCD_E
D4
D5
D6
D7
P33
P34
P36
P45
P44
P47
P46
DIO2
IRFZ46N
HYPER
TERMINAL
+12V
PWM
M
CH2
COMPUTADOR
PESSOAL
OSCILOSCÓPIO
CH1
Figura 8: Circuito dos testes reais para as UPEMs
Estes testes físicos de implementação em FPGAs
foram realizados no LAS (Laboratório de Arquitetura e
Sistemas) do UNIVEM - Centro Universitário Eurípides, o
qual dispõe de kits de prototipação com FPGAs Virtex,
Spartan II, APEX e FLEX.
A figura 9 ilustra o sistema real composto por (i) um
kit de prototipação, placas DIO2 e D2E, da Digilent; (ii)
um osciloscópio TDS220 da Tektronix; (iii) um gerador
de funções MFG 4205 da Minipa; (iv) um kit LABX3 da
microEngineering Labs e; (v) um pequeno motor DC,
12V, utilizado para verificar fisicamente o correto
funcionamento do algoritmo de emulação de um periférico
gerador de PWM.
Figura 9: Ambiente de testes reais para as UPEMs
Neste ambiente foram testados e comprovados os
seguintes algoritmos desenvolvidos para emulação de
periféricos: (i) um Timer; (ii) uma Captura; (iii) um PWM;
(iv) funções de transmissão e recepção serial e; (v) escrita
em display de caracteres LCD.
Na figura 10 é apresentada uma forma de onda obtida
pelo osciloscópio Este algoritmo de emulação instrui a
UPEM a produzir um pulso de PWM, com TON à 90% e
2kHz. Este algoritmo controlou a velocidade do motor,
comprovando a viabilidade e o funcionamento da
emulação de um periférico de PWM em uma UPEM.
Figura 10: Forma de onda correspondente ao algoritmo
de emulação de um periférico produtor de PWM
11. CONCLUSÕES
Este artigo apresentou e propôs uma arquitetura,
composta de UPEMs específicas para emular o
comportamento de periféricos de microcontroladores. É
proposto um método de programação mais simples, com
base em uma arquitetura mais flexível, ao menos no que
diz respeito a configuração dos periféricos.
Nesta arquitetura, ao invés dos periféricos
tradicionais, existe uma ou mais UPEM(s), composta por
uma CPU, uma memória de programa de emulação e
memória RAM de trabalho, capaz de executar programas
de emulação do comportamento de vários periféricos. Esta
arquitetura permite a escolha de qual periférico será
utilizado em cada automação em particular, bastando para
isto, alterar o programa de emulação presente na UPEM.
Com o objetivo de emular mais de um periférico ao
mesmo tempo uma UPEM foi replicada e, foi possível
mapear duas UPEMs completas em um mesmo FPGA,
XILINX XC2S200.
Finalmente, destaca-se os pontos fortes e fracos da
arquitetura final proposta:
Pontos fortes: (i) as UPEMs podem assumir vários
comportamentos diferentes, podendo substituir vários
periféricos; (ii) programadores não necessitam conhecer
detalhes profundos de configuração de periféricos e; (iii)
uma UPEM poderá ser adaptada em microcontroladores
de diferentes fabricantes e de diferentes arquiteturas.
Pontos fracos: (i) A área final que esta UPEM
ocupou em FPGA; (ii) com a utilização de um Sistema
Operacional Multitarefa para microcontroladores [13],
talvez seja inviável a utilização da arquitetura proposta,
visto que estes sistemas permitem a execução de processos
em paralelo em uma única CPU. Estes sistemas ainda não
estão disponíveis no mercado comercial; (iii) os novos
microcontroladores Java [14,15,16] são capazes de
trocarem de processos em tempo de execução
nativamente. A chegada destes microcontroladores ao
mercado poderá inviabilizar a arquitetura proposta das
UPEMs.
Todos os algoritmos de emulação, funcionaram
corretamente e é possível o desenvolvimento de outros
algoritmos destinados a outros periféricos e
funcionalidades
Acredita-se
que
o
método
de
substituir
funcionalidades de periféricos por trechos de códigos,
além de proporcionar maior flexibilidade de adequação a
cada projeto, oferece ao programador maior comodidade.
Não é necessário conhecer a fundo o funcionamento,
configuração ou detalhes internos de cada periférico.
Basta somente que o programador conheça a sintaxe da
instrução, sua função e formato dos dados de retorno.
Para o desenvolvimento da UPEM e dos algoritmos
de emulação de periféricos, a UPEM foi testada, tanto em
nível de emulação quanto com experimentos reais,
implementada e validada em FPGAs, e espera-se que a
arquitetura apresentada venha a contribuir para a formação
de novas idéias e arquiteturas com enfoque similar.
Algumas alternativas para futuros trabalhos são
apresentadas a seguir:
Em hardware: (i) Desenvolvimento de estruturas internas
de comunicação entre a CPU de algum microcontrolador e
as UPEMs e entre as próprias UPEMs. Esta comunicação
serviria basicamente para que uma UPEM possa autorizar,
modificar
ou
suspender
o
funcionamento
e
comportamento de outras, bem como receber dados da
CPU principal do microcontrolador. As estruturas
poderiam adotar comunicação serial com algum protocolo
conhecido, como o RS232, I2C, dentre outros. O volume
de dados à serem trocados não é alto (somente algumas
strings ou comandos), portanto não há necessidade de alta
taxa de transferência;
(ii) Desenvolvimento de mecanismos de hardware
gerenciadores de acesso às memórias de cada UPEM,
permitindo que a CPU do microcontrolador ou outras
UPEMs sejam capazes de ler ou modificar valores
diretamente nestas memórias, acredita-se que assim será
possível modificar o comportamento de um periférico
emulado, bem como trocar todo o código presente nestas
memórias, alterando radicalmente a função e o
comportamento de uma ou mais UPEM(s) específica(s);
(iii) Estudar e depurar o funcionamento de cada
algoritmo de emulação objetivando-se mapear no FPGA
somente os endereços da memória RAM presente em cada
UPEM, que são essenciais para o correto funcionamento
dos algoritmos; acredita-se que grande parte dos
endereços das memórias de programa mapeadas no FPGA
não são requisitados pelos algoritmos do PICBASIC,
sendo então possível diminuir a significativa área final
ocupada pela memória RAM das UPEMs;
(iv) Estudar qual será o número mínimo de portas de
E/S relevante em cada UPEM (lembrando que cada
UPEM foi descrita com oito portas bidirecionais);
(v) Desenvolvimento de novos algoritmos para
estudar, analisar e emular outros comportamentos de
periféricos ou funcionalidades, utilizando as UPEMs
propostas nesta dissertação, usando a sintaxe do
PicBasicPro ou outros compiladores para outros
microcontroladores;
BASCOM[19] e o CodeWarrior [20], com o intuito de
desenvolver novas UPEMs respeitando o conjunto ISA
destes microcontroladores.
(vi) Projetar e programar um "Ambiente de
Desenvolvimento" (Hardware/Software Codesign) para a
Arquitetura que usa as UPEMs. Assim, seria possível
escrever, descarregar, depurar ou definir, cada código
presente em cada memória de programa de cada UPEM,
bem como o programa principal da automação em
desenvolvimento.
Em software: (i) Estudo de outras combinações de
instruções BASIC, de modo a investigar se é possível
obter maior redução no conjunto ISA proposto na UPEM,
descrita em VHDL e mapeada com sucesso em um FPGA;
(ii) Realizar um trabalho de pesquisa sobre as rotinas
do próprio compilador PicBasicPro objetivando adequálas à um conjunto ISA mais reduzido; acredita-se que este
trabalho exigirá um amplo e avançado estudo, dado que a
equipe de desenvolvimento do PicBasicPro procurou
reduzir ao máximo suas rotinas;
(iii) Estudar e possivelmente reescrever as rotinas
internas do PicBasicPro objetivando desenvolver
programas de emulação de periféricos que utilizem o
mínimo possível da memória RAM das UPEMs,
permitindo que estas sejam fisicamente reduzidas;
(iv) Estudo de instruções de outros compiladores de
alto nível, tais como C++, [17], Pascal e Basic [18],
desenvolvidos para microcontroladores PIC, investigando
código assembler resultante e o possível conjunto ISA,
para outra possível CPU específica para periféricos;
(v) Estudo equivalente com outros compiladores
destinados à outros microcontroladores tais como 8051
[11] MPLAB, Ambiente de desenvolvimento para microcontroladores
PIC, http://www.microchip.com/
12. REFERÊNCIAS
[1]
PIC16F62X FLASH-Based 8-Bit CMOS Microcontrollers
Novembro /1999, www.microchip.com
[2]
MC68HC908JL8 MC68HC908JK8 Technical Data Rev. 2,
Dezembro /2002, www.motorola.com
[3]
Atmel 8-bit Microcontroller with 8K Bytes Flash AT89S8252,
Novembro / 2003, www.atmel.com
[4]
National Semiconductor COP8CBE9/CCE9/CDE9 8-Bit CMOS
Flash Microcontroller Abril / 2002, www.national.com
[5]
Morioka, Sumio, projeto CQPIC, 1999 http://www02.sonet.ne.jp/~morioka/papers.htm
[6]
Clayton, John, risc16f84, (last update 2002),
http://www.opencores.org/cores/risc16f84/
[7]
Wallner, Daniel, PPX16 (last update 2002),
http://members.optushome.com.au/jekent/FPGA.htm
[8]
FPSLIC, ATMEL, www.atmel.com/products/ FPSLIC/
[9]
OPENCORES, Comunidade de códigos IP abertos, nas linguagens
VHDL e VERILOG http://www.opencores.org
[10] PICBASICPro, Compilador Basic para microcontroladores PIC,
http://www.rentron.com/PicBasic/ products/ PICBASIC-PRO.htm
[12] CodeDesigner Lite, microEngineering Labs, Inc.,
http://picbasic.com/resources/win_ide.htm
[13] Farmer , Jerry, A Real-Time Operating System for PICmicro
Microcontrolers, Myriad Development Company,
www.microchip.com
[14] aJile, Real-Time direct execution Processor for Java,
http://www.ajile.com/aj100.htm
[15] Ito, Sergio Akira, Carro, Luigi, Ricardo Jacobi, Pezzuol FemtoJava,
Making Java Work for Microcontroller Applications, , IEEE
Design & Test of Computers 9-10/2001, págs 100-110
[16] Gomes, V. F., Beck, A. C., Carro , L., A VHDL Implementation of
a Low Power Pipelined Java Processor for Embedded Applications.
Publicado no IBERCHIP 2004. Cartagena de Indías, Colombia
[17] CCS, CCS Inc, http://www.ccsinfo.com/news.shtml
[18] MikroBas, MikroPas, MikroElektronika,
http://www.mikroelektronika.co.yu/english/product/compilers/
[19] BASCOM, MCS Electronics, Compilador Basic para
micocontroladores AVR 8051 www.mcselec.com/bascom-avr.htm
[20] CodeWarrior, Metrowerks,
http://www.metrowerks.com/mw/default.htm