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

Instrução do PICBASIC

1. PULSIN PORTA.1, 1, VAR 2. COUNT PORTA.1, W 3. SEROUT 4. PAUSE 1000 5. PWM PORTB.7,127,100 6. PULSOUT 3, 100

Função

1. Mede a largura do pulso 2. Mede a freqüência do pulso 3. Comunicação serial 4. Suspende a execução por 1s 5. Produz um pulso de PWM 6. Produz um pulso à 100Hz, por 3s

Periférico Equivalente

1. CPP 2. CPP 3. USART 4. TIMER 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.

Tabela 2: O conjunto ISA da UPEM proposta 1 addlw 9 call 17 iorwf 25 rrf 2 addwf 10 clrf 18 movf 26 sublw 3 andlw 11 comf 19 movlw 27 subwf 4 andwf 12 decf 20 movwf 28 swapf 5 bcf 13 decfsz 21 nop 29 xorwf 6 bsf 14 goto 22 retlw 7 btfsc 15 incf 23 return 8 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 .

PORTAS DE E/S

PORTAS DE E/S

(B) CAPTURA

(C) TEMPORIZAÇÃO

(A) PWMARQUITETURA FINAL PROPOSTA

UPEM

PORTAS DE E/S

3

UPEM2

UPEM1

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.

ARQUIVOHEXADECIMAL ARQUIVOHEXADECIMAL

PROGRAMA HEX2VHDPROGRAMA HEX2VHD

MODIFICAÇÕES PARA ADEQUAÇÃOMODIFICAÇÕES PARA ADEQUAÇÃO

PICBASICPROPICBASICPROPROGRAMA DE EMULAÇÃO ESCRITO EM BASICPROGRAMA DE EMULAÇÃO ESCRITO EM BASIC

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 afirma-se 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

Tabela 4: Recursos utilizados separadamente por componentes da UPEM

Recursos do FPGA XC2S200 Slices Slice Flip

Flops 4 input LUTs

Memória RAM 502 (21%) 537 (11%) 928 (19%) Memórias ROM: - - - Temporiza 1 s 36 (1%) - 68 (1%) Indica 1K 65 (2%) - 124 (2%) Frequencímetro 133 (5%) - 243 (5%) PWM 65 (2%) - 126(2%) LCD 98 (4%) - 181 (3%) PIC e FPGA 256 (10%) - 481 (10%) Total disponível 2352 4704 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.

Figura 7: Flooplanning de duas UPEMs completas

mapeadas no FPGA XC2S200 Tabela 5: Recursos utilizados por duas UPEMs completas

mapeadas no FPGA XC2S200 Recurso Usado Total % Usada Nº de SLICEs 2036 2352 86% Nºde GCLKs 1 4 25% Nºde TBUFs 16 2464 1% Nº de External GCLKIOBs 1 4 25% Nº de External IOBs 20 142 14% Nº de LOCed External IOBs 20 20 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.

GERADOR DE FUNÇÕES

DIO2

D2E

HYPERTERMINAL

P176

P179P163

M

+12VIRFZ46N

OSCILOSCÓPIOCOMPUTADOR PESSOAL

KIT PIC

PORTB.6

PIC16F628GND

GND SAÍDA DE SINAL

CH1

CH2

CLOCK 50MHz

REF. CLOCK 4MHzREF. CLOCK 4x

P33P34P36P45P44P47P46

LCD_RSLCD_RWLCD_ED4D5D6D7

PWM

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; 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

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.

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.so-net.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

[11] MPLAB, Ambiente de desenvolvimento para microcontroladores PIC, http://www.microchip.com/

[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