Edit Teste do Oliver

Title:

Last edited: 8:18:58 pm on 13 October 2003 by gandalf.merlintec.com

A página *Desenvolvimento do Oliver* conta o que aconteceu depois do fim dos testes.

!!!23 de Junho de 2003
Foram medidas as potências consumidas pelo primeiro protótipo em diversas condições diferentes. Isto foi feito de maneira indireta, observando a queda de tensão no fusível da fonte e sabendo que ele tem uma resistência de 0,7ohm e que a tensão neste ponto é de 18V. O pior caso foi de 0,8W com o backlight acionado, seguido do teste da SDRAM. É possível estimar que o circuito final deve consumir menos que 1W.

!!!19 de Junho de 2003
!!Flash e CPLD - parte 8 (final)
O arquivo video.exo foi regravado na Flash de dois em dois bytes e o circuito da CPLD foi criado. A FPGA continou funcionando mesmo depois de programada a CPLD. Desligando e ligando o aparelho apareceu a imagem prevista na TV (a programação é extremamente rápida quando comparada com a via JTAG, mesmo que o circuito da CPLD apenas envia um byte para a FPGA a cada 3 ciclos de relógio para que possa funcionar com relógios de até 42MHz). Assim,

| Está encerrada a fase de testes do primeiro protótipo

As modificações sugeridas para o segundo protótipo (com as já testadas em vermelho) são:
| | De | Para | Explicação
| furos de fixação | . | alinhar com LCD e fonte | a montagem é possível atualmente, mas fica mais fácil com os furos alinhados
| conector com a fonte | . | alinhar entre as duas placas | a ligação só é possível via cabo. É mais fácil deixar o conector na placa digital bem na beirada como está e mudar a fonte
| pinos nos conectores do LCD e teclado | abertos | terra | já que estão sobrando mesmo, não custa aterrá-los para que fique mais fácil fazer medições ou usar estes conectores para ligar outros circuitos que não LCDs e teclados
| pull up na entrada do leitor de código de barras | . | 560ohm | isto não funciona em aberto
| resistor de proteção do alto falante | 1Kohm | 33ohm | com o valor original o som ficava fraco demais
| resistor da base do transistor de backlight | 1Kohm | 560ohms | o valor exato não importa
| resistor de filtro do som | 3.3Kohm | 5Kohm = 2 de 10Kohm em paralelo | o valor atual funcionou muito bem, mas é o único com este valor no projeto. Resistores de 10Kohms são mais usados
| oscilador | 14.31818MHz | 27.0000MHz, 3.3V | as DLLs da Spartan 2 não operam abaixo de 25MHz. O circuito "manual" de multiplicação de 14 para 28MHz funciona, mas pode ter que ser alterado para operar com diferentes osciladores e além disso ocupa um espaço desnecessariamente. Na verdade, qualquer frequência acima de 25MHz pode ser usada. O oscilador deve funcionar em 3.3V.
| pull up nos pinos /INIT e DONE da CPLD | . | 10Kohm | a CPLD só tem pull ups enquanto não está programada. Estas saídas da FPGA são tipo coletor aberto (para facilitar o projeto com múltiplas FPGAs na mesma placa) e precisam de resistores de pull up
| pull up no pino R/B da Flash | . | 10Kohm | esta saída é tipo coletor aberto
| pino 10 do teclado | p140 da FPGA | p141 da FPGA | no projeto atual não é possível usar a USB e o pino 10 do teclado ao mesmo tempo. O pino 141 é usado para indicar o acesso ao teclado via CPLD, mas uma combinação de /ENABLE e /G poderia fazer isto sem "gastar" um pino
| pino 1 da CPLD | p141 da FPGA | p18 do teclado | com a alteração acima um pino da CPLD também seria liberado e poderia ser usada para a ligação com teclados maiores (80 ao invés de 70 teclas)
| DQ15A-1 da Flash [45] | FPGA [66] e SDRAM [53] | FPGA, SDRAM e CPLD [1] | a FPGA usa esta linha como dados, mas a CPLD precisa dela como endereço e tinha que ser ligada também

!!!18 de Junho de 2003
!!Flash e CPLD - parte 7
Foram estudados outros circuitos com Flash e nenhum deles ligava o pino de RESET diretamente no Vcc. Mas um manual da Fujitsu indicava que esta é uma opção válida. Olhando no resistor o pino RY/BY estava sempre alto (como deveria) e um erro no arquivo de pinagem estava fazendo a FPGA não refletir isto. Um comando mais demorado, "erase chip", mostrou que tudo estava funcionando. O comando direto de leitura de fabricante e modelo também funcionou bem como o reset por software, mas o CFI (justo o que tentamos ontem) realmente não dá resultados. Foram gravadas as duas primeiras palavras da Flash e lidas corretamente e depois a memória foi apagada novamente.

