Popopo escribió: ↑02 Abr 2022, 08:24este finde, trataré de dedicar un hueco al tema de los menús, quiero probar si puedo realizar algo de los menús pero sin pantalla, es decir, con control por terminal serie. Lo cual para unos cuantos a día de hoy, puedes venir bien ese ahorro de 2.7€, algo más para pantallas mayores. Para mi sobretodo... por motivos de visión, poder usar menús grandes. Os adelanto que si no tengo muchos problemas, espero hacer una aplicación de escritorio en Java para lo que es todo el manejo del tester.
Estaba releyendo las últimas páginas y me gustaría hacer una reflexión.
[TL;DR]
De entrada dejemos algo bien claro, en el tester el puerto serie está muerto. Sabemos que el puerto serie del Nano utiliza tres cables, las dos señales TXD y RXD y además "tierra" (GND) y que, tomando precauciones fácilmente asumibles como que no haya nada conectado a J4 ni chips en el zócalo ZIF, podremos actualizar el firmware sin problema pero el uso de estos pines durante el funcionamiento propio del tester es un asunto a tratar aparte.
Como vemos en
el esquema desde las primeras versiones del tester, las señales RXD y TXD que corresponden respectivamente a los pines digitales D0 y D1, están conectadas a los pines 1 y 2 del zócalo ZIF, es decir, que son utilizadas para comunicarse con las memorias. Pero es que no nos queda otra, usamos todos los pines digitales y no nos sobra ni uno.
Sabemos también que todos los pines del Nano estarán en modo INPUT como una capa adicional importante de la protección contra sobretensión/sobrecorriente gracias a la alta impedancia en este modo (~100MΩ) y, en consecuencia, con TXD en modo INPUT no sería posible la comunicación serie o, visto de forma complementaria, un TXD en modo OUTPUT no va tolerar bien señales en contra, dos pines en OUTPUT y OUTPUT en íntimo contacto se van a llevar bastante mal.
Alguien podría plantear el planificar una hipotética interfaz de usuario (UI) a través del puerto serie como una secuencia de periodos interactivos y no interactivos. Por ejemplo, el tester arranca para inmediatamente pasar a un ciclo principal que comienza esperando la entrada del usuario activando el puerto serie y cuando se completa la interacción, se desactiva el puerto serie, se realiza el test sobre el chip y vuelta a empezar. Sobre el papel esto es posible pero debilita muchísimo la protección del pin D1 (TXD) y aumenta casi al infinito la probabilidad de que posibles conflictos por desincronización entre el flujo de trabajo del usuario y la secuencia de operaciones del tester acaben con el sepelio del pin D1 o incluso del Nano que, por su parte, se vería afectado y en su último canto del cisne mostrara un simpático comportamiento anómalo.
Quizás ese mismo "alguien" pudiera argüir una serie de precauciones a tomar por el usuario pero, siendo tan realistas como pragmáticos, no serían ni remotamente tan fácilmente asumibles como las mencionadas y más tarde o más temprano aparecerá el error fatal como la antesala del llanto y el crujir de dientes.
Y ahí no queda todo porque ese modo de funcionamiento, con TXD cambiando de chaqueta de INPUT a OUTPUT a cada poco y ese UI completamente intrincado a lo largo y ancho del código, afectaría profundamente al ciclo principal del firmware requiriendo mucho esfuerzo y añadiendo demasiadas modificaciones para "solo" proporcionar ese UI por puerto serie.
¿Hay otras soluciones? Sí pero yo apostaría por las puramente hardware como por ejemplo añadir, opcionalmente y para ese propósito, el concentrador I2C y dotar así al tester de un canal alternativo para la comunicación serie; un segundo microcontrolador conectado a J1 y J2 que controlara al primero. Los testers sin UI serie no se tendrían esa necesidad.
el SMD cuanto más grande mejor
Deuxe!!!!! 
