sexta-feira, 15 de novembro de 2013

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

sábado, 9 de novembro de 2013

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

sexta-feira, 1 de novembro de 2013

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

domingo, 27 de outubro de 2013

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

sexta-feira, 25 de outubro de 2013

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

domingo, 20 de outubro de 2013

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.


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

sábado, 12 de outubro de 2013

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


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

terça-feira, 6 de agosto de 2013

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


https://lh3.googleusercontent.com/-DwF4ZPovNJ0/UfVVtkbfcFI/AAAAAAAAAKU/fZa3fji6EKA/s1600/Proto1.jpg


Olá,

Eu fiquei um período relativamente grande sem postar nada porque eu estava tendo uma série de dificuldades com o projeto do emulador. Acima tem as imagens da fiação no meu protoboard com a EEPROM, o PIC, o display de LCD e o CPLD instalados. Quase não dá pra ver a eeprom e o PIC de tanto fio em torno dos componentes, mas está tudo funcionando até agora. Ainda falta instalar no protoboard o cartão SD e as quatro teclas de controle.

Depois que eu descobri que o PIC18F4550 possui pinos conflitantes entre os dispositivos EUSART e MSSP eu decidi que não mais usaria um PIC no módulo de controle externo para controlar o display de LCD e as teclas de controle. Eu tinha tomado esta decisão inicialmente com o objetivo de diminuir o "overhead" sobre o PIC principal que faz a comunicação diretamente com o barramento do MSX. Desta forma a topologia do projeto mudou e o PIC agora controla as teclas de controle e o display de LCD. Eu também estava pensando em trocar o PIC por outro modelo mais moderno com mais memória e com dispositivos EUSART e MSSP não conflitantes mas decidi em insistir no mesmo PIC. Abaixo segue a imagem com a nova topologia.

Com a topologia num estágio mais maduro eu fui capaz de finalmente decidir qual será a função dos pinos do PIC. Ou seja, eu consegui distribuir o que cada pino do PIC fará.. A tabela abaixo ainda não é definitiva mas está bem próxima do que cada pino fará. Talvez eu use o pino RE3/MCLR para detecção de pressionamento de uma tecla e use um outro pino do PIC para acender e apagar um LED. O LED seria usado para indicar a presença do cartão SD no slot e também para indicar que está havendo alguma atividade no cartão. Da seguinte forma: 1) Led Apagado - Sem cartão SD, 2) Led Acesso - Com cartão SD e 3) Led piscando - O cartão SD está sendo acessado. Eu ainda não me decidi completamente porque me parece que o LED seria uma redundância desnecessária já que eu terei um LCD com as informações que o LED me dará e muito mais.


O primeiro passo... e o primeiro problema... foi para inserir o código para tratar o LCD. A PLIB da Microchip oferece o xlcd que teoricamente deveria funcionar bem com o meu display mas por algum motivo que eu desconheço não funcionou ou eu não fui capaz de fazer as funções funcionarem para mim. Então eu criei as minhas próprias funções para tratamento do LCD. Eu criei um função putch para permitir que eu use a função printf em conjunto com o LCD também. Abaixo segue uma imagem com o display funcionando. Eu usei o printf para escrever o texto abaixo e na segunda linha eu "printei" alguns caracteres customizados que eu criei para usar com o emulador. O primeiro caractere seria um disquete (não acho que ficou muito parecido com um). O segundo caractere uma pasta (também não sei se ficou muito parecida). O terceiro e o quarto representam um cadeado aberto e fechado respectivamente. E os demais caracteres seriam setas para cima e para baixo que serão usados para a navegação dos arquivos dentro do cartão SD. O disquete seria para indicar que o arquivo sendo visto é um arquivo .dsk válido e a pasta para indicar que na verdade o que estamos vendo é um pasta de trabalho. Talvez eu crie um caractere especial em formato de coração para marcar um arquivo .dsk para ser carregado por default ao ligar a interface.







O segundo passo foi fazer o PIC finalmente comunicar com o MSX via barramento. Eu estou disponibilizando todo o código na minha pasta pública do Dropbox e o link segue no final da mensagem mas eu estou listando o código da rotina de tratamento da interrupção do PIC abaixo porque me deu muito trabalho e gostaria de falar um pouco mais em detalhe sobre ela. A rotina abaixo é o coração de todo o projeto, simplesmente do seu funcionamento depende todo o restante do projeto. Se eu não conseguisse fazer uma rotina rápida o suficiente para atender as requisições do barramento do MSX o projeto se tornaria inviável. Mas posso adiantar que eu consegui.

#include "xc.inc"

global _total_bus_read, _total_bus_write, _total_bus_readwrite
global _temp_FSR0L,_temp_FSR0H
global MSXBUSIntRead
global MSXBUSIntWrite