Foi criado um programa no Smalltalk Squeak para ler uma arquivo no formato .exo ("S Records" da Motorola) e copiá-lo para a Flash. Como são necessários 60 caracteres para cada dois bytes gravados, 20KB leva em torno de quatro minutos.

Quando foi criado o programa para a CPLD deu para ver que falta uma ligação: o sinal DQ15A-1 da Flash não funciona como endereço quando ela está no modo 16 bits (como quando a FPGA a está usando) mas no modo 8 bits é quem define qual dos dois bytes de uma palavra aparece em DQ7 a DQ0. Uma maneira de contornar isto é gravar o arquivo de dois em dois bytes (a CPLD só leria os ímpares) mas no circuito final deve ser acrescentada esta ligação.

!!!17 de Junho de 2003
!!Flash e CPLD - parte 6
O circuito de teste da Flash tem um registrador de 20 bits, e ao receber os caracteres 0123456789:;&lt;=&gt;? ele repete o que foi recebido (permitindo a confirmação) e desloca o registrador inserindo de 0 a F nos quatro bits inferiores. Os seguintes caracteres são interpretados como comandos:

| # | copia o registrador para o endereço da Flash
| ( | lê da Flash para o registrador, onde os 4 bits superiores são a paridade dos outros quatro grupos de 4
| ) | escreve os 16 bits inferiores do registrador para a Flash
| $ | envia os 4 bits superiores do registrador codificados como descrito acima. O registrador é deslocado em 4 bits e preenchido com 0.

Qualquer outro caracter é ignorado e um "." é enviado para indicar erro.

O circuito funcionou, mas a leitura sempre devolve 0???? (que é FFFFh) como seria de se esperar de uma Flash toda apagada. Mas o comando CFI (para leitura das características da memória) também retornava sempre este valor.

O pino RY/BY da Flash parecia estar sempre baixo, indicando que ela não estava saindo do estado de inicialização.

!!!16 de Junho de 2003
!!Flash e CPLD - parte 5
Para tentar diminuir a taxa de erros, foi alterada a frequência de amostragem. Os erros ficaram diferentes, mas a quantidade continuou igual. Operando a interface serial a 2400bps não ajudou. Um teste rápido confirmou que o problema era exclusivamente na recepção e que a transmissão estava perfeita. Observando o relógio de amostragem em relação ao sinal de entrada, deu para ver que a fase variava de maneira constante. Um erro de digitação fez com que a amostragem da recepção estivesse igual à amostragem de transmissão. Corrigido isso todos os caracteres enviados passaram a ser recebidos sem erro, mas quando um arquivo inteiro era enviado mais da metade apresentava erro.

O osciloscópio mostrou que no envio de arquivos eram quase sempre enviados dois caracteres seguidos, com um tempo maior entre os pares. Como depois de recebido um caracter, este tinha que ser enviado, o circuito de recepção só voltava a ficar pronto para o próximo depois do início da transmissão. Foi colocado um registrador a mais entre a recepção e transmissão para dar uma folga maior, mas isto não deu resultado. Olhando quando o circuito de recepção começava a esperar o próximo caracter, deu para ver que isto estava demorando muito depois do "stop bit". O limite do contador de bits foi alterado de 10 para 9 e a recepção de arquivos ficou perfeita. Era como se a FPGA estivesse programada para 2 stop bits e o Hyperterminal para 1. Foi alterada a velocidade para 38400bps e tudo continuou a funcionar.

!!!13 de Junho de 2003
!!Flash e CPLD - parte 4
Foi criado um circuito de transmissão serial, que deveria enviar sempre "0" para o PC. O Hyperterminal passou a tomar um tempo enorme do processador tornando os demais programas no PC muito lentos, mas nada aparecia na tela. As formas de onda pareciam razoáveis, mas era bem difícil ver onde terminava um caracter e começava outro. Foi acrescentado um intervalo maior entre caracteres mas sem nenhum resultado. O circuito foi alterado para mudar os quatro bits inferiores ao invés de sempre serem 0000, mas isto não teve efeito. A ordem dos bits estava errada (primeiro deve ser enviado o bit menos significativo) mas corrigir isto não resolveu. Então a velocidade foi reduzida de 38400 para 9600. Como ainda não aparecia nada na tela, a frequência foi medida com o frequencímetro e o resultado foi o valor exato esperado (4800Hz para uma onda quadrada que mudava a cada bit enviado).

O problema é que o Hyperterminal estava com a opção "handshake: hardware" e com isto corrigido (já que não usamos sinais RTS e CTS) apareceram os caracteres 02468:<> repetidas vezes. A velocidade foi aumentada para 38400 outra vez mais ai parou de funcionar, de modo que 9600 foi usado dai em diante.

