Va de Retro DRAM tester [v2.00]

[cacharreo]

Añadida la placa v1.05 que simplifica el diseño sustituyendo el conmutador S1 de la v1.04 por 2 MOSFET (N-Channel y P-Channel) y un par de resistencias de 10kΩ. Esto ahorra al usuario tener que andar conmutando según la memoria a examinar.

[Rebobinando]

Dos cuestiones recurrentes,

1) Contamos con que los beta testers tendran la placa del prototipo v1.02 en dique seco un tiempo mientras se hacen con los componentes necesarios. No es un problema ni nada preocupante, cada cual a su propio ritmo.

2) Como beta tester ¿qué componentes debería conseguir?
Los del listado de componentes (BOM) de la placa v1.04 y añadid un 2N7000, un BS250 y algunas resistencias extra de 10kΩ 1/4W 1% (mínimo 2 resistencias más),

3) ¿Puedo usar un Arduino Nano con el chip CH340x en lugar del FTDI FT232RL?
Si actualmente puede comunicarse con el ordenador para subir un sketch compilado es buena señal, solo si no se le puede actualizar el cargador (bootloader) al conocido como "nuevo" (optiboot) no serviría en absoluto. Estos clones suelen funcionar bien y son económico pero cada uno es de su padre y de su madre con diferentes peculiaridades.

En cualquier otro caso el cambio afectaría de entrada a la velocidad de transferencia entre Nano y PC que habría que ajustarla a 57.6kps pero por lo demás ignoro si al no responder a las especificaciones del Nano original, a la larga conllevaría otros efectos secundarios sobre el firmware del tester.

Hay un indicio de cuál es el cargador de cada Nano en el Arduino IDE, si en Tools -> Processor aparece "ATMEGA328P" y al desplegar "ATMEGA328P (Old bootloader)" se puede probar a cambiarlo al que está encima "ATMEGA328P". Si sigue subiendo bien los sketchs al Nano es buena señal, si no habría que intentar actualizar el cargador (bootloader). Se pueden encontrar un montón de tutoriales online para llevar a cabo este procedimiento.

Muchas gracias por la inforrmación. La confirmación sobre los componentes es de gran ayuda

[cacharreo]

De nada aunque, a fin de evitar que cada uno acumuléis excedentes de componentes, pienso que lo suyo sería coordinarse con @Popopo, hacer una primera compra conjunta y lo que sobrara podría quedar para los kits cuando se distribuyan. Si ya habéis pedido, en el futuro podréis coordinaros con @Popopo para que los excendentes se usen para los kits.

Otra alternativa para los beta testers sería usar el listado de componentes de la placa v1.05 y añadir un conmutador SS-22D07 (DPDT) o similar, éste último solo serviría para la modificación del prototipo v1.02.

[cacharreo]

Actualizadas las modificaciones para el prototipo v1.02 añadiendo otra placa hija fija para convertirla en la placa v1.05.



Como siempre, esta modificación está especialmente recomendada para beta testers.

• Enlace a las modificaciones a realizar

[Popopo]

De nada aunque, a fin de evitar que cada uno acumuléis excedentes de componentes, pienso que lo suyo sería coordinarse con @Popopo, hacer una primera compra conjunta y lo que sobrara podría quedar para los kits cuando se distribuyan. Si ya habéis pedido, en el futuro podréis coordinaros con @Popopo para que los excendentes se usen para los kits.

Otra alternativa para los beta testers sería usar el listado de componentes de la placa v1.05 y añadir un conmutador SS-22D07 (DPDT) o similar, éste último solo serviría para la modificación del prototipo v1.02.

Me parece bien, hagámoslo.
Creo que voy a necesitar fusibles y no ando seguro que más, ZIF tengo, pantalla OLED tengo... ¿qué os falta a vosotros?

Por otra parte, ¿cómo ves de estable la versión v1.05?
Porque si crees que es funcional, mando a hacer 5 placas para no andar modificando demasiado con la v1.02 que nos has mandado. No soy consciente del calado de los cambios.

Lo que me digáis. Si hace falta algo, me decís y hago compra para las placas de prueba.

[Popopo]

