Timer e timers: come trovare più timers in un'applicazione complessa mentre un microcontrollore standard di solito ha solo due o tre timers? Sono stato ingegnere di marketing per la Philips e tenevo anche corsi di formazione per i nostri clienti. Mi ricordo ancora una domanda da uno di loro (dalla sua domanda ho capito che le nostre università danno agli studenti un'opinione sbagliata).
La domanda e' come trovare più timers in un'applicazione complessa mentre un microcontrollore standard di solito ha solo due o tre timers? La risposta e' semplice: creare timers supplementari nel software. Si, timers software! Questa e' la vista interna di un microcontrollore dalla Cypress. I motivi per cui un microcontrollore non può avere troppi timers sono: soldi e silicio. A proposito avete mai visto più di un timer di tipo "real time" in un computer? La risposta e' no, perché c'è un solo timer "real time" con la batteria. Tutti gli altri timers sono timers software implementati nel software. Dopo tutto, i timers software dovrebbero essere implementati nel sistema.
Ma come implementare timers software con un solo timer hardware?
Per iniziare dobbiamo utilizzare "l'hardware timer" come base tempi, che offre un tempo base per ogni periodo. Per esempio, l'"hardware timer" può generare "timer interrupt" ogni 16ms. Poi possiamo generare timers software per 32ms, 64ms, 128ms, e 256ms. Il timer software di un secondo può essere realizzato con 4 interupts di 256ms. Se si desidera, e' possibile aggiustare l'accuratezza del timer. Il metodo è sufficiente per un sistema embedded, dal momento che la maggior parte delle applicazioni non richiedono molta accuratezza del timer. Se volete un timer "real-time" utilizzate circuiti integrati dedicati, invece di timers software, perché il "real timer" esterno può offrire maggiore precisione con compensazione di temperatura a causa della deviazione di frequenza del cristallo. Non utilizzate il "watch dog timer" come "timer base", di solito è riservato per salvare l'intero sistema in caso di guasto.
Per avere un'idea, guardate una frazione del sorgente C. Si possono creare molti timers, però con la condizione di avere abbastanza RAM. Nella progettazione dei timers software ci sono: "base timer", "timer ISR" e "application software timers". Lo 0 di un "application software timer" sta per non attivo ed 1 sta per timeout, qualunque altro numero sta per timer software in esecuzione. I timers sono i contatori alla rovescia.
#define OSTI_TIMER_EXPIRED 1 /* The timer has been expired */
#define OSTI_TIMER_INACTIVE 0 /* The timer is inactive and will not be updated */
#pragma registerbank(1)
void USING(1,OSTI_Update_expiring_timer(Byte IDATA *timer_ptr))
{
if ( *timer_ptr > OSTI_TIMER_EXPIRED)
{
(*timer_ptr)--;
}
}
/*
This function is called by assembly code every 128ms.
The assembly code is machine dependent, not included here.
*/
void USING(1, OSTI_128ms(void))
{
UIBG_128_ms_timer();
}
uibg.c
/*
This function will update all software timers for application purpose.
Here, two timers for menu update, refresh whole display is triggered.
*/
void USING(1,UIBG_128_ms_timer(void))
{
OSTI_Update_expiring_timer(&uimn_menu_timer);
OSTI_Update_expiring_timer(&refresh_display_timer);
}
Se si utilizza un RTOS, è possibile gestire i "timers", un RTOS di solito ha già tale funzione.
I timers sono sempre troppo pochi. Piu ne hai e piu ne usi. Certo la soluzione sotto interrupt aiuta ma ovviamente limita l’uso dei timers al flusso di programma, invece sono spesso le periferiche ad “assorbirci” timer (gestite in real time)
Io ad esempio uso una soluzione che chiamo heartbeat, gestendo sotto l’isr vari stati ed anche varie temporizzazioni, ovviamente solo quando ho finito i timers a disposizione, altrimenti perche complicarsi la vita?