Foi criado um circuito de recepção serial e ligado ao circuito de transmissão para reenviar ao PC tudo o que fosse recebido. Inicialmente a ordem de recepção estava invertida e quando isto foi corrigido qualquer caracter digitado aparecia repetidas vezes enchendo toda a tela. Um pequeno acrescimo fez cada caracter recebido ser enviado apenas uma vez. Deu para ver que qualquer combinação de bits funciona. Enviado repetidas vezes qualquer caracter deu para ver um erro de em torno de um caracter por 20 recebidos. É mais fácil contornar isto no software do PC. Além disso o circuito de recepção travava de vez em quando. Testes mostraram que ele entra num estado invalido e então um circuito adicional corrigiu esta situação.

!!!12 de Junho de 2003
*+oliver10.jpg+*

Não dá para ver muito bem na foto os 3 resistores de 10Kohm que foram acrescentados à placa. Dois são de montagem de superficie e estão ligados aos pinos da CPLD por fios verdes. Eles estão acima e à direita da CPLD na foto. O terceiro é um resistor convencional ligando a CPLD a um capacitor que se encontra na parte de baixo.

Um símples circuito de teste (ligando os pinos RX e TX entre si) mostrou que o PC, com o conector cinza, está no que chamamos de porta serial 2 do Oliver enquanto o conector preto está na 1. A porta serial do PC funciona bem a 38400bps mas não em velocidades maiores.

!!!11 de Junho de 2003
Foram acrescentadas duas linhas na tabela de modificações no fim da página que serviriam para liberar pinos na FPGA e CPLD para que teclados maiores possam ser usados sem interferência com a USB (atualmente um pino pode ser usado ou pelo teclado ou pela USB mas não pelos dois ao mesmo tempo).

Uma possibilidade interessante seria o uso de circuitos de "mouse" ótico como leitor de código de barras. Estes circuitos são de baixo custo e possuem recursos de leitura de imagens que não são aproveitados quando usados apenas como mouse. Isto não substituiria o atual leitor a não ser em algumas aplicações (principalmente aquelas onde a canaleta não é desejável). Um aparelho assim também poderia servir como uma espécie de "trackball" para movimentar um cursor.

Testamos um oscilador da ABC Xtal de 36MHz para ver se seria uma opção para este primeiro protótipo mas ele não funciona satisfatoriamente em 3.3V, ao contrário do oscilador atual da Interquip. Um oscilador da Fox de 24MHz também foi testado e não foi muito melhor que o da ABC em 3.3V.

!!!10 de Junho de 2003
!!CPLD e Flash - parte 3
Falta mais um resistor de pull up, que deve ser o último. O pino R/B da memória Flash também é uma saída em coletor aberto (para que várias Flashs possam ser ligadas em paralela e o processador espere enquanto qualquer uma delas estiver ocupada).

Nos primeiros testes, a CPLD fornece o pull up necessário por não estar programada ainda. No teste da CPLD, a FPGA deve fornecer o pull up necessário durante o processo de programação (isto não está muito claro no datasheet). O problema só acontece quando a FPGA quer acessar a Flash (principalmente gravar nela) depois de ter sido programada via a própria Flash e CPLD ao invés de via cabo JTAG.

!!!9 de Junho de 2003
Foram feitas as alterações indicadas em vermelho na tabela do fim da página. Todos os testes continuaram funcionando e o som ficou bem mais alto. O backlight continua igual com o novo valor de resistor, como era esperado. Os falantes novos possuem imã exposto, de modo que deve ser tomado cuidado em sua montagem para não haver perigo de desmagnetizar cartões ou disquettes. O falante de uma polegada parece reproduzir som quase tão bem quanto os de duas polegadas num teste com forma de onda em rampa de 110 a 3200Hz.

O indutor da primeira fonte foi trocado por outro de 68&micro;H mas com encapsulamento de plástico. Está esquentando bastante com o backlight sempre ligado mas nem tanto quanto o indutor original.

!!!6 de Junho de 2003
Foi criada a tabela de modificações sugeridas no fim desta página.

!!CPLD e Flash - parte 2
Seria possível liberar um pino na CPLD já que quando o sinal /enable da Flash está inativo, o /g é ignorado. Assim, este poderia ser pulsado para indicar acesso ao teclado no lugar do pino dedicado que é usado agora.

Só que o datasheet do Spartan 2 mostra que não é necessário gerar um relógio de programação de frequência mais baixa. O sinal /cs pode ser usado para controlar quando a FPGA lê um dado da Flash e isto pode ocorrer a cada poucos pulsos do relógio ao invés de em cada pulso.

!!!5 de Junho de 2003
!!CPLD e Flash
A saída do oscilador entra em dois pinos na FPGA: um que foi usado até agora e outro para a programação via memória Flash. Como a Flash é de 70ns, a frequência máxima do relógio de programação deve ser 14,286MHz. O oscilador atual é um pouco mais alto que isso, mas deve funcionar assim mesmo. Para usar uma frequência mais alta, como os 27MHz sugeridos ontem, seria necessário modificar o circuito para que o relógio de programação viesse da CPLD (que, infelizmente, não tem nenhum pino sobrando).

