Va de Retro DRAM tester [v2.00]

[geloalex]

Puede suministrar un voltaje de salida de 5v – 28v DC.
Voltaje de entrada es de 2v – 24v DC. Hasta 2A DC. aun que necesitaría disipación a máxima carga.

[cacharreo]

si ves que es estrictamente necesario lo hacemos.

Estrictamente necesario no, como sabéis estas modificaciones estaban ahí en el aire desde el principio solo que siempre damos prioridad a minimizar la BOM. En este caso era algo que difícilmente va a ocurrir una vez la placa esté montada correctamente pero como Murphy dice que "cualquier cosa que pueda ir mal, irá mal" después de la experiencia de Francisco el criterio de coste/BOM pasa a un segundo plano y primamos la protección porque no es descartable que en el futuro con los kits definitivos pudiera repetirse.

Aún así como había que probarlo lo tengo hecho, obviamente con el diodo menos tieso que la imagen anterior para hacer la curva para ir limpiamente de uno a otro pin (el corte de la pista de alimentación no se ve porque está hecho junto al pin del Nano)



y funciona como debe pero, como era de esperar, este rectificador Schottky causa una caída de tensión de unos 200-320mV sobre la tensión suministrada por el Arduino y eso afecta a los valores leídos desde el teclado. La calibración se hace en 5 segundos pero además se ha añadido una directiva de compilación condicional para compilar y publicar cuando haga falta firmware para una versión (1.02c sin diodo a la que venimos llamando 1.02 a secas) y la otra (1.02d con diodo).

Han hecho falta dos limpiezas con alcohol, otra con aire comprimido y 4 fotos hasta obtener una en la que no se vieran restos (pelusilla) del trapo que pongo sobre la placa para darle con el cepillo para quitar los restos de flux/resina.

tal vez solo poner un mensaje al inicio de la guía de no conectar nada a corriente

¡Hecho!

El HW668 que prestación tiene? Pregunto porque tengo varios step Up y step down por casa y así me ahorro comprar ese

Sirve para generar los +12V desde los +5V. También tengo varios boost/step up por aquí, lo difícil es que sean tan compactos y que coincidan los pads para soldarlo a la placa 1.02 pero respetando los puntos de conexión se podría quedar fuera de la placa conectado con cables. Por la corriente no habrá problema, el consumo de las 4116 no va a requerir los supuestos 2A del HW-668, con los módulos de 500mA iría bien de sobra. Otro posible problema de otro boost/step up es que el ruido de conmutación sea excesivo.

[Popopo]

Efectivamente, el incidente fue por hacerlo sin leerlo todo bien. Me está pasando últimamente con bastantes cosas, imagino que se me está yendo la cabeza y no es broma. No veo necesario hacer modificaciones, tal vez solo poner un mensaje al inicio de la guía de no conectar nada a corriente sin haber seguido todos los pasos detenidamente.

Como es en formato Kit, esto se puede repetir muchas veces. Es una pxxxxa, hay que tener en cuenta todos los factores hasta cierto grado, esta modificación ¿qué cuesta? es cambiar un tipo de diodo por otro de muy similar precio. Por tanto a mi me parece muy buena idea. No es que te pase a tí porque una mañana estés más confunso, es que nos puede pasar a todos al despertar o venir un problema por otra parte que se hubiera podido solucionar con la modificación. El error de montaje solo ha traído a la palestra una mejora del diseño. ¿Coste? el cambio de un tipo de diodo por otro tipo... mas o menos se mantiene.

[Popopo]

Estrictamente necesario no, como sabéis estas modificaciones estaban ahí en el aire desde el principio solo que siempre damos prioridad a minimizar la BOM. En este caso era algo que difícilmente va a ocurrir una vez la placa esté montada correctamente pero como Murphy dice que "cualquier cosa que pueda ir mal, irá mal" después de la experiencia de Francisco el criterio de coste/BOM pasa a un segundo plano y primamos la protección porque no es descartable que en el futuro con los kits definitivos pudiera repetirse.

