quinta-feira, 18 de julho de 2013

Problemas de precisão no CNC Portátil



Olá,

Eu criei o programa acima para me auxiliar nos testes com o meu cnc portátil. Tenho realizado alguns testes mas continuo com o problema de falta de precisão. Creio que estou perdendo passos ao iniciar o movimento do motor e ao parar.

Porquê? Eis a questão.

Eu de inicio acreditei que era um problema lógico. Alguma coisa no firmware dos controladores dos motores de passo. Repassei várias vezes o código do firmware e não detectei nada de anormal. Depois eu pensei que pudesse ser um problema mecânico. Já lubrifiquei tudo para diminuir o atrito e o problema persiste. Agora eu estou acreditando que o problema é a inércia.

Eu outro dia vi um vídeo no Youtube aonde uma pessoa estava segurando um motor que estava sendo controlado pelo software linuxCNC. E no vídeo pude perceber que ao iniciar o movimento o motor sofre uma aceleração progressiva e antes de concluir o movimento o motor sofre uma desaceleração progressiva. Isto me deixou pensando. E agora eu percebo que talvez o software linuxCNC movimente o motor dessa forma para diminuir o efeito da inércia sobre a parte mecânica do sistema.

O meu CNC portátil salta do 0 para a velocidade final instantâneamente e talvez isto provoca alguma perda de passos devido a inércia. Eu já fiz um teste com o CNC portátil do jeito que está mas com a velocidade de operação do motor bem mais baixa e o problema persiste apesar de eu estar com a impressão de que o problema melhorou um pouco.

Nos próximos dias vou aprontar uma nova versão do firmware com o objetivo de incluir o recurso da aceleração e desaceleração progressiva e ai eu posto o resultado aqui no blog.

Um abraço,

José Paulo

segunda-feira, 15 de julho de 2013

Atualização do projeto de emulador de interface de disquete (#2)




Olá,
Conforme vocês podem ver na foto acima eu comecei a testar o conceito do projeto. Eu já tinha um eeprom gravada com a Bios da interface CDX-2 e agora eu criei a lógica no CPLD para atender ao projeto conforme está no diagrama do sistema enviado no outro e-mail. Uma coisa que eu já desconfiava e agora tenho certeza é que não será necessário usar o EPM3064, posso o usar o EPM3032 sem problemas. A parte lógica está usando apenas 13 macrocélulas o que dá para expandir o design mesmo usando o EPM3032 que é bem barato (U$ 2,50 no ebay). O projeto criado no Quartus WEB está num arquivo compactado dentro da minha pasta pública do dropbox. O link segue abaixo:

https://dl.dropboxusercontent.com/u/62498964/CPLD.zip
 

Eu criei um programinha basic (ver foto acima) com a finalidade de constantemente estar gerando gerando requisições de IO para o endereço D0 e desta forma testar o CPLD observando as formas de onda no meu osciloscópio. Na foto dá pra ver também que a eeprom está funcionando conforme o esperado e a Bios do CDX-2 está ativa e funcionando bem.
De cara posso garantir que a parte que decodifica o endereço está funcionando perfeitamente. Abaixo tem uma tabela que demonstra a parte de decodificação.


O objetivo desta decodificação de endereços é acionar no PIC um "Interrupt-On-Change" quando os endereços do IO corretos estiverem presentes no barramento do MSX. Os pinos de seleção serão ligados aos pinos RB4, RB5, RB6 e RB7 do PIC que possuem o recurso de "interrupção com a mudança". Ou seja, caso o estado lógico destes pinos se altere é gerado uma interrupção. Nos PIC18F há dois vetores de interrupção, um de alta prioridade e outro de baixa prioridade. Eu pretendo usar o vetor de alta prioridade para atender às requisições de barramento do MSX. Além disto este vetor de interrupção será escrito em assembler (provavelmente a única parte do programa escrita em assembler) não só para acelerar o atendimento às requisições do barramento como para controlar exatamente a temporização da rotina. O que é difícil de alcançar com uma rotina escrita em C.

O problema agora surgiu na hora de introduzir wait states. Eu criei três pinos no CPLD que selecionam a quantidade de wait states que serão introduzidos caso seja recebida uma requisição de IO válida. O objetivo dos wait states é garantir que o PIC vai ter tempo suficiente para ler e/ou escrever no barramento de dados. Eu não quero criar um número fixo de wait states por dois motivos: 1) Eu não sei se o PIC será ou não capaz de atender às solicitações do barramento sem ciclos de espera (se for possível melhor, mas só vou saber após eu começar a escrever o código para o PIC) e 2) eu não sei se o PIC será capaz de atender as solicitações do barramento em máquinas mais velozes como o Turbo-R (provavelmente não). Por estes motivos é que eu achei importante ter uma forma de introduzir ciclos de espera configuráveis.