PSECT highintvec,class=CODE,abs,
ovrld
            org 0x10
HighIntStart:
            movff   FSR0L,_temp_FSR0L
            movff   FSR0H,_temp_FSR0H
            clrf    FSR0H
            movf    PORTB,w
            andlw   0xf0
            swapf   WREG
            movwf   FSR0L
            incf    INDF0
            bsf     FSR0L,4
            btfsc   PORTB,PORTB_RB7_POSITION
            goto    MSXBUSIntRead
            goto    MSXBUSIntWrite

PSECT text,class=CODE,ovrld

MSXBUSIntRead:
            movff   INDF0,PORTD
            clrf    TRISD
            bra     wait_bus_r

MSXBUSIntWrite:
            movff   PORTD,INDF0

            banksel _total_bus_write
            incf    _total_bus_write
            bnc     wait_bus
            incf    _total_bus_write+1
            bra     wait_bus

wait_bus_r:
            banksel _total_bus_read
            incf    _total_bus_read
            bnc     wait_bus
            incf    _total_bus_read+1

wait_bus:
            movf    PORTB,w
            andlw   0xf0
            xorlw   0xf0
            bnz     wait_bus
                       
            setf    TRISD
            banksel _total_bus_readwrite
            incf    _total_bus_readwrite
            bnc     end_int
            incf    _total_bus_readwrite+1
end_int:
            bcf     INTCON,INTCON_RBIF_POSITION
            movff   _temp_FSR0L,FSR0L
            movff   _temp_FSR0H,FSR0H
            retfie  f
            end

Inicialmente eu gostaria de falar que eu já tinha programado em assembler para PIC (PIC12F e PIC16F) e que fazia um tempo longo que eu não tinha programado nada em assembler. E com este projeto eu descobri como eu estou literalmente enferrujado para programar em assembler. Foi um verdadeiro pesadelo criar esta rotina simples e eu acho que o ASPIC18, que é o compilador assembler que acompanha o XC8, tem várias e várias armadilhas para quem tá começando. Boa parte da minha dificuldade foi em descobrir o que o compilador e o linker estavam fazendo com o meu código. Uma dificuldade adicional é o fato de que o compilador gera pouquíssimas mensagens de erro o que dificulta bastante a depuração. Isto posto vou agora voltar a descrição do projeto.

O barramento de dados do MSX está ligado diretamente nos pinos RD0..RD7 do PIC e os pinos de seleção do CPLD estão ligados nos pinos RB4..RB7. Uma descrição mais detalhada de como funciona os pinos de seleção está na mensagem #2. O importante é saber que caso seja realizado uma operação de IO dentro dos endereços válidos o estado lógico dos pinos RB4..RB7 serão alterados e será gerada no PIC uma "interrupt-on-change" que foi dada alta prioridade. A idéia é que nenhuma outra fonte de interrupção no PIC gera interrupções de alta prioridade a não ser a "interrupt-on-change" com isto eu diminuo a quantidade de código no vetor de alta prioridade e aumento a velocidade no tratamento da interrupção.

A primeira parte do código incrementa um contador de acessos de registro. O que isto significa? Significa o seguinte: Imagine que o MSX faça um acesso de escrita de IO no endereço D1 a primeira parte de código incrementará o valor contido no endereço 0x01 da memória do PIC. Já se o MSX fizer um acesso de leitura de IO no endereço D2 a primeira parte do código incrementará o valor contido no endereço 0x0a da memória do PIC. O objetivo disto é para termos uma forma de descobrir qual registro foi lido ou escrito pelo MSX. A idéia é que estes registros por default tenham valor 0 e a rotina principal do PIC faça com regularidade uma varredura destes contadores, caso um ou mais destes contadores não possua valor 0 a rotina principal tratará o registro de acordo com a situação e zerará o contador novamente. Caso o contador possua um valor maior que 1 significa que o MSX fez dois ou mais acessos ao registro sem que a rotina principal a tenha processado o que, dependendo da situação, pode ou não ser uma situação de erro.

