Eu e o Igor testamos neste final de semana o circuito da interface SD/MMC funcionando a 14MHz com um 'clock' gerado a partir de um cristal. O Objetivo é transferir os dados em até 1,7uS após a instrução INI/OUTI, pra poder funcionar no TurboR em modo R800.
O crítico é o circuito de adaptação de lógica TTL para 3V, que até 3,5MHz funciona bem, mas com uma frequência mais alta ele simplesmente não consegue acompanhar. Vamos agora testar circuitos de adaptação baseados em um transistor na configuração Base Comum, dotado de um 'pull up' ativo.
Nas medições que fizemos descobrimos também que que o inversor a transistor demora muito tempo para desligar (sair da saturação ao corte) e o substituímos por uma porta lógica, aproveitada do próprio circuito oscilador.
Projetos para computadores MSX
Mostrando postagens com marcador Leitor de SD/MMC. Mostrar todas as postagens
Mostrando postagens com marcador Leitor de SD/MMC. Mostrar todas as postagens
segunda-feira, 14 de maio de 2007
segunda-feira, 16 de abril de 2007
Correção da montagem
A correção do circuito, para corrigir a fase do sinal de 'clock' aplicado ao 74LS165 pode ser vista na figura abaixo: Basta remover os jumpers indicados em Azul escuro, e fazer duas novas ligações, conforme indicado em Azul claro. (Clique na imagem para ampliar)
A correção para a versão da placa com 50 pinos é nos mesmos pontos.
A correção para a versão da placa com 50 pinos é nos mesmos pontos.
Documentação dos 'Drivers' I2C e SD/MMC
Terminei a primeira versão da documentação dos 'Drivers' SD/MMC.
Tenho estudado algum material sobre FAT, e vislumbro utilizar uma implementação já pronta de FAT escrita em C, mas também tenho em mente algumas idéias para poder ler/escrever arquivos num cartão formatado em FAT, sem ter que ter que manipular a FAT, ou seja, sem ter que me preocupar com alocação/realocação de cadeias, criação de entradas em diretórios, etc.
Tenho estudado algum material sobre FAT, e vislumbro utilizar uma implementação já pronta de FAT escrita em C, mas também tenho em mente algumas idéias para poder ler/escrever arquivos num cartão formatado em FAT, sem ter que ter que manipular a FAT, ou seja, sem ter que me preocupar com alocação/realocação de cadeias, criação de entradas em diretórios, etc.
sábado, 14 de abril de 2007
Correções e 'Updates'
Durante os testes para fazer o circuito funcionar com um 'clock' de 2x3.58Mhz uma certa instabilidade foi notada durante os testes de 'loopback'. Uma investigação mais detalhada mostrou que a linha de 'clock' (linha SCK) do registrador 74165 deveria ser invertida em relação à linha de 'clock' do registrador 74595, vide desenho abaixo:
Com o 'clock' de 3,5Mhz a instabilidade nunca se manifestou, por isso este 'bug' havia passado despercebido até o momento.
A correção consiste em desconectar o pino 2 de IC2 (74165) da linha SCK e conectá-lo à linha /SCK, pino 1 do 7400 (na realidade 1, 9 10 e 11 estão interligados). Vide figura abaixo:
O Guia de Montagem e teste sofreu uma atualização, onde foram descobertos alguns errinhos, remanescentes da inversão das linhas D0 e D7 do registrador Paralelo. Estes foram corrigidos e o documento encontra-se atualizado.
Eu comecei a escrever a documentação dos drivers. A documentação das Rotinas I2C já está pronta, e estou trabalhando no momento na documentação das rotinas do cartão.
Com o 'clock' de 3,5Mhz a instabilidade nunca se manifestou, por isso este 'bug' havia passado despercebido até o momento.
A correção consiste em desconectar o pino 2 de IC2 (74165) da linha SCK e conectá-lo à linha /SCK, pino 1 do 7400 (na realidade 1, 9 10 e 11 estão interligados). Vide figura abaixo:
O Guia de Montagem e teste sofreu uma atualização, onde foram descobertos alguns errinhos, remanescentes da inversão das linhas D0 e D7 do registrador Paralelo. Estes foram corrigidos e o documento encontra-se atualizado.
Eu comecei a escrever a documentação dos drivers. A documentação das Rotinas I2C já está pronta, e estou trabalhando no momento na documentação das rotinas do cartão.
Primeiro FAQ
Respondendo a algumas questões, postadas aqui e no msx.org
P: Quanto custa?
R: Eu gastei menos de R$80,00 em componentes para montar a placa base, a placa de relógio de Tempo Real, e o adaptador de MMC/SD. Coloquei uma planilha com código Farnell dos componentes usados nestas placas na área de arquivos do projeto.
P: Tem pra vender?
R: Este é um projeto que foi desenvolvido pensando na construção caseira, mas como eu estou ciende de que nem todos entusiastas do MSX têm condições/tempo/recursos/conhecimentos técnicos para montar este circuito, (especialmente por causa das placas de circuito impresso), eu escolhi utilizar uma licença livre neste projeto, de forma que qualquer um, até mesmo uma empresa, pode realizar, e até mesmo vender o circuito montado, bastando respeitar a liberdade do projeto, ou seja, utilizando a mesma licença livre qualquer implementação, modificação, otimização para o hardware/software, e mantendo os créditos originais do projeto.
P:Tem como conseguir somente as placas?
R: As placas foram projetadas para serem feitas em casa, com métodos caseiros ([1] [2] [3] [4]). É uma boa chance de aprendizado. Eu mesmo nunca mais usei proto-board depois que aprendi esta técnica. Outra opção é mandar fazer em alguma empresa que trabalhe com baixas quantidades. Uma busca rápida no google já retorna várias possibilidades.
P: É um cartucho independente? Pode ser conectada direto conector do ao MSX ?
R: A placa base tem 2 versões: Uma com um conector de 50 pinos, feita pra ser conectada à traseira do Expert via cabo 'Flat' de 50 vias, mas que pode ser facilmente adaptada a qualquer MSX; e outra, que é conectada via 'Flat' de 34 a uma outra placa contendo uma ROM e um mecanismo de chaveamento semelhante a uma Megarom (vide projeto CARTUCHO MSXDOS2 do site MSXPro)
P: Aonde posso encontrar um arquivo ZIP com todo o projeto?
R: Ainda não agrupei tudo num arquivo só, mas meu 'repositório' encontra-se no link abaixo:
http://www.vespanet.com.br/~danjovic/msx/HB-7000.
P: Funciona no Turbo R em modo R800?
R: Por enquanto ainda não, pois apesar de executar internamente as instruções com um 'clock' elevado, externamente, no barramento, o 'clock' é de apenas 3,58Mhz, e não dá tempo, entre duas instruções consecutivas, do circuito serializar os dados. Mas o Igor esta trabalhando firmemente nisso agora. Mas com certeza vai ser possível. A estimativa é que a velocidade de transferência suba para 1 byte a cada 1.7us, o que dá algo em torno de 570KBytes/s. Então vale a pena investir um pouco mais de tempo e colocar 1 ou 2 CIs a mais na placa.
P: Tem que ser MSX com mapper ?
R: O projeto foi desenvolvido num Hotbit 1.1 "pelado". Ainda falta desenvolver um "patch" pro DOS/BDOS (veja post abaixo), mas espero que no final não precise de mais nada a não ser o cartucho com a ROM.
P: Ele lê o SD/MMC como sendo HD? Qual sistema de arquivos ele usa?
R: Quando estabeleci os requisitos do projeto, propositalmente não incluí entre eles a adaptação com o BDOS/MSXDOS por se tratar, do meu ponto de vista, de um projeto à parte, numa "camada" superior. Mas provi as funções de baixo nível necessárias: 'INIT', 'READ BLOCK' e 'WRITE BLOCK' (e algumas funções impressão de erro). Como nunca programei para BDOS/MSXDOS (meu MSX nem tem Disk Drive), achei melhor solicitar auxílio nesse sentido, antes de partir para uma iniciativa própria.
P: Quanto custa?
R: Eu gastei menos de R$80,00 em componentes para montar a placa base, a placa de relógio de Tempo Real, e o adaptador de MMC/SD. Coloquei uma planilha com código Farnell dos componentes usados nestas placas na área de arquivos do projeto.
P: Tem pra vender?
R: Este é um projeto que foi desenvolvido pensando na construção caseira, mas como eu estou ciende de que nem todos entusiastas do MSX têm condições/tempo/recursos/conhecimentos técnicos para montar este circuito, (especialmente por causa das placas de circuito impresso), eu escolhi utilizar uma licença livre neste projeto, de forma que qualquer um, até mesmo uma empresa, pode realizar, e até mesmo vender o circuito montado, bastando respeitar a liberdade do projeto, ou seja, utilizando a mesma licença livre qualquer implementação, modificação, otimização para o hardware/software, e mantendo os créditos originais do projeto.
P:Tem como conseguir somente as placas?
R: As placas foram projetadas para serem feitas em casa, com métodos caseiros ([1] [2] [3] [4]). É uma boa chance de aprendizado. Eu mesmo nunca mais usei proto-board depois que aprendi esta técnica. Outra opção é mandar fazer em alguma empresa que trabalhe com baixas quantidades. Uma busca rápida no google já retorna várias possibilidades.
P: É um cartucho independente? Pode ser conectada direto conector do ao MSX ?
R: A placa base tem 2 versões: Uma com um conector de 50 pinos, feita pra ser conectada à traseira do Expert via cabo 'Flat' de 50 vias, mas que pode ser facilmente adaptada a qualquer MSX; e outra, que é conectada via 'Flat' de 34 a uma outra placa contendo uma ROM e um mecanismo de chaveamento semelhante a uma Megarom (vide projeto CARTUCHO MSXDOS2 do site MSXPro)
P: Aonde posso encontrar um arquivo ZIP com todo o projeto?
R: Ainda não agrupei tudo num arquivo só, mas meu 'repositório' encontra-se no link abaixo:
http://www.vespanet.com.br/~danjovic/msx/HB-7000.
P: Funciona no Turbo R em modo R800?
R: Por enquanto ainda não, pois apesar de executar internamente as instruções com um 'clock' elevado, externamente, no barramento, o 'clock' é de apenas 3,58Mhz, e não dá tempo, entre duas instruções consecutivas, do circuito serializar os dados. Mas o Igor esta trabalhando firmemente nisso agora. Mas com certeza vai ser possível. A estimativa é que a velocidade de transferência suba para 1 byte a cada 1.7us, o que dá algo em torno de 570KBytes/s. Então vale a pena investir um pouco mais de tempo e colocar 1 ou 2 CIs a mais na placa.
P: Tem que ser MSX com mapper ?
R: O projeto foi desenvolvido num Hotbit 1.1 "pelado". Ainda falta desenvolver um "patch" pro DOS/BDOS (veja post abaixo), mas espero que no final não precise de mais nada a não ser o cartucho com a ROM.
P: Ele lê o SD/MMC como sendo HD? Qual sistema de arquivos ele usa?
R: Quando estabeleci os requisitos do projeto, propositalmente não incluí entre eles a adaptação com o BDOS/MSXDOS por se tratar, do meu ponto de vista, de um projeto à parte, numa "camada" superior. Mas provi as funções de baixo nível necessárias: 'INIT', 'READ BLOCK' e 'WRITE BLOCK' (e algumas funções impressão de erro). Como nunca programei para BDOS/MSXDOS (meu MSX nem tem Disk Drive), achei melhor solicitar auxílio nesse sentido, antes de partir para uma iniciativa própria.
Portanto se algum desenvolvedor tiver interesse em adaptar o MSXDOS para este funcionar com este circuito, por favor entre em contato.
terça-feira, 10 de abril de 2007
Primeiro "Release"
É com imensa satisfação que anuncio o primeiro "release" da interface de cartões SD/MMC para MSX, cujas principais características são:
Investi neste projeto boa parte do meu tempo livre (e algumas centenas de Reais) com um objetivo: Provar para os "Speccers" [1],[2],[3] e "Applemaníacos" que eu gosto tanto do meu MSX quanto eles gostam dos micros deles!
Por isso, seguindo uma filosofia semelhante, este também é um projeto livre, e estão disponíveis todas as informações necessárias para quem quiser construir o seu. É permitido até mesmo construir e vender para terceiros, contanto que se mantenham os créditos originais da autoria do projeto, as mesmas licenças, e que se mantenham igualmente livres quaisquer modificações/implementações baseadas neste projeto, como incorporação de seus blocos lógicos dentro de CPLDs ou FPGAs.
Quero ainda agradecer ao amigo Igor, que desde o início vem acompanhando e ajudando com este projeto (e também com outros para o MSX) .
(vista geral do protótipo2)
- Concepção 100% livre (aberta) de "Hardware" de "software/firmware";
- Aceita cartões SD e MMC;
- Taxa de leitura/escrita 154/145 KBytes/segundo num MSX1 a 3,58MHz
- Mapeado em I/O dentro da norma MSX, (Portas <3fh,>
- Possui interface I2C;
- Possui relógio de tempo Real I2C;
- Utiliza apenas componentes comuns;
- Montado em placa de circuito impresso de face simples, construída com métodos caseiros;
Investi neste projeto boa parte do meu tempo livre (e algumas centenas de Reais) com um objetivo: Provar para os "Speccers" [1],[2],[3] e "Applemaníacos" que eu gosto tanto do meu MSX quanto eles gostam dos micros deles!
Por isso, seguindo uma filosofia semelhante, este também é um projeto livre, e estão disponíveis todas as informações necessárias para quem quiser construir o seu. É permitido até mesmo construir e vender para terceiros, contanto que se mantenham os créditos originais da autoria do projeto, as mesmas licenças, e que se mantenham igualmente livres quaisquer modificações/implementações baseadas neste projeto, como incorporação de seus blocos lógicos dentro de CPLDs ou FPGAs.
Quero ainda agradecer ao amigo Igor, que desde o início vem acompanhando e ajudando com este projeto (e também com outros para o MSX) .
(vista geral do protótipo2)
Fechamento de atividades
Depois dos testes realizados no feriado, e da conclusão de algumas outras atividades pendentes, resolvi fechar as atividades da versão inicial do leitor de SD/MMC.
Contudo, as seguintes atividades ficaram postergadas em relação ao "release" inicial:
Contudo, as seguintes atividades ficaram postergadas em relação ao "release" inicial:
- Construção de duas placas base;
- Medição do consumo, pois este não se mostrou como ítem crítico;
- Solucão do problema de funcionamento do Turbo-r em modo Turbo (R800), por não fazer parte dos requisitos iniciais (embora esta agora vá ser a próxima prioridade);
segunda-feira, 9 de abril de 2007
Testes no Turbo-R
Durante o final de semana eu e o Igor fizemos uns testes no Turbo-R dele. Em modo MSX2, o circuito funcionou corretamente, mas em modo TURBO, o cartão não respondia.
Investigamos até encontrar a causa: O Turbo-R, em modo TURBO, executa internamente as instruções do Z80 com um "clock" maior, mas mantém no barramento externo os mesmos 3,5MHz, e por isso, executa a próxima instrução OUTI/INI antes que o byte da instrução anterior tenha sido serializado.
Em números:
A 3,58MHz, um período de Clock dura 280ns. Para serializar 8 bits são necessários pelo menos 2,24us, e o intervalo de tempo entre duas instruções OUTI/INI é de 16+4(WS) ciclos de clock, ou seja, 5,6us.
No Turbo-R em modo Turbo, o intervalo (medido no osciloscípio) entre duas instruções OUTI/INI consecutivas era de apenas 1,7uS. (Estranho pois este valor corresponde a 11,764Mhz - considerando 20 instruções por ciclo de clock)
Ou seja, Eu precisaria de no mínimo 2,24us entre uma instrução e outra, mas so tinha 1,7us. Para confirmar este raciocínio, fizemos um "driver" em Basic pra inicializar o cartão, rodando modo turbo, e o cartão respondeu corretamente.
Conclusões:
Para o circuito funcionar no Turbo-R, Duas abordagens são possíveis:
A criação de um "driver" específico além de não ser uma solução elegante, pode até trazer perdas na taxa de transferência. A outra opção, aumentar o "clock" pode ser conseguida através de um oscilador e um sincronizador, ou de um dobrador de "clock".
Embora o dobrador de clock não aumente a taxa de transferência num MSX1/2, no Turbo R ela sobe consideravelmente, pois transferir um byte a cada 1,7us equivale a uma taxa de pico teórica de 588Kbytes/segundo, ou aproximatamente 4,6Mbits/segundo (no MSX1/2 o pico teórico máximo é de 178Kbytes/s ou 1,4Mbits/s)
Fizemos algumas experiências com um dobrador, usando um 74LS86 (Quad XOR). O dobrador funcionou corretamente, mas por algum motivo que não deu ainda tempo de investigar, a contagem automática de pulsos se encerra no sétimo pulso, em vez do oitavo.
Dobrador de "clock"
Investigamos até encontrar a causa: O Turbo-R, em modo TURBO, executa internamente as instruções do Z80 com um "clock" maior, mas mantém no barramento externo os mesmos 3,5MHz, e por isso, executa a próxima instrução OUTI/INI antes que o byte da instrução anterior tenha sido serializado.
Em números:
A 3,58MHz, um período de Clock dura 280ns. Para serializar 8 bits são necessários pelo menos 2,24us, e o intervalo de tempo entre duas instruções OUTI/INI é de 16+4(WS) ciclos de clock, ou seja, 5,6us.
No Turbo-R em modo Turbo, o intervalo (medido no osciloscípio) entre duas instruções OUTI/INI consecutivas era de apenas 1,7uS. (Estranho pois este valor corresponde a 11,764Mhz - considerando 20 instruções por ciclo de clock)
Ou seja, Eu precisaria de no mínimo 2,24us entre uma instrução e outra, mas so tinha 1,7us. Para confirmar este raciocínio, fizemos um "driver" em Basic pra inicializar o cartão, rodando modo turbo, e o cartão respondeu corretamente.
Conclusões:
Para o circuito funcionar no Turbo-R, Duas abordagens são possíveis:
- Criar um "driver" específico para o Turbo R
- Aumentar o "clock" do gerador de "clock" automático.
A criação de um "driver" específico além de não ser uma solução elegante, pode até trazer perdas na taxa de transferência. A outra opção, aumentar o "clock" pode ser conseguida através de um oscilador e um sincronizador, ou de um dobrador de "clock".
Embora o dobrador de clock não aumente a taxa de transferência num MSX1/2, no Turbo R ela sobe consideravelmente, pois transferir um byte a cada 1,7us equivale a uma taxa de pico teórica de 588Kbytes/segundo, ou aproximatamente 4,6Mbits/segundo (no MSX1/2 o pico teórico máximo é de 178Kbytes/s ou 1,4Mbits/s)
Fizemos algumas experiências com um dobrador, usando um 74LS86 (Quad XOR). O dobrador funcionou corretamente, mas por algum motivo que não deu ainda tempo de investigar, a contagem automática de pulsos se encerra no sétimo pulso, em vez do oitavo.
Dobrador de "clock"
quinta-feira, 5 de abril de 2007
Fechando a documentação.
Acabei de acertar biblioteca com a caixa Patola para MSX, e de gerar todos os diagramas e "layouts" (estes em 300 e 600 dpi) dos componentes do sistema formato em formato GIF. Falta gerar os arquivos EPS com todos os "layouts"e ajuntaro ao pacote.
Falta ainda converter os códigos fonte dos "drivers" e programas de teste para formato "WAV".
A atualização do guia de montagem e teste vai ser feita em conjunto com o Igor, que vai montar uma interface na versão de 50 pinos, enquanto eu vou montar uma outra na versão de 34.
O consumo em modo de gravação eu vou medir na casa do Igor durante o feriado de páscoa. Pretendemos testar no Expert, no Hotbit e também no Turbo R que ele tem.
Falta ainda converter os códigos fonte dos "drivers" e programas de teste para formato "WAV".
A atualização do guia de montagem e teste vai ser feita em conjunto com o Igor, que vai montar uma interface na versão de 50 pinos, enquanto eu vou montar uma outra na versão de 34.
O consumo em modo de gravação eu vou medir na casa do Igor durante o feriado de páscoa. Pretendemos testar no Expert, no Hotbit e também no Turbo R que ele tem.
sábado, 31 de março de 2007
Outra Atualização de Status
Outra atualização de Status, com as atividades que faltam, antes do primeiro "release" do projeto:
- Atualizar o guia de montagem e teste;
- Atualizar o "layout" das placa do cartucho de adaptação por causa de uma discrepância entre a furação da placa biblioteca da caixa Patola e a caixa real.
- Medir o consumo do circuito, durante uma gravação do cartão
- Disponibilizar todos os diagramas e "lay-outs" em formato Eagle, EPS e GIF;
- Disponibilizar todas as listagens e os arquivos .wav dos "drivers" e dos programas de teste
Programa de teste de SD/MMC concluído
Concluí o programa que testa a interface com cartões SD e MMC. Eu fiz uma ligeira modificação no programa em assembler, para registrar o incremento da variável JIFFY (timer do MSX) e poder ter um 'benchmark' da velocidade de transferência . Eis um vídeo do programa rodando com um cartão SD inserido no soquete, e mais abaixo abaixo a captura das telas com um cartão MMC e um SD.
leitura CID/CSD com cartão MMC
leitura e escrita com cartão MMC
leitura CID/CSD com cartão SD
leitura e escrita com cartão SD
leitura CID/CSD com cartão MMC
leitura e escrita com cartão MMC
leitura CID/CSD com cartão SD
leitura e escrita com cartão SD
Versão 1.0a da placa da interface HB-7000
Esta versão da placa é feita especialmente para ser ligada ao conector traseiro do Expert, através de um cabo "flat" de 50 vias.
quinta-feira, 29 de março de 2007
Versão 1.0 da placa da interface HB-7000
concluí hoje o roteamento da versão 1.0 da placa da interface HB-7000, já com conector de 34 pinos e controle (opcional) do sinal /BUSDIR.
A incorporação do sinal Busdir, foi para fazer esta placa 100% compatível com o padrão MSX, mas incluí também um "jumper" que permite desconectar o sinal /BUSDIR, para os casos em que o circuito vá operar conectado diretamente ao barramento de um micro que possua um expansor de slots com "buffer" interno cujo circuito não tenha sido projetado pensando na utilização de 2 ou mais expansors simultaneamente.
A incorporação do sinal Busdir, foi para fazer esta placa 100% compatível com o padrão MSX, mas incluí também um "jumper" que permite desconectar o sinal /BUSDIR, para os casos em que o circuito vá operar conectado diretamente ao barramento de um micro que possua um expansor de slots com "buffer" interno cujo circuito não tenha sido projetado pensando na utilização de 2 ou mais expansors simultaneamente.
quarta-feira, 28 de março de 2007
Busdir
Um requisito de última hora, resultado de uma conversa com o Igor sobre BUSDIR.
Para estar demtro da norma, um periférico que utilize leitura em I/O deve gerar o sinal BUSDIR com base nos sinais /IORQ, /RD e da lógica de decodificação interna.
Eu utilizei dois "buffers tristate" ociosos do 74HCT125 para gerar um sinal /BUSDIR a partir dos sinais /RD0 e /RD1.
Para estar demtro da norma, um periférico que utilize leitura em I/O deve gerar o sinal BUSDIR com base nos sinais /IORQ, /RD e da lógica de decodificação interna.
Eu utilizei dois "buffers tristate" ociosos do 74HCT125 para gerar um sinal /BUSDIR a partir dos sinais /RD0 e /RD1.
sexta-feira, 23 de março de 2007
Cálculos para a rotina de teste de escrita
Achei a conta que tenho que fazer. Eu preciso calcular o endereço da metade do cartão. Eu já sei calcular o tamanho em blocos de 512bytes.
Apesar das operações de transferência com o cartão serem sempre em blocos, o padrão de endereçamento de dados é byte a byte, usando 32 bits A3-A2-A1-A0, onde A[3..0] têm 8 bits cada um. Apesar disso, todas as operações de leitura e escrita têm que utilizar alinhamento de bloco, ou seja, têm que ser múltiplos de 512bits, senão o cartão reporta um erro de endereçamento ilegal.
Para realizar o teste de escrita, eu escolhi escrever em uma sequência de blocos que fica na metade do tamanho máximo do cartão, pois aí certamente será uma área de dados, e já estará depois da FAT.
Como eu utilizo um programa Basic que faz interface com um programa em Assembler, eu preciso converter o tamanho em blocos num número que corresponda ao endereço da metade do cartão,
Então faço o seguinte:
Com este cálculo eu transformo o valor T_blocos em 4 bytes, B4,B3,B2,B1. O cálculo de B4 é mais para a conta ficar genérica, pois dado que o cartão SD/MMC utilizam 32 bits para endereçar, ou seja, suporta apenas 4GB. O valor de A4 vai ser sempre 0.
Dado que cada bloco tem 512 bytes, para obter a posição do último byte do cartão, eu tenho que multiplicar o tamanho em blocos por 512. Assim para para obter a posição do byte que fica na metade do cartão, eu tenho que multiplicar o tamanho em blocos por 256, ou seja, deslocar 8 bits para a esquerda.
Isso é feito utilizando-se como endereço:
Vou implementer estas rotinas no programa Basic e continuar o trabalho.
Apesar das operações de transferência com o cartão serem sempre em blocos, o padrão de endereçamento de dados é byte a byte, usando 32 bits A3-A2-A1-A0, onde A[3..0] têm 8 bits cada um. Apesar disso, todas as operações de leitura e escrita têm que utilizar alinhamento de bloco, ou seja, têm que ser múltiplos de 512bits, senão o cartão reporta um erro de endereçamento ilegal.
Para realizar o teste de escrita, eu escolhi escrever em uma sequência de blocos que fica na metade do tamanho máximo do cartão, pois aí certamente será uma área de dados, e já estará depois da FAT.
Como eu utilizo um programa Basic que faz interface com um programa em Assembler, eu preciso converter o tamanho em blocos num número que corresponda ao endereço da metade do cartão,
Então faço o seguinte:
T_Blocos=Tamannho em blocos de 512 bytes
TBH= int(T_blocos/65536)
TBL= T_blocos-TBH*65536
B4=int(TBH/256)
B3=TBH-B4*256
B2= int(TBL/256)
B1= TBL-B2*256
Com este cálculo eu transformo o valor T_blocos em 4 bytes, B4,B3,B2,B1. O cálculo de B4 é mais para a conta ficar genérica, pois dado que o cartão SD/MMC utilizam 32 bits para endereçar, ou seja, suporta apenas 4GB. O valor de A4 vai ser sempre 0.
Dado que cada bloco tem 512 bytes, para obter a posição do último byte do cartão, eu tenho que multiplicar o tamanho em blocos por 512. Assim para para obter a posição do byte que fica na metade do cartão, eu tenho que multiplicar o tamanho em blocos por 256, ou seja, deslocar 8 bits para a esquerda.
Isso é feito utilizando-se como endereço:
A0=0
A1=B1
A2=B2
A3=B3
Vou implementer estas rotinas no programa Basic e continuar o trabalho.
quarta-feira, 21 de março de 2007
Módulo RTC (atualizado)
Dando prosseguimento às atividades, reprojetei a placa do módulo de relógio RTC para poder comportar 4 tipos de baterias diferentes:
-CR2032, CR2430, Ni-Cd mini ou uma bateria genérica, ligada à placa através de 2 terminais.
O layout mudou ligeiramente, como dá pra ver na figura abaixo.
Um pacote com todos os arquivos encontra-se neste link
-CR2032, CR2430, Ni-Cd mini ou uma bateria genérica, ligada à placa através de 2 terminais.
O layout mudou ligeiramente, como dá pra ver na figura abaixo.
Um pacote com todos os arquivos encontra-se neste link
domingo, 18 de março de 2007
Mais uma Atualização de Status
Mais uma atualização de Status, mas agora apenas com as atividades que faltam, antes do primeiro "release" do projeto:
Alguns comentários, sobre outras atividades, a serem executadas, mas somente depois do "release" inicial estão comentadas abaixo:
-Testar o circuito em 8MHz. Para isso eu preciso de conseguir um MSX que rode a 8MHz. Não conheço ninguém que tenha um. Talvez em algum encontro de MSX...
-Arranjar uma alternativa para o conversor de tensão 3V-5V atual. O circuito atual, embora bem simples, funciona bem. Nem o chaveamento (liga/desliga) é necessário, quando se utiliza um soquete específico de SD/MMC, que liga primeiro os pinos de VCC e GND, assim que o cartão é inserido. Além disso fiz vários testes de "hot insert/removal" no soquete improvisado sem danificar o cartão, enquanto os soquetes de SD/MMC ainda não tinha chegado da Farnell.
-Testar com outros cartões SD/MMC. Eu só tenho 2 modelos de cartão, um SD e outro MMC. Pretendo testar com mais cartões, mas tenho consegui-los emprestados.
- Finalizar o programa de teste para SD/MMC
- Atualizar o guia de montagem e teste;
- Atualizar o "layout" das placas da interface de cartões e do cartucho de adaptação. Este último por causa de uma discrepância entre a furação da placa biblioteca da caixa Patola e a caixa real.
- Corrigir e atualizar o "layout" do Módulo RTC, que tinha uma inversão entre os sinais SDA e SCL, que tem que ser corrigida. Além disso vou dotar a placa de pelo menos 4 opções de soquete para bateria: CR2420, que estou usando, CR2032 que pode ser aproveitado de uma placa velha de PC, Ni-CD mini, também pode ser aproveitada de uma fonte de PD, e um par de terminais, para ligar qualqer outro tipo de bateria que forneça 3V.
- Medir o consumo do circuito, durante uma gravação do cartão
- Disponibilizar todos os diagramas e "lay-outs" em formato Eagle, EPS e GIF;
- Disponibilizar todas as listagens e os arquivos .wav dos "drivers" e dos programas de teste
Alguns comentários, sobre outras atividades, a serem executadas, mas somente depois do "release" inicial estão comentadas abaixo:
-Testar o circuito em 8MHz. Para isso eu preciso de conseguir um MSX que rode a 8MHz. Não conheço ninguém que tenha um. Talvez em algum encontro de MSX...
-Arranjar uma alternativa para o conversor de tensão 3V-5V atual. O circuito atual, embora bem simples, funciona bem. Nem o chaveamento (liga/desliga) é necessário, quando se utiliza um soquete específico de SD/MMC, que liga primeiro os pinos de VCC e GND, assim que o cartão é inserido. Além disso fiz vários testes de "hot insert/removal" no soquete improvisado sem danificar o cartão, enquanto os soquetes de SD/MMC ainda não tinha chegado da Farnell.
-Testar com outros cartões SD/MMC. Eu só tenho 2 modelos de cartão, um SD e outro MMC. Pretendo testar com mais cartões, mas tenho consegui-los emprestados.
Programa de Teste dos Cartões
O programa de teste dos cartões SD/MMC já avançou bastante. A parte mais trabalhosa, que envolve fazer as contas já está pronta.
Agora já consigo saber o tamanho em blocos do cartão. Este número será dividido por 2 e passado para a parte do programa que executa um teste de gravação.
Achei estranho o tamanho ser ligeiramente menor do que a capacidade nominal, ou seja, um cartão de 128MB tem na realidade algo em torno dos 120MB.
Seguem abaixo duas telas do programa.
Tela do programa com um dos cartões MMC
Tela do programa para o cartão SD
Agora já consigo saber o tamanho em blocos do cartão. Este número será dividido por 2 e passado para a parte do programa que executa um teste de gravação.
Achei estranho o tamanho ser ligeiramente menor do que a capacidade nominal, ou seja, um cartão de 128MB tem na realidade algo em torno dos 120MB.
Seguem abaixo duas telas do programa.
Tela do programa com um dos cartões MMC
Tela do programa para o cartão SD
sábado, 17 de março de 2007
Rotinas de leitura de CSD e CID
Terminei ontem de madrugada as rotinas de leitura de CSD e CID dos cartões SD/MMC. Complementei o driver com um programinha de teste básico, que permite 4 operações:
Agora só está faltando escrever um programa em Basic para compor um programa de teste funcional da interface.
O código está neste link.
Complementando o "post", os dados do CSD e CID dos cartões sob teste:
- Ler CSD
- Ler CID
- Ler blocos do cartão
- Escrever blocos no cartão.
Agora só está faltando escrever um programa em Basic para compor um programa de teste funcional da interface.
O código está neste link.
Complementando o "post", os dados do CSD e CID dos cartões sob teste:
MMC CARD1
CSD
90 26 01 2A 0F 59 00 F4
F6 DB 1F FF 92 40 40 2F
CID
15 00 00 30 30 30 30 30
30 11 D0 06 D5 91 B8 00
MMC CARD2
CSD
90 26 01 2A 0F 59 00 F4
F6 DB 1F FF 92 40 40 2F
CID
15 00 00 30 30 30 30 30
30 11 D0 06 CD 39 B8 00
SD CARD
CSD
00 36 00 32 17 59 81 DF
76 DA FF 81 96 40 00 C1
CID
18 49 4E 31 32 38 4D 42
04 40 A7 DE 3D 00 B3 4B
CRC nos comandos do cartão MMC
Quando os cartões SD e MMC operam em modo SPI eles ignoram (por default) o CRC dos comandos enviados; porém passei um bom tempo pra descobrir que o cartão MMC que eu estou testando se recusava a enviar o "data token" quando a CRC "dummy" enviado no final do comando era "00" (zero). Quando desconfiei disso, mudei para 0FFh (255), e o problema foi resolvido. Eu desconfio (embora não tenha testado) que manter o bit 0 (zero) do byte de CRC em nível lógico alto, já resolva o problema. Interessante que para o cartão SD este valor não fez a menor diferença.
De qualquer forma, embora o CRC dos comandos dos cartões SD/MMC seja ignorado, é recomendável utilizar o valor OFFh para evitar surpresas.
De qualquer forma, embora o CRC dos comandos dos cartões SD/MMC seja ignorado, é recomendável utilizar o valor OFFh para evitar surpresas.
Assinar:
Postagens (Atom)