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

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

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

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

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

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

Morte das revistas de eletrônica no Brasil

Olá,

Hoje eu estou prestando meu testemunho dos serviços prestados pelo grupo editorial bolina que é a editora que distribui a revista elektor no Brasil.

Eu fiz faz dois anos uma assinatura de um ano da revista elektor eletrônica. Todas as edições chegaram apesar de algumas edições terem chegado com um mês de atraso. Mas naquela época tudo bem desde que eu recebesse as revistas. Já que a coisa mais difícil hoje em dia é encontrar revista de eletrônica em banca de jornal. Daí a minha vontade inicial em fazer a assinatura.

Quanto terminou o prazo de um ano eu recebi uma ligação da editora perguntando se eu queria renovar a assinatura e eu concordei fazendo o plano de dois anos e pagando o valor da assinatura à vista. Nos primeiros 3 meses eu recebi as revistas e depois eu passei a não mais receber as edições. Tinha meses que eu recebia e tinha meses que eu não recebia até que eles simplesmente pararam de enviar totalmente as edições para minha casa. A última edição que eu recebi foi no final do ano passado.

Toda a parte legal e de contatos que eu estou fazendo para obter o ressarcimento foge um pouco do foco. O que eu realmente quero dizer é que é uma pena que as publicações nacionais sobre eletrônica estejam morrendo. Quero dizer é que as revistas de eletrônica tiveram um papel muito importante na divulgação da eletrônica. Trouxeram para as pessoas comuns a possibilidade de trabalhar com eletrônica e foram incentivadores de empresas e de carreiras profissionais - e eu me incluo nesta categoria.

Com o desaparecimento das bancas das revistas de eletrônica morre uma forma importante de divulgação de todo este maravilhoso mundo que é a eletrônica. E serviços de baixa qualidade prestados por empresas como o grupo editorial bolina só tende a afastar ainda mais pessoas que poderiam se tornar possíveis apaixonados por eletrônica.

Ou seja, não temos mais edições e publicações que divulguem e propaguem a eletrônica entre o público leigo, temos escolas e universidades que não incentivam a realização e a experimentação de projetos - formam apenas trocadores de placa e fazedores de relatórios - e temos um comércio morto que cobra preços abusivos com um serviço de baixa qualidade e tecnicamente despreparado. Todos estes fatores só podem levar o nosso País a mais dependência tecnológica no futuro.

Um abraço,


José Paulo