Analicemos el problema... Voy a darte las causas y me gustaria que vos llegues a una solucion de codigo.
Como sabes el programa es secuencial , primero ejecuta una instruccion, luego ejecuta otra y asi... Ocurre que las instrucciones de cambiar un bit son muy rapidas, y es por esto que usamos los delays, sino cambiaria demasiado rapido como para que lo veamos.
Esos delays, hacen que el compilador se ponga a ejecutar instrucciones que no tienen ningun fin, saltos sin sentido, instrucciones que no hacen nada como NOP, etc, todo para que pase el tiempo que le dimos. El problema de esto, es que mientras esta en ese delay no podemos hacer nada, es como si dejara de responder.
Otro problema... supongamos que tenes la lectura del boton y pasa por 4 delays de 1segundo cada uno, si presionas el boton en el primer delay, hasta que llegue a la lectura del boton deberias tener que tenerlo presionado esos 3 o 4 segundos hasta que llegue a esa instruccion.
Y ese es tu problema.
¿Como soluciono esto?
Podriamos acortar la cantidad de la demora, para que el boton se lea mas rapidamente. Esto trae aparejado otro problema. Y es que va a ir mas rapido la secuencia, pero por ejemplo suplirlo para que no cambie de secuencia luego de que pase varias veces.
Podemos usar una interrupcion de un boton, para que sea atendido, ya que al ocurrir una interrupcion este dejaria esperando al delay, iria a a la interrupcion y luego volveria al delay.
Para evitar tantos delays en el "while" de la secuencia, podrias utilizar un array, y guardar los datos ahi, para que funcionen como una tabla.
Podes usar un Timer que te de esos "0.5 segundos", y asi evitar que el micro este haciendo "nada", y te olvidas de los delays, Ahora al ejecutarse tan rapido vas a tener que proteger tu boton, para que no se detecte varias veces.
Esas son algunas de posibles soluciones, para evitar problemas creo que lo mas simple seria usar arrays, y buscarle la vuelta a los delays.
Presenta tu eleccion de solucion a estos problemas, es decir intenta implementar alguna solucion y luego vemos que hay de malo.
------------------------------------------------
PD:
Veo que usas el #BYTE, CCS cambia la direccion (TRISx) si es que usas output(PIN_B0) o input() por ejemplo.
Para evitar esto, CCS posee una directiva que se llama #USE FAST_IO(B) , donde la B es por el puerto B, de esa forma luego haces set:_tris_b(0b11111111) Y pones como entrada y/o salida a los pines que vos quieras, lo bueno es que al usar ese FAST_IO no te va a cambiar la direccion de los otros pines. Ejemplo:
Suponete que tenes RB0 entrada, y RB7:RB1 como salida, ahora si queres sacar un dato por el PORTB, usas output_b(), entonces haces:
#USE FAST_IO(B)
void main(void)
{
set_tris_b(0b11111110);
while(1)
{
output_b(0b01010101);
delay_ms(500);
output_b(0b10101010);
delay_ms(500);
}
}
A pesar que yo ponga un 1 o un 0 sobre RB0, este se va a mantener como entrada, y por lo tanto no va a tener efecto sobre este. Todo esto gracias al #USE FAST_IO(B). Y otra cosa, no tengo que usar los BYTE para definir los registros, que es lo que intenta evitar CCS. Y si quiero leer un pin hago input(PIN_B0) y eso me devuelve 0 o 1.
PD2:
No se si te diste cuenta, pero los "delays" mientras menos se usen o eliminarlos por completo, es lo mejor, ya que estos hacen que el micro este ocupado haciendo nada. Y no permiten que responda a las entradas.
