# Mi grabador de memorias paralelo USB



## TRILO-BYTE (Ene 11, 2014)

bueno no se quien se anima a construir este dispositivo que ayuda agrabar memorias paralelas 
con puerto USB

el microcontrolador que estoy usando es el PIC18f4550 programado en C18 con su respectivo bootloader 

el hardware es realmente sencillo solo hay que alambrar en un protoboard 2 circuitos integrados los famosos CD4040 
armar el PIC18f4550 con su cristal , su capacitor Vbus y su cable usb no requiere los mas grandes misterios ni conocimientos

el software para comunicarse con la PC esta escrito en Visual C++ por lo que no requiere mucho conocimiento 

el proyecto sirve para grabar memorias SRAM por que es relativamente rapido grabarlas solo hay que ponerles una bateria CR2032 para que se comporten como memorias EEPROM

si graba memorias EEPROM pero como la comunicacion que estoy utilizando es HID no es muy rapido

el grabador ha sido probado con exito para programar un sistema minimo basado en el Z80 , juegos de NES y Atari 2600







enseguida subire los diagramas ...


----------



## Daniel Meza (Ene 11, 2014)

Bien, lo probaré... una duda ¿cuál es el limite de capacidad en la memoria a grabar?


----------



## TRILO-BYTE (Ene 11, 2014)

pues mira la capacidad maxima te la dan los CD4040 que si se te acaban las lineas de direcciones pues solo es ponerle otro cd4040

nunca lo he intentado por que no he tenido una memoria tan grande en mis manos 
pero cuando exeden los 8kb se tarda un rato grabando , no es que sea malo
sino que la clase HID es muy lenta mas lenta que el RS232 pero la ventaja es que no se usa driver para el HID y eso lo hace compatible con todas las verciones de windows


----------



## Daniel Meza (Ene 11, 2014)

Ya veo, porque la memoria que tengo es de 32KB. Eso de la compatibilidad es muy bueno, el programador chino de EPROM's que tengo sólo trabaja bajo XP 

PD. ¿Podrías poner los diagramas en PDF o imagen?, la versión que tengo de proteus no los abre


----------



## TRILO-BYTE (Ene 11, 2014)

Aca pongo los esquematicos en PDF 

el grabador que hise si pense en la compatibilidad en RS232 hay broncas por las librerias y si lo hago en clase CDC igual hay broncas con los drivers y no son compatibles en tre verciones de windows

la compilacion del .hex del micro es para Sram para grabar EEPROM es muy lento demaciado asi que la deshabilite  pero si graba las EEPROM  no he podido grabar memorias FLASH que seria genial pero no se como grabarlas tienen un algoritmo muy confuso si alguien sabe grabar una FLASH pasenme su algoritmo para meterlo al grabador

asi seria grabador universal casero  seria un sueño para los electronicos amateur y sobretodo Retro informaticos

para probar el circuito solo basta con grabar un archivo de texto y volverlo a leer si se grabo bien y se leyo esta bien armado

pero si lo arman y ven defectos corregibles me dicen para pulir el programa los archivos del codigo fuente son muy grandes pero si los requien revisar igualmente los subire


----------



## Sr. Domo (Feb 6, 2014)

Muy lindo 

Pero, si quiero grabar una EEPROM que tenga datos, puede "formatearse" con este programa?
Se ve bastante tentador, finalmente le podría dar un uso a muchas EEPROM que tengo arrumbadas ahí.... junto con una 74181 que anda por ahí y unos 74373, los CD4040 y más cosas  ya me emocioné 

Lo de poner dos CD4040 en cascada para 24 líneas no lo recomiendo, ya que el CD4040 no tiene línea de carry out para que puedan ponerse en serie y cuente de 4096 (111111111111) a 4097 (1000000000000) como trabajan con el flanco de bajada de la onda cuadrada, pues la salida Q11 del primer CD4040 haría que el segundo CD4040 esté con Q0 en alto todo el tiempo...
Tal vez para solucionar esto se conectaría una puerta NOT entre Q11 del primer CD4040 y la entrada de reloj del segundo CD4040 para que cuando el primer CD4040 no pase de 4096, el segundo CD4040 tiene su entrada CLK en alto para que cuando el primer CD4040 tenga en alto todas sus líneas, al siguiente pulso de reloj volverá a contar desde cero y el segundo CD4040 sume +1 al siguiente flanco de bajada.
Y si con la puerta NOT no se soluciona esto, la circuitería del carry out se va haciendo más grande 

salu2!


----------



## Daniel Meza (Feb 6, 2014)

Los bytes que grabes sustituirán a los anteriores, no veo problema en ello a menos que te refieras a las EPROM (las de ventanita) que si necesitaban de un voltaje mayor para el modo de programación


----------



## TRILO-BYTE (Feb 6, 2014)

bueno ay un detalle 
no graba por el momento EEPROMS por cuestion de rapidez  bueno el programa .hex lo bloquee pero es desbloqueable 

pero cuando lo soliciten si lo puedo desbloquear 
si graba EEPROMS a velocidad razonablemente lenta pero lo graba

ahora cuestiones de UV EPROMS no lo graba por que el torpe de mi  no tiene luz UV germicida pero es cuestiones de deciciones y hacer unas pruebas no lo he hecho
ya que en programacion uno la cagetea un poco y hay que andar borrando las memorias hasta que quede el programador

