domingo, 29 de setembro de 2013

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

segunda-feira, 23 de setembro de 2013

Nova peça para o Kicad: Adaptador smd para cartão micro sd

Olá,

Eu criei mais uma nova peça (part) para o kicad: um adaptador smd para cartão micro sd. A peça em questão pode ser facilmente encontrada no ebay e os arquivos do kicad você pode baixar no kicad cloud acessando os links abaixo.

Para o esquema elétrico:
http://www.kicadcloud.com/schematicSymbol/4370

Para a placa de circuito impresso:
http://www.kicadcloud.com/pcbModule/4371

Abaixo segue mais informações sobre a peça:



Um abraço,

José Paulo

domingo, 8 de setembro de 2013

Energia: Arduino Framework para o Launchpad da Texas

IMG 



 Olá,

Eu já escrevi aqui no blog a respeito do Launchpad da Texas Instruments. E eu descrevi a maior vantagem dos Launchpads: o preço. E a maior desvantagem: a incompatibilidade com a plataforma arduino.

Pois bem. Eu tenho o MSP430 Launchpad e o Stellaris Launchpad. Recentemente eu acessei o site da Texas para baixar a última versão do software de desenvolvimento para o meu Stellaris Launchpad e, para minha surpresa, a Texas parou de dar suporte para a família de MCUs Stellaris a favor da nova família Tiva. Você simplesmente não consegue mais baixar os softwares que são necessárias para você usar este modelo de placa de desenvolvimento. Curiosamente, na loja online da Texas o Stellaris Launchpad ainda está disponível para venda (com preço promocional - Uau!!!). Creio eu que sejam pontas de estoque que a Texas ainda possui.

Na minha humilde opinião eu creio que a forma como a Texas tratou do assunto simplesmente abandonando os usuários do Stellaris a favor da nova linha Tiva é um absurdo e um absurdo ainda maior é continuar vendendo as pontas de estoque que eles nem mesmo dão mais suporte. Isto só me faz querer pensar duas ou mais vezes antes de usar os produtos da Texas em meus projetos.

De qualquer forma eu descobri que fiquei órfão e com uma plaquinha que eu não conseguia usar. E, buscando por alternativas para continuar usando a plaquinha que possuo é que eu esbarrei com o projeto "Energia". Basicamente o Energia é um framework baseado no Arduino que permite usar o MSP430 Launchpad e o Stellaris Launchpad. Fantástico! Nos testes iniciais tudo funcionou direitinho de primeira e como os Launchpads já vem com o programador incorporado você não perde espaço no MCU com o bootloader e o seu sketch entra em ação assim que você alimenta a placa. Nos arduinos originais o programa de bootloader entra em operação primeiro e apenas após alguns segundos é que o seu sketch assume o controle do MCU.

Eu realmente sempre usei MCUs da microchip e fiz algumas experiências com 8051 e com os MCUs da Texas. O arduino era uma plataforma que eu ainda não havia experimentado e estou muito entusiasmado em usar meus launchpads com o Energia. Ao mesmo tempo que eu poderei continuar usando meus launchpads eu ainda vou poder aprender um pouco sobre a linguagem Wiring e a plataforma arduino no geral.

Os launchpads não são arduinos. A pinagem e o "form factor" dos launchpads fazem com que estes não sejam compatíveis com os famosos shields dos arduinos que são as verdadeiras estrelas do mundo arduino. Mas de qualquer forma é uma alternativa muito interessante.

Abaixo segue o link para o site do projeto Energia:

http://energia.nu/

Se você possui um launchpad MSP430 ou Stellaris eu acho que vale a pena experimentar o Energia. Além de tornar o trabalho de programação dos launchpads muito mais fácil é uma alternativa interessante para as soluções proprietárias que a Texas Instruments oferece.

Um abraço,

José Paulo

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

Olá,

Já faz um bom tempo que eu não escrevo nada no blog. Um pouco por conta de falta de tempo, um pouco por dificuldades diversas que eu tenho enfrentado em meus projetos e um pouco por conta de uma falta de interesse momentâneo. Mas é isso. Espero retomar as atividades tanto aqui como nos meus projetos.

O projeto do emulador de interface de disquete está se arrastando. Dificuldades mil eu tenho encontrado. E tocando o projeto sozinho amplia o grau de dificuldade.