Depois do código inicial a rotina se divide em duas partes. Uma parte que trata as leituras de barramento e a outra que trata as escritas. No caso das escritas, o código lê o valor contido no PORTD e armazena este valor no registro correto. No caso de leituras, o registro correto é escrito na PORTD e a PORTD é configurada como saída (o estado normal da PORTD é estar configurada como entrada). Há um conjunto especifico de registros no PIC para leituras e um conjunto específico para as escritas. Desta forma é possível o MSX escrever um valor em um endereço de IO e imediatamente após ler um outro valor no mesmo endereço de IO. Isto na verdade está em acordo com o que faz o CI controlador de disquete WD2793 que estou tentando emular que no endereço 0 você escreve um comando mas no mesmo endereço você lê o status do chip. Até este momento o código é crítico e precisa ser o mais rápido possível. Eu me esforcei bastante em diminuir ao máximo a quantidade de instruções nesta parte da rotina e nos meus cálculos  eu consigo atender o barramento do MSX com 21 ciclos de máquina do PIC ou seja, consigo atender o barramento em 1,75 us com o PIC rodando a 12 MIPS. É uma pena que não tenha como reservar o uso dos registros de indexação FSRx para a rotina de interrupção. Eu conseguiria economizar 5 ciclos de máquina do PIC simplesmente se eu não tivesse que salvar o estado de FS0L e FS0H e se não tivesse que iniciar o FS0H toda vez que a interrupção roda. Mas fazer o que?

A parte final da rotina incrementa uns contadores de 16 bits que eu estou usando para fazer testes mas que na versão final serão retirados e há um loop em que espera os pinos RB4..RB7 voltarem para seu estado default, i.e., todos os pinos com nível lógico 1, para finalmente restaurar o estado de FS0RL e FS0RH e terminar a interrupção. O interessante é que durante a inicialização do MSX com a BIOS do CDX2 os registros relativos ao disco são sempre acessados o mesmo número de vezes. Durante meus testes eu fiz uma rotina que de tempos em tempos amostra no LCD a quantidade de vezes que foi realizado operações de escrita ou leitura nos endereços de IO de D0 até D7. A foto abaixo foi tirada após a inicialização do meu MSX com a BIOS CDX2.

Na imagem acima o barramento de dados ainda não tinha sido ligado ao PIC. Depois que eu liguei o barramento de dados ao PIC a rotina de inicialização trava na inicialização tentando ler milhares de vezes os endereços de IO, muito interessante. Eu agora tenho que ligar o MSX com o PIC desligado para só então ligar o PIC. Isto para evitar o travamento durante a inicialização. Provavelmente o valor 0xff no registrador de status faz com que a rotina de inicialização da bios do CDX2 entre em loop constante. Como ainda não há uma rotina que trate adequadamente os registros o valor nunca muda.


https://lh3.googleusercontent.com/-c9SCK8DdHKc/UfV6SWEYjsI/AAAAAAAAALo/y7Le6S6x7pU/s1600/PIC+Entrando+em+a%C3%A7%C3%A3o.jpgNa Imagem ao lado podemos ver o PIC entrando em ação. No MSX foi gerado uma leitura no endereço de IO D0. A linha amarela é a linha de endereço A2 sendo monitorada no pino RB6 do PIC e a linha azul é a linha de dados D0. Podemos observar que um pouco antes da descida da linha de endereço do Z80 a tensão do barramento de dados começa a flutuar porque nem o Z80 e nem o PIC está comandando o barramento. No momento que a linha de endereço desce o "interrupt-on-change" entra em ação e a rotina de interrupção começa a tratar o barramento. Podemos ver o momento exato em que o TRISD é zerado e o barramento de dados se torna uma saída escrevendo o valor lógico 1 na linha de dados D0. Todo o intervalo desde a descida da linha de endereço até que linha de dados passe a ser controlada pelo PIC é o tempo de processamento da rotina de interrupção descrita anteriormente. A linha de endereço só se mantém ativa todo este período graças aos 7 wait states que estou inserindo. Eu ainda não testei mas é provavel que com 5 ou 6 wait states o circuito continue funcionando. Mas de qualquer forma ficou claro que é muito importante o uso de wait states para o meu emulador.

Mais a frente eu devo alterar o CPLD para que multiplique o número de wait states sendo gerado por 2 ou por 3. De forma que se os pinos  WS_SEL  possuir o valor 7 por exemplo seja gerado 14 ou até mesmo 21 ciclos de espera. Desta forma espero tornar o meu projeto compatível com computadores mais rápidos como por exemplo o Turbo-R.

Na imagem acima é a mesma configuração dos sinais da imagem anterior só que desta vez é uma operação de escrita aonde está sendo escrito o valor 0 no endereço de IO D0. Podemos observar que o Z80 baixa a linha de dados um pouco antes de baixar a linha de endereço e que ele levanta a linha de dados um pouco depois de levantar a linha de endereço.

Por hoje é só. Estou mega cansado e me sentindo um pouco estafado mas feliz com o progresso do projeto. Espero que as informações que estou colocando aqui seja de alguma utilidade para alguém.
Conforme prometido segue o link para o arquivo contendo todo o código do PIC até agora. Eu vou estudar uma forma de colocar o código num servidor de svn para que, quem quiser, possa contribuir também para o projeto. Se alguém tiver alguma sugestão ou crítica sou todo ouvidos.


Um abraço,

José Paulo