Gravador de EEPROMs Paralelas com Arduino

Microcontroladores Arduino
1

Para um projeto de flashcart para o Master System, eu precisei de um gravador de EEPROMs, daqueles que geralmente custam mais de 200 reais. Como eu já tinha alguns componentes necessários em mãos, resolvi montar meu próprio gravador por bem menos.

Gravador de EEPROM

O design original foi feito pelo Tiido Priimägi, que utilizava uma porta paralela. Como eu tenho um sistema 64bits, isso não funcionaria para mim. Me baseei também no projeto MEEPROMMER, que é feito para chips menores e portanto com menos linhas de endereçamento.

Os componentes que eu usei são:

  • 1 Arduino-compatível
  • 3 Octal Flip-Flops (74HC574)
  • 1 Flash EEPROM 4Mbit (512KB) Atmel (AT29C040A)
  • Muitos jumpers!

Eu não tenho um esquema em mãos, mas a idéia básica é a seguinte:

  • O EEPROM possui 19 linhas de endereçamento, 8 linhas de dados (byte), linhas Chip Enable, Output Enable e Write Enable
  • Para ler um byte da memória (ROM padrão JEDEC) basta ligar (LOW-enabled) as linhas que correspondem ao endereço desejado, ligar a linha OE e ler as 8 linhas de dados.
  • Para gravar um byte da memória (após ser escrito o código de destravamento, que varia de chip pra chip e está no datasheet) você precisa informar o endereço, ligar o byte a ser gravado nos dados e pulsar (LOW-HIGH) a linha WE. No caso da minha EEPROM é preciso gravar em “páginas” de 256 bytes de cada vez, lendo o último byte e esperando que ele mude antes de começar a próxima página.

Mas você deve estar se perguntando: “Como eu consigo 33(!) linhas no Arduino? O meu só tem 13!” A resposta simples são Shift Registers (74HC595), que recebem uma entrada serial (1 linha) e enviam o resultado em paralelo, em 8 linhas ou mais se juntar com mais Shift Registers.

Porém, para uma EEPROM Flash, isso pode ser um pouco lento demais. Portanto, no meu design eu usei Flip-Flops que mudam instantaneamente com entrada e saída paralelas (8 linhas). Ligando 3 no mesmo “bus”, eu posso usar as mesmas 8 linhas para controlar os 19 bits de endereçamento e depois como I/O de dados. O Flip-Flop é um latch que guarda a entrada na saída quando acionado, isso é, eu posso jogar um byte na sua entrada, acionar e depois mudar a entrada que a saída continua a mesma. Com 3 deles posso endereçar até 24 bits e depois usar as ligações diretas com o Arduino como I/O.

Com isso, a ligação fica assim:

  • 8 linhas digitais Input/Output para o “bus”
  • 3 linhas digitais Output para controlar cada um dos Flip-Flops
  • 3 linhas analógicas usadas como Outputs digitais para controlar as linhas CE, OE e WE da EEPROM.

Feito o hardware do gravador, eu adaptei versões do firmware do projeto EEPROMMER baseado no esquema mostrado acima e do gravador em Python para mandar ROMs pela porta serial. O código está meio “gambiarra” e pode não funcionar para outros chips se não o 29C040, portanto eu não recomendo que usem sem modificações, mas se alguém quiser eu disponibilizo. Quando eu me der bem com algum CAD de esquemas também posto aqui o esquema da ligação se ainda não ficar claro para alguém.

2 curtidas
2

Olá @Svetlana o seu projeto é bem parecido com o projeto que tenho me dedicado no último ano, construir um cartucho regravável para alguns consoles retrô (no caso, o meu inicial é o Mega Drive e depois irei portar para outros consoles).

O meu ponto de partida eu não usei shift registers, fiz um teste básico com eles e não gostei da performance, é lenta, principalmente porque o código com ele precisa perpassar todos os 8 pinos para retornar o que se quer(não é à toa que você precisou daquela ilha de LED’s ali para poder escovar os bits visualmente), nem prototipei com ele, passei ao um expansor i2c de 8 portas, que é o CI correto para esse tipo de operação, mas finalmente terminei por utilizar o MCP23017, com uma interface i2c expande 16 portas e você pode fazer um belo combo com ele. Isso acabou virando um gravador de EEPROM externo.

