Contestando tus preguntas una a una:
es eficiente hacer esto?
- Siempre mas eficiente seria tener un Timer el cual pueda tener una interrupcion en el tiempo que desee como sucede en el caso de Timers de 32 bits. Tiene que tener algunas consideraciones, como carga o reset por hardware, y tambien estas sujeto a la frecuencia del cristal y su variacion.
Al no poseer un Timer que pueda interrumpir en esos tiempos, no queda otra que utilizar una base mas pequeña y contar las interrupciones.
existira alguna otra alternativa para manejar eventos sin utilizar los dichosos delays()?
- Varias cosas necesitan delays.. Especialmente las secuenciales, por ejemplo manejo el manejo del LCD, a no ser que tus señales sean lentas a comparacion del micro. Pero muchas veces se puede prescindir de estos con el costo agregado de mas programa. Por ejemplo si deseo enviar "HOLA" por UART, enves de enviar todo y quedarme esperando (tecnicamente no es un delay, pero si una espera hasta que termine) podrias hacer un buffer y que se maneje con la interrupcion de TX.
En caso de tener varias cosas con delays, si uno usa un RTOS, mientras una aplicacion pide un "delay" al OS, podria estar haciendo otra cosa...
Tambien es mejor tratar de crear un codigo que no requiera delays.... Por ejemplo si quisiera actualizar el LCD y luego cambiar el texto al segundo, entonces tener una funcion en el main
que se encargue del LCD, adentro muestra lo que debe mostrar y acciona un mecanismo para que pregunte si paso el segundo (observando la variable del Timer) para volver a cambiar el LCD...
Como comente antes, a costa de la complejidad del programa.
Que pasaria por ejemplo si salta otra interrupcion distinta a la del timer0, podria afectarse mi medida de tiempo,?
Depende del microcontrolador que estes usando (marca y modelo)...
En un PIC16 es un poco mas complejo todas las posibilidades que podes tener.... El codigo de la interrupcion seria algo asi:
Si bandera Timer 0 = 1?
-> Rutina de interrupcion Timer0
Si bandera RX UART = 1 ?
-> Rutina de interrupcion RX UART
Las posibilidades son:
- Ocurrio int de Timer0 y mientras esta ejecutandose Timer0 ocurre la de UART, no habria problema, ejecutaria una y luego la otra sin salir de la misma interrupcion
- Ocurrio la de la UART y cuando esta haciendo la rutina ocurre la del Timer0, Cuando termina de la UART, sale de la interrupcion y vuelve a entrar para atender la del Timer0, ese es un poco de error que tendrias.
Si usas el modulo CCP, que te resetea el Timer, no tendrias que preocuparte por esto, y tenes una ventana entre interrupcion e interrupcion para hacer lo que debas hacer.
Si es un PIC18:
Tenes 2 prioridades, podes elegir que el Timer tenga prioridad alta, de esa forma si ocurre el 2do caso como en el PIC16, este se atienda sin falta, y luego siga la de baja prioridad como la de RX UART.. Si usas el modulo CCP, entonces no vas a tener problemas.
Si tenes un dsPIC/PIC32/STM32/etc
Ademas de tener MAS prioridades, tenes Timers que hacen lo que hacia el Timer+CCP en los PIC16/18 , por lo que resume mucho mas los problemas y errores.
