Con este tipo de hardware llega un momento que al usuario le molestan tantas piezas sueltas y cables de interconexión. Estando acostumbrado a los sintes modulares no me asustan los cables pero creo que no es la preferencia más popular.Popopo escribió: ↑06 Abr 2022, 21:48De hecho, es posible que la versión final, en vez de soldar las piezas directamente a la PCB que se saque, ponga unos pines hembra y haga una plaquita con ese propósito, logrando no tener que tocar nada de nada más y tener un 4en1, osea, como la gameboy, cambias el "cartucho" y tienes otro juego, pues en el mismo cartucho, eliges el software + módulo protección que quieres y tienes tu tester de lo que se tercie.
Va de Retro DRAM tester [v2.00]
Moderadores: cacharreo, Fundadores
Reglas del Foro
Aquí solo tienen cabida proyectos de hardware que incluyan siempre al menos sus esquemáticos para poder reproducirlos si llevan componentes electrónicos, y si es posible los ficheros del programa en que se hacen, los diseños de las placas, los gerber, etc. Si llevan algún tipo de software asociado debe estar diponible el código fuente
Para los que no cumplen estas condiciones se debe postear en el foro de proyectos generales.
Aquí solo tienen cabida proyectos de hardware que incluyan siempre al menos sus esquemáticos para poder reproducirlos si llevan componentes electrónicos, y si es posible los ficheros del programa en que se hacen, los diseños de las placas, los gerber, etc. Si llevan algún tipo de software asociado debe estar diponible el código fuente
Para los que no cumplen estas condiciones se debe postear en el foro de proyectos generales.
- cacharreo
- Moderador
- Mensajes: 5627
- Registrado: 09 Ago 2019, 10:17
- Ubicación: /home/cacharreo/
- Has thanked: 1190 times
- Been thanked: 2719 times
- Contactar:
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
© cacharreo
- cacharreo
- Moderador
- Mensajes: 5627
- Registrado: 09 Ago 2019, 10:17
- Ubicación: /home/cacharreo/
- Has thanked: 1190 times
- Been thanked: 2719 times
- Contactar:
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Finalmente ha sido posible hacer el experimento con los fusibles utilizando tensión e intensidad, dejo el enlace a la gráfica actualizada.
© cacharreo
- cacharreo
- Moderador
- Mensajes: 5627
- Registrado: 09 Ago 2019, 10:17
- Ubicación: /home/cacharreo/
- Has thanked: 1190 times
- Been thanked: 2719 times
- Contactar:
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Ahora mismo he hecho pruebas de cara a desacoplar las librerías y la visualización en la pantalla y, en un futuro próximo, haré lo mismo con la lectura del teclado.Popopo escribió: ↑05 Abr 2022, 13:24Creo que es interesante poder manejarlo desde el ordenador, porque más adelante con una aplicación Java sería muy cómodo tener toda la información y también realizar la navegación por los menús, sin contar con el pequeño ahorro que podría suponer. Adaptado a preferencias y también, como es mi caso, a problemas visuales.
De todas maneras, es algo que se puede hacer a futuro una vez terminado, tal y como bien habéis dicho, el modelo actual del tester. No imaginé que se pudiera usar los pines del I²C para comunicación por vía serie. Pues genial
A fin de cuentas y en cuanto a la salida, nos quedaría un módulo/librería para la OLED 0.91" de 128x32, otro para la OLED de 1.3" de 128x64 y se puede crear uno para salida serie con el mismo objeto "display" que usan sus homólogos pero que "imprime" sobre un buffer de 4 líneas x 21 caracteres y cada vez que se llama a la función para mostrar el buffer en "pantalla" se envía por puerto serie (transmitir esos 90 bytes a 38.4kb/s se lleva un poco menos de 24ms). Respecto a la entrada, hace falta un módulo para la botonera y otro que reproduzca las mismas funciones pero que recoja e interprete los datos del puerto serie.
© cacharreo
- cacharreo
- Moderador
- Mensajes: 5627
- Registrado: 09 Ago 2019, 10:17
- Ubicación: /home/cacharreo/
- Has thanked: 1190 times
- Been thanked: 2719 times
- Contactar:
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
En los últimos días estábamos solucionando la conversión entre el bus de datos y direcciones de las memorias y del tester. En abstracto éste es un problema resoluble de forma óptima mediante redes de permutaciones de bits (Beneš), un terreno muy trillado en criptografía pero como la realidad es muy tozuda había que comprobar en la práctica los resultados en un Nano. La función con la red de permutación de bits para el bus de direcciones de la 4116 daba buenos tiempos, calcular la asociada a una fila o una columna de una memoria llevaba en promedio unos 14µs o, lo que es lo mismo, 224 ciclos de reloj del Nano. Cada operación de direccionamiento implica direccionar una fila, una columna, manipular /RAS, /CAS, /WE... por lo que, si se puede, mejor evitar el lujo de invertir los 28µs/448ciclos en las permutaciones.
Modelizando ambos buses encontramos que para el de direcciones hay tres tipos diferentes, el de la 41464, el de la 41256 y el de la 44256; y para el de datos son también tres tipos y coinciden con las mismas memorias. Si utilizamos tablas lookup para las permutaciones de los buses de direccionamiento y datos se requieren unos 3942 bytes, bastante más de los exiguos 2048 bytes de la SRAM del Nano, pero si en lugar de generar en RAM las estrictamente necesarias (de 816 o 1542 bytes según la memoria) antes de las operaciones, por ejemplo, durante la espera en la pantalla de cableado, van registradas como constantes en el propio programa es viable alojar esos 3942 bytes en los 32768 de la memoria de programa. No tenemos otra opción puesto que en las pruebas con la tabla lookup en RAM para la 4116 teníamos un tiempo de "cálculo" promedio de 0µs (por debajo de la precisión de la medida en microsegundos, o sea, <1µs o <16 ciclos) frente a los 14µs del cálculo sobre la marcha.
La parte simpática apareció cuando nos topamos con un curioso bug del compilador de Arduino IDE. Supongamos que ejecutamos éste simple y sucio código en nuestro Nano:
obtendríamos en el puerto serie la siguiente salida, tal y como cabía esperar:
pero si modificamos donde dice "bB < 3" por "bB < 4" para que en lugar de mostrar 3 elementos muestre 4, la salida es:
o cualquier burrada parecida, muy fácil de resolver con un programa tan pequeño (de menos de 160 bytes) pero que ha molestado en las pruebas reales con un programa de más de 16kB en el que el objeto que gestiona la pantalla se lleva nada más arrancar el 25% de la RAM disponible.
Modelizando ambos buses encontramos que para el de direcciones hay tres tipos diferentes, el de la 41464, el de la 41256 y el de la 44256; y para el de datos son también tres tipos y coinciden con las mismas memorias. Si utilizamos tablas lookup para las permutaciones de los buses de direccionamiento y datos se requieren unos 3942 bytes, bastante más de los exiguos 2048 bytes de la SRAM del Nano, pero si en lugar de generar en RAM las estrictamente necesarias (de 816 o 1542 bytes según la memoria) antes de las operaciones, por ejemplo, durante la espera en la pantalla de cableado, van registradas como constantes en el propio programa es viable alojar esos 3942 bytes en los 32768 de la memoria de programa. No tenemos otra opción puesto que en las pruebas con la tabla lookup en RAM para la 4116 teníamos un tiempo de "cálculo" promedio de 0µs (por debajo de la precisión de la medida en microsegundos, o sea, <1µs o <16 ciclos) frente a los 14µs del cálculo sobre la marcha.
La parte simpática apareció cuando nos topamos con un curioso bug del compilador de Arduino IDE. Supongamos que ejecutamos éste simple y sucio código en nuestro Nano:
Código: Seleccionar todo
typedef struct
{
byte array1[3];
byte array2[4];
} myStruct;
const static myStruct data[2] PROGMEM = {
{
{9, 8, 7},
{1, 2, 3, 4}
},
{
{10, 11, 12},
{6, 7, 8, 9}
}
};
void setup()
{
Serial.begin( 115200 );
Serial.print( " [ " );
for ( byte bA = 0; bA < 3; bA++ )
{
Serial.print( data[0].array1[bA] );
Serial.print( " " );
}
Serial.println( "]" );
Serial.print( " [ " );
for ( byte bB = 0; bB < 3; bB++ )
{
Serial.print( data[1].array2[bB] );
Serial.print( " " );
}
Serial.println( "]" );
}
void loop()
{
}
Código: Seleccionar todo
[9 8 7]
[6 7 8]
Código: Seleccionar todo
[9 8 7]
[184 184 184 184]
© cacharreo
- Gomas48K
- Aspirante a demonio
- Mensajes: 271
- Registrado: 16 Jun 2021, 06:08
- Ubicación: España
- Has thanked: 716 times
- Been thanked: 216 times
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Hola, se me pasó por la cabeza, usar pantallas de tinta electrónica (Epaper), porque no necesitan refresco constante, solo al cambiar de imagen... pero los precios son muy altos.
Además, necesitan mas señales y se complicaba algo el implementarlas.
Solo lo comento, por dejar la idea, aunque no sea viable en este caso, lo mismo alguien lo lee y le puede ser útil para otros proyectos.
https://es.aliexpress.com/item/10050013 ... mainSearch
Además, necesitan mas señales y se complicaba algo el implementarlas.
Solo lo comento, por dejar la idea, aunque no sea viable en este caso, lo mismo alguien lo lee y le puede ser útil para otros proyectos.
https://es.aliexpress.com/item/10050013 ... mainSearch
Con mi Gomas 48K, hasta el mismo infierno!!!
- Gomas48K
- Aspirante a demonio
- Mensajes: 271
- Registrado: 16 Jun 2021, 06:08
- Ubicación: España
- Has thanked: 716 times
- Been thanked: 216 times
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Hace años era muy común, el hacer algo que no querías que te copiaran... y rellenarlo con resina.
Se han usado mil métodos para quitar esa resina, cada cual mas estrambótico... yo he llegado a quitarlo, hasta arañando con un punzón fino y una brocha... como si fuera un yacimiento arqueológico.
Con mi Gomas 48K, hasta el mismo infierno!!!
- cacharreo
- Moderador
- Mensajes: 5627
- Registrado: 09 Ago 2019, 10:17
- Ubicación: /home/cacharreo/
- Has thanked: 1190 times
- Been thanked: 2719 times
- Contactar:
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Si no me equivoco hasta fuentes de alimentación de Commodore venían con esa resina, termodinámicamente un disparate pero que entonces pareció buena idea.
(fotos cortesía de @pintza)
El método arqueológico es el más popular.
© cacharreo
-
- Aspirante a demonio
- Mensajes: 436
- Registrado: 25 Feb 2021, 00:18
- Has thanked: 190 times
- Been thanked: 118 times
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Según dice en https://www.tutorialspoint.com/how-to-u ... table-data , si se usa PROGMEM (almacenamos en la flash y no en la RAM) se debe leer esa zona con pgm_read_byte o pgm_read_byte_near.
Cambiando esta línea en el segundo bucle ya funciona.
Código: Seleccionar todo
Serial.print( pgm_read_byte_near(data[1].array2 +bB) );
- cacharreo
- Moderador
- Mensajes: 5627
- Registrado: 09 Ago 2019, 10:17
- Ubicación: /home/cacharreo/
- Has thanked: 1190 times
- Been thanked: 2719 times
- Contactar:
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Gracias por la aportación.
Por cierto, si no me equivoco con "pgm_read_byte" bastaría, el compilador se apaña usando el tipo de puntero adecuado sin necesidad de especificar "near" o "far".
En general el uso de PROGMEM implica tanto declararlo como ajustar el acceso a los datos en el código específico pero aquí mi intención era solamente mostrar el bug del compilador de Arduino IDE que no compila adecuadamente para un ATMega328P (y conociendo por la configuración que está compilando para un ATMega328P) para el que debería obviar PROGMEM como si no existiera, máxime cuando la estructura de datos está precedida de la cláusula "const" que es redundante al extremo.
Este bug genera situaciones más jugosas. Por ejemplo, el acceso a los datos no funciona si está dentro de un ciclo (loop como "for", "while", "do while") pero si se desenrolla el ciclo cuadruplicando, por ejemplo, la línea que muestra el dato, sí que funciona. Extremadamente divertido. Escrito en pseudo-código sería esto:
contra esto otro:
Viene a ser más o menos lo mismo que en la guía de referencia de Arduino pero es necesario para microcontroladores con doble espacio de direcciones y que requieran punteros de 32bits para acceder o a la memoria de programa (Flash) o a la RAM. No es el caso del Nano basado en un ATMega328P que tiene un espacio de direcciones único.issalig escribió: ↑08 Abr 2022, 20:16Según dice en https://www.tutorialspoint.com/how-to-u ... table-data , si se usa PROGMEM (almacenamos en la flash y no en la RAM) se debe leer esa zona con pgm_read_byte o pgm_read_byte_near.
Por cierto, si no me equivoco con "pgm_read_byte" bastaría, el compilador se apaña usando el tipo de puntero adecuado sin necesidad de especificar "near" o "far".
Y quitando PROGMEM también funciona, es lo más fácil e intuitivo y aún así los datos quedarán en memoria de programa tal y como están declarados.
En general el uso de PROGMEM implica tanto declararlo como ajustar el acceso a los datos en el código específico pero aquí mi intención era solamente mostrar el bug del compilador de Arduino IDE que no compila adecuadamente para un ATMega328P (y conociendo por la configuración que está compilando para un ATMega328P) para el que debería obviar PROGMEM como si no existiera, máxime cuando la estructura de datos está precedida de la cláusula "const" que es redundante al extremo.
Este bug genera situaciones más jugosas. Por ejemplo, el acceso a los datos no funciona si está dentro de un ciclo (loop como "for", "while", "do while") pero si se desenrolla el ciclo cuadruplicando, por ejemplo, la línea que muestra el dato, sí que funciona. Extremadamente divertido. Escrito en pseudo-código sería esto:
Código: Seleccionar todo
for ( byte bX = 0; bX++; bX < 4 )
Serial.printnl( array[bX] );
Código: Seleccionar todo
Serial.printnl( array[0] );
Serial.printnl( array[1] );
Serial.printnl( array[2] );
Serial.printnl( array[3] );
© cacharreo
-
- Aspirante a demonio
- Mensajes: 436
- Registrado: 25 Feb 2021, 00:18
- Has thanked: 190 times
- Been thanked: 118 times
Re: Test de Memorias 4116, 4164 y 41464 - NEWS
Lo que no tengo claro es que sea un BUG, simplemente, si se usa PROGMEM hay que usar pgm_read_byte para leer