Na minha obsessão por reduzir o esquema elétrico, tive que abandonar o UNO, justamente pelo fato de não ter portas o suficiente, a necessidade de expandir portas, faz dele inadequado para esse tipo de aplicação, então acabei utilizando o Teensy ++ 2 que resolveu meu problema, quando eu fosse criar o cartucho, de fato, só precisaria de um AT90USB1286, mas não sei se o farei com microcontroladores… meu projeto tem ido em direção às FPGA’s.

Acima a imagem do gravador usando um Teensy ++ 2.0 (com 46 portas disponíveis).

Ainda não terminei de criar todo o sistema, e só irei fazer quando terminar mesmo, só liberei meu projeto ainda bugado para algum auxílio no fórum da PJRC, esse projeto de gravador de uma EEPROM bem específica que eu estava usando naquele momento. Assim como você, por coincidência, meu programa cliente é um aplicativo em Python, o que está aí é antigo, já há uma interface gráfica para ele, fiz usando Tkinter.

Sobre a paginação de memória, eu particularmente não lido com isso, porque é uma mera convenção relacionada aos bits mais significativos do endereço, eu saio escrevendo direto mesmo.

Atualmente minha linha vai em direção à linha do Everdrive, estou trabalhando com FPGA’s Spartan 6 da Xilinx e Cyclone IV da Altera, com uma FPGA 101, mas devido à falta de material para a FPGA 101, minha atenção está focada na Spartan 6 com uma placa Mojo V3, mas aí minha filhinha nasceu e o projeto parou, estou me dedicando a coisas muito mais simples apenas para testes por enquanto, só trabalho 1 hora por dia com um driver de motor de passo feito sem CI e só…

2 curtidas
3

Oi @sksdutra, não conhecia esse expansor i2c, bem interessante, mas preciso ver se também não seria devagar (mas nem tanto) igual aos shift registers. O EEPROM de Flash precisa de velocidades de gravação mais rápidas que um EEPROM normal, além do paginamento que eu descrevi. Se você tentar gravar a próxima página antes de verificar que a página atual foi gravada (ou ao menos esperar 5-10ms, o que seria mais lento), a página inteira é descartada e reprogramada para FF em todos os bytes pois o tempo de programação não passou.

Para o resto do projeto do flashcart em si, é só substituir a ROM de um cartucho que tenha o mapper apropriado de 4Mbits (After Burner, Phantasy Star e outros), refazendo uma das trilhas onde o CI da ROM do Master e da EEPROM diferem. Eu usei esse tutorial do Charles MacDonald.

Aqui um link sobre o projeto no meu blog (em inglês) e mais fotos.

1 curtida
4

No meu caso, eu estou reconstruindo o cartucho mesmo, pretendo colocar um USB para fazer a gravação direta, por isso estou usando MCU com core de USB e trabalhando com FPGA’s. Paralelamente a isso, estou programando uma ROM hospedeira capaz de acessar um cartão com o SGDK.

Este tipo de projeto é bem trabalhoso se você for além do básico, mas dá para aprender muito.

5

Com certeza isso é bem mais trabalhoso, por isso escolhi o Master, já que é mais fácil apenas reutilizar um cartucho. No caso do Mega Drive isso não é tão fácil porque, além de alguns jogos serem maiores, são mais proprietários (mas eu não cheguei a fazer muita pesquisa porque não tenho um). O Super Nintendo nem se fale, tem uma penca de mappers diferentes com poucos jogos por cada, por isso que o Super EverDrive não tem compatibilidade perfeita e o sd2snes tem que emular tanta coisa pra cada jogo em firmware.

1 curtida
6

O problema dos consoles de 16-bits são os chips especiais e alguns mappers, no caso do Mega Drive, só tem 1 mapper oficial definido que é o mapper utilizado em Super Street Fighter II para mapear 40Mb, assim como tem apenas 1 chip especial que o SEGA VR usado em Virtua Rancing.

Já o SNES tem vários chips especiais e não lembro de nenhum mapper, mas os jogos não respondem por 5% da biblioteca, porém são jogos clássicos como Star Fox, que usa o Super FX. Em algum lugar por aí há uma lista dos chips e jogos. Nesse ponto, o sd2snes é um projeto bem mais avançado que o Super Everdrive, quando eu portar minha bagunça pro SNES, vou primeiro me focar no básico, ainda não sei sequer como vou reverter a engenharia dos chips, mas não é tarefa fácil e pode ser que eu nem consiga, o cara do sd2snes já trabalha nisso há quase 1 década e portou alguns dos chips (como o da Capcom para rodar Megaman x2 e x3), mas só agora tem falado sobre Super FX.

