issalig escribió: ↑28 Abr 2022, 10:43¿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.
Popopo escribió: ↑28 Abr 2022, 10:56No 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.
Popopo escribió: ↑28 Abr 2022, 10:56Me 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.