Actualizadas las modificaciones para el prototipo v1.02 añadiendo otra placa hija fija para convertirla en la placa v1.05.
Como siempre, esta modificación está especialmente recomendada para beta testers.

Aysss pero que bonita es!!!
Me encanta eso de poder cambiar cosas añadiendo o quitando plaquitas, viva la modularidad XD

actualizo el primer mensaje con la nueva versión.

[cacharreo]

Aysss pero que bonita es!!!
Me encanta eso de poder cambiar cosas añadiendo o quitando plaquitas, viva la modularidad XD

La verdad es que esas dos parejas de dos pines en F01 y F08 están dando muchísimo juego.

Me parece bien, hagámoslo.
Creo que voy a necesitar fusibles y no ando seguro que más, ZIF tengo, pantalla OLED tengo...

Consideradlo como una pre-compra para los kits, el material no se va a desperdiciar.

Por otra parte, ¿cómo ves de estable la versión v1.05?
Porque si crees que es funcional, mando a hacer 5 placas para no andar modificando demasiado con la v1.02 que nos has mandado. No soy consciente del calado de los cambios.

Aguantando dos días sin incidencias lo que al ritmo actual es muchísimo y las lecturas desde el Nano son correctas aunque como veis en la foto las pruebas son muy espartanas,



pero mejor vamos a darle un tiempo que los cacharreos con el firmware son los que al final decidirán.

Edito: La placa es estable pero el Nano no se está comportando debido a peculiaridades internas del ATMega328P que están en conflicto con los objetivos del proyecto. Más adelante se explicará con detalle.

[Popopo]

Desde luego, no voy a soldar componentes para dejarlos finalizados... como seguramente salga nueva versión de placa, los soldaré dejando patilla de margen para luego desoldar y poner en la placa "final"

ZIF para betatester que necesiteis tengo, creo que pantalla OLED a quien no tenga para las pruebas, tengo.
Creo que debo comprar:

• Fusibles rearmables

• Esos transistores para desacoplar corriente

• Módulo de alimentación

• El integrado U3 creo que también.... el BOM pone

  LMC7660 (montado sobre zócalo U32)

  pero imagino quiere decir "montado sobre U3"

¿quién necesita? y ¿qué cosa necesita?
Para realizar compra y organizar el mandároslo cuando me llegue... cuando llegue.

[cacharreo]

Desde luego, no voy a soldar componentes para dejarlos finalizados...

Por mi parte estoy adoptando la posición "preservadora" por lo que acabaré con unas cuantas placas montadas de diferentes versiones. Se les coge cariño.

como seguramente salga nueva versión de placa, los soldaré dejando patilla de margen para luego desoldar y poner en la placa "final"

Una placa de JLC admite, con suerte y tacto exquisito, 3 o 4 cambios a partir de ahí las probabilidades de quedarse con el pad o pistas son mucho más altas.

Pero atención a dejar margen en las patillas, inventos similares o incluso dejar flux en la pcb porque en los nodos F-Z todo está muy cerca por un motivo, disminuir la capacitancia. Si esta se dispara por encima de los 100pF olvidaos de que sean viables los tests de memorias a velocidades/frecuencias por encima de los 500kHz.

• El integrado U3 creo que también.... el BOM pone

  LMC7660 (montado sobre zócalo U32)

  pero imagino quiere decir "montado sobre U3"

En todas las BOM aparece dos veces según el orden de montaje, primero el zócalo y después el integrado.

...
1 U3 Zócalo de agujero redondo DIP-8
...
1 U3 LMC7660 (montado sobre zócalo U32)
...

aunque externamente las referencias se leen como U3, el integrado es U31 y el zócalo U32. Esto es algo que se repite en todo el esquema, J1 es J11, J1' es J12... por desgracia el CAD no permite referencias reales como J1' por lo que hay que utilizar estos rodeos pero si lo véis más claro de otra forma, se cambia.

[cacharreo]

De los mismos creadores del test con Timer1 en el que conseguíamos salidas de 8MHz llega ahora este test de velocidad (de escritura),

Código: Seleccionar todo

/// #############################################################################
// VdR-RAM-tester
// Speed test #1
// #############################################################################