Achei uma imagem mais avançada do gravador de EEPROM protótipo gravando.

1 curtida
7

Bacana ver que há pessoas no universo maker local tentando fazer coisas com FPGA, mas me parece que será utilizar um canhão pra matar um mosquito :slight_smile: (falo por ignorância da complexidade do projeto) pode ficar mais interessante montar com um CPLD. Fico me perguntando se um microcontrolador com barramento externo de memória e um SDCARD e uso massivo de DMA ñao resolve de forma bem elegante o problema.

8

O uso do FPGA se justifica por causa do número de portas e velocidade, se você tentar carregar uma ROM de 512KB, um MCU de 8 bits, que atinge com cristal no máximo 16MHz deve levar 10 a 15 segundos(talvez até mais) para fazer a tarefa, talvez com um MCU da linha Kinetis com 72MHz ou mais esse problema seja resolvido, no entanto, para todas as conexões necessárias você precisa de várias portas, um MCU vai ficando bem caro por causa disso, o preço de um FPGA sai bem mais em conta neste quesito, se houver necessidade de CI’s auxiliares, tudo pode ser implementado no próprio core do FPGA, valorizando o espaço limitadíssimo de uma placa de cartucho.

1 curtida
9

Por isso comentei do CPLD. Estamos falando em quantas portas? e qual a taxa do barramento? E eu não citei o uso de um 8 bits, minha sugestão foi para um processador com barramento para memória externa e controlador para leitura de um cartão SD por exemplo. Poderia colocar os números na mesa? (largura do barramento, troughput ) Há que se tomar cuidado com essa afirmação do preço do FPGA ficar em conta. Se disputar por preço o FPGA sempre vai perder. Mesmo com os dispositivos que você citou estando na casa dos U$ 15. A fonte é mais complexa e há a exigência de circuito externo para gravação e o bga é um tanto mais chato de fazer circuito. Novamente eu só estou curioso, ok? Achei bacana fazer com FPGA, eu gosto bastante!(Inclusive ganho a vida com isso rsrs)

10

Existe a possibilidade de fazer com qualquer uma das tecnologias citadas, inclusive as primeiras versões do Everdrive foram feitas com um MAX II da Altera, no entanto, à medida que o projeto cresceu, o desenvolvedor do aparelho passou a utilizar FPGA’s, Cyclone II da Altera, não sei precisar de cabeça o modelo, mas não é com empacotamento BGA.

Da última vez que visitei o fórum, algumas pessoas que queriam implementar mais alguns features no aparelho se deparam com o fato de que até o último recurso desse Cyclone II havia sido esgotado.

Eu não sou engenheiro e não trabalho com isso, sou um mero hobbysta e pedagogo por formação, meu projeto parou justamente na confecção no primeiro cartucho, que não teria nada disso, seria um cartucho ordinário, construido com uma EEPROM customizada gravada no aparelho externo que construí com o Teensy ++ 2. E foi bem aqui que eu tive que parar a cerca de 5 meses por causa do nascimento da minha filha.

O próximo passo seria trabalhar em adicionar, no próprio cartucho, a funcionalidade de regravação da EEPROM para gravar 1 jogo por vez e depois um SD, fiz os testes de leitura e escrita com AVR 8 bits e ficou lento, mas ainda não testei com o Kinetis de 72MHz (Teensy 3.1).

Outro fator é o estudo, eu ainda estou aprendendo a lidar com FPGA’s, estou estudando VHDL(parado), não achei difícil, mas preciso me dedicar e fazer projetos menores ainda.

11

Entendi. Como eu falei não conheço a complexidade do problema. FPGA com encapsulamento que não seja BGA infelizmente são poucos :frowning: Que eu sei há um Cyclone 4 e 2 Spartan 6(das famílias mais recentes).

Que isso de mero pedagogo cara, conheço um monte de engenheiro que sabe bem menos do assunto que você. Só citei que trabalho com FPGA pra indicar que gosto tanto da tecnologia que busquei ativamente como trabalho.