Acima tem uma tela do meu osciloscópio. A linha amarela é o IORQ e a linha azul é o sinal de clock. O sinal de clock do barramento é usado para cronometrar o tempo total do sinal de wait state. Na imagem acima o meu programinha basic não está rodando e portanto o osciloscópio está captando outras requisições de IO que o sistema do MSX tem que fazer regularmente. As formas de onda estão ruidosas assim porque estou medindo o sinal que vem de um flat cabe com uns 40 cm de comprimento e na ponta do conector há fios que extendem ainda mais esta distância e isto tudo para plugar num protoboard. Ou seja, tem que ter ruído mesmo. Mas a eeprom está funcionando no protoboard e a parte de decodificação parece estar funcionando bem.




Na imagem acima o programinha basic está rodando e curiosamente o tempo de ativação do IORQ aumentou mas eu posso garantir que não estou introduzindo wait states. E é ai o problema, mesmo que eu introduza wait states o sinal de IORQ não se estende conforme seria o  esperado. Veja a imagem abaixo.


A linha azul agora é o sinal de wait state e no caso estou introduzindo apenas um ciclo de wait state e eu não sei porque o Z80 não está alongando o tempo do IORQ. A temporização está igual ao datasheet do Z80 com o wait state sendo introduzido após o T3 e mesmo assim o processador parece não estar amostrando a linha de wait. Provavelmente eu vou mudar a lógica do CPLD para que a linha de wait desça junto com o IORQ para ver se o tempo se estende ou não.

Um abraço,

José Paulo

terça-feira, 9 de julho de 2013

Atualização do projeto do emulador de interface para o MSX

Boa Noite,

Acima está um diagrama geral atualizado do sistema que irá compor o emulador de interface de disquete. Abaixo vou explicar melhor o que cada seção fará.

Componentes Selecionados para o Projeto:
================================

1) MCU PIC18F4550
Vantagens:
- Eu já tenho o componente;
- Grande quantidade de pinos disponíveis;
- Opera em 5V (compatível com o MSX);
- Possui encapsulamento DIP (que facilita testes com o protoboard) e TQFP (que facilita a inserção numa placa com as dimensões reduzidas como as placa do cartucho do MSX);
Desvantagens:
- Custo elevado;
- Já está um pouco defasado com relação a outros MCU´s;
- Possui pouca memória de programa. Estou preocupado que não dê para inserir todo o código necessário e é quase certo que não vai dar para inserir código para ativar a funcionalidade do USB e ao mesmo tempo fazer a interface com o cartão SDCARD;
- Trabalha a apenas 12 MIPS. Pode ser um pouco lento para fazer a interface com o barramento do MSX, especialmente com versões mais modernas do MSX como o Turbo-R. Será necessário prever o uso de Wait States no circuito para evitar problemas;

2) CPLD EPM3064
Vantagens:
- Eu já tenho o componente;
- Quantidade de pinos adequada para a aplicação;
- Opera em 3,3V mas os pinos de IO toleram operar em 5V;
- Possui encapsulamento PLCC (possuo placa de desenvolvimento que aceita este encapsulamento) e encapsulamento TQFP (que facilita a inserção numa placa com as dimensões reduzidas como as placa do cartucho do MSX);
- Possui 64 macro-células que eu acredito que seja mais que o suficiente para a aplicação. Talvez seja possível usar o EPM3032 que tem a mesma pinagem mas apenas 32 macro-células e é bem mais barato;
Desvantagens:
- Custo um pouco elevado;

3) EEPROM AT49HF010
Vantagens:
- Eu já tenho o componente;
- Opera em 5V;
- Possui encapsulamento PLCC que é bem menor do que uma EPROM UV tradicional como o 27128 e desta forma facilita a confecção de uma PCI do tamanho de um cartucho de MSX;
Desvantagens:
- Possui 128Kx8 que é muito mais que os 16Kx8 da EPROM original. O que fazer com esta memória a mais? Colocar outras BIOS de "bônus" tais como o MSX Assembler e alguns jogos?

Detalhes da Interface CDX-2:
=====================

A interface CDX-2 original possui basicamente dois componentes: uma eeprom 27128 para armazenar o "disk bios" e um chip WD2793 para fazer a interface do computador com a unidade de disco físico. Pelo que eu pude entender os endereços de IO da interface são como seguem

Endereço de IO        Uso            Tipo de Acesso
D0                            2793            Escrita/Leitura
D1                            2793            Escrita/Leitura
D2                            2793            Escrita/Leitura
D3                            2793            Escrita/Leitura
D4                            Registro        Escrita
D5                            Registro        Escrita
D6                            Registro        Escrita
D7                            Registro        Escrita