Outro problema encontrado foi o fato dos sinais PROG, INIT e DONE serem do tipo "coletor aberto". Eles precisariam de resistores de "pull up", mas estes não foram incluídos na placa. Os esquemas da placa Xess não indicam estes resistores (apesar de indicarem outros) a não ser o mais detalhado, de modo que a impressão de que esta placa não os usava estava errada. No Oliver é possível fazer com que PROG seja uma saída da CPLD ao invés de entrada como é normalmente. Ai não só seria dispensável o resistor, mas seria possível implementar uma função de "watchdog" que reiniciaria tudo desde a programação da FPGA e "boot" do processador toda vez que este deixasse de acessar o teclado por um certo tempo (e o software seria escrito para que isto nunca acontecesse em condições normais).

Uma alternativa para o INIT e DONE seria gerar um pequeno pulso de 3,3V logo antes de ler estes sinais na CPLD. Se a FPGA os estiver puxando para baixo, a leitura será 0, caso contrário 1. Se a FPGA estiver aterrando os sinais, haverá um breve curto. Em princípio as saídas da FPGA e CPLD aguentam isto sem problemas, mas é melhor verificar bem antes de tentar a experiência. No caso do DONE, é possível adivinhar quando a FPGA deixará de aterrá-lo pois isto ocorrerá logo depois de enviado o último byte - quando a contagem atingir um valor conhecido. Assim não seria necessário gerar os pulsos nesta linha antes disso. Com o INIT seria possível esperar um tempo bem acima do que a FPGA normalmente leva para limpar sua memória, mas isto tornaria a inicialização do aparelho mais lenta do que o necessário.

!!!4 de Junho de 2003
!!Portas Seriais - parte 2
O PC e a estação Sun já haviam se comunidado usando os programas Hyperterminal e TIP respectivamente. Não deu certo tentar substituir o tip por algo em Self na Sun pois ele não consegue nem abrir o arquivo. A troca do Hyperterminal pelo Squeak do lado do PC funcionou sem problemas, o que era de se esperar já que ele tem um "plug-in" só para cuidar das portas seriais. Assim, foi possível transmitir informações geradas por programas, o que será necessário no teste da Flash.

!!SDRAM - parte 3 (final)
O relógio continuou com problemas e não foi possível colocar "buffers" em todos os sinais críticos pois a FPGA tem um número bem limitado deles. Depois de muitas tentativas, foi criado um circuito para aumentar a largura dos pulsos do multiplicador por 2 usado para gerar o 28MHz. Mas o relógio da SDRAM continuou sendo 3x 14MHz e não 4x como deveria ser. Se fosse criado de propósito um circuito para multiplicar por 3 aposto que nunca funcionaria! O culpado da confusão toda é o oscilador que gera uma onda em que o período baixo é 25% mais comprido do que o alto. A solução foi criar todo um estágio adicional para tornar o relógio de entrada quadrado antes de mais nada, e ai a multiplicação por 2x, 4x e 8x (e finalmente uma divisão por 2 para gerar 57MHz "limpo") funcionou de maneira satisfatória. Mas talvez com outro oscilador seja necessário um circuito um pouco diferente. Melhor trocar o oscilador por um de 27MHz.

O circuito de teste de memória estava sempre na fase de inicialização. Os seus dois circuitos de relógio não estavam indicando que obtiveram uma sincronização satisfatória. Atrasando o "reset" para esperar um tempo depois da sincronização dos multiplicadores mencionados acima, o teste passou a funcionar. Ele está indicando que a memória está funcionando corretamente a 57MHz. Foram observados alguns sinais internos da controladora de SDRAM para verificar se realmente ela está operando, e tudo está como o esperado ("refresh" a cada 30&micro;s, leituras na segunda fase do teste e escritas na primeira, e assim por diante).

!!!3 de Junho de 2003
!!SDRAM - parte 2
O erro que o Webpack estava reclamando era uma biblioteca usada no arquivo principal que é incompatível com a usada nos sub-componentes. Cada uma definia o tipo UNSIGNED de uma maneira um pouco diferente.

O circuito de relógio não está funcionando. Várias alterações foram feitas sem resultado.

!!!2 de Junho de 2003
!!Saída de Som (final)
Foi implementado o circuito do "Application Note 154" da Xilinx usando o relógio de 115MHz e um contador para gerar uma forma de onda tipo rampa de aproximadamente 440Hz. Surpreendentemente, foi possível ouvir algo apesar do resistor de proteção de 1Kohms. Encostando em paralelo um resistor de 68ohms (o menor disponível no momento) o volume ficou bem razoável. Isto indica que mesmo com a fonte de 5V e o alto falante de 8ohms, basta trocar o resistor de proteção por um de 33ohms e tomar cuidado no posicionamento do falante dentro do gabinete para que a saída de som seja audível na aplicação final.