en pocas palabras quien lo construya  y vea cosas que no le gustaron pues esta abierto el foro para la lluvia de ideas

y quien sabe alomejor se hace todo un grabador profecional en este mismo foro con materiales que cualquiera pueda adquirir 



aa se me pasaba

si eso de poner CD4040 en cascada  que bueno que lo mencionan

es el caso del FAN-OUT si hay que poner un bufer en los CD4040 pero pues una memoria no tiene muchos cientos de miles de direcciones

las memorias para los cartuchos de NES o ATARI ,etc llegan a las 15 direcciones


----------



## Sr. Domo (Feb 6, 2014)

TRILO-BYTE dijo:


> aa se me pasaba
> 
> si eso de poner CD4040 en cascada  que bueno que lo mencionan
> 
> ...



 y para mí 65.536 bytes se me hacen muy poquitos 

Es el problema de usar CD4040 en cascada, ya que no podrá contar correctamente el segundo contador, ya que estos contadores incrementan con el flanco de bajada y no como el CD4017 por ejemplo.

En resumen, cuando empieza a contar el primer contador, la salida Q11 estará en bajo, por lo que el segundo contador habrá contado 1, cuando el primer contador llega a 4096, al reiniciarse el segundo contador habrá contado a 2 en vez de 1

Mencioné este punto porque yo tengo unas 5 EEPROM que son de hasta 8 Megabits, no Megabytes, sino Megabits (Kb= 1024 bits / KB= 1024 bytes) y tienen hasta 18 líneas de direcciones!

Salu2!


----------



## Daniel Meza (Feb 6, 2014)

Al PIC le sobran varías líneas, sería cuestión de software solucionar ese problema, ¿no amigo TRILO-BYTE?


----------



## TRILO-BYTE (Feb 6, 2014)

pues si mas o menos 
use este diseño por que el colega Erick Peña hiso este armatoste
http://spaceinvader.comuf.com/Atari_SRAMCART.htm

me gusto el hardware se me his simple y economico asi que lo continue y lo puli para USB y plataforma WIN FORM

respecto a lo de los Mega BYTES que seria algo deseable
eso se soluciona quitando el 4040 y usar no se un puerto como el nec82c55
he visto algunos grabadores que hacen uso de este puerto para las memorias FLASH
pero se me hiso un poco caro respecto a los CD4040 que tenia arrumbados

para grabar una FLASH
el problema inicial es que leer las Datasheet es algo confuso por que tienen algoritmos de grabacion 
y no he podido grabar o borrar un byte que es algo frustrante

pero como digo antes de caer en discuciones y rabietas lo mejor es probarlo y ver en que se puede mejorar

como digo quien quiera el codigo fuente  y meterle mano adelante solo pidanlo 
la idea es mejorar algo


----------



## Sr. Domo (Feb 7, 2014)

TRILO-BYTE dijo:


> pues si mas o menos
> use este diseño por que el colega Erick Peña hiso este armatoste
> http://spaceinvader.comuf.com/Atari_SRAMCART.htm
> 
> ...



Respecto a los algoritmos para algunas Flash, es el mismo algoritmo, solo que cambia en los bits de direcciones.
Para grabar una flash de estas, hay que leer en la tabla de algorimos donde diga "BYTE WRITE" y así ya se podrá grabar, pero, esos datos del algoritmo no se grabarán en la EEPROM, sino que la lógica interna detectará la secuencia de bytes y responderá de acuerdo a esta secuencia.

Es algo complicado, pero ya entendiendo estos algoritmos ya se puede grabar casi cualquier flash.

Una vez hice un fragmento de programa en ensamblador para realizar los algoritmos siguiendo el protocolo de las flash y a lo que recuerdo si podía ejecutar todos los comandos


----------



## TRILO-BYTE (Feb 7, 2014)

No me vendría mal un ejemplo.
Lo intenté y no pude, bueno eso fue por que me encontré la flash en una lectora de CD.
Y la hoja de datos dice que se bloquean contra borrado, así que no supe.

Como digo, estaría bien que se pudiera hacer algo mejor.


----------



## Sr. Domo (Feb 12, 2014)

Hola nuevamente 

Me tardé en responder este tema por un problema con la conexión a internet, pero aquí estoy otra vez.

Antes de continuar quiero aclarar que el programa que había hecho era para un procesador intel 8085 en lenguaje ensamblador, este programa lo eliminé porque quería mejorarlo y optimizarlo.

Bueno, pero de algunas cosas me acuerdo, las mencionaré para ver si ayuda de algo.

El programa estaba diseñado para trabajar con 12 memorias distintas, todas bajo el mismo protocolo de comunicación, o sea que todas usan el mismo algoritmo para cada tarea, lo único que varía es la longitud de la dirección, ya que unas eran de 16 bits de dirección, otras de 18, de 14 y así, por lo que si una dirección usada era 5555h para un bus de 16 bits, para uno de 14 por ejemplo sería la dirección 555h.

Cuando seleccionas la memoria, según yo y mis no muy amplios conocimientos en programación, la identificación de la memoria era mediante el acceso a la dirección de la memoria RAM que hemos introducido con el teclado hexadecimal.