void setup()
{

  // set digital port D2 mode to OUTPUT
  // Data Direction Register D (DDRD) controls PD7-PD0 mode
  DDRD = 0b00000100;
  
}

void loop()
{

  // D2 HIGH 
  PORTD |= (1<<PD2);

  // D2 LOW
  PORTD &= ~(1<<PD2);

}

a la vista del código veréis que en la inicialización se configura el puerto digital #2 (D2) para salida (OUTPUT) y en el ciclo principal del programa simplemente se alterna el estado de D2 de encendido a apagado.

Esta operación, que sería igual de rápida activando o desactivando 8 puertos digitales a la vez, ha sido una buena forma de tener una estimación más realista de a qué podemos aspirar. Mientras que utilizando la clásica función digitalWrite() ⁽¹⁾ para fijar el estado de D2 hablaríamos de velocidades máximas entre los 110 y 120kHz (sí, sí, kilohertzs), mediante la manipulación directa de los puertos la velocidad es muy superior, unas 13-18 veces más rápida, pero aún así esto supone un límite en 2MHz como veis en la imagen del osciloscopio,



o, en otras palabras, un periodo de 8 ciclos de reloj de un Nano a 16MHz o 500ns.

Pero escribir 8 puertos digitales simultáneamente está aún lejos de nuestros objetivos, necesitamos trabajar con bastantes más por cada lectura/escritura en la memoria. Si lo intentamos con un nuevo programa:

Código: Seleccionar todo

// #############################################################################
// VdR-RAM-tester
// Speed test #2
// #############################################################################

void setup()
{

  // set digital port D2 mode to OUTPUT
  // Data Direction Register D (DDRD) controls PD7-PD0 mode
  DDRD = 0b00000100;

  // set digital port D8 mode to OUTPUT
  // Data Direction Register B (DDRB) controls PB5-PB0 (D13-D8) mode
  DDRB = 0b000001;

  // set digital port D17 mode to OUTPUT
  // Data Direction Register C (DDRC) controls PC7-PB0 (D21-D14) mode
  DDRC = 0b00001000;
 
}

void loop()
{
  
  // D2 HIGH 
  PORTD |= (1<<PD2);

  // D8 HIGH 
  PORTB |= (1<<PD0);

  // D17 HIGH 
  PORTC |= (1<<PC3);

  // D2 LOW
  PORTD &= ~(1<<PD2);

  // D8 LOW
  PORTB &= ~(1<<PD0);
  
  // D17 LOW
  PORTC &= ~(1<<PC3);
  
}

enciende y apaga "a todo lo que da" 3 puertos digitales diferentes, que a efectos prácticos sería igual de rápido activando o desactivando todos los pines I/O del Nano, pero la velocidad resultante es la mitad de la anterior, 1MHz o, en términos de periodo, 16 ciclos de reloj de un Nano a 16MHz o 1,000ns.



En una situación de prueba real en el que el procesador va a estar leyendo, calculando, almacenando información y refrescando la pantalla es de cajón que va a ser aún más lento. De confirmarse esto implicaría que, como se dijo, los tests se harían a la velocidad que el Nano pueda pero no será posible realizar tests a velocidades tales que sirvan para verificar que una memoria de 200ns funciona bien con accesos de lectura/escritura a 5MHz.

De momento esta es la tesis más realista a menos que se nos escape alguna posibilidad.

Estos tests los he realizado con un Arduino Nano R3 con CH340C. Las impresiones no han sido buenas, después de soldarle los pines y subir el firmware (a 115.2kbps), funcionaba sin problemas pero la segunda vez que se intenta subir el firmware falla estrepitosamente quejándose de un fallo de sincronismo o de comunicación. Desconectando el Nano del puerto USB, reiniciando Arduino IDE y volviendo a conectar el Nano por USB, vuelve a funcionar lo que apunta a un posible fallo por parte del Arduino IDE o de AVRdude pero, aún de forma incómoda y aparatosa, compilar y subir al Nano con CH340C es posible.

⁽¹⁾ La función digitalWrite() realiza demasiadas comprobaciones adicionales como si el pin existe, si está activa la PWM (y la desactiva), calcula el puerto asociado al pin, la máscara para el puerto, comprueba el estado actual y si es necesario lo cambia, etc., etc.