O registro na verdade é um flip-flop que seleciona o disk drive, seleciona o lado do disco que será realizada a operação de leitura/escrita e aciona a rotação do motor da unidade de disco. Conforme segue a tabela abaixo:

Bit 0                Disk 0
Bit 1                Disk 1
Bit 2                Disk 2
Bit 3                Disk 3
Bit 4                Side
Bit 5                Motor




Já é tarde, são 1:39 da matina. Depois eu continuo a mensagem.

Um abraço,

José Paulo

segunda-feira, 8 de julho de 2013

Placa de protótipo para a memória IS61LV256

Olá,

Acima está a placa de protótipo para a memória IS61LV256 que é uma memória RAM estática der 32Kx8 e que funciona com 3,3V. Abaixo segue a foto do circuito de teste que eu montei para testar a placa e a memória em sí:


O circuito consiste de uma placa de desenvolvimento com o CPLD EPM570 da Altera controlando as escritas e leituras da memória RAM. O que o circuito faz basicamente é escrever todas as posições de memória com um determinado valor e depois lê este valor da memória e compara para ver se está certo. O resultado final sai num pino do EPM570 que eu consigo monitorar no meu osciloscópio. Depois o ciclo de escrita/leitura recomeça com um valor que é o incremento de 1 do valor antigo. Com o teste e o CPLD funcionando na velocidade de 50MHZ o circuito faz o ciclo de escrita/leitura em todas as 32768 posições de memória 760 vezes por segundo aproximadamente sem dar erros. Muito interessante. Gostei bastante do resultado.

Eu acho que não é necessário dizer que funcionou conforme o esperado. Futuramente pretendo fazer umas experiências bem interessantes com o conjunto memória/CPLD.

Abraços,

José Paulo

quinta-feira, 4 de julho de 2013

KickStart no Projeto do emulador de interface de disquete para MSX

Olá,

A imagem acima é um primeiro "brain storm" do que eu pretendo fazer para a minha interface de disquete. Eu tenho dois computadores MSX: um expert 1.0 e um Hotbit convertido para 2.0. Eu tenho drive de disquete e tenho as interfaces de disquete o que eu não tenho é paciência para continuar trabalhando com disquetes de verdade. Por este motivo é que eu decidi por criar uma interface de hardware que emule o funcionamento da interface de disquete do MSX mas que na verdade trabalhe com disquetes virtuais (arquivos) usando um SDCard. A minha ideia inicial é manter o projeto mais simples possível.

A interface escolhida para ser "emulada" pela sua simplicidade foi a interface CDX. A ideia é que o circuito emulador trabalhe o mais próximo possível de como funcionaria o circuito emulado. Basicamente falando a interface CDX possui dois componentes: A EEPROM que armazena a BIOS de disco e o chip de interface de disquete 2793 que faz a interligação da unidade de disquete com o computador.

A bios que será usada será uma bios de uma interface de disquete real. Neste quesito a minha interface não difere em nada de uma interface tradicional. Talvez apenas o componente escolhido. Ao invés do antigo e tradicional 2764 eu vou usar uma EEPROM AT89HF010 da Atmel com encapsulamento PLCC. Além de ser muito menor, consome bem menos energia.

Vai haver um MCU PIC que vai emular o funcionamento do chip 2793. O PIC escolhido até o momento é o PIC18F4550. Ele também ficará responsável pela comunicação com o SDCard e por controlar a interface com o usuário.

Eu vou usar um CPLD EPM3064 da Altera para executar duas funções: realizar a decodificação dos endereços entre o barramento do MSX e o PIC e servir como buffer conversor de tensão entre o PIC que trabalhará com 5V e o SDCard que trabalha com 3,3V.

Há muito ainda a ser feito. Esta é uma primeira idéia inicial e não sei se os componentes escolhidos até aqui vão ser mantidos até o fim do projeto. Qualquer novidades serão postadas no blog.

Um abraço,

José Paulo

quarta-feira, 3 de julho de 2013

Footprint SOJ-28 300 mils

Olá,

Eu estou criando uma placa para adaptar umas memórias RAM Estáticas modelo IS61LV256 que eu comprei no ebay para uso em protoboard e decidi compartilhar o footprint. Este footprint não existe na biblioteca default do Kicad. Caso seja interessante você pode conseguir o footprint no Kicad Cloud no link abaixo:


http://www.kicadcloud.com/pcbModule/4350


No futuro eu vou compartilhar outros componentes e footprints que eu criei para uso em meus projetos.

Um abraço,

José Paulo