Supongamos que elegimos la EEPROM 39SF020 y en el menú te dice que para trabajar con esta memoria debes presionar "5", entonces presionas 5 (0101) y el programa accederá a la dirección 5 de la memoria RAM, leerá la dirección almacenada ahí (estas direcciones han sido cargadas al inicio del programa) y la colocará en la pila para realizar un salto a esa dirección. Antes de que me digan porque solo 4 bits y no los 16 bits de dirección, ah, pues el resto de bits son puros unos o ceros, dependiendo si esas direcciones están "muy lejos" de la primera.

Cuando salta a esa dirección, cargará la biblioteca de algoritmos y el archivo donde de están los datos de la EEPROM como matrícula, capacidad, fabricante, etc..., en la memoria RAM

Al cargar todo esto, en el menú te aparecerá que deseas hacer, por ejemplo grabar datos, copiar datos de una ROM a otra, borrar sectores, "formatearla", protegerla...

Al igual que la selección de la memoria, si quieres grabar un byte que es así como te permite la 
grabación este tipo de memorias EEPROM, pues debes pulsar la tecla de acuerdo a la función que quieras.

Por ejemplo si quieres grabar un byte, pulsas la tecla "A" del teclado hexadecimal y aquí se viene lo bueno 

Al grabar el primer byte, según el datasheet de esta EEPROM con la que hemos estado "trabajando" dice así:



El datasheet dice que antes de programar un byte cualquiera hay que introducir una pequeña secuencia de datos hexadecimales que escribiremos tal y como dice la tabla en nuestro programa programador 

Entonces, dice que para introducir esta secuencia necesitaremos 4 ciclos de reloj o cuatro estados de los buses de direcciones y datos, entonces esto es lo que haría el programa:

1. Seleccionar comando "Grabar byte"
2. Cargar archivos en la RAM
3. Comenzar secuencia de grabación:

En la secuencia de grabación, una vez que han sido cargados los datos que se usan para la secuencia (55h, AAh, 2Ah, A0h), para el primer ciclo de la secuencia el programa pasará a cargar el bus de direcciones con el dato 5555h.

Aquí el programa envía la dirección donde se ubica el byte 55h al par de registros H y L para cargar el dato en el par de registros D y E.

MVI H, data
MVI L, data

Ejemplo*

MVI H, 2Ah
MVI L, B5h

Donde el dato 55h lo obtiene de la misma dirección de la memoria RAM (dirección ejemplo 2AB5h)

El dato obtenido será almacenado en los registros D y E, mientras que nuevamente los registros H y L son cargados con la dirección almacenada en el programa (dirección ejemplo: F550h):

MVI D, data
MVI E, data

Ejemplo*

MVI D, F5h (dirección del byte AAh)
MVI E, 50h (dirección del byte AAh)

Ya que se ha cargado la dirección, será leída y el dato será cargado en el acumulador:

MOV A, M*

Donde M es la dirección cargada previamente en los registros D y E y el dato en el acumulador será el 

byte AAh.

¿Por qué leer los datos desde la RAM y no cargarlos directamente desde la memoria del programa? 
Porque el programa trabaja con estos bytes todo el tiempo hasta que termines de grabar por completo una EEPROM, y hacer eso requiere más instrucciones, ya que retornas, realizas saltos y todo para acceder a los mismos datos, además que tardas más en acceder a memoria del programa que a la memoria RAM.

Sigamos

Una vez cargado el dato AAh y la dirección 5555h, el programa enviará esos datos a la EEPROM (STAX D)
Pero, aquí la instrucción dice que la dirección y el dato va destinado a la memoria RAM. Aquí se debe implementar un circuito para que deshabilite la RAM durante esta instrucción y el dato y la dirección estén presentes para la EEPROM y no para la memoria RAM.

Cuando ha sido enviado el primer "paquete de datos" a la EEPROM, se repite todo este proceso pero ahora con los datos marcados en la tabla del datasheet donde dice 2nd Bus Write Cycle.

Ese es el algoritmo para un ciclo de escritura, en total son 4 para los 4 ciclos de escritura para 
grabar un byte.

Se me olvidaba, al llegar al cuarto ciclo de escritura, la tabla del datasheet dice:

Addr: BA
Data: Data

Esto que quiere decir?

Esto significa que aquí el programa solicitará tu dato y dirección donde quieras grabar el byte. 

Supongamos que quieres grabar en la dirección FFFFh y el dato 10h, aquí el programa lee primero la dirección y la almacenará en el par de registros D y E y luego almacenará el dato en el acumulador. Al almacenarse te pedirá que presiones Enter para grabarlo en la memoria, presionas Enter y se ejecuta la instrucción (STAX D), pero el circuito que se debe implementar deberá deshabilitar la memoria para que los datos no sean almacenados en la RAM, sino que vayan directo a la EEPROM.

Una vez grabados, el programa lee la dirección donde se grabó el byte y lo almacena en el registro B, los compara el introducido por ti y el leído y si está correcto retorna a donde vuelve a ejecutar el algoritmo de escritura (Byte Program) para grabar otro byte.

Si el dato grabado es incorrecto, saltará a otra dirección notificandote el error.

Esta secuencia puedes hacerla de forma que sea un solo archivo donde el programa accederá desde una determinada dirección y ahí ya sabrá que hacer con el resto.

Las normas generales son:

