Atualização do projeto de emulador de interface de disquete (#12) - Pagando pelos pecados.

Olá,

Após um longo período sem postar nada no blog sobre o meu projeto de emulador de interface de disquete para o MSX eu finalmente volto a escrever sobre o tema. O motivo para isto foi a grande quantidade de problemas que encontrei para retirar o projeto do protoboard e leva-lo para uma forma mais definitiva. Abaixo segue as agruras pelo qual passei para sair de um ponto ao outro. Eu trago este relato na esperança de que as minhas experiências descritas abaixo possam ser de utilidde para alguém para evitar que passem pelo mesmo processo sofrido pelo qual passei.

Pois bem, em Novembro de 2013, eu alcancei um estágio em que o circuito estava funcionando muito bem no protoboard e eu senti a necessidade e a vontade de projetar e produzir uma placa de circuito impresso para o projeto. Após umas duas semanas de trabalho eu alcancei o design de uma placa de circuito impresso que eu passei a chamar de revisão A. Boa parte do tempo gasto no design desta placa foi tentando criar um design que me fosse possível produzir a placa em casa mas eu cheguei a conclusão que, apesar de eu conseguir produzir PCIs com ótima qualidade ainda assim não era o suficiente para a produção desta placa em especifico. Ou seja, eu precisava contratar o serviço de uma empresa para fazer a placa para mim.

Meu objetivo era o de produzir 3 placas de circuito impresso. Eu me lembro que eu pedi o orçamento para três empresas especializadas e foi aí que começaram meus problemas. Este tipo de empresa te fornece uma quantidade mínima de placas de normalmente 10 ou 20 placas por pedido a um custo que estava girando na época em torno de R$ 650,00 à R$ 750,00. Eu realmente não estava interessado em ficar com um monte de placas de circuito impresso. Então eu comecei a procurar por alternativas e acabei encontrando o site OSHPark (https://www.oshpark.com/).

Este é um site americano voltado para ajudar quem está criando projetos de hardware open source a obter protótipos dos seus projetos. Este site requer que você compartilhe seu design com os usuários do site e após você publicar seu projeto no site qualquer um pode emitir pedidos para a criação de protótipos. Além disto há uma restrição no site que a quantidade de placas no pedido deve ser múltipla de 3, ou seja, você deve pedir 3 ou 6 ou 9 placas, etc. Para mim este site encaixou como uma luva, pois eu queria três placas e o meu projeto é open source. Então eu coloquei o pedido no site a um custo em torno de R$ 350,00 (U$ 118,55 + U$25,00 USPS Priority Mail) na época.

Eu realmente fiquei surpreso com a qualidade do atendimento do site. Após efetuar o pagamento e em cada etapa do processo o site foi atualizando o status do pedido me informando a cada passo o que estava ocorrendo. E, apesar do site informar que as placas são fabricadas sob demanda e que dependendo do volume de pedidos as placas para serem produzidas podem demorar mais ou menos tempo, as minhas placas demoraram um tempo que eu achei relativamente curto. Eu coloquei o pedido no dia 29/11/2013 e as placas foram despachadas no dia 09/12/2013. Obviamente que o problema após as placas terem sido despachadas foi a nossa querida e amada (Sic) EBCT que demorou mais de dois meses para entregar o produto.

Mas as placas chegaram e novamente fiquei positivamente surpreso com a qualidade da PCI conforme mostrado na foto acima. A máscara de solda púrpura é uma característica do site OSHPark. O site é todo construído nesta mesma cor.

Claro que eu fiquei bastante agitado com a chegada das placas. Eu tratei logo de soldar os componentes na placa e testar a minha plaquinha e... Não funcionou. :-(

Após algum tempo investigando o porque eu percebi que cometi um erro grave. O tempo todo que eu testei o circuito no protoboard eu usei o CPLD EPM3064 versão PLCC 44 pinos. Quando eu desenvolvi a placa eu resolvi usar a versão TQFP 44 pinos do mesmo chip. Sendo que, apesar de fisicamente a posição dos sinais em ambos os chips ser rigorosamente a mesma a forma como os pinos são contados em um encapsulamento e no outro são diferentes conforme podemos ver na imagem abaixo.

No Kicad eu desenvolvi para EESchema um componente EPM3064 levando em consideração a pinagem do PLCC 44 pinos mas na hora de associar o footprint eu associei o footprint do TQFP 44 pinos. Com isto os sinais ficaram deslocados em 6 posições na PCI e obviamente isto não poderia funcionar. Além deste problema eu cometi algumas falhas no diâmetro de furos dos componentes e dos furos de fixação da placa na caixa do Carchano o que dificultou bastante a fixação dos componentes e os furos de fixação eu tive que alargar um pouco para que a mesma encaixasse na caixa corretamente.

Triste mas resoluto eu parti para a criação do design da revisão B da placa corrigindo todos os erros que eu havia cometido na revisão A o que me tomou mais um par de semanas para concluir. Desta vez eu queria a placa em minhas mãos mais rapidamente e na época eu tomei conhecimento de um site nacional com o princípio de funcionamento mais ou menos parecido com o OSHPark. O site que eu estou me referindo é o http://pci.eletronica.org/ que no momento desta postagem está informando que o site está suspenso por tempo indeterminado.

O princípio de funcionamento deste site é mais ou menos o mesmo do site OSHPark. Você envia o design da placa em formato Gerber e o site calcula o preço da placa para você. Na PCI Eletrônica não havia a restrição de múltiplo de 3 placas mas mesmo assim eu pedi três placas porque é o que eu sempre quis: três placas que funcionassem. O custo final ficou em torno de R$ 550,00 na época, ou seja, mais caro que no site OSHPark e foi após pagar o valor que os problemas começaram.

Quando eu emiti a ordem no site o status do meu pedido ficou como (Aguardando aprovação de pagamento). Uma semana após eu ter pago pelo pedido continuava a mesma coisa. Eu mandei um e-mail no qual eu fui respondido informando que o site estava com problemas mas que eles haviam já detectado o meu pagamento e que "muito em breve" eles estariam produzindo a placa. Mais uma ou duas semanas (não me lembro mais o tempo exato) sem nenhum e-mail ou alteração do status do meu pedido eu mandei um e-mail reclamando da demora. Novamente fui respondido só que desta vez eu fui informando que os meus arquivos Gerber estavam com problema e que por isto eles ainda não haviam mandado a placa para produção.

A partir daí eu passei a trocar uma série de e-mails com a "área técnica" da empresa. Inicialmente eu fui informando que os arquivos não estavam abrindo e sugeriram que eu instalasse um programa chamado viewplot que era o programa que eles usavam para verificar os arquivos Gerber que eles recebiam. Instalei o software e não vi qualquer problema nos meus arquivos neste software. Então eles me pediram um par de vezes que eu mandasse os arquivos novamente e no final pediram que eu mudasse a unidade de medida de polegadas para milímetros e que mudasse o formato dos números para ponto fixo. Tudo feito ainda demorou mais umas duas semanas para eles me mandarem as placas e me entregarem o código de rastreamento. Mais umas 3 semanas por conta da nossa querida e amada EBCT (Sic) e finalmente a placa chegou conforme podemos ver na foto abaixo. O processo todo demorou mais de 3 meses entre colocar o pedido no site e efetivamente receber as placas na minha casa.

 

A PCI.Eletrônica me enviou o dobro de placas que eu havia pedido sem nenhum custo adicional para mim, o que foi um pequeno plus com relação ao que eu queria porque acabou que eu fiquei com uma quantidade de placas acima do que eu queria. Devo dizer que a qualidade da placa é muito boa e inclusive eles se deram ao trabalho de estanhar os contatos da placa, o que não aconteceu com as placas da OSHPark. Um problema com as placas foi que o corte do contorno da placa que eles fizeram ficou em torno de 1,5 mm maior do que eu havia especificado. Com isto eu tive que desbastar o excesso de placa nas laterais porque o design da placa que eu fiz ocupa todo o espaço da caixa do Carchano e com este excesso eu não estava conseguindo encaixar a placa na caixa.

Me pus novamente a soldar os componentes na placa. Desta vez tanto o PIC como o CPLD foram reconhecidos e aceitaram a programação dos seus respectivos programadores. Para fazer um teste inicial eu coloquei a placa sem o painel de controle no meu MSX e eu puder ver que o MSX estava mostrando as mensagens da EEPROM presente na placa - bom sinal. Então eu colouque o painel de controle e... Não funcionou. :-(

Pior, depois que eu coloquei o painel tanto o PIC, como o CPLD pararam de responder aos seus respectivos programadores. Sendo que acabaram-se os CPLD´s com encapsulamento TQFP 44 pinos em casa. Além disto claramente o display de LCD também ficou danificado e eu tive que trocar o display.

Novamente me pus a investigar o problema e percebi que eu inverti a pinagem da alimentação entre o painel de controle e a placa principal. Eu resolvi este problema simplesmente trocando a posição dos fios no cabo flat.

O problema agora era que se acabaram os CPLD´s. No site da Farnel Brasil não havia mais em estoque. Pedi para orçar. Esperei uma semana e nenhuma resposta da Farnell. Fui no Ebay e comprei os CPLD´s e mais alguns componentes no dia 15/08/2014 sendo que até o momento desta postagem estes componentes mantém o status no site do Correios conforme podemos ver abaixo:

Bem, no meio da minha frustação e após um mês eu ter pedido para orçar o componente eu recebi um e-mail da Farnell com o bendito orçamento. Aprovei e paguei o orçamento e por volta de meados de Outubro/2014 eu recebi os CPLDs em casa.

Soldei e programei o CPLD. Chequei vinte vezes tudo novamente só para ter certeza. Pluguei o cartucho no meu Expert e... FUNCIONOU!!!

Finalmente eu consegui colocar o meu "Emulador de Interface de Disco" para funcionar com a placa de circuito impresso revisão B. Depois de praticamente um ano, muito dinheiro gasto, muita espera e aborrecimentos finalmente a placa funcionou.

É óbvio que a primeira pergunta que vem a mente é: Será que realmente valeu a pena? E aí a resposta é: Depende. Se o objetivo fosse exclusivamente para usar os meus computadores MSX a resposta é um NÃO gigantesco. Eu teria poupado não somente aborrecimentos como muito dinheiro comprando uma das outras interfaces que já existem e funcionam muito bem.

Por outro lado este foi apenas uma pequena parte do meu objetivo. Pois o meu objetivo principal sempre foi o de aprender e se eu olhar por este lado apenas a resposta passa a ser um SIM igualmente gigantesco. Eu acredito que eu aprendi muito, tanto sobre microcontroladores, como sobre CPLDs, tal como interfaces de computador. Aprendi muito sobre a estrutura do sistema de arquivos FAT. Aprendi muito também sobre cartões SD. Aprendi inclusive que desenvolver hardware no Brasil é extremamente difícil e caro.

Há ainda um outro lado que é o da satisfação pessoal e do orgulho. Depois de anos de desenvolvimento - eu comecei a pensar e a estudar sobre como eu iria executar este projeto em 2011 - você conseguir êxito no seu projeto é muito gratificante. è uma sensação muito boa e ao mesmo tempo muito difícil de descrever. Eu acredito que só quem desenvolveu e criou algo do zero e obteve êxito no final sabe de verdade como é. E a resposta à pergunta inicial olhando por esta perspectiva é também um SIM gigantesco.

Ou seja, se você é daqueles que realmente não gosta de desenvolver hardware ou software e quer apenas usar o seu MSX então não inicie um projeto como este. Mesmo que você ache que você teve alguma ideia mirabolante que vai "revolucionar" o computador MSX. Por um outro lado eu recomendo que todos que gostam efetivamente de trabalhar com desenvolvimento de hardware e software que tentem, pelo menos uma vez, fazê-lo. Porque apesar de todos os aborrecimentos e gastos, caso você consiga concluir seu projeto a satisfação em fazê-lo supera qualquer dificuldade.

Eu ainda tenho muito a dizer sobre o funcionamento do circuito e muitas coisas aconteceram após a isto e por este motivo eu estou reservando posts futuros para descrever e mostrar em maiores detalhes a interface funcionando.

Um abraço,

José Paulo

Curso Online grátis de Java ME Embeded para o RaspBerry PI

 

Bom dia à todos,

Pra quem ainda não sabe, e eu acho difícil de ainda ter alguém que trabalha ou estuda na área técnica que não tenha ouvido falar destes dispositivos, o RaspBerry PI é um "computador" cuja a placa é do tamanho de um cartão de crédito e que expõe um conector com GPIO´s, I2C, SPI, UART, PWM e I2S. Tem muita gente ao redor do Globo fazendo muita coisa bacana com o RPi (abreviação de RaspBerry PI). Em breve eu devo escrever sobre as minhas impressões pessoais sobre o mesmo além de outras novidades, aguarde!

Bom, continuando...

Se você tem um computador, é necessário criar programas para ele. Para criar programas você precisa de uma linguagem de programação. E as principais linguagens de programação disponíveis para o RPi são o Python (considerado pelos criadores do RPi como sendo a principal linguagem para a plataforma) e a linguagem C.

A Oracle está desenvolvendo o Java ME Embeded 8 e está atualmente disponibilizando para download uma versão conhecida como EA2 (Early Access 2) que como o nome sugere se trata de uma versão em que algumas características podem mudar em um futuro próximo.

Para divulgar a nova versão 8 do Java e ajudar a divulgar o Java ME a Oracle está disponibilizando o Java MOOC (Massive Online Open Course). Se trata de um curso online grátis no qual ao longo de 5 semanas você vai aprender a desenvolver uma aplicação Java para o RPi interagindo com vários dispositivos  de hardware e aprendendo vários conceitos de Java no processo. Com certeza que é um curso bem interessante.

Na verdade está notícia em sí não é nova, inclusive já há uma turma em andamento que começou em 31 de Março. A novidade agora é que devido ao sucesso do curso resolveram abrir uma nova turma com o começo previsto para o dia 19 de Maio.

Além de um conhecimento básico de programação e de eletrônica é necessário que você possua um RPi e que você possua alguns acessórios que são vendidos pela Adafruit que fica no EUA. Eu não sei, mas eu acredito que já está meio em cima para comprar o material da Adafruit pelo correio. Até começar o curso o material ainda não vai ter chegado muito provavelmente. Dá última vez que eu comprei alguma coisa dos EUA o material demorou 5 meses pra chegar - devo escrever uma outra matéria a respeito disso.

De qualquer forma, caso você ainda possua o RPi a Farnell vende o aparelho por R$ 189,00 sem o cartão SD Card e sem fonte. Eu comprei o meu RPi da Farnell e usei um cartão SD que eu já tinha e para alimentar o RPi eu estou usando uma fonte de celular. A compra dos acessórios é bacana mas eu não creio que seja imprescindível para poder fazer o curso. Pelo que eu tenho visto até agora dá para se virar sem os acessórios só que fica mais difícil de fazer o curso. Eu devo escrever mais outra matéria explicando como eu estou fazendo para praticar sem os dispositivos da Adafruit.

Segue o link para inscrição no curso:
https://apex.oracle.com/pls/apex/f?p=44785:145:0::::P145_EVENT_ID,P145_PREV_PAGE:1841,143

Espero que isto seja útil. Java é uma linguagem que está muito em voga e aprender Java pode ser um fator importante na carreira de qualquer profissional da área.

Um abraço,

José Paulo

Controlando motor de Disco Rígido

Olá,

Outro dia um colega estava desmontando um disco rígido defeituoso atrás dos ímãs de neodímio e ia jogar todo o restante fora. Foi aí que eu me lembrei de alguns vídeos que eu vi no YouTube de "Hard Disk POV". Vídeos como o do link abaixo:

http://www.youtube.com/watch?v=6dygwdisUj0#aid=P9R6_GgRM2I

Então eu pensei; "Taí um projeto muito bacana". Eu peguei o restante do HD que ia para o lixo e comecei a trabalhar para tentar fazer o motor do HD girar. A minha idéia era a de fazer um relógio de ponteiro usando um HD para deixar o bicho paradinho em minha escrivaninha rodando e mostrando a hora indefinidamente. Já posso adiantar que eu descobri que os motores de discos rígidos demandam muita energia para rotacionarem e que isto me desestimulou para fazer o projeto como eu queria. Afinal não é vantajoso você ter um relógio de ponteiro que consuma no final do mês muitos kW/h e acabei por fim jogando "todo o restante do hd fora". Mas não antes de eu fazer alguns testes e de aprender bastante sobre motores BLDC (motores CC sem escova) e sobre circuitos de controle com malha fechada. E é sobre isto o assunto desta matéria.

Para fazer meus testes eu usei um MSP430 launchpad Texas Instruments em conjunto com o software chamado Energia. Eu já descrevi o que é o Energia e o MSP430 lauchpad em mensagens anteriores. Basicamente o MSP430 launchpad é uma placa de testes e prototipagem muito parecida com as placas arduínos (mas não é compatível o arduíno) e o Energia é um ambiente de desenvolvimento muito parecido com o ambiente do arduino (mas não é compatível) no qual permite a você escrever programas também chamados sketchs e programa-los nas placas launchpad.

O disco rígido de teste possuí três bobinas que eu vou chamar durante o resto deste texto de "fases". Estas fases estão interligadas a um ponto comum. Portanto o motor do meu disco rígido possuía 4 contatos. Um contato para o ponto comum e um contato para cada fase. Havia algumas inscrições no motor mas eu não encontrei qualquer referência ou informação técnica na internet. Com um ohmímetro eu descobri que do ponto comum para cada fase existe uma resistência de 1,2 Ohms e entre as fases existe uma resistência de 2,4 Ohms. Com isto eu descobri quem era o ponto comum e quem eram as fases.   O contato do ponto comum ficava numa extremidade e eu deduzi que a ordem de acionamento das fases seguiriam a sequência dos contatos. Eu mantive esta dedução até o final e depois eu obtive a confirmação de que esta dedução estava certa por outros meios que eu vou explicar mais a frente.

Para acionar as fases eu liguei o ponto comum a uma fonte de alimentação de 12Vdc (apesar de não ter informações sobre o motor do HD me pareceu natural o uso deste valor de tensão). Cada fase eu liguei no dreno de um power mosfet canal N IRF840 e a fonte do mosfet eu liguei no terra. Como a tensão de limiar do gate do IRF840 está acima de 4V e o launchpad trabalha com tensão de 3,3V eu tive de usar um circuito auxiliar para comandar o power mosfet. Então eu usei um outro mosfet canal n, o BS270, para ajudar a elevar um pouco mais a tensão de gate do IRF840 quando acionado. Este tipo de configuração para acionamento de cargas é conhecido em inglês como "low side load driving". O circuito em sí não me parece muito importante agora, mas sim os resultados que eu obtive.

Eu comecei a tentar fazer o motor girar simplesmente acionando as fases do motor em sequência e gradativamente diminuindo o tempo de acionamento entre as fases para aumentar gradativamente a velocidade de rotação do motor . O comportamento do circuito foi muito fraco. Na maioria das vezes o motor simplesmente balançava para um lado e para o outro depois ficava estático. Algumas vezes o motor começava a girar e depois de algum tempo parava. E em outras vezes o motor girava lentamente e se eu aplicasse qualquer carga sobre o motor (Ex.: colocando levemente o dedo sobre o disco) o motor parava e não retornava a girar. Girar o motor com as mãos ao iniciar o acionamento elétrico do motor trazia pouca ou nenhuma ajuda. Um outro problema que eu detectei é que das vezes que o motor mantinha a rotação, a velocidade não era igual, i.e., as vezes o motor girava mais rápido e em outras vezes o motor girava mais rápido. Com isto ficou claro para mim que acionar as fases sem ter um controle efetivo da polaridade e da posição do eixo do motor é até possível mas é muito difícil e ineficiente.

Para controlar a posição do eixo e desta forma controlar o acionamento correto do motor há duas formas (pelo menos até aonde eu pude apurar das minhas pesquisas na internet): usando sensores de efeito hall e detectando a força eletromagnética reversa (back EMF). Eu decidi por tentar detectar a força magnética reversa e para isto eu modifiquei o meu circuito de controle para o circuito abaixo:

A ideia do circuito é simples: uma tensão de 3,3V no gate do transistor Q1 faz com que corrente circule na fase. Com o motor em rotação e sem termos corrente circulando na fase faz com que surja um DDP nos terminais da fase que é proporcional a posição do eixo do motor com relação a fase. Ou seja, a tensão será máxima se os pólos dos magnetos do eixo estiverem alinhados com a bobina da fase em questão. Usando as entradas ADC do MSP430 eu posso ler o nível de tensão das fases com o motor já em movimento e nos momentos aonde as três fases não estão sendo acionadas e desta forma acionar as fases de acordo com a posição correta do eixo.

Foi surpreendente a melhoria no comportamento do motor. Com esta última configuração ainda há o problema de "como fazer o motor começar a girar". Mas uma vez que o motor começa a girar eu posso garantir que ele não para mais. Eu posso aplicar carga sobre o motor (pressionando o dedo sobre o disco em movimento) que apesar do motor diminuir a sua rotação ele não mais para. Eu posso ajudar o motor girando o disco com as mãos que com certeza ele vai manter a rotação. E eu posso garantir que em todas as vezes o motor girava sempre na mesma rotação (em torno de 800 rpm). Um outro detalhe curioso é que se eu mudasse a ordem de acionamento das fases o motor ou girava mais lentamente ou não girava o que confirmou a minha suposição inicial sobre a ordem correta de acionamento das fases.

O código do sketch que eu usei nos testes está listado abaixo. Este código eu escrevi sem qualquer planejamento ou pretensão. Foi um código construído por meio de tentativa e erro e com certeza podia ter sido melhor escrito mas como eu não queria levar o projeto adiante eu simplesmente me dei por satisfeito.

//definição das variáveis locais
byte _step;
unsigned long time;
int time_count_on;
int time_count_off;
unsigned long key_pressed_count;
boolean motor_active;
boolean motor_start;
int phase1_level;
int phase2_level;
int phase3_level;

//definição das constantes do sketch
const int PHASE1_SWITCH=P2_0;
const int PHASE2_SWITCH=P2_1;
const int PHASE3_SWITCH=P2_2;
const int PHASE1_LEVEL=A0;
const int PHASE2_LEVEL=A1;
const int PHASE3_LEVEL=A2;

const int START_TIME_ON=15;
const int MIN_TIME_ON=1;
const int START_TIME_OFF=40;
const int MIN_TIME_OFF=1;
const int KEY_PRESSED_TIME=500;

void setup()
{
  // put your setup code here, to run once:
  pinMode(PHASE1_SWITCH,OUTPUT);
  pinMode(PHASE2_SWITCH,OUTPUT);
  pinMode(PHASE3_SWITCH,OUTPUT);
 
  pinMode(PUSH2,INPUT_PULLUP);

  analogReference(INTERNAL1V5);
 
  _step=1;
  time_count_on=START_TIME_ON;
  time_count_off=START_TIME_OFF;
  time=0;
  key_pressed_count=0;
  motor_active=false;
  motor_start=false;
  digitalWrite(PHASE1_SWITCH,LOW);
  digitalWrite(PHASE2_SWITCH,LOW);
  digitalWrite(PHASE3_SWITCH,LOW);
}

void loop()
{
  // put your main code here, to run repeatedly:
  if(digitalRead(PUSH2)==LOW){
    if(key_pressed_count==0){
      key_pressed_count=millis()+KEY_PRESSED_TIME;
    } else {
      if(key_pressed_count<millis()){
        motor_active=!motor_active;
        if(motor_active==true){
          motor_start=true;
        }
        key_pressed_count=millis()+5000;
      }
    }
  } else {
    key_pressed_count=0;
  }
  if(motor_active==true && motor_start==true){
    digitalWrite(PHASE1_SWITCH,HIGH);
    delay(150);
    digitalWrite(PHASE1_SWITCH,LOW);
//    delay(300);
 
    digitalWrite(PHASE2_SWITCH,HIGH);
    delay(100);
    digitalWrite(PHASE2_SWITCH,LOW);
//    delay(300);
 
    digitalWrite(PHASE3_SWITCH,HIGH);
    delay(80);
    digitalWrite(PHASE3_SWITCH,LOW);
//    delay(300);

    digitalWrite(PHASE1_SWITCH,HIGH);
    delay(60);
    digitalWrite(PHASE1_SWITCH,LOW);
//    delay(150);
 
    digitalWrite(PHASE2_SWITCH,HIGH);
    delay(60);
    digitalWrite(PHASE2_SWITCH,LOW);
//    delay(100);
 
    digitalWrite(PHASE3_SWITCH,HIGH);
    delay(60);
    digitalWrite(PHASE3_SWITCH,LOW);
//    delay(50);
    motor_start=false;
  }   

  if(motor_active==true && time==0){
    switch(_step){
      case 2:
        digitalWrite(PHASE1_SWITCH,HIGH);
        digitalWrite(PHASE2_SWITCH,LOW);
        digitalWrite(PHASE3_SWITCH,LOW);
        time=millis()+time_count_on;
        _step++;
        break;
      case 1:
      case 3:
      case 5:
        if(time_count_off!=0){
          digitalWrite(PHASE1_SWITCH,LOW);
          digitalWrite(PHASE2_SWITCH,LOW);
          digitalWrite(PHASE3_SWITCH,LOW);
          time=millis()+time_count_off;
        } else {
          time=millis();
        }
        delay(1);
        phase1_level=analogRead(PHASE1_LEVEL);
        phase2_level=analogRead(PHASE2_LEVEL);
        phase3_level=analogRead(PHASE3_LEVEL);
        if(phase1_level>phase2_level && phase1_level>phase3_level){
          _step=4;
        } else {
          if(phase2_level>phase1_level && phase2_level>phase3_level){
            _step=6;
          } else {
            _step=2;
          }
        }
        break;
      case 4:
        digitalWrite(PHASE1_SWITCH,LOW);
        digitalWrite(PHASE2_SWITCH,HIGH);
        digitalWrite(PHASE3_SWITCH,LOW);
        time=millis()+time_count_on;
        _step++;
        break;
      default:
        digitalWrite(PHASE1_SWITCH,LOW);
        digitalWrite(PHASE2_SWITCH,LOW);
        digitalWrite(PHASE3_SWITCH,HIGH);
        time=millis()+time_count_on;
        _step=1;
    };
    if(time_count_off>MIN_TIME_OFF){
      if(_step==1){
        time_count_off--;
      }
    }
    if(time_count_off<time_count_on){
      if(time_count_on>MIN_TIME_ON){
        time_count_on=time_count_off;
      }
    }
  }
  if(motor_active==true && time<millis()){ 
    time=0;
  }
  if(motor_active==false){
    time=0;
    time_count_on=START_TIME_ON;
    time_count_off=START_TIME_OFF;
    _step=1;
    digitalWrite(PHASE1_SWITCH,LOW);
    digitalWrite(PHASE2_SWITCH,LOW);
    digitalWrite(PHASE3_SWITCH,LOW);
  }
}

Com o código acima eu consigo manter o rotação constante em torno de 800 rpm apesar de que é possível perceber um flutuação na velocidade inicial. É possível eliminar esta flutuação usando as técnicas de controle PID que são o pesadelo de qualquer aluno de engenharia elétrica. Além disto o algoritmo para iniciar a rotação do motor não está bom e precisa ser melhorado. Mas com o circuito e o código acima eu consegui testar vários conceitos interessantes. E é na esperança de que as informações acima sejam de alguma utilidade para alguém que eu termino esta mensagem.

Eu realmente não quis concluir o meu projeto. Nos momentos iniciais de rotação do motor o circuito chega a consumir em torno de 3A e com o motor estabilizado em 800 rpm o circuito consome 1A. Daí dá para perceber que se o motor estiver rodando na velocidade máxima em que ele foi projetado que é 5200 rpm o consumo de energia diminui bastante. Por outro lado é impossível ou extremamente difícil controlar com precisão o acionamento de leds 86 vezes por segundo usando um microcontrolador trabalhando a 16Mhz. Lembrando que este mesmo microcontrolador teria que controlar também o acionamento das fases, ler de tempos em tempos botões para verificar se o usuário não quer interagir com o aparelho e se comunicar de tempos em tempos com um CI RTC tipo o DS1307. Simplesmente muita complexidade para um "projetinho simples" e eu perdi o interesse em continuar na pesquisa.

Mas de qualquer forma aí está a idéia para quem quiser continuar a pesquisar e construir o projeto.

Um abraço,


José Paulo

Amplificador para fone de ouvido

 Olá,

Já faz um tempão que eu não escrevo nada no blog! Falta de tempo e de paciência também. Mas ei, eu agora estou de férias e pretendo recuperar o tempo perdido.

Um projetinho rápido que eu fiz a pedido de um amigo foi um amplificador estéreo para fone de ouvido. A idéia é bem simples: Um amplificador de baixa potência, alimentado pela rede elétrica, simples de usar, com controle de volume e que tenha uma boa qualidade de áudio.

Para a tarefa eu selecionei o C.I. TDA2822M que é um amplificador estéreo com encapsulamento DIP ou SMD de 8 pinos. Este C.I. é o 555 dos amplificadores de áudio. É um C.I. que vários fabricantes o produzem e em qualquer lojinha de eletrônica você acha fácil. Na configuração estéreo você consegue colocar para fora algo em torno de 0,6W e em configuração ponte (áudio mono) você consegue uma potência de 1,2W aproximadamente. Além disto a distorção harmônica fica em torno de 0,5% o que é muito bom. E se não bastasse todas as vantagens, ainda é um componente relativamente barato custando em lojas do ramo algo em torno de R$ 2,00 cada um. O link com o datasheet segue listado abaixo:

http://www.unisonic.com.tw/datasheet/TDA2822.pdf

Uma das premissas do projeto é que o amplificador fosse alimentado pela rede elétrica. Eu não queria embutir uma fonte de alimentação na mesma caixa do amplificador com receio que isto fosse gerar ruídos na saída de áudio devido a interferências eletromagnéticas. Com isto eu decidi usar fontes externas. Eu tenho o costume - não sei muito bem o porquê - de guardar as fontes de alimentação de equipamentos que eu descarto. Com isto eu tenho várias e várias fontes de alimentação com saída AC e DC e nas mais variadas tensões e correntes de operação. Então eu decidi por adotar um Jack DC J4 como porta de entrada para alimentação.

Um outro cuidado que eu tomei foi em usar uma caixa metálica ao invés de uma caixa plástica com o objetivo e a esperança que a caixa metálica funcionasse como uma gaiola de Faraday isolando o circuito de ruídos externos. A placa de circuito impresso é preso por um único parafuso à base da caixa que está ligado ao terra do circuito. Desta forma a base da caixa tem o mesmo potêncial que o terra do circuito, porém, eu inicialmente não tomei nenhum cuidado com a tampa da caixa. Quando eu testei o circuito eu percebi que ruído vindo de celulares e monitores próximos "vazava" no áudio e isto era uma coisa bastante irritante. Depois eu tive a idéia de raspar a tinta que faz o contato da base da caixa com a tampa. Para minha agradável surpresa, a interferência cessou completamente. Ao ponto de eu poder apoiar meu celular em cima da caixa do amplificador e não ouvir mais nenhuma interferência vinda do celular. Santo Faraday!

 Pelo incrível que pareça eu fiz duas revisões deste projeto: revisão A e revisão B. Na revisão A o TDA2822M é o único componente ativo. O problema da revisão A é que se você ligasse o aparelho com o fone fechado em sua orelha você escuta um som forte de "POC" que chegava a machucar e isto não era legal. Nada demais, basta você ligar o amplificador e depois colocar o fone de ouvido e tudo funcionaria ok. Mas com o sucesso da primeira versão mais pessoas me pediram para fazer o amplificador, então eu decidi que na próxima revisão eu iria atacar este problema. A solução foi a seguinte: Ao invés de ligar o TDA2822M direto á alimentação  eu liguei a alimentação do C.I. a um transistor NPN em configuração "seguidor de emissor" e coloquei um circuito RC na base do transistor de forma que quando a alimentação fosse ligada, a tensão de alimentação do C.I. subisse gradativamente. Posso dizer que este problema foi resolvido totalmente.

E é isto! Segue abaixo o link com o projeto do kicad.

https://dl.dropboxusercontent.com/u/62498964/Phone%20Amplifier.zip

Até breve,

José Paulo

Atualização do projeto de emulador de interface de disquete (#11) - Eureka!

Olá,

Eu estava tendo um problema para usar a eeprom AT49HF010 no meu projeto. Inicialmente estava acreditando que o problema era que o CI não estava conseguindo comandar o barramento de dados do MSX sem a ajuda de um buffer. Posteriormente eu vi que estava na verdade cometendo um erro. Eu estava usando como sinais para a seleção do chip o CS1 e o READ ligados respectivamente nos pinos CE e OE, mas isto é um erro e estava provocando o acionamento do CI com outros dispositivos presentes no barramento. Quando eu liguei os sinais CS1 e SLTSL à eeprom tudo passou a funcionar normalmente (EUREKA!).

Com este erro resolvido passei a me preocupar com a possibilidade de adicionar a capacidade de escrever e não apenas ler na eeprom. Após algum tempo de estudo eu cheguei a conclusão que o melhor caminho seria ligar o pino CE no sinal SLTSL e o sinal CS1 ser ligado no pino OE. Normalmente, pelo que tenho observado, se faz o contrário. Os diagramas que eu tenho encontrado na internet eu vejo que os projetistas ligam o sinal CS1 no pino CE e o sinal SLTSL no pino OE, mas isto não faz muito sentido para mim porque o sinal CS1 participa de uma lógica com sinal READ. Se você deseja fazer apenas leituras a ordem não importa muito, mas no meu caso, como eu quero realizar também escritas, eu preciso dos sinais na "ordem certa". Além disto o sinal CS1 também seria ligado a CPLD para participar de uma lógica tal que, caso escritas para a eeprom estejam habilitadas e o CS1 não esteja ativo (nivel zero) o CPLD ativará o sinal de escrita para a eeprom. Desta forma eu garanto que leituras permanecerão funcionando, mesmo durante a programação, e escritas somente serão ativadas intencionalmente.

Resumindo:

- Leituras para a eeprom somente são possíveis selecionando o slot correto para a página 1 (4000h-7fffh) e realizando uma operação de leitura na faixa de endereço da página 1.

- Escritas para a eeprom somente são possíveis ativando as escritas via CPLD e realizando uma operação de escrita para um endereço cuja a página esteja ativa para o slot correto. Ou seja, eu posso fazer uma escrita para qualquer endereço dentro da faixa de 64K desde que a página deste endereço esteja selecionada para o slot no qual está ligada a eeprom.

Com este problema resolvido eu finalmente me decidi sobre o que fazer com os dois pinos que eu tinha sobrando no PIC. Um dos pinos ficará ligado ao sinal de RESET e o outro pino ficará responsável pela detecção de presença do cartão SD.

As últimas mudanças que eu  fiz já estão disponíveis em:

http://sourceforge.net/p/msxdiskinterfaceemulator/Circuit/HEAD/tree/

Aproveito também para lembrar que apesar de fisicamente - nop hardware - ser agora possível fazer escritas para a eeprom, este recurso somente estará presente em revisões do firmware posteriores a versão 1.0.

Com tudo isto exposto acima, caso alguém tenha alguma dúvida, crítica ou sugestão, por favor fique a vontade para expor sua opinião.

O próximo passo agora é acertar os detalhes finais dos footprints dos componentes para podermos iniciar o layout da placa de circuito impresso.

Um abraço,

José Paulo

Atualização do projeto de emulador de interface de disquete (#10) - Painel de Controle

Olá,

A última novidade sobre este projeto é que eu fiz o diagrama elétrico e o layout da placa de circuito impresso do painel de controle. Com o layout na mão me foi possível executar a construção do painel conforme vocês podem ver nas fotos acima.

Tenho que confessar que eu não fiquei muito feliz com o resultado final mas no final eu aprendi uma lição importante. Apesar das fotos não mostrarem os quatro parafusos que estão próximos ao display de LCD são longos e prendem a tampa ao LCD e à placa de circuito impresso tudo junto. Má ideia. Foi um sacrifício fazer as coisas encaixarem uma nas outras e demorei um tempo longuíssimo para montar todo o conjunto. Apesar do painel estar funcionando eu recomendo que não construam (caso se queira reproduzir o projeto) um painel de controle usando o layout que eu fiz.

De qualquer forma é isto. O painel está pronto e está funcionando e no final das contas ficou bem bacaninha.

Eu já dei um commit com estas últimas alterações para o sourceforge caso alguém queira dar uma verificada é só acessar:

http://sourceforge.net/projects/msxdiskinterfaceemulator/

Um abraço,

José Paulo

Atualização do projeto de emulador de interface de disquete (#9) - Source Forge

Olá,

Eu finalmente acrescentei ao código fonte os avisos da licença GPL. Com isto eu criei um espaço no source forge e todos os arquivos pertinentes ao projeto estão lá. Caso você queira participar do projeto ou queira apenas reproduzir o projeto o mesmo está disponível em:

https://sourceforge.net/projects/msxdiskinterfaceemulator/

Com relação ao diagrama elétrico está concluído. Acredito que eu tenha que fazer mais uma inspeção final antes de declarar a versão do diagrama como sendo a versão 1.0. O layout do PCB já foi iniciado e eu parei no estágio de distribuição dos componentes. Com relação ao código fonte em sí eu ainda não acrescentei a documentação no código e nem fiz o clean up conforme prometido. Mas pretendo fazer isto em breve. Além disto tem que ser feito todos os bug fixes necessários.

Esta é apenas uma mensagem rápida porque estou sem tempo no momento. Mas qualquer coisa é só entrar em contato.

Um abraço,

José Paulo

Gabarito para caixa de cartucho do Carchano

Olá,

Eu fiz um gabarito para a caixa de cartucho grande vendida pelo Carchano para o software Kicad. Abaixo segue o link para o arquivo no formato PCBNEW (editor de PCB do Kicad):

https://dl.dropboxusercontent.com/u/62498964/MSXDiskEmul.kicad_pcb

A caixa pode ser comprada aqui:


http://www.carchano.com.br/loja/produtos_descricao.asp?lang=pt_BR&codigo_produto=3



Um abraço,

José Paulo

Nova versão do Energia está disponível

Olá,

Há algum tempo atrás eu escrevi um artigo descrevendo mais um pouco sobre o energia. Segue abaixo o link para consulta:

http://paixaoeletronica.blogspot.com.br/2013/09/energia-arduino-framework-para-o.html

Bom, agora saiu uma nova versão do energia - na verdade já não é nem tão nova assim já que saiu em 23/09/2013 - com vários "bug fixes". Pra quem tem launchpads como eu vale a pena experimentar. Maiores informações no link abaixo:

http://energia.nu/release.html

Um abraço,

José Paulo

Nova Peça para o Kicad: Conector 50 pinos para o slot MSX

Olá,

Eu criei um novo componente para o Kicad. Trata-se de um conector 50 pinos para o slot do MSX. Eu intenciono usar este componente para criar a placa de circuito impresso. Abaixo segue o link do Kicad Cloud do módulo para PCB e o componente para o diagrama elétrico.

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

http://www.kicadcloud.com/schematicSymbol/4377

Espero que seja de alguma utilidade para mais alguém.

Um abraço,

José Paulo

O emulador de Interface de disco na MSXRIO 2013

Olá,

Eu levei o emulador de interface de disco para o MSXRIO 2013. Confesso que fiquei bastante preocupado de chegar lá e a interface não funcionar devido a algum fio se soltar do protoboard, mas tudo funcionou direitinho conforme podemos ver na foto acima. A recepção do pessoal foi bastante calorosa e eu pude estabelecer alguns contatos interessantes. Eu fiz e levei para a feira um folder que é como se fosse um manifesto declarando o que é e como funciona a interface e chamando as pessoas a estarem participando do projeto. Abaixo segue o link do dropbox para o arquivo versão PDF do folder.

https://dl.dropboxusercontent.com/u/62498964/Brochure.pdf

Eu fiz contato com dois desenvolvedores que me informaram que estão criando um ambiente de desenvolvimento cross para o MSX. Eles falaram que a intenção é criar uma IDE que permita compilar jogos e programas para MSX no PC e dentro da IDE ter uma forma de imediatamente poder rodar o programa e debuga-lo direto no MSX. Até o momento eles tem usado uma interface de rede mas devido a todo o overhead existente no processo de comunicação com o MSX o tempo para a transferência do programa tem sido longo. Como o emulador de interface de disk drive prevê a inclusão de uma porta USB slave para uso futuro eu falei da possibilidade de usar esta porta usb para permitir a transferência e debug do programa no MSX. Eles demonstraram bastante interesse pela ideia e se mostraram bastante motivados e a motivação deles me "contaminou".

Para a versão 1.0 do firmware não pretendo inserir nenhum código no firmware do PIC visando este fim, isto ficará para revisões futuras. Mas, eu pretendo ligar os sinais para permitir a geração de interrupções por parte da interface. A interface de disco CDX-2 - que eu estou emulando - não usa interrupções e por este motivo a sinalização para a geração de interrupções não é usada. Mas como o PIC ainda possui alguns pinos sobrando eu achei interessante usar estes pinos reserva para permitir a geração de interrupções no MSX em futuras revisões.

Então como funcionaria esta "segunda funcionalidade" do emulador?

Olhando o dump da ROM do CDX-2 é possível observar que aparentemente sobraram algumas centenas de bytes de espaço livre. Usando este espaço livre alteraríamos a CDX-2 para criar uma ISR que aguardaria por uma interrupção por parte da interface que sinalizaria que a IDE lá no PC quer transferir dados para o MSX. Então a ISR, usando os endereços de IO livre na interface (escrita - D5 até D7/leitura D4 até D6) estabeleceria a comunicação com a interface e realizaria a transferência dos dados, posteriormente transferindo a execução para o programa recém carregado. Se você não é desenvolvedor e não quiser usar a interface para este fim então tudo bem, nenhum overhead será criado.

Além disto eu fui perguntado se a interface suporta a emulação de discos de 1.44MB e a resposta é não. Hoje a interface suporta a emulação de discos de 360K e 720K porque eram os formatos suportados pela interface CDX-2. Então eu perguntei se havia alguma interface de disco para MSX que suportava discos de 1.44MB e a pessoa me apresentou uma interface, eu na hora falei que iria tirar uma foto da interface para poder obter maiores informações mas acabou que outra pessoa chegou perguntando outras coisas e eu depois esqueci de tirar a foto e também esqueci o nome da pessoa. Ou seja, eu fiz uma bagunça. Eu estou torcendo para que a pessoa que me falou sobre a interface entre em contato comigo para que eu possa aprender mais sobre ela. Eu não pretendo adicionar o suporte para discos de 1.44MB na versão 1.0 do firmware mas é uma coisa totalmente possível para futuras revisões.

Além disto, eu fui perguntado sobre qual formato a placa de circuito impresso usará, se o formato Patola ou o formato de cartucho grande fornecido pelo Carchano. Eu já até comprei algumas caixas do Carchano mas estas caixas são realmente muito grandes e seria muito melhor se eu tivesse acesso as caixas da Patola. O circuito cabe tranquilamente em uma caixa pequena. Me informaram que a Patola ainda teria a forma para produzir caixas para cartuchos do MSX e que a Patola pode produzir se for colocado um pedido grande de caixas. Se alguém puder me fornecer algumas caixas patola virgens ou se alguém tiver uma previsão de quando estas caixas patola estarão disponíveis novamente para a compra eu paro o desenvolvimento da placa de circuito impresso para poder usar as caixas Patola, senão eu vou usar as caixas grandes do Carchano como base para o projeto mesmo.

Eu conversei também com o Rogério Belarmino sobre a possibilidade da Technobytes produzir o emulador de interface de disco quando o produto estiver em um estágio mais maduro. Afinal de contas o emulador é um projeto open source e qualquer um pode produzir e vender o produto se quiser sem ter que pagar nada por isto. Particularmente falando é fácil para mim produzir as minhas próprias placas e até gosto de fazer placas como um hobby. Mas eu sei que tem gente que gostaria de ter acesso ao emulador mas não tem as habilidades e/ou recursos necessários para por o projeto em prática. Então se a Technobytes ou o Carchano resolverem reproduzir o projeto seria muito legal.

No mais, eu não fiquei até o final do evento porque havia trabalhado no dia anterior até as 22:00 e estava realmente cansado. O grande evento do encontro acredito que seria um novo desenvolvimento do Oazem mas infelizmente não consegui ficar até a apresentação ser realizada. 

Um abraço,

José Paulo

Atualização do projeto de emulador de interface de disquete (#8) - It Works!

Olá,

Ótimas notícias! O emulador de interface de disquete para MSX está funcionando! Conforme podemos ver acima há duas fotos dos jogos "Elevator Action" e "Abadia do Crime". Jogos estes que foram carregados para o meu Expert 1.0 usando a interface. Muito legal.

Basicamente não houve qualquer alteração no circuito desde a última atualização postada aqui. O que houve foi a correção de alguns bugs e a interface passou a funcionar ok. Eu aproveitei e escrevi o código necessário para permitir escritas em disco e com algum sucesso eu consigo realizar escritas. Por exemplo, se eu escrever um programa em basic e executar o comando save o programa será salvo, porém, ainda há algum bug no código do firmware porque se eu escrever vários programas, e tentar salva-los, alguns serão escritos e outros não. Este problema eu ainda tenho que investigar mais a fundo.

De qualquer maneira o problema descrito acima ainda não é o foco para o momento. Como o protótipo está funcionando no protoboard, o que prova que o conceito do circuito está correto, eu decidi focar minha atenção em criar a parte física do projeto, i.e., diagrama elétrico e placa de circuito impresso.

Abaixo segue uma imagem da revisão 1 do diagrama elétrico:

 

 O link para o projeto do circuito (Kicad) segue abaixo:

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

A "revisão 1" do diagrama elétrico ainda não representa todo o circuito, falta ainda interligações a serem feitas mas o grosso do circuito está lá.

Conforme prometido meses atrás eu pretendo disponibilizar todo o projeto como sendo OSHW (Open Source Hardware) e seguindo o que determina a licença GNU segue no diagrama uma cópia da disposições gerais da licença. O motivo para eu ter colocado o circuito sob a licença GNU e não em domínio público é para garantir o meu reconhecimento. Muito trabalho e muito esforço tem sido colocado por mim neste projeto e o mínimo que eu peço é que as pessoas, caso venham a comercializar e/ou modificar o projeto que mencionem o meu nome como o iniciador ou fundador do projeto. É só.

Além disto, não está mais disponível no dropbox as revisões do código do firmware que eu disponibilizei antes. O motivo para isto é que eu quero realizar um "clean-up", documentar o código  e acrescentar os avisos da licença GNU antes de compartilhar o código. Além disto eu acho que vou iniciar um projeto no Source Forge e colocar o código disponível lá.

No mais, no próximo sábado (19/10/2013) acontecerá a MSXRIO 2013 e eu pretendo mostrar o meu protótipo funcionando lá. Como eu somente enviei um pedido para reserva de mesa hoje eu não sei se vou conseguir mesa para expor meu projeto. De qualquer forma, caso eu consiga vai ser muito legal. Espero que com isto eu consiga a adesão de mais pessoas para o projeto já que até o momento tem sido um projeto de uma pessoa com algumas participações pontuais.

Um abraço,

José Paulo

Adaptador para cartões Micro SD

Olá,

Foto Superior

Foto Inferior

  

 

Eu criei uma placa para adaptar cartões micro sd ao meu protoboard para me permitir fazer experiências com estes dispositivos. As fotos do resultado final estão disponíveis acima. É possível utilizar um adaptador de micro sd para sd para adaptar os cartões ao protoboard e é isto que eu fazia mas descobri que estes adaptadores de micro sd para sd não são muito robustos e logo passam a apresentar mal contato.

Abaixo segue o link para o projeto do Kicad com o esquemático e o design da placa de circuito impresso. Espero que seja de alguma utilidade para alguém.

https://dl.dropboxusercontent.com/u/62498964/Adaptador%20microsd.zip

Um abraço,

José Paulo

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

Olá,

Acima segue a última foto atualizada do protótipo do emulador de interface de disquete. No circuito em si há poucas alterações, eu troquei o teclado que eu estava usando por um outro mais robusto e fiz um adaptador de cartão SD usando de fato um conector para cartões SD. Antes eu estava fazendo testes com cartões sd usando uma adaptação parecida com a da imagem abaixo:

Uma adaptação como da foto acima funciona mas eu acho que estes adaptadores de micro sd para sd não foram feitos para você ficar inserindo e removendo os cartões a todo o instante. Como estamos usando um circuito de teste que a todo o instante precisamos trocar os cartões logo o adaptador começa a apresentar problemas de mal contato. Para resolver este problema eu fiz uma placa de circuito com um conector para cartões micro sd de verdade e que me parece ser de boa qualidade e na placa eu inseri os resistores de pull up smd de 33K necessários para a interface com o cartão e um capacitor de 100nF entre a linha de alimentação e o terra. Os componentes smd não podem ser vistos porque estão soldados por baixo da placa adaptadora. A inserção destes componentes smd diminuiu um pouco a quantidade de fios no protoboard e melhorou a robustez do circuito.

Como podemos ver na foto acima eu coloquei 4 resistores de 100 ohms em série com os sinais do cartão smd e isto também melhorou bastante a qualidade da comunicação com o cartão sd.

As maiores alterações e aonde eu tenho alocado a maior parte do meu esforço é em desenvolver o firmware e eu fiz grandes progressos neste quesito.

As rotinas que fazem a comunicação com o cartão SD eu já tinha feito e praticamente não sofreram alterações. No estágio atual eu consigo acessar normalmente alguns cartões e outros não. Conforme eu já havia escrito anteriormente eu creio que o problema reside no fato de que nem todos os cartões sd suportam comunicação SPI. De qualquer forma eu consigo acesso tanto a cartão normais como cartões HD (High Density), então, para mim, já está bastante satisfatório para não ter mais que me preocupar com estas rotinas.

Numa camada acima estão as rotinas que manipulam a estrutura FAT existente nos cartões. Inicialmente eu tentei usar o Petit FatFs sem sucesso então eu parti para criar eu mesmo minhas próprias rotinas de manipulação do FAT. Hoje eu consigo navegar na estrutura de diretório e abrir os arquivos dsk o que é também bastante satisfatório.

Com as rotinas descritas acima prontas eu fui capaz de melhorar a interface com o usuário e de finalmente emular a interface com o MSX de forma a permitir ao computador que tenha finalmente acesso aos dados contidos nos arquivos dsk. Abaixo segue uma série de fotos da interface com o usuário em ação. Abaixo segue a foto da tela inicial do circuito:

 

A interface do circuito com o usuário se resume a quatro botões que eu vou chamar de "seta para cima", "seta para baixo", "Selecionar" e "Voltar". Nesta tela se eu teclar as setas eu seleciono as várias opções existentes no menu principal, o botão "voltar" não possui função neste tela e a tecla "selecionar" seleciona a opção desejada. Se na tela acima eu pressionar o botão "selecionar" eu pulo para a tela de seleção de arquivo. Caso não haja um cartão sd inserido ou caso ocorra algum erro de leitura no cartão sd aparece uma mensagem de erro e teclando qualquer tecla voltamos para o menu principal. Existindo um cartão sd que não apresente erros nos pulamos para a tela de seleção de arquivos no qual eu posso navegar na estrutura de arquivos do cartão sd e eu posso selecionar arquivos com extensão dsk. Qualquer outro arquivo existente no cartão não será mostrado. Caso o cartão não possua subdiretórios e não possua arquivos com extensão dsk aparecerá a mensagem de disco vazio e pressionando qualquer tecla voltaremos para o menu principal.

Na imagem acima podemos ver o resultado após pressionarmos a tecla "selecionar". No caso do cartão em questão temos um subdiretório chamado "TESTE1".

Se teclarmos o botão "selecionar" novamente nos entramos dentro do subdiretório TESTE1. Na imagem acima podemos ver a primeira entrada do subdiretório "TESTE1" que é a entrada "." que nada mais é do que uma referência ao próprio diretório. Na sequência temos a entrada ".." que é uma referencia ao subdiretório ou diretório raiz anterior ao subdiretório atual. Uma curiosidade: se teclarmos ao botão "voltar" nos não voltamos para o subdiretório anterior, mas sim para o Menu Principal. Enquanto na tela de seleção de arquivos o botão "voltar" sempre volta para o menu principal. Sendo assim para voltamos um nível na estrutura de diretórios temos que selecionar a entrada ".." e teclar o botão "selecionar".

Navegando na estrutura do subdiretório de exemplo "TESTE1" encontramos o arquivo da imagem abaixo:

 

No meio do nome do arquivo existe uma seta para a direita mas isto na verdade é o equivalente no display LCD ao caractere "~" de forma que o nome correto do arquivo é "ELEVAT~1.DSK". No display de LCD que eu estou usando não existe o caractere "~" mas eu creio que da para viver com este caractere trocado. O nome do arquivo continua bastante legível. Aliás, a rotina também somente amostra as entradas de diretório com o nome no formato 8.3. Nomes de arquivos e subdiretórios estendidos não são apresentados, mas isto não chega a ser um problema porque sempre existe duas entradas de diretório para o mesmo arquivo ou subdiretório uma no formato 8.3 e a outra no formato estendido. Isto faz parte da especificação do FAT32.

Neste momento se pressionarmos a tecla "selecionar" finalmente disponibilizamos um arquivo para o MSX manipular. Antes deste momento o MSX sempre obtém do registrador de status a informação de "drive not ready", i.e., uma leitura no endereço de IO D0 sempre obtém o valor 0x80. Com a seleção do arquivo a leitura do status passa a representar o estado atual do arquivo. Por exemplo, se o arquivo dsk selecionado tiver com a flag de read-only ativa o MSX receberá a informação de disco protegido contra gravação. Abaixo segue a foto da tela após a seleção do arquivo.

 

Na tela acima além de vermos o nome do arquivo selecionado podemos ver que o disco não está protegido contra gravação - cadeado aberto - e podemos ver os valores selecionados de cabeça, trilha e setor. Estes valores são atualizados automaticamente quando o MSX passa a manipular o "disk drive". Neste momento o MSX poderia acessar o arquivo dsk como se fosee um disco magnético real e é neste ponto que eu estou tendo problemas.

 

Com o arquivo selecionado se eu executar o comando "files" para listar os arquivos existente dentro do arquivo dsk o MSX apresenta a listagem correta. No caso da imagem acima está sendo apresentado o conteúdo do disco do jogo "Elevator Action", mas se eu digitar load "autoexec.bas" o MSX acessa o setor 2 da trilha 0, cabeça 0, depois o setor 6 da trilha 0 e da cabeça 0 e depois fica lendo o registrador de status indefinidamente como se estivesse esperando alguma coisa acontecer e não concluí o comando load. Eu realmente não consigo entender que alteração do status que ele está esperando que aconteça. De qualquer forma eu estou neste estágio de desenvolvimento.

Além disto, estou tendo problemas com a programação do PIC em si. Não consigo em hipótese alguma fazer com que a rotina de interrupção de baixa prioridade funcione para mim. Eu não consigo entender o porquê e eu preciso que isto funcione porque eu preciso temporizar diversas tarefas dentro do meu código. Isto é uma coisa que tem me aborrecido bastante e estou inclusive pensando em trocar o PIC 18F4550 por um PIC24FJ64GA004. A minha maior resistência a esta ideia é o fato de que isto representaria um retrocesso muito grande para tudo aquilo que eu já obtive até o momento. Se na próxima semana eu não obtiver uma resposta para este problema vou ter que começar quase que do zero na criação do meu projeto.

Abaixo segue o link do código fonte do firmware até o momento. O código está precisando de um clean up porque você vai testando e mudando coisas no seu código e chega um pouco que as coisas começam a ficar confusas. De qualquer forma o código está ai para quem quiser estudar e participar do projeto.

https://dl.dropboxusercontent.com/u/62498964/MSXFirmware_3.X%2020130929.zip

Um abraço,

José Paulo