Uso de la pantalla de 7 segmentos en pic18f

Tu problema inmediato parece surgir de la suspensión lisButton a menos que se presione un interruptor en particular. Por lo tanto, no puede "ver" el otro interruptor mientras la subrutina está colgada en un bucle esperando un interruptor diferente.

Hay algunas maneras de abordar este problema. Uno sería escribir una subrutina que busque cualquiera de los conmutadores y devuelva un código que indique qué conmutador vio. A continuación, puede probar ese código y actuar de manera diferente para los diferentes interruptores. Este es el equivalente a patear la lata por el camino: resuelve el problema hoy, pero si necesita hacer algo más que no sea un interruptor, el problema volverá a surgir.

Otra forma es pensar en términos de eventos. El interruptor que se presiona es un evento, el interruptor que se está liberando es un evento. Los eventos se pueden detectar en una interrupción (generalmente una interrupción periódica del temporizador) y los eventos falsos como el rebote del interruptor y el ruido pueden ser rechazados. Los eventos reales verificados se pueden poner en una cola de clases (mínimo un evento, pero podría tener un número mayor en un FIFO) y el programa principal repite en espera de eventos y luego responde a cada evento. Esto le permite fácilmente (y de manera confiable) hacer cosas como crear un evento cuando se mantiene presionado un interruptor durante más de 2 segundos, o el usuario hace un doble clic.

La razón para tener una cola en lugar de solo una ubicación es que le da a su programa principal más tiempo para tratar los eventos que ocurren en una sucesión rápida, como dos pulsaciones de teclas que son casi simultáneas. Si no tienes una cola, puedes perderte uno de ellos.

Estoy de acuerdo con los comentarios de Olin con respecto a la estructura y el estilo de la programación. A diferencia de, digamos, Python, el código de ensamblaje tiene poca estructura inherente, por lo que debe estar atento e imponer una estructura visible y salpicarla con comentarios útiles para no tener un montón de código de espagueti de solo escritura. Usar subrutinas, como lo hiciste, es un comienzo. Cosas como explicar la estructura general del código y todas las asignaciones de E / S en un encabezado de comentario exhaustivo en la parte superior del programa son rigurosas. Hace poco volví a visitar un programa de ensamblaje bastante complejo (matemáticamente y lógicamente) que escribí hace más de 16 años. El chip es obsoleto, por lo que tiene que ser portado y resulta en una arquitectura diferente. Los comentarios son muy útiles en tal situación.

El problema básico es que tu código es un desastre. No está listo para enfrentar lo que sea su error de incremento específico, y ciertamente no está listo para mostrar su código a otros. Sin la disciplina de codificación adecuada, siempre obtendrás resultados inestables. Algunos problemas obvios:

1. Muestras 35 líneas de código, pero ¡solo un solo comentario! Por supuesto, tendrás errores cuando estés tan descuidado. Peor aún, pedir a otros que vean este desastre es irresponsable hasta el punto de ser grosero. Sin comentarios, solo podemos adivinar qué crees que hace parte de este código y cómo pretendes que funcione.

2. En MPASM, los mnemónicos de opcode comienzan en la columna 2 o posterior. Esto los distingue de las etiquetas, que comienzan en la columna 1. ¿Cómo se armó este lío?

3. ¿Qué pasa con ", 0" como en la línea "MOVF num, 0"? Si recuerdo bien, eso especifica si el resultado se carga en W o no. Esto se hace con el parámetro opcional ", w" para que el código sea más claro. Luego, el valor predeterminado es escribir el resultado en el registro de archivos en lugar de W. El uso del valor de bit real en lugar del mnemónico proporcionado para ese propósito hace que el código sea difícil de seguir e invita a cometer errores.

4. ADDWF PCL es una forma primitiva de implementar una tabla de salto. Se puede usar, pero debe asegurarse de que no haya un límite de dirección de 256 bytes dentro de la tabla, lo cual no tiene.

Intentar seguir este código para encontrar un error sería como intentar rescatar al Titanic con una cucharadita. Regrese cuando, al menos, haya aplicado los principios básicos de diseño de software y esté listo para mostrar algo de respeto a aquellos a quienes solicita ayuda gratuita. Si no le importa su código, ¿por qué otra persona debería hacerlo?