Coincido al 100%, no es un gran problema, más cuando se sustituye un diodo por otro tipo, con lo que el coste mas o menos se mantiene. ¿es una mejora? si, ¿contiene el coste? si ¿entonces por qué no hacerlo? ya lo has hecho, yo aplicaré esta modificación que gracias a ti protege mejor.

Por otro lado, entiendo el problema de modificar el tema del firmware por los pulsadores... no mola. Tengo que buscar alguna solución a ello, debería estar desacoplado un asunto del otro. A ver si me viene la inspiración
Hoy espero terminar el montaje y meterme a hacer las pruebas previas y demás, ya luego programar un poco

[issalig]

Sería posible soportar los valores en la lectura de los botones para el antiguo y el nuevo?

Si no se superponen los valores de viejo y nuevo, se podría tener un OR o contemplar más opciones en la secuencia de ifs.

Pero no se si esto es liar mucho.

[cacharreo]

Coincido al 100%, no es un gran problema, más cuando se sustituye un diodo por otro tipo, con lo que el coste mas o menos se mantiene. ¿es una mejora? si, ¿contiene el coste? si ¿entonces por qué no hacerlo? ya lo has hecho, yo aplicaré esta modificación que gracias a ti protege mejor.

El nuevo diodo es más económico que el otro, unos 0.0018€, añadiendo el fusible de 250mA (0.1459€) el coste total de la modificación para la placa 1.05b es de 0.1441€, comprobado que es útil y necesario en mi opinión lo veo asumible.

Por otro lado, entiendo el problema de modificar el tema del firmware por los pulsadores... no mola. Tengo que buscar alguna solución a ello, debería estar desacoplado un asunto del otro.

Si recuerdas de las simulaciones, al pulsar cada botón se van a leer del DAC unos resultados proporcionales a la tensión de alimentación. Haciendo la modificación del diodo las proporciones son las mismas pero la tensión de alimentación baja un poco por lo que la lectura desde el teclado varía ligeramente.

Por dar unos ejemplos, una solución podría ser añadir un potenciómetro miniatura a la alimentación del DAC y así se puede calibrar a una tensión más baja, digamos 4V, que va a funcionar exactamente igual sea cual sea la tensión de alimentación y eso dejaría constantes los valores en el firmware. La solución complementaria sería escribir un script con un mini firmware específico para la calibración del teclado, se pide al usuario que pulse tal o cual botón, se hacen promedios y se modifica el firmware del tester antes de subirlo al Nano a los valores que ese tester en concreto necesita. Como veis estamos siempre en la misma disyuntiva, modificar el hardware -añadiendo un coste y el esfuerzo para el cambio de diseño de la placa- o modificar el software añadiendo un esfuerzo/incomodidad a la hora de escribir el firmware.

[Popopo]

Sería posible soportar los valores en la lectura de los botones para el antiguo y el nuevo?
Si no se superponen los valores de viejo y nuevo, se podría tener un OR o contemplar más opciones en la secuencia de ifs.
Pero no se si esto es liar mucho.

No es liar nada, se puede, de hecho se puede hacer por rangos de valores que casi seguro es como se hace ahora mismo. Se comprueba la tensión en el pin y el valor entre dos rangos se asocia a un botón u otro. Si los valores son muy cercanos pues pueden surgir algunos problemas para discernir. Pero es salvable, por otro lado, generar un firm para uno u otro es tan sencillo como crear los dos, comentar las líneas que referencia a uno y compilar. Listo.

Me siento muy culpable por no haber hecho nada hasta ahora en la parte software, no debí haber dejado todo el peso sobre @cacharreo, ya bastante hace con esa tremenda labor que lleva a cabo por la parte hardware, que es impresionante. No tengo el tiempo material para ponerme a ello, perdonadme.

[cacharreo]

¿Sería posible soportar los valores en la lectura de los botones para el antiguo y el nuevo?
Si no se superponen los valores de viejo y nuevo, se podría tener un OR o contemplar más opciones en la secuencia de ifs.
Pero no se si esto es liar mucho.

Teóricamente es posible, solo cambiaría que la lista de valores constantes/prefijados en lugar de tener cuatro elementos tendría 8. Las comprobaciones no se hacen usando "if" sino con un ciclo que se interrumpe tan pronto encuentra el valor más cercano, por lo que es más fácil añadir nuevos valores pero el problema es que entonces las distancias entre valores se reducen y, al menos en teoría, pueden aparecer ambigüedades en la lectura, más ambigua cuanto más a la derecha esté el botón.

