Nuova libreria secTimer

lesto:
non puoi intercettare l'overflow della millis SENZA riscriverla?

Aspetta. Millis è una funzione di Arduino che restituisce il valore di una variabile unsigned long che internamente viene incrementata ad ogni overflow del contatore TIMER0, 1 volta ogni 1/1000s. Quando tu invochi millis() altro non fai che chiedere il valore di questo contatore interno.

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.

OK. Forse capisco. Si tratta di integrare il codice inserendo nel core di Arduino la gestione di un contatore di secondi che scorra parallelamente al contatore dei millisecondi.
In questo modo si può fare tutto usando il TIMER0, però devo creare un nuovo file da sostituire a quello del core dell'Arduino. Stasera ci metto mano, ora non ce la faccio tra poco devo uscire.

EDIT:
però non è così semplice come sembra. Intanto si perde la portabilità di secTimer, e poi ogni volta che viene reinstallato/aggiornato il core la modifica si perde. E va visto se tale intervento invasivo da noia poi ad altre componenti del core.

non serve che sia parallelo (a meno che non vuoi usarlo anche come la libreria metro)
basta che intercetti gli interrupt di overflo del timer0, che usa per conteggiare il numero di overflow.
poi quando vuoi sapere i secondi trascorsi effettivamente, usa la formula che ho postato prima, che come vedi si basa su millis() per sapere lo stato dei secondi dall'ultimo overflow, ma poi somma il valore dei secondi causati dagli overflow, superando cosi il limite dell'overflow.

Ho studiato un po' il codice della funzione millis() dell'Arduino..... è un codice un po' particolare.
Vi spiego. Nella mia swRTC quando ho messo l'ISR per gestire l'overflow del timer ed incrementare il contatore dei millisecondi che poi usavo per aggiornare i secondi e tutti gli altri registri temporali in cascata (ore, minuti, giorni ecc...) avevo impostato il timer in modo tale che gli overflow avvenissero esattamente 1 ogni 1000mo di secondo. Ciò è possibile dando un valore iniziale al contatore interno del timer. Siccome il contatore è a 8 bit, quindi i valori possibili sono 256, tramite calcoli (la faccio breve) per 16 MHz si imposta un prescaler di 64 e si usa un valore iniziale che dev'essere di 6. In questo modo si ha 16000000/64/250=1000. Quindi 1000 overflow al secondo o, viceversa, 1 secondo ogni 1000 overflow.

Sull'Arduino la cosa è più complicata. Siccome appunto il timer 0 è usato anche per generare il segnale PWM sui pin 5 e 6, non potevano impostare il calcolo come ho fatto io perché se davano un valore di partenza al contatore alteravano anche il segnale PWM. Allora hanno adottato una soluzione via software per limare quella differenza di 6. Inoltre usano anche un altro calcolo per tener conto dei microsecondi.

Per allineare l'aggiornamento all'effettiva frequenza di overflow del timer devo tener conto del fatto che stiamo andando ad un clock leggermente diverso per cui devo calcolare 976 overflow al secondo invece che 1000.

Dopo aver capito come funzionava il tutto, sono riuscito a creare questi 2 file. Sono versioni che vanno sostituite ai file wiring.c e wiring.h dell'Arduino IDE 002x (per la 1.0 ancora non ho fatto nulla) nella cartella /hardware/arduino/cores/arduino.

Adesso c'è la nuova funzione seconds() che restituisce i secondi dall'avvio dello sketch, restando sempre funzionanti sia millis, delay e delaymicroseconds di Arduino e non consumando nessun interrupt o timer aggiuntivo.
Ah, questa modifica è compatibile anche con la secTimer per via del fatto che usa 2 timer differenti ma lo sketch secTimerLed non è più compilabile perché lì usavo una variabile denominata seconds, che invece ora è una parola riservata del core dell'Arduino.

Ah, altra cosa. C'è anche un nuovo file keywords.txt che dovete sostituire a quello che avete in /lib per avere l'evidenziazione del codice.

Resta da provare se la funzione continua a... funzionare attivando il PWM. Sicuramente sì (altrimenti non andrebbe neanche la millis) ma non ho materialmente avuto il tempo di provarla.

Allegato c'è uno sketch di prova, una specie di BlinkWithoutDelay che usa seconds() al posto di millis().

Resta inteso che funziona SOLO per l'Arduino e per gli Atmega168/328 e 1280/2560 dato che è una modifica al core dell'Arduino e non una libreria a sé stante.

seconds2.zip (6.57 KB)

Bravo! Poche righe di codice ma ben piazzate.

Ciao
QP

Ottimo :smiley:

Ho aggiornato i file wiring modificati, difatti ora vedete nel precedente post uno zip denominato seconds2.
Ed ho modificato anche il post stesso.... nel casino della mia IDE non mi ero accorto di aver selezionato per i test un 328 a 8 MHz per cui avevo per forza il lampeggio ogni 2 secondi usando 1000 overflow al secondo.... :blush:

Inoltre ripensando un po' ai calcoli, ho trovato che la giusta frequenza per aggiornare il contasecondi è di incrementarlo ogni 976 overflow, perché il timer è impostato per una frequenza di 976,5625 Hz. Si perde circa mezzo ms ogni secondo ma, vista l'imprecisione congenita del risonatore ceramico dell'Arduino UNO questo valore è ampiamente nella norma. Se volete maggior precisione potete modificare il codice e mettere lo scalo di 9 ms ogni 16 secondi, dato che 0,5625*16 = 9.

ho dato un'occhiata al wiring.h (arduino 0022) e ho tirato fuori questa soluzione (NON testata):

int secondsBecauseOverflow=0;
static int SECONDS_PER_TIMER0_OVERFLOW = MICROSECONDS_PER_TIMER0_OVERFLOW / 1000000; //defined in wiring.c
void setup(){
}

void loop(){
}

ISR(TIMER1_OVF_vect){
  secondsBecauseOverflow += SECONDS_PER_TIMER0_OVERFLOW;
}

unsigned long getSeconds(){
  return millis()/1000 + secondsBecauseOverflow;
}

ora, il bello che wiring.h possiede già la variabile "secondsBecauseOverflow" che si chiama "timer0_overflow_count", quindi basterebbe che alla wiring.h aggiungessero la riga

unsigned long seconds(){
    return millis()/1000 + (MICROSECONDS_PER_TIMER0_OVERFLOW/1000000) * timer0_overflow_count;
}

ed il gioco sarebbe già fatto di base!

Ma tu intercetti l'overflow del timer 1....

ISR(TIMER1_OVF_vect){
  secondsBecauseOverflow += SECONDS_PER_TIMER0_OVERFLOW;
}

Inoltre ho notato anch'io la variabile timer0_overflow_count, ma non è come dici. Se noti è contenuta nella routine di intercettazione dell'overflow del timer 0 e che viene aggiornato con la stessa frequenza con cui viene aggiornato il contatore dei millisecondi. Quella variabile la riusano per estrarre il numero di microsecondi.

x iscrizione

Ciao Leo, ti segnalo la soluzione di questo altro utente che ha creato una funzione "millis" a 64 bit.
--> blink 1.05 - Programming Questions - Arduino Forum

leo72:
Ma tu intercetti l'overflow del timer 1....

ISR(TIMER1_OVF_vect){

secondsBecauseOverflow += SECONDS_PER_TIMER0_OVERFLOW;
}

sì, ho sbagliato, ci va un 0 non un uno. :grin:

leo72:
Inoltre ho notato anch'io la variabile timer0_overflow_count, ma non è come dici. Se noti è contenuta nella routine di intercettazione dell'overflow del timer 0 e che viene aggiornato con la stessa frequenza con cui viene aggiornato il contatore dei millisecondi. Quella variabile la riusano per estrarre il numero di microsecondi.

sì, vengono aggiornate insieme, però timer0_millis viene incrementato di "MILLIS_INC" (che è l'equivalente della mia SECONDS_PER_TIMER0_OVERFLOW), mentre timer0_overflow_count viene incrementata di 1.
Noto con piacere che però loro anno salvato anche la parte decimale in timer0_fract.. questo è un punto a cui non avevo pensato, e bisogna farlo. ion pratica bisogna diplicare il codice della millis()

lesto:
sì, vengono aggiornate insieme, però timer0_millis viene incrementato di "MILLIS_INC" (che è l'equivalente della mia SECONDS_PER_TIMER0_OVERFLOW), mentre timer0_overflow_count viene incrementata di 1.

guarda se MILLIS_INC vale 1, proprio come l'incremento di timer0_overflow_count :wink:
Se risolvi tutte le define che generano MILLIS_INC, vedrai appunto il risultato che ti ho detto: 1.

Noto con piacere che però loro anno salvato anche la parte decimale in timer0_fract.. questo è un punto a cui non avevo pensato, e bisogna farlo. ion pratica bisogna diplicare il codice della millis()

Lo hanno dovuto fare perché, come ti ho spiegato, non usano un modo diverso di gestire la cosa.
Nella swRTC io difatti impostavo il contatore in modalità "contatore" appunto, con prescaler e valore iniziale del registro calcolati per ottenere esattamente 1000 overflow al secondo, mentre loro impostano il timer per funzionare in modalità "phase correct PWM", ottenendo una frequenza di 976,5625 Hz sui pin esterni e poco più di 1000 overflow al secondo. Di questa differenza loro tengono conto per riallineare i millis all'effettivo scorrere del tempo. Quindi della parte decimale non so che farmene :wink:
Casomai si può pensare di incrementare il contatore separato dei millisecondi ad ogni incremento di millis, così da sapere quando sono passati 1000 ms senza fare i conteggi a 976. Però non facendo il confronto diretto con millis perché questa va in overflow... ora butto giù 2 righe...

@pablos:
gli darò un'occhiata

leo scusami se torno a romperti le scatole XD questa libreria va anche lei in conflitto con la libreria irRemote per via del famoso timer?

spydread:
leo scusami se torno a romperti le scatole XD questa libreria va anche lei in conflitto con la libreria irRemote per via del famoso timer?

Non lo so. Che timer usa la irRemote?
Cmq c'è la versione "ridotta" di cui stiamo parlando ora che è un mod del core Arduino che usa solo il timer 0.

la irRemote usa il timer 2, e comunque la libreria ridotta che usa il timer0 dove la si puo' trovare? e l'ulitizzo e' uguale alla Swrtc?

spydread:
la irRemote usa il timer 2, e comunque la libreria ridotta che usa il timer0 dove la si puo' trovare? e l'ulitizzo e' uguale alla Swrtc?

La secTimer usa il timer 2. La modifica al core Arduino la trovi invece qualche post sopra, devi farti una copia di backup dei file originali. Questa libreria non è la swRTC, è un semplice contasecondi con overflow a 136 anni, non hai le funzioni temporali.

((6==rtc.getHours()) && (50==rtc.getMinutes()) && (00==rtc.getSeconds()))

quindi il comando scritto sopra non c'e'?

k, millis_inc vale normalmente 1 (normalmente, che succede se cambio f_cpu o prescaler? sbagli i calcoli di un overflow ma poi si auto-adatta!)
in oltre il PWM rimane operativo senza problemi.

spydread:
((6==rtc.getHours()) && (50==rtc.getMinutes()) && (00==rtc.getSeconds()))

quindi il comando scritto sopra non c'e'?

Nessuno di queste funzioni. Hai solo seconds() che ti restituisce il numero di secondi dall'avvio dell'Arduino.

lesto:
k, millis_inc vale normalmente 1 (normalmente, che succede se cambio f_cpu o prescaler? sbagli i calcoli di un overflow ma poi si auto-adatta!)
in oltre il PWM rimane operativo senza problemi.

Comunque ho replicato il codice che c'è nella funzione originale, poi l'ho caricato e messo accanto ad una Luigino con la delay. La Luigino ha il quarzo esterno, quindi dovrebbe dare un riferimento preciso. Ebbene, la mia versione col conteggio ogni 976 overflow è allineata al ll'Arduino, mentre quella col codice replicato no. Ergo, lascio la mia versione :wink:

complimenti per il lavoro,
illuminami su questo discorso:
usare il delay e' comodissimo, intendo come scrittura, delay xx e via, pero' questo blocca il tutto ecc ecc.
quindi si usa millis, cosi' come fa il blink without delay, che e' piu' complesso di come si usa la funzione delay, in piu' si deve tenere in considerazxione questo discorso dell'overflow.

Ora quindi cosa sarebbe utile per gli umani ? una delay2.0

che si usi come il delay normale, scrivendo solo:
delay2(1000);
sotto il cofano la delay2 dovrebbe usare il millis e tenere conto dell'overflow.

si puo' fare ?
non sarebbe molto meglio e comodo ?