Nuova libreria secTimer

Ho notato che ultimamente molti si lamentano del fatto che la funzione millis() vada in overflow dopo 49,7 giorni, creando non pochi problemi nel calcolo di intervalli temporali maggiori di tale periodo.
Riprendendo il lavoro fatto per la mia libreria swRTC ho deciso di creare una nuova libreria che ho, molto semplicemente, rinominato secTimer. (nome cambiato dal precedente Timer).

Questa libreria altro non fa che attivare un timer interno dell'Arduino (o del micro nel caso si voglia usare su progetti in standalone) per gestire un contatore di secondi. Quindi il tempo minimo che può gestire questa libreria è il SECONDO, non può gestire intervalli inferiori. Ma questo intervallo va più che bene per operazioni che devono essere eseguite molto tempo l'una dall'altra, come ad esempio attivare dispositivi (relé per accensione luci, LED ecc...) oppure per leggere ogni tanto un sensore (temperatura, ecc...).

Qual è il vantaggio di secTimer rispetto all'uso di millis()? Che millis(), come detto, va in overflow dopo 49,7 giorni. secTimer, invece, va in overflow dopo 136 ANNI! Questo significa che il vostro dispositivo cesserà di funzionare ben prima che la libreria riparta da zero! :wink:

La libreria si scompatta nella propria cartella delle librerie. Consiglio l'uso della cartella /libraries all'interno della propria cartella degli sketch (/home/utente/sketchbook per Linux o /Documenti/Arduino per Windows). Una volta installata, basta includerla nel proprio progetto, crearne un'instanza, far partire il contatore e poi leggere i secondi al momento del bisogno. Tutto è ben capibile aprendo lo sketch secTimerLed incluso con la libreria.

Ho scelto di dotare la libreria delle funzioni di avvio e arresto del contatore perché, visto che va ad utilizzare un timer hardware del microcontrollore, potrebbe capitare la necessità di usare temporaneamente quel timer per altri compiti per cui si può arrestare la libreria, prendere il controllo del timer, eseguire i propri compiti e poi riavviare la libreria.

L'impatto sulla dimensione del codice è limitato, circa 350 byte (compilando per Arduino): BlinkWithoutDelay genera sul mio sistema uno sketch di 992 byte mentre secTimerLed genera uno sketch di 1342 byte.

La libreria è alla prima versione. La base (swRTC) è buona per cui ho compilato senza problemi per Attiny84/85, Arduino MEGA e UNO, Atmega1284. Può esserci ancora qualche errore, nel caso segnalateli.

La licenza è, ovviamente, GNU GPL versione 3.0 o successive.

Buon divertimento! :wink:

secTimer-0_2.zip (23.4 KB)

Ottimo lavoro, come sempre, Leo! :grin:

Per gestire eventi "schedulati" era molto interessante anche la libreria Metro (cmq diversa nell'utilizzo e nelle funzionalità dalla tua):
http://arduino.cc/playground/Code/Metro

Sono 2 cose diverse.
La Metro esegue dei compiti ogni tot, la mia è un semplice contatore di secondi, per l'uso che uno ne vuol fare.

C'è già una library chiamata Time
http://www.arduino.cc/playground/Code/time
non è che poi crei confusione?

Comunque ottimo lavoro

bravo comunque quoto anche io di cambiare il nome

Grande Leo, come il solito :slight_smile:

@Leo ma se fra un secondo e l'altro usassi millis o micros per interpolare il tempo dove servisse per poi resettarlo?
si potrebbe ottenere la precisione di millies/micros e l'inoverflowabilità di Timer insieme.

@amario e ilmandorlone:
nome cambiato in secTimer (sec da seconds).
Ho anche corretto il file keywords per l'evidenziatura del codice nell'IDE, che mi ero dimenticato di sistemare.

@brain:
secTimer non altera le normali funzioni millis dell'Arduino o del micro per cui puoi usare entrambe le funzioni in abbinamento.

ottimo :wink:

Contra factum non datur argomentum :wink:

grazie perche' fai sempre cose che mi tornano utili come il tuo swrtc :wink:

reizel:
grazie perche' fai sempre cose che mi tornano utili come il tuo swrtc :wink:

Beh, alla fine sono le cose più ricorrenti di richieste di aiuto. La questione dell'overflow di millis viene fuori con una frequenza molto elevata.

Ottimo, quindi a tutte le domande "cosa succede quando il millis va in overflow" e che abbiamo sempre risposto "NULLA riparte da zero ......" abbiamo detto delle fregnacce? :slight_smile:

ciao

pablos:
Ottimo, quindi a tutte le domande "cosa succede quando il millis va in overflow" e che abbiamo sempre risposto "NULLA riparte da zero ......" abbiamo detto delle fregnacce? :slight_smile:

ciao

no è giusto, riparte da 0, proprio perchè va in overflow

leo, non esiste un modo per fare questa libreria SENZA perdere un timer? per esempio agganciarsi all'overflow della millis?? ho una mezza idea.
Se intercettiamo l'overflow della millis, e per trovare i valori "in mezzo" chiamiamo millis() quando l'utente chiama getSecond, perdi la possibilità di creare allarmi come la libreria Metro, ma guadagni un timer

lesto:
leo, non esiste un modo per fare questa libreria SENZA perdere un timer?

Forse sì, forse no. Considera però che la secTimer è una cosa fatta in poco tempo: avendo usato il core della swRTC ho preparato questa libreria in circa mezz'ora, documentazione compresa :wink:

per esempio agganciarsi all'overflow della millis?? ho una mezza idea.
Se intercettiamo l'overflow della millis, e per trovare i valori "in mezzo" chiamiamo millis() quando l'utente chiama getSecond, perdi la possibilità di creare allarmi come la libreria Metro, ma guadagni un timer

[/quote]
Ma non risolvi il problema della gestione dell'overflow di millis(), che l'utente deve comunque sempre considerare. Perché se lui mette un if con un check su millis e questa riparte da zero prima che l'if sia vero, siamo punto e a capo.

nono, in pratica la libreria farebbe da layer tra utente e millis(), gestendo in automatico gli if di overflow... o meglio se intercettasse l'interrupt, perchè così siamo slegati dal fatto che l'utente debba chiamare la libreria almeno una volta ogni 40 giorni

lesto:
nono, in pratica la libreria farebbe da layer tra utente e millis(), gestendo in automatico gli if di overflow... o meglio se intercettasse l'interrupt, perchè così siamo slegati dal fatto che l'utente debba chiamare la libreria almeno una volta ogni 40 giorni

Ho capito cosa vuoi fare ma non hai capito il mio appunto.
Prendi il classico:

tempo=millis()+10000; //qui millis valeva 500 unità sotto all'overflow (4294966795), quindi tempo va in overflow e contiene 9500
...
if (millis()>tempo) { //qui è 4294966795>9500? quindi è vero anche se in realtà è falso
....
}

In questo caso come gestisci il problema?

non capisco, l'idea non è di fornire all'utente una millis() "allungata" ma la seconds. quindi

tempo=millis()+10000

nella libreria sarebbe

tempo=millis()/1000+SecondiPerOverflow*NumeroOverflow

Ora sono io che non capisco. Se non modifichi il codice della millis(), la millis() soffre sempre dell'overflow, che devi comunque tamponare in qualche modo. O sacrifichi un altro timer, come ho fatto io, e metti una funzione che soffrirà di questo problema quando nessuno potrà prendersela con l'autore della secTimer (perché passato a miglior vita) oppure riscrivi la millis().

Ad esser sinceri, avevo pensato anche a questa opzione... ]:smiley:

non puoi intercettare l'overflow della millis SENZA riscriverla?

anche se la millis soffre gli overflow, se tu conti il numero di overflow.... sai quanti millisecondi sono passati, anche se non puoi conteggiarli usando una long, hai spezzato l'informazione in più variabili.

edit: mi hai fatto venire in mente un'idea fantastica per una libreria, da far includere tra quelle standard.
In pratica una libreria che si occupa di intercettare TUTTE le fonti di interrupt, e di gestire un array di puntatori a funzione (passati dall'utente) per ogni interrupt: quindi esattamente come l'attachInterrupt, solo che permette di attaccare più funzioni in coda.

però rimango nel dubbio per quanto riguarda come gestire prescaler e roba del genere, dovrei usare il minimo sempre, e poi simulare le richieste dell'utente