1. Las secuencias son exactamente las mismas para todas las EEPROM que maneja
2. El algoritmo de grabación y las demás son las mismas para todas las EEPROM que maneja
3. La identificación de comandos era acceder directamente a la RAM con el dato proveniente del teclado hexadecimal o con un algoritmo de comparación con múltiples bytes para acceder a la dirección donde se encontraban los datos. O en algunos casos se accedía a la memoria RAM para saltar a la dirección contenida ahí leyendo el teclado y sumandole una cantidad fija para acceder en caso de que la dirección que se obtenía al pulsar solo una tecla ya estuviera ocupada por otro dato.

Finalmente, al terminar, el programa retornaba hasta donde te pide seleccionar la memoria EEPROM con la que trabajarás.

---------------------------------

Perdón si me exageré en la respuesta, pero no entiendo otro lenguaje de programación para tratar de hacerlo más simple 

Es lo poco que recuerdo del programa, ya que era algo grande, con una memoria de 65.536 apenas cubrías el espacio necesario para el programa (64.000 bytes aprox.)

La parte más "pesada" es donde arrancaba y le tocaba cargar todas las direcciones de las subrutinas y saltos para todas las memorias, menús, algoritmos y otras cosas que necesitara durante su ejecución.
Una vez cargado ya se volvía "ligero" el trabajo, aunque algo laborioso 

Espero sirva de algo, al menos para dar una idea de como sería, dudas? aquí estoy y espero no tardarme 

Salu2!


----------



## TRILO-BYTE (Feb 12, 2014)

es justo lo que buscaba alguien con la experiencia en memorias flash 
lo revisare con cuidado pues ahorita tengo unos proyectos que me han encargado para nada sensillos

algo que era mi duda

vi que la hoja de datos me marca unas direcciones que van en secuencia 
lo intente con resultados para nada satisfactorios

mi pregunta es:

cuando se hace el cambio de direcciones que marca el fabricante 
¿debo tener habilitado o deshabilitado el chip enable?
yo lo hise en ambos casos pero por desgracia no pude grabar nada 

leere con cuidad lo que hisiste y comentare en un futuro espero que sea pronto los resultados 

ojala en un futuro este prototipo grabe lo que sea


----------



## Sr. Domo (Feb 12, 2014)

El cambio de direcciones es continuo, o sea uno tras otro. No deben haber "pausas" entre cada dato y dirección, ya que el control de la EEPROM lo tomará como un dato erróneo, no lo reconocerá y deberás reiniciar la secuencia.
Esto es por ejemplo, si introduces un dato y dirección y enseguida dejas ambos buses de la EEPROM en ceros, ahí el control de la EEPROM lo toma como un comando erróneo y no continua con la tarea que debía hacer, por lo que jamás podrás grabar un dato.

Para que la EEPROM pueda grabar es cuando un dato y una dirección, enseguida envíes el otro y así hasta llegar con el dato a grabar.

El señor datasheet nos dice:



La línea #CE o Chip Enable debe estar en bajo, L o 0 para programar, leer, borrar...

También debes observar muy bien esta tabla, ya que podrías estar deshabilitando la escritura, por lo que jamás podrás grabar algo si la línea #WE (Write Enable) está en alto, esta línea solo debe estar en alto cuando leas un dato de la memoria.

Para comprender mejor, aquí está como sería la secuencia durante la programación:



Como dice, aquí la programación está controlada por la línea #WE para evitar lo que posiblemente te suceda. Y viendolo bien, tal vez te falle la programación por las transiciones que hay en el bus de datos y direcciones a la hora de cambiar los códigos. Para evitar esto se usa la línea #WE para "disimular" esas transiciones.
Tal vez te preguntarás ¿Porqué deshabilitar #WE si los datos se perderían? No, no pasa eso, los datos se quedan, ya que los datos y direcciones presentes quedan almacenados temporalmente en la EEPROM durante el flanco de bajada de la línea #WE, por lo que los datos se quedan ahí aunque los quites de los buses.

Aclaro aquí: el dato queda "latcheado" con el flanco de bajada de la línea #WE, por lo que ya no se perderá ni tomará como un error el control de la EEPROM al cambiar los datos en sus buses.

El funcionamiento de este tipo de EEPROMS es muy complicado al principio, pero después de unas buenas leídas al datasheet de una EEPROM de este tipo ya podrás entender memorias parecidas y se te hará facil, como todo


----------



## TRILO-BYTE (Feb 12, 2014)

orale eso me sono a no va a funcionar con el CD4040 para grabar 
por que deshabilitaba el CE
debere usar una alternativa economica sin llegar al 82c55  

alomejor usare el 74hc595 
eso me para por no razonar el hardware

edito 

creo que el datasheet que lei una ocasion  estaba muy confuso era de una 29fxxx no recuerdo cual pues ya tiene un año que lo intente y se perdio esa memoria

pero explicado con peras y manzanas alomejor sea posible mejorar el circuito

nunca menciono la hoja de datos lo del CE y el WE 
creo que ahi estubo mi error garrafal  a todos nos pasa


----------



## Sr. Domo (Feb 14, 2014)

Lamentablemente es así, el CD4040 no servirá... lo ideal son los contadores programables, pero si quieres programar una dirección tras otra de forma secuencial, o sea que no grabes en la dirección 2A0Ch y luego te saltas hasta la dirección 3B0Dh por ejemplo. Si es necesario esto de programar de forma aleatoria, pues lo ideal son los contadores programables, si la idea es programar desde la dirección 0000h, luego la dirección 0001h y así hasta la FFFFh, pues con un arreglo en cascada de 2 CD4040 será más que suficiente.