No lugar da rampa, entretanto, o osciloscópio mostrou uma senóide quebrada. A tentativa de gerar uma onda quadrada também mostrou uma senóide quebrada de forma um pouco diferente. Com uma rampa de apenas quatro degraus e olhando os pulsos não filtrados com a outra ponta de prova tudo parecia certo. Voltando à rampa original continou certo e não o que tinha aparecido inicialmente. Está claro que é preciso não levar muito a sério o que o osciloscópio mostra pois os sinais sofrem muita interferências que não existem na realidade. Mudando o circuito para gerar uma rampa de 110Hz e depois outra de 880Hz deu para perceber que a faixa de reprodução do circuito e alto falante é aceitável para uma solução de baixo custo como esta.

!!SDRAM
Foi copiado o circuito de teste usado na placa da Xess e alterado para usar o relógio de 57MHz e para indicar o resultado num único pino a ser monitorado pelo osciloscópio. Infelizmente o WebPACK reclamou de incompatibilidade de sinais entre os vários subcomponentes. Como isto estava funcionando no projeto original, é preciso descobrir o que mudou na cópia.

!!!30 de maio de 2003
!!Leitor de Código de Barras - parte 4 (final)
O José disse que testou um leitor com um "pull up" de 220ohms (para dar 20mA em 5V) e que estava funcionando. Trocando o resistor no protoboard passou a haver atividade quando se passa um papel com barras pretas. Só que parece que a saída vai para 1 quando tem uma alteração na entrada e não para indicar preto. Ligando o leitor no Oliver e observando na TV a imagem correspondente a uma sequência de barras, parece que teremos que integrar o sinal do leitor.

Isto não deu certo. Aumentando a taxa de amostragem e passando o papel mais rapidamente pareceu dar resultados melhores. Só que a imagem atravessava a tela rápido demais para que se pudesse realmente ver o que estava acontecendo. Então a memória foi aumentada (para caber no Spartan II 15 o circuito foi re-escrito para usar uma memória de verdade ao invés de um registrador de deslocamento) para 512 bits e a taxa de amostragem ficou em 240 por segundo no lugar de 60 originalmente. O código de teste:

*+oliver8.jpg+*

ficou bem parecido na tela, apesar da foto abaixo não dar esta impressão:

*+oliver9.jpg+*

A conclusão é que o leitor indica diretamente a cor vista quando existem alterações rápidas, mas apenas a transição de branco para preto quando as alterações são lentas. Assim, existe uma velocidade mínima de passagem do código de barras para que a leitura possa ser feita corretamente.

!!!29 de maio de 2003
!!Leitor de Código de Barras - parte 3
Foi montado no protoboard um circuito só para alimentar o leitor de código de barras e colocar um resistor de "pull up" de 10Kohms na saída. Olhando com o multímetro e osciloscópio deu para ver que a saída fica sempre em zero, não importa se a peça está próxima de um papel branco ou preto (ou longe de qualquer papel, que deveria ser a mesma coisa que preto).

!!Portas Seriais
O novo projeto se chama teste04memorias pois vai incluir as seriais, o som e as memórias Flash e SDRAM. A primeira providência foi tentar melhorar o relógio de 57MHz. Mesmo o vídeo tendo funcionado daquela maneira, poderia causar problemas para a SDRAM ou para o futuro processador. A idéia era multiplicar por 2 mais uma vez para se obter 115MHz e daí dividir isto por 2 para obter um 57MHz mais "limpo". Deu certo, mas não foi fácil ter certeza disso num osciloscópio de 100MHz.

O primeiro teste das seriais foi simplesmente ligar a entrada 1 na saída 2 e a entrada 2 na saída 1. Uma porta foi ligada ao PC de desenvolvimento e a outra na estação Sun. No PC foi fácil usar o Hyperterminal para acessar a porta serial mas na Sun vai dar mais trabalho. Infelizmente mostrando as entradas no osciloscópio dava para ver que não acontecia nada quando era apertada uma tecla no Hyperterminal. Olhando os pinos da MAX232 apareciam umas tensões que não faziam sentido. O circuito foi modificado para gerar umas ondas quadradas nas saídas e apareceram direitinho nas saídas da MAX. Desligando um conector de cada vez e observando as entradas deu para ver que a serial 1 está no PC e a 2 na Sun. Surpreendentemente, ligando os conectores outra vez apareceram os sinais corretos e não o que estava lá antes.