O primeiro problema que eu tenho encontrado é com relação à comunicação com os cartões SD propriamente dito. Os cartões SD possuem duas formas de comunicação: usando o que é chamado de protocolo SD que é mais rápido, porém mais complexo, e a outra é por meio do "protocolo" SPI que é mais simples e que muitos MCUs disponibilizam dispositivos que implementam este protocolo como é o caso do PIC18F4550 que está sendo usado no projeto. O problema reside no fato de que aparentemente nem todos os cartões SD suportarem corretamente o protocolo SPI. Há documentos "oficiais" que descrevem em detalhes como se deve comunicar com os cartões SD tanto em modo SD como em modo SPI, mas aparentemente há cartões que não seguem estritamente o que é estipulado para este modo. Inclusive no documento versão 2 dos cartões SD é informado que futuras revisões do padrão podem não mais suportar o modo SPI. Uma pena. De qualquer forma eu consegui interagir com alguns cartões micro SD que eu tenho aqui em casa o que para mim já é satisfatório. E agora vai aí uma dica: aparentemente os cartões da marca Kingston funcionam muito bem em modo SPI.

O segundo problema é que eu não consigo fazer funcionar corretamente a interrupção de baixa prioridade. Como eu já descrevi em posts anteriores a interrupção que trata do barramento de dados do MSX precisa ser muito rápida e para isto eu dei a este rotina a interrupção de alta prioridade e escrevi a rotina em assembler para garantir o máximo de velocidade possível. Para garantir maior velocidade eu decidi também que a interrupção de alta velocidade tratará apenas da "interrup-on-change" que é a interrupção que é acionada quando o MSX faz uma operação de leitura ou escrita na faixa de endereços de IO equivalente ao controlador de disquete original deste computador (0xD0 à 0xD7). Pois bem, o problema surge quando eu quero usar os outros dispositivos do computador dando a elas a interrupção de baixa prioridade. Eu não sei porque, toda a vez que eu libero (habilito) as interrupções de baixa prioridade o MCU parece travar no mesmo instante. No momento os outros dispositivos não estão fazendo falta ainda. Mas seria legal poder usar a interrupção de baixa prioridade para por exemplo temporizar alguma coisa, sei lá.

O terceiro problema é com o sistema de arquivos FAT em si. Inicialmente estava pensando em usar o "petit FatFs" que é um software livre criado justamente para permitir que MCUs com pouco memória RAM e Flash possam fazer a interface com cartões SD contendo partições FAT. Pois bem, quando eu tento compilar o código do Petit FatFs o compilador acusa o erro de falta de espaço para o parâmetro X qualquer. Após muito quebrar a cabeça eu percebi que, apesar do código do Petit FatFs ser bastante enxuto, na verdade ele transfere muita informação entre as suas diversas funções e isto acaba violando o espaço que foi destinado por default pela Microchip para uso com estes parâmetros. Eu acho que se eu mudar o espaço reservado para a COMRAM no arquivo lkr do pic18F4550 eu consigo fazer as rotinas compilarem normalmente... mas pensando bem é melhor não. Porque? Eu explico. O Petit FatFs foi feito para transferir pequenas quantidades de informação mas na minha aplicação eu vou transferir entre o MSX e o cartão SD setores inteiros de 512 bytes. Eu então achei melhor reservar um espaço de 512 bytes na memória do PIC apenas para estas transferências entre o PIC e o cartão SD. Sendo assim eu estou fazendo as minhas próprias rotinas de tratamento do FAT.

As rotinas em si ainda possuem uma quantidade enorme de bugs mas já consigo navegar entre as pastas e arquivos dos cartões SD que estão em teste.

Abaixo segue algumas imagens da tela LCD do emulador de interface de disquete:







Nas imagens acima estou visualizando um arquivo chamado "ELEVAT~1.DSK" e um diretório chamado LOST respectivamente. É possível observar que no caso do arquivo eu não estou apresentando a extensão DSK porque eu achei desnecessário já que a minha rotina está filtrando para apresentar apenas os arquivos com esta extensão. Mas eu estou começando a perceber que isto pode ser um erro. Porque? Porque caso não haja no cartão SD um arquivo com extensão DSK e nem um diretório o rotina informa que o cartão está vazio e eu acho que isto pode levar o usuário a pensar erroneamente que o cartão está vazio enquanto que na verdade não está. Eu acho que vou mudar meu código para apresentar o simbolo do disquete apenas para arquivos válidos (com extensão DSK) mas apresentar outros arquivos que existam no cartão. O cadeado aberto indica que o arquivo, ou disco, pode ser escrito. Para o MSX, um arquivo com cadeado aberto vai representar um disquete sem a proteção contra a gravação e portanto o disquete (arquivo) pode ser alterado pelo MSX. As setas no canto direito indicam que há mais arquivos "para cima ou para baixo" que você pode navegar com as setas de UP e DOWN do controle da interface.

Ainda há muito a ser feito neste projeto mas o projeto está andando. Abaixo eu deixo o link para o código fonte do firmware do PIC. Caso alguém se sinta compelido em estudar o código e ajudar ou dar ideias, por favor, se sinta a vontade.

https://dl.dropboxusercontent.com/u/62498964/MSXFirmware_3.X%20-%20Nova%20Vers%C3%A3o.zip

Um abraço,

José Paulo