La línea #CE (Chip Enable) como su nombre lo dice "habilitar chip", si no lo habilitas, la EEPROM ignorará todo lo que suceda en los buses de datos y direcciones, por eso es la que casi todo el tiempo debe estar en bajo, ya que la entrada es negada (signo #).

Durante el desarrollo del programa, mejor dicho, casi al final, mi mente retorcida tuvo la maravillosa idea de desarrollar una pequeña interfaz un tanto parecida al 82c55 para un solo puerto. En ese puerto pasaban todos los datos y direcciones hacia el periférico (así los llamo a los dispositivos que en este caso es la EEPROM)
Esta interfaz iba conectada, en mi caso, al bus de datos y direcciones del uPC8085, donde la dirección sería para distinguir hasta 65.635 periféricos distintos, y solo 65.535 por que la dirección 0000h era inválida.

Entonces, tu simulabas un almacenamiento en la RAM y el dato en realidad iba a la dirección propuesta por los registros H y L.

Jamás diseñé tal circuito, pero no es complicado hacerlo o eso creo yo 
El circuito, según yo, lleva pocos componentes TTL o CMOS, unos decodificadores, puertas lógicas, latches y buffers.

Pero, que pasaba entonces para grabar la EEPROM?
Aquí en vez de enviar el dato y dirección sobre ambos buses, se generaba la dirección del periférico y mediante el bus de datos se enviaban todos los bytes para la secuencia, aquí se torna un tanto más complejo, ya que se debía desarrollar un protocolo simple de comunicación entre la interfaz y el CPU.

Despues de pasar sobre la interfaz que es más que nada un circuito que gestiona la entrada o salida de datos cuando se le envía la dirección que le corresponde, en todo el tráfico de datos entre el CPU y el periférico pasan bytes de datos y de control, los de datos pasan directamente al periférico y los de control pasan al controlador del periférico.

Ahi envias los bytes necesarios y el controlador del periférico ya debe saber que hacer. Aquí debes diseñar ese controlador, igual, mi mente retorcida me generó muchas ideas que jamás saldrán a la luz por que no tengo $$ para hacerlo, pero podría asegurar que funciona 
El controlador era simple, principalmente la parte donde demultiplexa los bytes recibidos según su protocolo, cada tantos bytes le pertenecen a la EEPROM y cada tantos al controlador, esos bytes del controlador se usaban para generar las condiciones necesarias en las líneas #CE, #WE y #OE porque el CPU no trae esas líneas, pues el controlador las genera virtualmente.

Cuando tenía ya una idea mejor de programar que era la mencionada, ví que el hardware no era tan grande como pensaba, ya que solo es el microcomputador (CPU, RAM, ROM), las interfaces a pantalla, teclado y programador y el controlador junto con su periférico.
Mi idea era hacer una plaqueta con varios zócalos DIP donde estarán conectados directamente al controlador donde generaría las condiciones de las líneas de control, el voltaje necesario 3.3v, 5v, 12... y todo esto controlado mediante un protocolo de E/S.

Lo mencionado es muy similar a una PC cualquiera, cuenta con la computadora en sí, las interfaces que gestionan la comunicación del puerto USB por ejemplo, el controlador que puede ser el circuito integrado en el interior de una memoria USB y el periférico en general que es la memoria de la memoria USB, algo confuso, pero así era la arquitectura 



> nunca menciono la hoja de datos lo del CE y el WE



Preguntale nuevamente al señor datasheet de cualquier EEPROM y vas a ver que te explica cada pin del encapsulado 

Pero como dices, a todos nos pasa, tienes razón en eso, una vez quise leer una EEPROM 27SF020 que era la BIOS de una PC vieja y no veía nada, hasta que ví que la línea #OE la tenía a VCC, entonces le puse un puente y se compuso


----------



## TRILO-BYTE (Feb 14, 2014)

ja si exacto yo queria usar el 82c55 para el grabador

pero mi idea se baso en hacer algo barato , facil para que cualquier colega se aventurara a cosntruirlo
y sobretodo pequeño.

el problema es que es tan simple que tiene sus debilidades "Error Garrafal mio" bueno ni tan mio ya que la idea la habia copiado 

el 82c55 lo he visto en maquinas de laboratorio donde usan muchas lineas de direccionamiento 
un ejemplo es el monocromador, los Raman , los magnetometros y los amplificadores Lock-in
y las tarjetas GPIB es decir es un circuito muy util para nada obsoleto por lo que veo.

lo malo es que es muy caro comparado con los CD4040

de hacer un harware no le tengo miedo alguno Daniel Meza es testigo de mis molestas preguntas 



ya que hacer una computadora es laborioso pero nada frustrante para un amante de la electronica 

aqui un ejemplito de mi computadora que por falta de tiempo no he terminado 





y aca un pequeño experimento corriendo en un viejo atari 2600


----------



## Sr. Domo (Feb 14, 2014)

Tal vez si se necesite el 82c55, pero habrían varios puertos de sobra, ya que solo se necesitaría uno por donde pasarán los datos y direcciones.

Me gusta la idea de hacerlo pequeño, pero lo malo de esto es que está muy limitado por varias razones: no permite la grabación de un solo byte en caso de que te equivoques y te des cuenta ya que llevas muchos bytes programados, no permite la protección de la información de la EEPROM, no puedes borrar por sectores...

Con el hardware un poco más sofisticado ya se podrían realizar las tareas que mencioné, pero ese hardware podría salir más caro que el original, tampoco un precio exagerado 

Tu idea se parecía a la que yo tenía, solo que yo iba a programar las EEPROM desde un intel 8085 y no desde la PC, ya que no entiendo para nada el protocolo USB, además que no sale mucha información acerca del mismo...

Para el direccionamiento se pueden reemplazar los contadores por unos latches octales 74373 por ejemplo, ahí la dirección la genera el programa, y como vayas programando se haría un pequeño código para que lo incremente si no presionas X tecla para programar desde otra dirección por ejemplo.
Los 74373 son baratos, yo los consigo a 13 pesos y pueden servir para almacenar todos los datos y son útiles, ya que trabajan con bytes al igual que el bus de datos del CPU.

Trataré de recordar bien como iba ese "hardware" y subo el diagrama de bloques para que te des una idea de como sería 



> aqui un ejemplito de mi computadora que por falta de tiempo no he terminado



Se ve lindo y bastante prolijo a comparación de mis circuitos en protoboard 

Muy lindo todo, yo por falta de $$ no he podido hacer cosas así 

Pero desde que me entró eso de aprender programación, se me ha hecho tan linda esa parte que he estado desarrollando un procesador de 8 bits bajo puro TTL, donde según yo, es un procesador parecido a los CPU RISC, pero tiene un set de instrucciones de más de 100 instrucciones 

En mi CPU he implementado todas las instrucciones que me gustaría que tuviera el 8085, pero como no las tiene, pues las puse para mi diseño. Aún no lo termino, pero va a quedar bastante lindo, y ahí el hardware para programar es más simple.

Lo único que he hecho son pruebas con la ALU 74181 que será usada para mi diseño y un montón de 74373 y 74193 para direccionar la memoria del programa (24 bits de bus  )
No he podido hacer cosas así por lo mismo, no hay tanto $$ para compar material...


----------



## TRILO-BYTE (Feb 14, 2014)

eso es lo que limita el diseño tiempo y dinero
eso de los 74HC373 no es nuevo en grabar una memoria paralela
lo hace bien el Batronix v3.3 
es un grabador bastante bueno para ser un grabador casero pero como todo tiene un talon de aquiles  que es por PUERTO PARALELO
por desgracia son escasas las computadoras con puerto serie y paralelo

asi que es bueno cuando uno tiene una PC con puerto pero igual tambien tiene su talon de aquiles el hardware es gratis pero el programa Prog-Studio no es gratis 

de todos modos si quieres hecharle un ojo al codigo y hacer unas modificaciones
puedo adjuntar el codigo fuente 

puedo decir que puedes usar el Compilador C18 que es para programar el microcontrolador 
y Visual C++ 2008 "es nesesario para que funcione la libreria "

y asi hacer que mi programa que es una porqueria quede algo desente 



Edito

si tengo muchas cosas que no las compre yo 
cuando estudiaba y creo que habia pocos con talento pues me encargaban los circuitos y me hise de protos , circuitos y muchos tiliches , yo solo ponia mano de obra y los demas todo y al final se me quedaba el material y sirve para hacer juguetitos


----------



## Sr. Domo (Feb 14, 2014)

Sabes, algo que se me ocurre es:

Por medio del puerto USB grabarlas como estaba en la idea original. Después, decodificarlo o "deserializarlo" u obtener los bytes en paralelo para que mejor se entienda, y luego implementar el controlador especial para EEPROMS. Ese controlador especial deberá ser compatible con la mayoría de EEPROMS, o sea que con un solo zócalo puedas grabar cualquier memoria.

La idea de hacerlo USB es muy buena, ya que no todos tenemos puerto paralelo, solo puertos serie...

Y algo que se me ocurría, ya que esto funcionaría con una PC, en el mismo zócalo puede ponerse una EEPROM e implementar la función "Copiar EEPROM" para que los datos se copien a una parte de la RAM de la PC o directamente a un archivo txt o hex para no perderlo, y luego ese archivo usarlo para grabarlo en otra EEPROM. Pero igual, el hardware puede aumentar...



> de todos modos si quieres hecharle un ojo al codigo y hacer unas modificaciones
> puedo adjuntar el codigo fuente
> 
> puedo decir que puedes usar el Compilador C18 que es para programar el microcontrolador
> ...



Bueno, nunca he programado algo para una PC, por eso no puse fragmentos de programa, ya que supongo que no serían compatibles o el funcionamiento sería distinto, solo te doy unas cuantas ideas. Para modificarlo ya no entro 

Lo ideal sería desarrollar correctamente el hardware externo a la PC, partiendo desde el puerto USB, si tu sabes como funciona el puerto USB te tendrías que encargar de "deserializar" los bits para que yo acá desarrolle el hardware donde irá la EEPROM 
Ya que por ahí deberá pasar el comando y otros datos para el controlador y si se edita el código fuente y luego se hace el hardware, tal vez necesitaríamos editarlo nuevamente.

Tal vez para "deserializarlos" tendría que usarse el mismo PIC y que los bytes paralelos los saque por un bus para que el hardware restante los pueda usar.


----------



## TRILO-BYTE (Feb 15, 2014)

eso de copiar la EEPROM lo hace muy bien 

tiene un boton que dice copiar y una casilla que uno de dice al programa cuantos Bytes copiar 

lo usaba para copiar juegos del NES y algunos tiliches que encontre 
graba una EEPROM a una velocidad amm algo desesperante pero lo hace 

yo uso las Sram HY6264 , HY62128 por que tengo muchas y en el trabajo encontre muchas mas asi que EEPROM no me llamo la atencion 

pero eso de la PC pues no te creas igual anduve a ciegas y aprendi a programar que no es dificil pero sin ayuda es muy dificil suena contradictorio

primero empece con los cables Rs232-USB , Borland C y con CCS pero CCS me era muy limitado al programar , el RS232 tenia problemas con los time-out y el Borland C era muy obsoleto para estos dias

y tuve que aprender por mi obsecion 

los algoritmos son los que mas dan lata como el formato intel HEX ese me costo 2 dias enteros entenderle , generar un HEX en pantalla sobretodo guardar y leer eso la verdad desanima mucho por que es muy dificil entenderle si nadie te enseña 

pero a fin de cuentas es un diamante en bruto 
si me gustaria que le movieran y hacer cosas a voluntad del foro asi como dices del 82c55 seria genial hacerlo para escribir una FLASH


----------



## Sr. Domo (Feb 15, 2014)

Entonces retiro lo de que le hace falta copiar bytes de una EEPROM a otra 



> yo uso las Sram HY6264 , HY62128 por que tengo muchas y en el trabajo encontre muchas mas asi que EEPROM no me llamo la atencion



yo estoy al revés, tengo muchas EEPROM, pero memorias SRAM casi no, no me gustan las DRAM, muy difíciles de usarlas 
La única SRAM grande que tengo es la W26010A que es de 64Kb me parece, tiene 16 líneas de dirección para seleccionar dos bytes, pues era de un disco duro.

Para aprender programación, fuí leyendo muchos libros que hablaran de eso, estudié la arquitectura de un procesador "genérico" y especialmente en el 8085. Después fuí aprendiendo para que son las instrucciones y que tanto puedes hacer. De ahí el feo concepto de "la programación es un asco!" ya quedó en el olvido 



> primero empece con los cables Rs232-USB , Borland C y con CCS pero CCS me era muy limitado al programar , el RS232 tenia problemas con los time-out y el Borland C era muy obsoleto para estos dias



Yo lo que luego hacía era crear mis propios protocolos de comunicación. Hasta llegué a diseñar un sistema inalámbrico que te permitía controlar 65.536 dispositivos distintos mediante una línea unidireccional por vía RF. 

Es algo difícil entender los códigos hexadecimales, tienes que saber muy bien que número representa cada símbolo, luego no perderte en la secuencia "instrucción - dato" porque si te equivocas puede ejecutar un dato o leer una instrucción...
Programar en lenguajes como C hace que me duela la cabeza, será porque estoy muy perdido en ese lenguaje 



> si me gustaria que le movieran y hacer cosas a voluntad del foro asi como dices del 82c55 seria genial hacerlo para escribir una FLASH



Solo te podría ayudar en el desarrollo del hardware, acerca del programa ya no, solo te doy ideas o los métodos que usaba, pero así como para modificar el codigo fuente, pues ahí si ya no puedo ayudarte...


----------



## Meta (Feb 18, 2014)

Hola:

Muy bueno el invento, sobre todo copias o grabar EPROM de la NES.







Parece ser que usas Visual C++. ¿Qué versión usas?

Lo comento porque tengo Visual Studio 2010 y se puede crear formularios Windows, en cuanto al 2012 y 2013 no lo incluye, solo modo consola.

Por eso quiero adaptar el código a C# y VB 2013 si usted lo desea, por supuesto. 

Otra cosa. 
¿No has pensado en emigrar usando MPLAB X v2.00 con el XC8 que es más moderno?
Lo que me da pena el C18 que está en desuso y tarde o temprano dejará de actualizar como ocurrió con MPLAB v8.92.

También está el completísimo SDK del puerto USB para los PIC18F.

Es una sugerencia, no te mosquees. 

Saludo.


----------



## TRILO-BYTE (Feb 18, 2014)

pero porsupuesto que es para el NES de hecho por eso empeze el proyecto del grabador 
por que siempre quise hacer un programa en esta consola
para eso esta en CC65 un compilador ANSI C funciona bien pero  no podia jugarlos en la consola real

los grabadores EPROM son muy caros y los caseros funcionan en MS-DOS o con el puerto ISA
EL BATRONIX v3.3 funciona bien pero es de paga y por puerto paralelo

Respecto al VC++ es el 2008 por que asi lo baje de la pagina de microsuave funciona bastante bien
respecto a C# no funciona la libreria de microchip que hace la vida mas facil, por eso me quede con VC++.

no le veo mucha diferencia a C# y a V C++ solo cambias puntos por flechas el codigo es igual

el MPLAB X si lo he usado pero no me acomode tarda 5 veces mas en cargar que el MPLAB normal 
pero si lo tengo y el XC8 bueno es que tengo la vercion original del C18 por eso no lo he probado