Por otro lado aparece un problema (teórico), ¿y si alguien decide sustituir componentes? Por ejemplo, un diodo de una referencia diferente podría causar una caída de tensión bastante más alta de hasta 0.7V, ¿añadiríamos también esos nuevos 4 valores? Así podríamos seguir hasta el infinitivo y hacer definitivamente inviable el escaneo de teclado por el método actual y en tal caso debería implementarse un procedimiento más complejo como, por ejemplo, un "polling" continuo del valor durante cierto periodo de tiempo para después estadísticamente determinar qué botón se pulsó. Una solucón ni tan elegante, ni tan sencilla de leer, ni tan ágil como el actual.

No es liar nada, se puede, de hecho se puede hacer por rangos de valores que casi seguro es como se hace ahora mismo. Se comprueba la tensión en el pin y el valor entre dos rangos se asocia a un botón u otro. Si los valores son muy cercanos pues pueden surgir algunos problemas para discernir. Pero es salvable, por otro lado, generar un firm para uno u otro es tan sencillo como crear los dos, comentar las líneas que referencia a uno y compilar. Listo.

El problema como dices es que se aumentan las posibilidades de colisión, es decir, se disminuye la capacidad para discernir entre uno y otro botón.

Respecto al firmware, como decía antes, se ha habilitado una directiva de compilación condicional que crea uno u otro firmware al compilar con solo cambiarla. No hace falta comentar nada. Como siempre, al arrancar el tester se leerá en la presentación del tester indicará la versión de placa en la que funcionará el firmware.

Me siento muy culpable por no haber hecho nada hasta ahora en la parte software,

No tienes por qué, en serio. El software es la parte más compleja pero por suerte se puede decir que "está hecho" y además está perfectamente determinado cuando podrá liberarse, de hecho ya existe el repositorio vacío para alojarlo que está a la espera de:
1) hacer las pruebas con las memorias (el beta-testing en sí),
2) en base a los resultados completar la programación de los tests que faltan (alternos, aleatorios y para los modelos de chips 1 y 2) (ahora solo tenemos los de 0s y los de 1s para el modelo de chip 0),
3) optimizar la asignación entre los pines físicos y los registros del Nano, lo que dará lugar a la placa 1.06 y un nuevo software menos pesado y que además volará,
entonces ya puede publicarse para admitir modificaciones, hacerlo antes complicaría los forks no os podéis imaginar cuánto.

[cacharreo]

Efectivamente, el incidente fue por hacerlo sin leerlo todo bien. Me está pasando últimamente con bastantes cosas, imagino que se me está yendo la cabeza y no es broma.

Por favor no le des importancia porque no la merece, es algo que podría pasarnos a cualquiera. El diodo tostado (marcado con el código SMD "B2") como comentamos es el MBR0520 y el componente indicado en tu fotografía es el resonador cerámico de 12MHz en formato SMD 3213 del convertidor USB-serie como puedes comprobar en el esquema:



todo muy fácil de conseguir y económico (en AliExpress aparecerá como cristal, oscilador, oscilador pasivo,...).

https://www.aliexpress.com/item/1005002427755924.html (Color: 12MHz)
https://www.aliexpress.com/item/1005003913077524.html (Color: 12MHz)
https://www.aliexpress.com/item/32841857579.html (Color: 12MHz)

Estos vendedores son todos de fiar, el último (de Hong Kong) es el más formal y aunque tarde algo en hacer los envíos, todo te llega con bolsas perfectamente etiquetadas con cantidad, referencia, etc.

• Esquema de Arduino Nano con CH340G en EasyEDA

[geloalex]

Acabamos de comentar por Telegram que J4 pase a ser macho (pines)y el cable que sale desde J3 los conectores pasen a ser Dupont hembras , dado que en esos cables hay tensión y es fácil que se toquen entre ellos al manipularlos con el Tester alimentado , es un cambio sutil pero creemos que contribuye a aportar algo mas de seguridad...