Entçao com relação ao cartão é importante que o uC possua controlador pra SD card se for fazer via SPI vai ficar lento mesmo, mas com o controlador o troughput é bem maior. Usando o controlador, mais um barramento externo e usando DMA deve ser possível.

Se está estudando VHDL sugiro encontrar o livro do Volnei Pedroni, para síntese é um dos melhores que eu já li e o texto é bem direto. No trabalho nós temos usado o MyHDL(Python) para simulação mas ele vai exigir um modelsim full ou escrita do código em verilog e o icarus para simulação. Eu coloquei na fila para estudar o cocotb(verificação em python) mas isso só deve acontecer no ano que vem. Esse ano estou lidando com projetos que não envolvem VHDL e só estou finalizando um último. Se ficar preso em algo com o VHDL pode ficar a vontade de me perguntar diretamente.

Possui algum link para encontrar material sobre o cartucho regravável?

PS: Parabéns pela filha, eu tenho dois e é muito bacana ter criança em casa. Suga até a última das nossas forças e muda a vida toda mas pra mim valeu a pena. Espero que pra você também.

12

Sobre o VHDL eu estava estudando pelo livro Free Range VHDL, é gratuito, os caras que escreveram são os criadores(ou relacionados com) da XuLA Board (Spartan 6) e vai direto ao ponto, mas vou dar uma olhada no valor deste do Volnei Pedroni. Eu tentei MyHDL mas ainda não me senti confortável com ele, apesar de trabalhar com Python a mais de uma década.

Este projeto é bem próximo do que eu pretendo: http://www.makestuff.eu/wordpress/electronics/umdkv1/ já o UMDK2 já vai por outro rumo, o cara está fazendo uma verdadeira suíte de desenvolvimento para Mega Drive já faz alguns anos com direito até a IDE baseada em Eclipse.

O objetivo final é chegar a um produto como este: http://krikzz.com/index.php?route=product/product&product_id=55 o cara é Ucraniano e devido aos problemas do país dele, esse produto está em falta no mercado e os chineses estão adorando.

13

Amigo, gostaria de perguntar sobre o master system ou megadrive, pois tenho 2 consoles desses dos modelos mais novos, aqueles q tem varios jogos na memoria, gostaria de saber se é possivel fazer alguma adaptaçao no console ou mesmo ler e gravar essa memoria que eles tem dentro onde ficão os jogos?

14

Se alguém gravou, com certeza há uma forma de regravar ou apagar, só não tenho como dar detalhes da operação porque eu não tenho o aparelho e nem me interesso em adquirir um, mas é bem possível que hajam pontos na placa para até facilitar essa operação para a empresa.

15

Não necessariamente. No caso poderia ser uma ROM e não uma EPROM ou EEPROM, onde ela só pode ser gravada uma vez (e já foi, de fábrica, com os jogos “na memória”). Neste caso não há como apagar ou regravar a memória, apenas substituir o chip por outro contendo os dados desejados.

16

É uma possibilidade, apesar de muito remota, já que esses consoles são relativamente novos e provavelmente usam uma memória flash, que são mais baratas e o preço x espaço é bem menor.

No caso de trabalharmos com a hipótese de uma memória *ROM, leve-se em conta que a quantidade de dados a serem gravados é limitada e fica bem mais caro a cada pequeno aumento nos dias de hoje, onde, para encontrarmos uma dessas, é mais fácil acharmos usadas, além disso, o suporte técnico seria inviável.

Por fim, a maioria das empresas terceiriza a produção para a China e a Tec-Toy deixou o JTAG exposto no Zeebo, provavelmente deixou os pontos para a memória desses consoles expostos também para facilitar gravação e suporte técnico.

Mas são meras conjecturas, apesar de ser um feito tecnicamente “complicado” atualmente, quem sabe não seja realmente uma ROM que descanse nas entranhas de um desses…

17

Boa noite pessoal, obrigado pelas respostas, eu vou tirar uma foto das placas do maste system e do mega drive no fim de semana e vou postar aqui, do master system faz tempo q eu olhei mas tenho quase certeza q é uma memoria flash.
Fim de semana eu subo no telhado e pego as placas pra postar aqui pra vcs, tenho um sega saturno tb, q esta sem canhão e pelo q eu vi na net tem um projeto pra usar um cartao sd nele também.