cuando quiero proyectos serios uso el C18 y cuando quiero proyectos rapidos uso el CCS

el SDK del USB puedes verlo en la carpeta de Microchip solutions /USB/ HID/ Custom demos/ picdem Fusb

ahora el codigo fuente si quieres hecharle el ojo me dice y lo subo no lo subo por que esta algo pesado
y si sabes de algorimos de programacion de la FLASH mejor aun grabar directo una FLASH
ahorita no he tenido tiempo de meterle mano pues ando algo ocupado

saludos


----------



## Meta (Feb 18, 2014)

Hola:

Has hecho un buen trabajo. Me imagino que el grabador de EEPROM caro que dices es el de siempre.






Es cara, si lo usas mucho, vale la pena. Comprar C18, lo malo que ya está obsoleto y no se actualiza. ¿Tan caro te costó?

Como hay que renovar, pues me qeudocon el XC8 el gratuito. En este seguirán actualizando para los nuevos Pic, si usas el PIC18F no te hará falta.

El tema de C# y C++, no solo cambia los puntos, cambian otras cosas, C# es más fácil y cómodo.

Juraría que había un sdk para C# y los PIC, o son cosas mías.

En tu proyecto,buen trabajo.


----------



## TRILO-BYTE (Feb 18, 2014)

no el C18 no lo compre , me lo dieron en un curso junto con una placa de desarrollo
lo tuve que tomar por que en mi escuela no eseñaban nada y en la red te confunde

y lo de los nuevos pic18 si hay mejores y mas baratos aun menos de $3 dolares
pero lo malo es que debes tener el pickit3 para que los puedas grabar 
y no me siento muy fan de Microchip bueno mas bien de cualquier micro 

el willem nunca lo arme y el que decia es el grabador universal que aca en mi pais esta por ensima de los $300 usd muy caro para grabar una eprom que te encuentras en viejas maquinas 486

el batronix v3.3 esta en la pagina de batronix pero es con puerto paralelo para usarlo debo encontrar una maquina con puerto paralelo 
y el programa es el prog-Studio y es de paga y corre en winxp 

asi que decidi hacer el mio

no soy tan fan de los micros asi que no busque como hacerlo con el Avr   por lo que veo los americanos venden un kit que hace lo mismo que el mio pero bueno el mio es gratis y cualquiera puede armarlo en casa 

el C# bueno si le he movido pero mas bien son clases las clases se actualizan en verciones mas recientes pero para leer un text box o un trackbar pues me quedo con Vc++

si es posible comunicar el puerto USB a mano limpia pero te avientas 400 lineas mas de codigo que mandando llamar una clase lo he hecho y no me gusto

o quien sabe es cuestion de ver las verciones recientes del microchip solutions aver si liberaron una nueva DLL para el HID USB.


----------



## Sr. Domo (Feb 18, 2014)

Meta dijo:


> Hola:
> 
> Muy bueno el invento, sobre todo copias o grabar EPROM de la NES.
> 
> ...



Hola nuevamente 

No, no uso compiladores ni nada, solo el bloc de notas, ya que usaba códigos hexadecimales. Por eso no entiendo lenguajes de programación, solo ensamblador 

Cuando programe mi primer programa  consideraré los compiladores que me recomiendas para ver cual me gusta o se adapta a lo que necesite 

Salu2!!


----------



## TRILO-BYTE (Feb 19, 2014)

para Domonation_Corp

si sabes ensamblador es muy facil usar un compilador Visual
es casi casi como usar power point "poder punto" 

arrastras los botones , los pegas , al boton le das doble click y metes el codigo

yo la verdad no soy un gran programador solo hago copias y pegas de codigos que funcionan de foros  ya saque el cobre.

y los algoritmos pues esos si los invento yo

hay mucha ayuda de parte de microsoft cuando buscas como funciona el codigo
ejemplo textBox1->Text asi lo buscas en google y te ayuda mucho microsoft en su pagina oficial  asi le hago cuando quiero buscar que hace cada cosa

y en la pagina de Conclase C ayuda mucho con los algoritmos de programacion

en resumen es muy facil aprender Visual C a el C tradicional como el Dev C o el Borland C "el de consola"

en lo personal ensamblador para mi es monotono , redundante y dificil escribir un algoritmo  no me gusta y muchas veces no puedes reciclar algoritmos como en C

suerte


----------



## Meta (Feb 19, 2014)

Hola:

Aquí una un tutorial en PDF hecho con PowerPoint para que sigas los pasos cómodamente. Héchale un vistazo y me dirás. El mejor que hice fue hecho en Visual C# que puedes ver aquí. El de Visual C++ y Visual Basic es más directo, si ya haz visto el tutorial de C# así que te pongo este.

http://electronica-pic.blogspot.com.es/2008/11/electrnica-pic.html

Ya verás que cómodo y fácil. Aunque sea de unas 500 páginas de lectura rápida, te vale las 200 primeras.

Saludo.


----------



## Sr. Domo (Feb 19, 2014)

TRILO-BYTE dijo:


> para Domonation_Corp
> 
> si sabes ensamblador es muy facil usar un compilador Visual
> es casi casi como usar power point "poder punto"
> ...



Ahhh, suena interesante, porque en ensamblador llega un punto donde el programa es muy grande y te confunde 

salu2!


----------

