domanda sul funzionamento dei timer counter atmel

[Rabeluk]

salve a tutti questa è la mia prima domanda su questo forum e spero davvero che possiate aiutarmi a chiarirmi le idee....
ma bando alle ciance, ho 2 quesiti che mi frullano sulla testa ma sarà il caldo o sarà lo stress non riesco a venirne a capo....

1) usando l'interrupt relativo all'overflow di un timer counter , se vado ad effettuare modifiche sul registro relativo allo specifico timer counter questa modifica viene rilevata come se fosse un interrupt? in pratica se modifico il valore(ad esempio) di TCNT0 (prendo in considerazione un qualsiasi micro atmel) in fase di conteggio questa modifica mi farà scattare l'interrupt legato all'overflow di TCNT0?
ora provo a spiegare il perché di questo quesito
da una mezza simulazione fatta (sulla progettazione di una sveglia digitale) è come se modificando il timer counter in fase di conteggio mi manda in overflow il registro e mi genera l'interrupt... io sinceramente non so se succede realmente una cosa cosi... dico questo perché in pratica io ogni minuto faccio una piccola correzione sul timer counter (ovviamente è in fase di conteggio)facendolo partire non da 0 ma da 4...... (un conteggio completo da 0 a 255 del timer counter equivale a 1/16 di secondo) .... indovinate quanto tempo guadagno* dopo 16 ore (giusto giusto un secondo) è un caso o la mia ipotesi è giusta?

2) sempre restando sui timer counter.... lavorando in modalità CTC e sfruttando in questo caso l'interrupt "Compare Handler" il conteggio con un solo registro da 8 bit mi garantirà 256 conteggi o 255?
anche questa domanda deriva dal fatto che ho notato una netta differenza nello sfruttare l'interrupt "Overflow Handler" invece che quello con il confronto...in pratica è come se con l'interrupt "Compare Handler" mi risulta un conteggio in meno....
infatti se carico il registro di confronto(ad esempio OCR0 per TCNT0) con il valore massimo ,cioè 255 il conteggio mi risulta + veloce....

spero di essermi spiegato bene e che possiate aiutarmi
PS per ora sto programmando solo in assembly e non conosco il C

[deluca]

potresti spiegare meglio il progetto? si tratta di un orologio che conta hh:mm: e secondi?

si tratta di un modo di operare alquanto strano,
perchè questi aggiustamenti? che tipo di oscillatore stai usando?

[Rabeluk]

salve, sto usando un atmega8535 e per scandire il tempo uso il TCNT2 in modalità asincrona con cristallo di 32.768 Khz.
la sveglia oltre a ore,secondi e minuti mostra anche la data (cioè giorno/mese/anno) il problema è che perdo tempo negli aggiornamenti del display e per compensare al tempo perso provo a guadagnare ogni minuto qualcosa...

[deluca]

ciao rabeluk,
chiaramente il cristallo è già compensato ecc ecc tutte le indicazioni del caso......

dove effettui l'aggionamento del display (7seg o LCD che sia?) spero tu non lo faccia all'interno dell' handler interrupt.
lì devi perdere meno tempo possibile ed effettuare le istruzioni necessarie per calcolare l'incremento temporale.

Nel tempo-morto, ovvero nel rimanente, (main loop) avresti tutto il tempo per effettuare gli aggiornamenti visivi.

[Rabeluk]

ciao rabeluk,


Nel tempo-morto, ovvero nel rimanente, (main loop) avresti tutto il tempo per effettuare gli aggiornamenti visivi.

è la modifica che ho appena apportato , non so perché mi era presa l'idea di mettere le routine del display nella routine dell'interrupt.. ora credo di aver ottenuto maggiore accuratezza..

chiaramente il cristallo è già compensato ecc ecc tutte le indicazioni del caso.....

non ho capito

[js-bascom]

non ho capito

I cristalli devono essere calibrati per essere il piu' vicino possibile alla frequenza desiderata, di solito si usano piccoli condenzatori variabili per lo scopo.

Per lavori piu' serii usa un oscillatore DS32KHz che e' calibrato e compensato per i cambio di temperatura o usa un chip RTC che contiene qulacosa simile come il DS3232.

[Rabeluk]

a ok si si , uso 2 condensatori da 22 pico per il cristallo usato per gestire la frequenza del Micro e siccome su una guida AVR ho letto che per far lavorare il timer counter con cristallo esterno non c'è bisogno di condensatori non li ho predisposti.... comunque per il momento sto solo simulando il tutto con pr_t_us

[Rabeluk]

avrei un'altra domanda da porvi....
in pratica quando passa un effettivo secondo prima di aggiornare il registro dei secondi spreco 4 colpi di clock.... il ritardo dovuto a questi 4 colpi di clock si propaga? cioè in un anno avrò un ritardo di (4x60x60x24x365)/2000000 secondi?

[Leonardo]

1) Prendendo ad esempio un ATMEGA328P, da datasheet:

TCNT0 – Timer/Counter Register: The Timer/Counter Register gives direct access, both for read and write operations, to the Timer/Counter unit 8-bit counter. Writing to the TCNT0 Register blocks (removes) the Compare Match on the following timer clock. Modifying the counter (TCNT0) while the counter is running, introduces a risk of missing a Compare Match between TCNT0 and the OCR0x Registers.

C'è il rischio di perdere un Compare Match più che avere un interrupt non desiderato

2) 8 bit = 256 valori contando lo 0, quindi da 0 a 255


Per quanto riguarda l'ultima domanda:

I timer sono indipendenti rispetto alla CPU, quando esegui del codice non si fermano

Ciao

[Rabeluk]

1) Prendendo ad esempio un ATMEGA328P, da datasheet:

TCNT0 – Timer/Counter Register: The Timer/Counter Register gives direct access, both for read and write operations, to the Timer/Counter unit 8-bit counter. Writing to the TCNT0 Register blocks (removes) the Compare Match on the following timer clock. Modifying the counter (TCNT0) while the counter is running, introduces a risk of missing a Compare Match between TCNT0 and the OCR0x Registers.

C'è il rischio di perdere un Compare Match più che avere un interrupt non desiderato

questo lo sapevo, però è impossibile una cosa del genere visto che il compare match sarebbe molti colpi di clock dopo.

2) 8 bit = 256 valori contando lo 0, quindi da 0 a 255


Per quanto riguarda l'ultima domanda:

I timer sono indipendenti rispetto alla CPU, quando esegui del codice non si fermano

quindi il ritardo non si accumula, ottimo l'accuratezza dipenderà solo dai cristalli in pratica?

[Leonardo]

A meno di errori grossolani nel codice dipende dal clock di riferimento, ovvero dal cristallo oscillatore
Ti lascio un Application Note che potrebbe interessarti: http://www.atmel.com/Images/doc8333.pdf

Ciao

[Rabeluk]

ottimo, grazie mille
le stesse considerazioni possono essere fatte per la gestione della frequenza di lavoro del micro? Chiedo perché ho scelto di usare un cristallo di 2 MHZ in modo da limitare i consumi

[Leonardo]

Si, valgono praticamente tutte le stesse considerazioni tenendo presente della frequenza del cristallo oscillatore.

Se non necessiti di grande precisione e stabilità in frequenza per la CPU potresti optare per l'oscillatore RC interno, ridurrebbe più che altro il numero di componenti da utilizzare.

Più che la sola frequenza per limitare i consumi (in base al micro) dove possibile dovresti disattivare le periferiche non utilizzate e utilizzare lo sleep il micro, tutte considerazioni che permettono di risparmiare qualche mA che devono essere fatte se ha senso, inutile utilizzare un 7805 con una tensione di 9v e cercare di ridurre i consumi agendo solamente sul micro

Prego
Ciao

[Rabeluk]

Più che la sola frequenza per limitare i consumi (in base al micro) dove possibile dovresti disattivare le periferiche non utilizzate e utilizzare lo sleep il micro,o

sono considerazioni che ho fatto all'inizio del progetto ma poi per accelerare i tempi ho evitato di inserire ulteriori "optional"

grazie dell'aiuto
ciao

[Rabeluk]

Vorrei chiedervi se secondo voi uno schema del genere può andare bene... Ho un dubbio sul buzzer in quanto non so se quello che ho utilizzato sia un vero piezobuzzer (di funzionare funziona,però...) o qualche dispositivo simile.Premetto che non ho mai usato componenti del genere e non ho alcuna esperienza. (ho usato proteus per lo schema e per la simulazione).

la sigla del buzzer è SOUNDER ACTIVE Piezo Sounder model (Digital)-Outputs via sound card

[ulisse21]

lo schema secondo me va bene,
unica cosa è che ti sei tolto la possibilità di comunicare tramite rs232 e i2c.

non è necessario portare tutte le gnd ad un unico nodo (come vedo sulla destra dello schema).
per rendere più chiaro lo schema ti consiglio di usare anche qualche bus.

ciao e benvenuto al forum

[Rabeluk]

lo schema secondo me va bene,
unica cosa è che ti sei tolto la possibilità di comunicare tramite rs232 e i2c.

va be non fa niente .. ho utilizzato solo le cose che mi servono cercando di ottimizzare al meglio quello che voglio fare.. magari non ho gestito al meglio le risorse ma è la mia prima esperienza coi micro alla fine ...

non è necessario portare tutte le gnd ad un unico nodo (come vedo sulla destra dello schema).
per rendere più chiaro lo schema ti consiglio di usare anche qualche bus.

se riesco apporto la modifica un po' di ordine non fa mai male


comunque ritornando al buzzer c'è anche questo componente (l'immagine allegata).... all'inizio pensavo fosse questo il buzzer... potreste chiarirmi le idee?
la sigla di questo è
BUZZER ACTIVE DC Operated Buzzer-Outputs Via Sound Card