Maggiore precisione con contagiri PIC

[DirtyDeeds]

Sì, bisogna però verificare se, come velocità, si riesce a fare con il timer e gli interrupt del PIC. Proviamo a fare due conti: la frequenza è l'inverso del periodo, ossia



Se misuri il periodo con una risoluzione , la risoluzione che hai sulla frequenza è



e dovrai quindi avere



Quindi dovrai pilotare il timer che misura il periodo con un clock minore di quel valore. E attento che a basso numero di giri non vada in overflow, quant'è il minimo? E' un bel po' che non uso i PIC, quindi lascio a te verificare se ce la fai.

[Edge]

Bè, in tal caso, dovendo basarmi sul periodo anzichè sulla frequenza, dovrò dare un numero minimo di giri misurabili per evitare l'overflow del timer. Però potrei anche impostare una variabile che tiene conto dell'overflow del timer.
Vediamo se la procedura per il calclo del periodo l'ho capita:

- Inizializzo il timer con una risoluzione per esempio di 1ms (quindi overflow ogni ms giusto?)
- Al momento dell'arrivo del primo fronte di salita salvo il valore del timer.
- Al momento del secondo fronte di salita salvo nuovamente il nuovo valore del timer.
- Faccio la differenza dei valori salvati e trovo il periodo.

[DirtyDeeds]

Però potrei anche impostare una variabile che tiene conto dell'overflow del timer.

Sì, questa è la via migliore.

Inizializzo il timer con una risoluzione per esempio di 1ms (quindi overflow ogni ms giusto?)

Il resto è giusto, ma questo no: la risoluzione che vuoi deve coincidere con il periodo del clock che pilota il timer. Il calcolo che ho fatto sopra ti dice che questo periodo deve essere minore di ; se il timer è un registro a n bit, l'overflow avverrà dopo un periodo pari a .

Alla fine, poi, dovrai fare l'inverso del numero trovato per ottenere una frequenza.

[Edge]

Il resto è giusto, ma questo no: la risoluzione che vuoi deve coincidere con il periodo del clock che pilota il timer

Ah ok, ho capito.

Quindi se sfruttassi lo stesso quarzo che monto adesso, ovvero 40kHz la mia risoluzione sarebbe di 25uS, che in tal caso sarebbe troppo bassa per il mio scopo.
Quindi essendo il TIMER0 ad 8bit --> 2^8 = 256 ed avendo una risoluzione di 25uS, il TMR0 andrebbe in overflow ogni 6,4 ms. Giusto?

[DirtyDeeds]

Sì, esatto. Sicuramente devi aumentare la frequenza di clock, ma dovresti fare anche attenzione alle seguenti cose:

- Avere una risoluzione di 10 giri/min alla massima frequenza di 9000 giri/min significa che devi fare almeno 900 conteggi: se usi un timer a 8 bit, questo ti va in overflow almeno tre volte durante il conteggio. E ti va in overflow molto di più a frequenze più basse, quando il periodo da misurare è più alto. Sono almeno 10 anni che non uso più un PIC, però se non ricordo male c'era la possibilità di unire due timer (forse TMR0 e TMR1) per farne uno a 16 bit, forse ti converrebbe iniziare a usare questa possibilità. Paolino e TardoFreak forse possono dirci qualcosa di più.
- Volendo comunque gestire l'overflow, devi tenere conto che se lo gestisci tramite un interrupt pilotato dal timer, la gestione deve: i) non bloccare l'interrupt che arriva dal sensore, altrimenti avresti un errore di conteggio, e ii) essere sufficientemente veloce da non impedire il conteggio del successivo impulso della base tempi. Ciò significa che la routine di gestione dell'overflow deve eseguire il compito in un tempo inferiore a , ovvero che la frequenza di clock del PIC deve essere sufficientemente più alta di . Insomma, devi farti qualche conticino su queste cose.

[TardoFreak]

Che PIC utilizzi?
perché usi un quarzo con una frequenza così bassa?

[Edge]

Insomma, devi farti qualche conticino su queste cose

Ok. Ci sono arrivato.

Che PIC utilizzi?
perché usi un quarzo con una frequenza così bassa?

Utilizzo un PIC16F72 e utilizzo un quarzo da 40kHz perché volevo un periodo da 1s solamente "giocando" con prescaler e inizializzazione di TMR0. Potevo usarne anche uno da 1MHz ma in casa non ne avevo e dovevo ordinarne. Siccome ne avevo uno da 40kHz e questo andava comunque benissimo per il mio scopo, ho usato quello nel progetto. Tutto qui. Solo che nel mio firmware conto gli impulsi ricevuti in 1s. Stavolta invece devo ragionare sul conteggio del periodo tra due fronti di salita (discesa) successivi.

In laboratiorio avevo anche un quarzo da 8Mhz con cui inizialmente avevo provato, però avendo due interrupt (quello dell'overflow su TMR0 e quello dell'impulso su RB0), associando una varibile che si decrementava ad ogni overflow di TMR0 per creare una base dei tempi di circa 1s, accadeva che l'interrupt sull'overflow di TMR0 non mi facesse gestire correttamente il conteggio degli impulsi su RB0.

Potrei pensare anche ad utilizzare il TMR1, ma non ho iniziato da molto con la programmazione dei PIC e fino ad ora ho realizzato applicazioni sfruttando solo il TIMER0. Quindi se riuscivo ad arginare il problema solo utilizzando il TMR0 non sarebbe stato male. Però forse davvero non si riesce solo con il TMR0.

[TardoFreak]

Non ho sotto mano il datasheet ma mi pare che il Timer1 sia a 16 bit. perché non lo vuoi usare? Non è diverso dall' altro.

[Edge]

Non ho sotto mano il datasheet ma mi pare che il Timer1 sia a 16 bit. perché non lo vuoi usare? Non è diverso dall' altro.

Si, è a 16bit.
Non è che non lo voglio usare, è che avevo provato ad utilizzarlo inizialmente sfruttando la funzione Capture di RC2/CCP1 sempre per calcolare il numero dei giri (anzi, nel primo post che avevo fatto inerente al contagiri che volevo fare sfruttava questo metodo) ma mi ero un po' incasinato e non capivo se facevo bene e quindi ho optato per il conteggio degli interrupt su RB0 e la creazione di una base dei tempi di 1s con TMR0 che mi sembrava la soluzione più semplice. Solo che c'è il difetto della perdita dei 60 giri ad ogni perdita di impulso che mi rende poco precisa la lettura per quello che devo fare.

[DirtyDeeds]

A complemento, aggiungerei che hai due possibilità per implementare il conteggio:

1) Usi un timer con un numero sufficientemente grande di bit, chessò 16, tale da essere sicuro di non avere overflow anche alla frequenza più bassa e azzeri il timer a ogni inizio di conteggio. In questo modo non c'è bisogno di gestire l'overflow, ma il conteggio non è continuo. Questo potrebbe essere un problema se volessi fare medie tra più periodi adiacenti.
2) Fai un conteggio continuo, come tu stesso avevi ipotizzato qualche messaggio fa, ma a questo punto sei obbligato a gestire l'overflow del timer perché prima o poi questo arriverà. Meno frequentemente arriva, però, meglio è, perché così hai il tempo di fare anche altre cose, tipo visualizzare la misura Inoltre, se fai bene le cose, potresti facilmente riuscire a implementare anche una misura di periodo medio.