O Hyperterminal não estava causando nenhum efeito, então a velocidade foi baixada de 9600 para 110 bps para ficar mais fácil ver algo. Só quando o programa foi reconfigurado da COM1 para a COM2 é que deu para observar caracteres sendo transmitidos. A serial 2 foi desligada da Sun e ligada ao laptop 386 (usado como terminal no projeto do bloqueador) e foi possível, reconfigurando o Hyperterminal para 2400 bps, trocar mensagens entre os dois PCs.

!!!28 de maio de 2003
!!Saída de Vídeo - parte 5 (final)
Como a frequência era mais próxima do PAL-M do que o NTSC, o circuito foi modificado para ter a alternancia de fase deste primeiro sistema. Infelizmente a imagem continuou igual.

Olhando o projeto de codificador de vídeo em *http://www.opencores.org* deu para ver que um simples contador de 32 bits é suficiente para gerar as várias frequências de cor dos diversos sistemas de vídeo ao redor do mundo. A mesma técnica pode ser usada para corrigir o erro do oscilador e isto foi feito. Foi eliminada a alternancia de fase e apareceu amarelo na imagem. Variando verticalmente a tonalidade e saturação e horizontalmente o brilho podemos ver todas as cores que o Oliver é capaz de gerar:

*+oliver7a.jpg+*

!!Leitor de Código de Barras - parte 2
Foi invertido o cabo do leitor de código de barras sem nenhum efeito. Olhando o manual com o OpenOffice ao invés do Kword deu para ver o desenho da plaquinha, o que indica que a pinagem estava correta originalmente. Infelizmente não está funcionando.

!!!27 de maio de 2003
A fonte com o indutor de 68&micro;H funcionou muito bem. Mesmo com o back light ligado não deu para perceber um aquecimento após alguns minutos de operação. Os próximos testes continuarão com esta fonte.

!!Saída de Vídeo - parte 4
O frequencímetro não dá resultados para alta frequência, mas gerando uma onda quadrada de 3,58MHz e usando a ponta de prova do osciloscópio ele indicou um erro de 5025Hz (1,3%) na referência de cor, o que é muito maior do que o permitido pela especificação NTSC. A tentativa de medir outro oscilador para se ter uma idéia da variação de um para outro não deu certo já que o frequencímetro está funcionando a 14MHz. Mas em princípio, com este oscilador a imagem vai ser preto-e-branco mesmo. Não compensa gastar mais com um de maior qualidade já que os clientes não vão usar a saída de TV e a maioria das TVs no Brasil são PAL-M (ou seja - pegaria p/b de qualquer maneira).

O acrescimo do sincronismo vertical funcionou muito bem, mesmo sem os pulsos de equalização que seriam necessários teoricamente.

*+oliver6a.jpg+*

!!Leitor de Código de Barras
Uma faixa horizontal foi colocada no vídeo para mostrar o que está vindo pelo pino do leitor de código de barras. Parece que a pinagem do aparelho não bate com a que foi adotada na placa do Oliver. A imagem acima mostra o resultado de rápidos toques com um dedo ligando o pino 2 (sinal) ao pino 4 (terra). O leitor em si não funcionou, indicando sempre zero. A faixa mais clara no meio da tela não existe na verdade, mas é um efeito da câmera. As bordas das "barras" são outro "defeito especial" causado pelo movimento das mesmas da direita para esquerda.

!!!26 de maio de 2003

!!Saída de Vídeo - parte 3
Finalmente temos 57MHz. O problema é que os circuitos de DLL da Spartan não podem ser usados abaixo de 25MHz. Assim, o primeiro duplicador de frequência não podia usar este circuito. Uma alternativa com um circuito de ou-exclusivo e um flip-flop deu o seguinte resultado estranho:

*+oliver5a.jpg+*

A onda de baixo é o 57MHz, mas cada quatro pulsos estão "grudados". Uma senóide de 3,58MHz pode ser vista na parte de cima - ele tem um ruído enorme de alta frequência mas este não entraria na TV já que esta tem um filtro passa baixa de 6MHz.

O problema dos DLLs explicam o não funcionamento do circuito de teste da SDRAM na placa de desenvolvimento Xess em 14MHz.

!!!23 de maio de 2003
Visita do José e Rosângela - eles trouxeram um cabo mais comprido para ligar a porta paralela à placa JTAG, o que permitiu virar o protótipo para que o teclado e LCD ficassem numa posição mais natural para quem está no computador ao lado. Também fizeram uma segunda placa de fonte com um indutor de 68&micro;H ao invés do de 330&micro;H da fonte original. Deixei para testar a nova fonte depois que terminar os testes da placa digital.

!!Saída de Vídeo - parte 2
Foram geradas algumas variações de senoides com amplitudes e fases diferentes, que são sinais típicos de vídeo colorido. A tentativa de mudar a base de tempo de 14 para 57MHz não deu certo - no lugar de 28MHz a primeira DLL estava gerando pulsos estreitos de 14MHz e a segunda DLL estava com uma saída constante. O contador continuou funcionando como antes, o que não faz sentido. Substituindo a senoide por uma onda quadrada de 3.58MHz, a seguinte forma de onda se tornou possível:

*+oliver4a.jpg+*

Não existe sincronísmo vertical aqui, mas como todas as linhas são exatamente iguais por enquanto isto não faz falta. Infelizmente a imagem que está aparecendo na TV não tem cores:

*+oliver003.jpg+*

O "color burst" parece bem razoável, mesmo com uma onda quadrada no lugar da senoide desejada. Aumentando ao máximo a saturação, uma das barras parecia ficar um pouco esverdeada. Mas eliminando o color burst não fez diferença, de modo que este efeito não indica nada. Esta televisão mostrou imagens coloridas ao ser ligada ao TI99/4A que tem saída NTSC, mas é melhor confirmar que este não é o problema testando com um conversor NTSC=&gt;PAL/M.

!!!22 de maio de 2003

!!LCD - parte 5 (final)
O circuito de ontem foi modificado para indicar a linha e a coluna realmente. O grande trabalho foi fazer com que o VHDL amostrasse os sinais nos instantes corretos. Os códigos mostrados vão de "B1" para o canto superior esquerdo a "E5" para o inferior direito. Não existe coluna "A" neste teclado. A tecla "E5" agora acende o backlight do LCD e qualquer outra tela apaga.

!!!21 de maio de 2003

!!LCD - parte 4
Apesar do circuito do LCD já ter funcionado, foi acrescentado um teste do teclado também. Primeiro foi feita a tentativa de se escrever "A1&star;" repetidamente numa posição no meio da tela. Só que apareceram diversos "A" espalhados pelo LCD. Várias coisas foram tentadas mas a conclusão foi que não havia nada de errado a não ser o fato de o cristal líquido não indicar corretamente o seu status de ocupado enquanto ele altera o cursor. Colocando um atraso de 4 ms entre deslocar o cursor para a terceira linha e enviar o "A" resolveu o problema.

O "1" do "A1&star;" foi substituído pelo que era lido do teclado (e os sinais que estavam sendo enviados para os pinos do teclado para serem observados no osciloscópio foram eliminados). O resultado foi muito estranho - pressionando quase qualquer tecla alterava o caracter mas este não voltava ao valor anterior ao se soltar a tecla. Como não tem nenhum "pull up" nas linhas, elas estavam servindo de memória. As colunas foram mudadas de entradas símples para bidirecionais e foram colocadas em "1" logo antes de leitura para ter um valor garantido. As primeiras tentativas de se escrever isto em VHDL deixaram o software da Xilinx bem maluco, mas fazendo de outra maneira deu o resultado esperado: aparecia "A?&star;" sem nenhuma tecla apertada e "A>&star;", "A/&star;", "A;&star;", "A7&star;" e "A=&star;" conforme eram apertadas teclas da segunda coluna. Depois o circuito foi alterado para testar as demais colunas (a coluna 0 não é usada neste teclado). A ordem das linhas é um pouco estranha devido ao layout da Fourth: 5, 4, 1, 2 e 3 de alto para baixo.

O próximo passo é varrer todas as teclas e indicar o número da linha no lugar do "1", o número da coluna no lugar do "A" e usar o "&star;" para indicar se alguma tecla está sendo pressionada no momento ou não. Se mais de uma tecla for pressionada ao mesmo tempo, apenas a última na ordem da varredura será registrada.

!!Saída de Vídeo

Foi criado um projeto teste03video com um circuito muito símples para gerar uma onda dente de serra na saída de vídeo. De fato, apareceu uma onda de 3,3V pico a pico e de uns 900KHz. Infelizmente o "degrau" de 7 (0111) para 8 (1000) ficou um pouco menor do que os demais, o que indica que o 2R está um pouco diferente dos demais. Mas isto não deve ter um efeito visível na imagem gerada. Com uma carga de 68ohms a onda passou para 1,5V pico a pico. O dente de serra foi trocado por uma senoide com o uso de uma tabela, mas a fórmula usada [8+8&star;seno(360&star;x/16)] não está boa e gerou uma senoide muito saturada.

!!!20 de maio de 2003

!!LCD - parte 3
A implementação das linhas de dados bidirecionais estava errada, de modo que a verificação do status do LCD não funcionava. Resolvido isso, o circuito passava a esperar eternamente o sinal de ocupado do LCD ir para 0 apesar do osciloscópio mostrar que estava em 0 quase o tempo todo. Este "quase" era a chave do problema: a linha estava sendo amostrada no instante errado, justamente quando havia um curto pulso para 1. Com isto resolvido o teste foi encerrado com o Oliver escrevendo sua primeira palavra:

*+oliver002.jpg+*

!!!19 de maio de 2003

!!LCD - parte 2
O grande problema do circuito original é que a transferência da informação de "command" para "ack" era feita durante um tempo longo demais. Restringindo esta transferência a um único instante surgiram as formas de onda desejadas. Mas ainda não aparece nada no LCD. Parece ser algum problema de inicialização. Logo que o aparelho é ligado, mexendo-se com o contraste dá para ver duas linhas de blocos cinza na tela. Depois da tentativa de inicialização ficam quatro linhas, o que está certo. Mas não aparece o cursor e nem os caracteres enviados.

O que facilitou bastante a depuração do erro do dia 16 foi o uso de uma segunda ponta de prova no osciloscópio. Esta não está muito boa: divide a amplitude do sinal por 10 e distorce muito sinais de baixa frequência. Mas é melhor do que nada.

!!!16 de maio de 2003
Normalmente a programação do FPGA não dá nenhum problema desde que se lembre de saír do programa Impact da Xilinx e entrar outra vez antes de cada tentativa. Quando isto não ocorre e o programa não mais consegue acertar a FPGA, o jeito é desligar e religar a máquina.

Deu para notar que a fonte esquenta bastante quando o backlight do LCD está ligada. O indutor é o maior problem e talvez não aguente operar durante muito tempo nestas condições(é conveniente colocar um indutor com maior capacidade de corrente - tipo dos usados nas fontes chaveadas).

!!LCD
Foi criado um projeto chamado teste02lcd. O circuito inicial fazia aparecerem o mesmo caracter alternado com um espaço e ocupando apenas duas linhas. Não era isso que era para acontecer. Todos os sinais do LCD (principalmente o "enable") vistos no osciloscópio parecem estar com a forma de onda desejada. Alterando o circuito para no final ficar sempre enviando o mesmo caracter, dava para ver que está tudo em ordem mas mesmo assim aparecia "U" no lugar de "r". Algumas tentativas de enviar outros caracteres deram resultados igualmente estranhos, ainda mais por aparecerem caracteres japoneses.

Parte do problema poderia ser que o LCD tivesse entrando no modo de 4 bits por alguma razão. A inicialização não estava muito parecida com a descrita no manual, de modo que o circuito foi totalmente refeito e foram introduzidos atrasos de 4ms. Agora não aparece nada, mas a sequência de comandos está correta enquanto que antes não estava. Dá para ver que tem algum erro no circuito que faz com que os comandos pares sejam ignorados.

!!!14 de maio de 2003

!!Oscilador e BackLight do LCD
Foi criado um novo projeto no software WebPack chamado teste01oscilador. Um esquema mostra o sinal do 14MHz ligado a um contador de 16 bits cujas saídas "mais lentas" foram ligadas aos 10 pinos do teclado. Como todos estes pinos foram configurados como saídas, o teclado foi desligado para evitar curtos.

O projeto compilou direitinho e foi carregado com sucesso na FPGA. Mas nada apareceu nas saídas.

Foi acrescentado uma saída (sempre 1) para o controle do back light to cristal líquido. Isto deveria acendê-lo (e não 0 como indicado nas notas do esquema). Mas o Impact não conseguia mais achar o cabo JTAG. Várias coisas foram tentadas mas no fim o problem é que tinha outra cópia do software rodando ao mesmo tempo (com a janela escondida atrás das outras). Resolvido isso o LCD ficou bem brilhante. Apagando as luzes deu para ver que vai funcionar muito bem na prática.

Na alteração do esquema para o backlight ficar em 0 (desligado), deu para notar que o "clear" do contador estava em 1 e por isso ele estava sempre parado em 0. Mudando isso apareceram as ondas quadradas desejadas nos pinos 1 a 10 do conector do teclado. Estas ligações estão corretas, então, e o oscilador de 14MHz está funcionando muito bem (não é possível observá-lo diretamente).

!!!13 de maio de 2003
Chegada do primeiro protótipo do Oliver em São Carlos:

*+oliver001.jpg+*

!!Fonte
A fonte foi testada sem carga e as tensões ficaram próximas das previstas. Quando foi colocada a carga (a placa do processador), as tensões geradas pelos transistores caiu cerca de 0,4V.

Calculamos que a corrente na carga era da ordem de 5mA, mas o projeto deveria poder trabalhar com 300mA ou mais. Com resistores de polarização 100 vezes menores, a variação caiu para um nível aceitável. A dissipação de calor nos resistores aumentou 100 vezes, é claro, mas ainda é bem menor do que nos transistores. Os resistores foram recalculados para que a tensão seja maior que a nominal sem carga e próxima da nominal a 300mA.

!!Cabo JTAG
O software Impact da Xilinx reconheceu o cabo feito na RZ e achou a CPLD XC9536 e a FPGA XC2S50 do Oliver.

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: