swRTC

Capito

Quindi i pin che utilizzano i timer per altri scopi non possono essere usati per i pwm è corretto?

non capisco la domanda. i timer sono interni, non e' che usano dei pin. puoi usare la swrtc senza che questa infici nessun pin.
i pin pwm saranno legati si' ai timer, e quindi se per qualche motivo viene alterata la normale funzione dei timer ci possono essere conseguenze su pwm

la domanda sarebbe ...sto usando:

timer 2 sulla swrtc abbinato al pin 9
timer 3 per la trasmissione IR abbinato al pin 5

su questi 2 pin posso usare il PWM, quindi variare il duty cycle senza compromettere il normale funzionamento delle librerie?
Ma forse questo faccio prima a provarlo, piuttosto un problema che mi da preoccupazioni del timer è il suo overflow, ho un massimo di 800 timer programmabili nell'arco di un anno, 400 ON e 400 OFF distribuiti su 50 pin, ciascun pin reagisce con altre programmazioni impulsive da 1 a 250 secondi ciascuno, se questi timer mi cadono nel 41 esimo giorno succede un casino a tutti gli apparati collegati ai relays.

Pensavo di creare un overflow di 4 anni usando 2 long (41ggx41gg = 1681gg/365 circa 4 anni) ma non mi viene in mente nulla per registrare i valori così lunghi e leggerli.
Non so, la butto lì, ma in qualche modo devo evitarlo :slight_smile:

ciao

La swRTC imposta il timer 2 in modalità di funzionamento normale: con questa modalità viene disattivata la generazione del segnale PWM perché non c'è cambio di stato dei pin OC2A e/o OC2B.

Tornando ai tuoi timer... da dove li hai tirati fuori 800 timer scusa??
Comunque nessuno ti impedisce di usare un tipo "unsigned long long", se vuoi. E' un tipo di dati a 64 bit, che va in overflow dopo 500 e passa anni! Paghi però il fatto che per gestire dati a 64 bit aumenti considerevolmente il quantitativo di Flash occupata dal tuo programma.
In alternativa devi cambiare modo di gestire il controllo dello scorrere del tempo. In questo modo puoi continuare ad usare millis() e variabili a 32 bit e non avere più problemi di overflow:
http://www.leonardomiliani.com/?p=576

io credo che sbagli approccio sul concetto dei pin. se ad esempio colleghi il pin 6 ad un led e gli vari la luminosita', non e' che alteri il delay di arduino (il pin 6 fa capo al timer 0, cosi' come il delay)

quindi dire "timer 2 sulla swrtc abbinato al pin 9" e' fuorviante

per il discorso dell'overflow qui sul forum c'e' uno scienziato, un certo leo, non so se lo conosci, lui ha anche un suo sito sul quale viene spiegato come evitare il problema con una semplice operazione :slight_smile:

il Maestro mi ha anticipato :slight_smile:

Testato:
io credo che sbagli approccio sul concetto dei pin. se ad esempio colleghi il pin 6 ad un led e gli vari la luminosita', non e' che alteri il delay di arduino (il pin 6 fa capo al timer 0, cosi' come il delay)

Il motivo è presto detto. Il core di Arduino imposta i timer per funzionare in una determinata maniera all'avvio dello sketch.
Il timer 0, nello specifico, viene regolato in modalità Fast PWM. Grazie alla modalità Fast PWM può anche generare appunto un segnale PWM sui pin collegati. Viene inoltre impostato per generare una frequenza di 976 Hz. Questo valore non è casuale: è quello più prossimo a 1000 Hz che possiamo ottenere senza andare ad alterare manualmente il funzionamento del timer, sfruttandolo cioè per la sua interezza: il contatore del timer 0 parte da 0 ed arriva a 255, per poi ripartire da 0 ecc...
Per variare il duty cicle si sfruttano i registri OCR0A/B. Basta mettere in essi il valore del duty cicle (da 0 a 255) che, senza alterare né la frequenza del segnale né altro del timer si ottiene sul corrispondente pin il segnale PWM voluto.

Oltre a questo, si aggancia anche un interrupt all'overflow del contatore. In questo modo, tramite dei piccoli accorgimenti software che illustrai tempo fa, si va ad ottenere un incremento del contatore interno millis pari a 1000 volte al secondo.

Testato:
il Maestro mi ha anticipato :slight_smile:

ma va'.... :smiley:

@Leo

Nel tuo sito metti questo esempio

if (millis() - tempo_precedente > intervallo) {
    tempo_precedente = millis();
    ....
}

dicendo :

Ammettiamo che tempo_precedente valga 4.294.967.000 e che intervallo valga 1000. Ad un certo punto millis() va in overflow e riparte da zero.

il confronto diventa 0 - 4294967000 > 1000
Si tenderebbe a pensare che il confronto diventi: -4294967000 > 1000

ma usando interi di tipo unsigned la sottrazione in realtà restituisce come valore 296.

ma tu qui
if (millis() - tempo_precedente > intervallo) {

nel millis() non usi l'unsigned è sott'inteso da qualche parte?

comunque io ho sempre usato questa

unsigned long Millis_corrente = millis();   
    if(Millis_corrente - Millis_Precedente > intervallo) 
    {   
      Millis_Precedente = Millis_corrente;
      ...
      ...  
    }

che direi sia la stessa, ma ovviamente non ho mai taroccato i valori per vedere che succede, quindi così anche trovandomi vicino al punto 0 non mi salta l'opearzione? parola di lupetto :slight_smile: :slight_smile: o devo provare :smiley:

ciao

Leo mi sorge un dubbio, ma se questo semplice trucco che pablos sta gia' usando e che tu hai descritto sul blog, cioe' millis() - tempo_precedente > intervallo elimina il problema overflow di millis, a che serve la tua secTimer ?

pablos:
nel millis() non usi l'unsigned è sott'inteso da qualche parte?

Non ho capito questa domanda. Millis() è una funzione predefinita di Arduino che restituisce un unsigned long.
Il suo valore è quindi un 32 bit senza segno.

comunque io ho sempre usato questa

unsigned long Millis_corrente = millis();   

if(Millis_corrente - Millis_Precedente > intervallo)
   {  
     Millis_Precedente = Millis_corrente;
     ...
     ...  
   }




che direi sia la stessa, ma ovviamente non ho mai taroccato i valori per vedere che succede, quindi così anche trovandomi vicino al punto 0 non mi salta l'opearzione? parola di lupetto :) :) o devo provare :D

ciao

E' lo stesso ma fai uso di una variabile tampone inutile, sprecando quindi 4 byte di SRAM per nulla :wink:
Se ottimizzi il controllo così:

if(millis() - Millis_Precedente > intervallo) 
    {   
      Millis_Precedente = millis();
      ...
      ...  
    }

ottieni l'identica cosa.

EDIT:
pablos, potresti rispondermi sul thread del leOS?

Testato:
Leo mi sorge un dubbio, ma se questo semplice trucco che pablos sta gia' usando e che tu hai descritto sul blog, cioe' millis() - tempo_precedente > intervallo elimina il problema overflow di millis, a che serve la tua secTimer ?

Avevo scritto la secTimer diversi mesi prima di pubblicare una soluzione al problema di millis.
A parte questo, la secTimer è un contasecondi non un contamillisecondi. Per cui puoi usarla per misurare intervalli in secondi in tutti i casi in cui serve gestire questa unità di misura.

Millis() è una funzione predefinita di Arduino che restituisce un unsigned long.

va bene se è così allora tolgo la variabile di appoggio unsigned .... grazie ciao

EDIT: ho risposto al topic LEOS2

pablos:

Millis() è una funzione predefinita di Arduino che restituisce un unsigned long.

va bene se è così allora tolgo la variabile di appoggio unsigned .... grazie ciao

EDIT: ho risposto al topic LEOS2

OK per entrambe.

Scusa Leo, ma vista la grandezza della notizia, hai aperto un topic tipo "il problema millis non esiste ?"

Testato:
Scusa Leo, ma vista la grandezza della notizia, hai aperto un topic tipo "il problema millis non esiste ?"

Prima l'overflow fa schiantare il micro, poi, no quando arriva a termine riparte da 0, poi si riparte da 0 senza schiantare niente, ma i risultati ottenuti saranno falsi, ora mi dici che il problema millis non è mai esistito ahahahahhaha sta storia è peggio dei maya.

anche qui il tutorial mostra la stessa formula l'abbiamo sempre avuta sotto il naso :slight_smile: http://arduino.cc/en/Tutorial/BlinkWithoutDelay

EDIT: Testato .... ti posso dare una testata? :smiley:

Che il contatore vada in overflow e che riparta da zero è indubbio.
Dopo questo, entra in gioco il "come" viene gestito il controllo. E' tutto lì. Se il controllo viene fatto in un certo modo, il problema non affligge il codice.

Di come fosse fatto nel BlinkWithoutDelay sinceramente non mi ero mai preoccupato :stuck_out_tongue_closed_eyes:

pablos accomodati pure, ma ritengo non sia giusto riceverla.
credo siamo sulla stessa barca, anche io come te, ho avuto il terrore dell'overflow del millis, ora scopro che il problema non c'e', basta usare bene la formula.
Ti assicuro che in questi termini non si era mai espresso nessuno, infiniti commenti ci sono sul forum sul terrore millis, e lo stesso Leo ci ha scritto fiumi prima di arrivare alla soluzione definitiva.
Sottolineare che il problema non esiste credo sia cosa buona e giusta per il mondo intero :slight_smile: e Leo deve ricevere un premio nobel :slight_smile:

Testato:
pablos accomodati pure, ma ritengo non sia giusto riceverla.
credo siamo sulla stessa barca, anche io come te, ho avuto il terrore dell'overflow del millis, ora scopro che il problema non c'e', basta usare bene la formula.
Ti assicuro che in questi termini non si era mai espresso nessuno, infiniti commenti ci sono sul forum sul terrore millis, e lo stesso Leo ci ha scritto fiumi prima di arrivare alla soluzione definitiva.
Sottolineare che il problema non esiste credo sia cosa buona e giusta per il mondo intero :slight_smile: e Leo deve ricevere un premio nobel :slight_smile:

:slight_smile:

accomodati pure, ma ritengo non sia giusto riceverla.

Ueee guarda che scherzavo :smiley: