Newsgroup: it.hobby.elettronica.digitale
Titolo: Progetto Orologio con 16f84

Salve a tutti. Sono all'opera per la realizzazione di un 
orologio con display a 7 segmenti tramite un pic 16f84.
Premetto che conosco l'assembler da poche settimane e solo 
grazie al corso di Tanzilli.
Ho abbozzato qualcosa che x il momento mi mostri su un display 
a 7 segmenti il passare dei secondi da 0 a 9.
Il problema è che mettendo a confronto il display con un 
cronometro, dopo pochi minuti il conteggio del pic perde il 
sincronismo con il vero cronometro.
Perchè succede questo? Dove ho sbagliato?
Allego il sorgente del programma asm e faccio notare che il 
tempo di dalay di un secondo, l'ho realizzato tramite il TMR0 e 
tramite il registro Count che provvedono a dividere la 
frequenza del quarzo (4 MHz) fino a portarla ad 1 Hz.
;7SEG.ASM Conta i secondi da 0 a 9
;23 ottobre 2003
PROCESSOR 16F84
RADIX DEC
INCLUDE "p16F84.INC"
ERRORLEVEL -302
__CONFIG 3FF1H
ORG 0CH
Count RES 1 ;Riserva 1 byte  per il registro Count
ORG 00H ;RESET VECTOR
bsf STATUS,RP0 ;Commuta sul bank 1
movlw 11111111B ;RA0 -> RA4 configurate come ingressi
movwf TRISA
movlw 00000000B ;RB= -> RB7 configurate come uscite
movwf TRISB 
movlw 00000100B ;Assegna il prescaler a TMR0 e lo setta a 32
movwf OPTION_REG
bcf STATUS,RP0 ;Commuta sul bank 0
Display
movlw 01111110B ;Visualizza il numero 0
movwf PORTB
call Delay 
movlw 00001100B ;Visualizza il numero 1
movwf PORTB
call Delay
movlw 10110110B ;Visualizza il numero 2
movwf PORTB
call Delay
movlw 10011110B ;Visualizza il numero 3
movwf PORTB
call Delay
movlw 11001100B ;Visualizza il numero 4
movwf PORTB
call Delay
movlw 11011010B ;Visualizza il numero 5
movwf PORTB
call Delay
movlw 11111010B ;Visualizza il numero 6
movwf PORTB
call Delay
movlw 00001110B ;Visualizza il numero 7
movwf PORTB
call Delay
movlw 11111110B ;Visualizza il numero 8
movwf PORTB
call Delay
movlw 11011110B ;Visualizza il numero 9
movwf PORTB
call Delay
goto Display 
Delay
movlw 6
movwf TMR0
movlw 125
movwf Count
DelayLoop
movf TMR0,W
btfss STATUS,Z
goto DelayLoop
movlw 6
movwf TMR0
decfsz Count,1
goto DelayLoop
return
END
Inviato da 
www.mynewsgate.net

 perde il  sincronismo con il vero cronometro.
Capito perche' ODIO il TMR0? (ma anche gli altri non scherzano)
Intanto da quando si scrive nel TMR l'incremento non parte subito, ora non
ricordo ma e' ritardato di qualche ciclo di clock. E poi, peggio ancora e
ASSURDO, il prescaler viene azzerato perdendosi tutti gli impulsi trascorsi
dall'overflow del timer fino al momento in cui viene ricaricato... (gli ST
questa vaccata non la fanno) Il risultato per quanto ne so e' che si deve
usare un quarzo potenza di 2 e lasciare che il timer vada per conto suo
dividendo sempre per 256 (senza mai ricaricarlo). Io se proprio devo taglio
la testa al toro generando una frequenza campione esterna. In questo caso
userei due CD4518 per ottenere 400Hz dal quarzo e li leggerei via software
(o al limite con un interrupt) da un pin di ingresso.
Claudio F

 In questo caso userei due CD4518 per ottenere 400Hz dal quarzo
O comunque guarderei se c'e' un fattore di divisione del prescaler che mi
fornisce un numero intero di millisecondi (sempre lasciando andare il TMR0
per i fatti suoi), che pero' difficilmente saranno frazioni intere anche di
1 secondo... e va quindi complicato il software con opportuni conteggi di
correzione (tipo 1 secondo aggiunto ogni tot ecc...)
Claudio F

 ha scritto:

Grazie per avermi dato queste informazioni.
Il problema, a quanto pare, è più complicato di quanto pensavo.
Ora, visto che ne capisci più di me, mica mi puoi dare una mano 
x generare questo benedetto Hz senza cose esterne? 
Inviato da 
www.mynewsgate.net

 x generare questo benedetto Hz senza cose esterne?
Se non usi il prescaler (bit PSA=1) il TMR0 divide per 256 la freq clock/4 e
ottieni il tempo minimo base di 4000000/4/256=3906,25Hz (256uS).
Attivando il prescaler non fai altro che moltiplicare questo tempo (o
dividere questa frequenza) per il fattore di divisione del prescaler stesso,
in nessun caso salta fuori un sottomultiplo dell'Hz:(
Usando un quarzo da 3,2768MHz invece avresti un tempo base di
3276800/4/256=3200Hz (312,5uS). Dividendo con il prescaler per 64 arrivi a
50Hz (20mS), per cui basterebbe contare 50 overflow del timer e sarebbe
passato esattamente 1 sec.
Volendo per forza usare un quarzo da 4 terrei la base tempi a 256uS (niente
prescaler). Visto che in 1 secondo i 256uS entrano 3906,25 volte conterei
per 3 volte 3906 overflow (ottenendo secondi da 0,999936sec) e la quarta
3907 overflow (ottenendo un secondo da 1,000192sec), che in totale danno 4
secondi spaccati. La differenza di qualche 100uS nella durata dei secondi
non credo costituisca un problema visto che poi presi a gruppi di 4 il tempo
e' invece precisissimo.
Claudio F

 ha scritto:

Domani, con un pò di pazienza rifletto su quanto mi hai detto.
Solo che c'è un altro problema: I microsecondi che perdo con i 
cicli di ogni istruzione come li devo compensare??
HELP!!!
Inviato da 
www.mynewsgate.net

 istruzione come li devo compensare??
Non c'e' niente da compensare, almeno per come la intendo io. Ogni 256uS mi
trovo il bit T0IF settato, lo resetto, faccio quello che devo fare e torno
ad aspettare che si setti di nuovo. Non avevo guardato bene il tuo primo
list, ma comunque non andava bene anche se il TMR0 non avesse i problemi
gia' detti, e proprio perche' la somma di tutte le istruzioni tra l'inizio
di una una cifra e l'inizio l'altra non dava in ogni caso un tempo pari a 1
secondo. Tutte le istruzioni di elaborazione devono invece essere contenute
e comprese nel ciclo "mainloop" (dell'esempio di sotto) agganciato ai 256uS
(o altro tempo se si preferisce, ma si complica la correzione). In questo
caso non va bene leggere direttamente il valore del TMR0 perche' cambia ogni
uS. Il bit di overflow T0IF invece resta settato finche non lo si resetta "a
mano".
mainloop
 BTFSS T0IF
 GOTO  mainloop
 BCF   T0IF
...ELABORAZIONE...
...OGNI 256 uS....
 GOTO mainloop
Claudio F


Grazie 1000 Claudio. Oggi, con um pò di pazienza raccolgo le 
idee e poi faccio le mie prove. Ti farò sapere appena posso.
Intanto se ti viene in mente qualche altra cosa... io sono 
sempre qui! :-)
Un'altra cosa: visto che a quanto pare ne sai mooooooolto più 
di me, mica mi puoi dire dove trovare qualche guida, tutorial, 
manuale, ecc... per programmare i pic? Io sono partito dal 
lavoro di Tanzilli e poi, con il manuale della microchip che 
purtroppo è in inglese! Qualcosa ci capisco, ma preferisco 
l'italiano. Mi puoi aiutare?
A presto, fastdius
Inviato da 
www.mynewsgate.net

 lavoro di Tanzilli e poi, con il manuale della microchip che
Qualche appunto (piu' software che altro) l'ho messo su:
http://net.supereva.it/stor2.freemail/pic/pic.htm
Curiosamente oggi sono alle prese anch'io con un orologio con PIC... anche
se di altro tipo.
Claudio F


Ora dò un'occhiata al sito ke mi hai indicato.
Cmq riflettendo su quello che mi hai detto precedentemente, mi 
trovo di fronte ad un altro problema.
Allora: tu mi dici che se uso un quarzo da 4 MHz e non uso il 
prescaler del TMR0, arrivo alla frequenza di 3906,25 Hz.
Mi basta contare 3 volte 3906 e 1 volta 3907 e arrivo ad avere 
4 secondi spaccati. Il problema è: come cavolo faccio a contare 
3906 e 3907? Se uso dei registri supplementari posso dividere 
3906 prima per 217 e poi per 18: in questo modo ottengo 1.
Ma per 3907 come devo fare? Non è divisibile per nessun numero 
fino a 256 (cioè mi dà sempre un risultato con la virgola).
Come devo ovviare? Usando un'altro quarzo?? Tu che mi consigli?
GRAZIE 1000
PS: con che tipo di orologio stai a vendo a che fare?
CIAO, fastdius
Inviato da 
www.mynewsgate.net

 PS: con che tipo di orologio stai a vendo a che fare?
http://net.supereva.it/stor2.freemail/dcf/dcf.htm
Claudio F


MA TU 6 UN MOSTROOOOOO!!!!
Ho visto il progetto del robot. Devi essere proprio uno con le 
palle tu! Dimmi un pò, quanti anni hai? Di dove 6? Come hai 
imparato tutto quello che sai??
Per quanto riguarda il mio problema, ho letto la parte sui loop 
nel tuo sito, e devo dire che ho capito il concetto.
Per ora non dovrei avere + problemi (SPERIAMO)! Cmq spero di 
poter contare sempre sul tuo aiuto. Ti farò sapere se il mio 
banale contasecondi funziona. A preso.
fastdius
Inviato da 
www.mynewsgate.net

> 
http://net.supereva.it/stor2.freemail/dcf/dcf.htm
Lifter: TU SEI PAZZO :)
--
...:::Zmaster:::...
DSL powered
zmast[ANTISPAMSYSTEM]@
freemail.it
www.zmaster.tk
Collaboratore del Media Player Project

Claudio, aiutamiiiiiii!!!
Ti ho inviato un'e-mail, ti è arrivata??
Non so dove ho sbagliato!! Cmq ho fatto una modifica: 
nell'interrupt vector salvo W in un registro temporaneo e poi 
prima di uscire con l'istruzione retfie, carico nella W il 
valore del registro temporaneo. In questo modo i numeri sul 
display avanzano, ma non lo fanno una volta al secondo, bensì 
ci mette circa 17 secondi. Come mai??
HELP ME!!!
fastdius
Inviato da 
www.mynewsgate.net

 nella W il valore del registro temporaneo.
...e lo STATUS? (seguendo strettamente la procedura scritta nel ds)
Claudio F
PS finora non ho mai usato gli interrupt

FINALMENTE HO RISOLTO!!!!
..in pratica succedeva questo:
quando davo tensione al circuito sul display appariva lo 0. Poi 
dopo un secondo appariva l'1 e poi gli altri numeri avevano 
ritardi di circa 16 - 17 secondi.
Dopo 2 giorni ho trovato il problema:
quando uscivo dall'interrupt vector (che contava 3906 
decrementi con un doppio registro a 8 bit come diceva sul tuo 
sito) mi ero dimenticato di ricaricare il valore 3906. Quindi 
invece di contare 3906 (cioè un secondo) mi contava 65536 (cioè 
16,7 secondi).
Vabbè, ora vado a dormire e domani vedo di implamentare nel mio 
programma un secondo display a 7 segmenti per visualizzare i 
secondi da 0 a 59. ...dovrò multiplexare le uscite: chissà cosa 
ne esce. Ti farò sapere.
Cmq grazie 1000 x tutti i consigli.
A presto
fastdius
Inviato da 
www.mynewsgate.net

 Perchè succede questo? Dove ho sbagliato?
Ti dico la mia esperienza con quarzo a 4MHz.
1) Nel programma SEQTMR0.asm del corsodi Tanzilli,
l'autore non considera alcuni ritardi intrinseci
nell'architettura del PIC quando avviene la scrittura su TMR0.
Questo non pregiudica il funzionamento del programma,
ma in alcuni applicazioni, dove è richiesta una elevata
accurateza, può portare a grossi problemi.
I ritardi da considerare sono
 a) il prescaler è azzerato ogni volta che si scrive su TMR0.
 b)Quando scrivo un valore su TMR0 la scrittura diventa effettiva solo
 dopo un ciclo macchina e il conteggio di TMR0 è inibito per i due
 cicli macchina sucessivi
Maggiori chiarimenti su questi ritardi
li trovate a pag.28 nel documento DS30430C.pdf
(data sheet PIC 16F8x) sul sito 
www.microchip.com
 e sul
documento PICmicro MID-RANGE MCU FAMILY sul sito  
http://www.microchip.com
sezione "TMR0 PRESCALER" e "Design Tips"
In sostanza ogni volta che scrivo su TMR0
perdo la sincronizzazione tra prescaler e TRM0 e,
ancorapiù grave,
perdo il valore contenuto nel prescaler.
Nell'esempio SEQTMR0.asm posso
quindi perdere anche diverse decine di us
con una frequenzadi 125 volte al secondo.
In pratica perdo decine di us su un intervallo
di 8000us, un errore dell'ordine di 1250 ppm ( parti per milione).
E' un errore intollerabile per costruire un orologio
dato che l'errore si somma in continuazione ad ogni ciclo.
E' possibile compensare questi ritardi scrivendo
un appropiato valore in TMR0 ma bisogna
tenere il conto di quanti us si
perdono qua e la' , compito possibile ma tutt'altro che facile.
Un' alternativa consiste nel lasciare andare
TMR0 in continuazione, senza mai riscriverlo,in free-run.
Anche con l'ausilio di un contatore software non riesco
ad ottenere un intervallo di 1 secondo esatto.
Ottengo intervalli di durata troppo breve o troppo lunga rispetto il
secondo.
Una soluzione consite nel mediare la durata deglii intervalli
In questo progetto
http://www.piclist.com/techref/microchip/cntdn/index.htm
TMR0 funziona in free-run ,cioè non è mai riscritto,
e il prescaler è impostato 1:16.
TMR0 va in  overflow ogni 16*256=4096us
Dentro la routine di interrupt il registro INTCNT
inizializzato a 244, è decrementato di 1.
Qundo INTCNT arriva  zero sono trascorsi
4096*244=999424us quindi  viene eseguita,
con leggero anticipo, la routine
che cambia i secondi e insieme reinizializzato INTCNT a 244.
Un ulteriore registro tiene conto di quante volte
è stata eseguita la routine che cambia i secondi.
Dopo 7 cambiamenti del registro dei secondi,
INTCNT è reinizializzato a 245 anzichè 244.
La routine che cambia i secondi è eseguita quindi
per 7 volte ogni 4096*244=99424us e
una volta per  4096*245=1003520us
quindi in media per (999424*6+1003520)/7=1000009us
non pefretto ma buono.
Con una semplice proporzione trovi che un errore
di 9us ogni 1000000us (9ppm)
corrisponde a meno di 1sec al giorno.
Se realizzi il circuito sono pronto a scommettere
che l'errore che troviparagonandolo auncronometro
è molto molto maggiore.
Eppure il software e giusto.
Probabilmente la tolleranza in frequenza del quarzo
 la temperatura incidono molto
sulla velocità di esecuzione.
Bisognerebbe avere un frequenzimetro e verificare
l'effettiva freq.di oscillazione.
Nel mio circuito PIC timer
http://spazioinwind.libero.it/nferrarese/
ho utilizzato una tecnica mista:
TMR0 quasi sempre in free-run
con scrittura su TMR0 ogni tanto.
Non ti descrivo la tecnica perche'
è piuttosto empirica.
La puoi cmq trovare descritta nel file zip relativo al timer.
Penso comunque che, in ogni caso,
molto dipenda dalla
effettiva frequenza a cui oscilla il quarzo.
Spaccarsi la testa per otterere routine che
durano esattamente 1000000 us
può essere vanificato da un quarzo che non oscilla
alla freq nominale.
Vedere
Data sheet dei quarzi a 4MHz serie HC49 sul sito
http://www.rs-components.it/
nel range da 0°C a  50°C la tolleranza del quarzo
può andare da 15ppm a 200ppm.
IMHO
Ciao.

Carissimo Pompeo, grazie 1000 per le info che mi hai dato.
Da quanto hai scritto ho capito ke con un quarzo da 4 MHz le 
cose sono un pò difficili, giusto?
Ma se ne usassi un altro?
Tipo 3,2768 MHz oppure 4,194304 MHz??
Le cose andrebbero meglio?
Per esempio: con 3,2768 MHz, se uso TMR0 in free runner ho una 
frequenza di (3276800/4/256)= 3200 Hz.
Se poi uso il prescaler a 128 ottengo 3200/128 = 25 Hz
In pratica, se setto un registro a 25 e lo decremento ad ogni 
overflow di TMR0, ho esattamente 1 Hz, giusto?
O c'è qualke altro inconveniente da considerara???
GRAZIE!!!
Inviato da 
www.mynewsgate.net

...

Il pic che riporta -04 vuol dire che è
costruito per andare al max a 4MHz.
Se usi un quarzo con freq. maggiore
probabilmente funziona comunque,
ma non stai rispettando le specifiche quindi
non è una soluzione affidabile.
Visto che devi costruire un orologio
non hai bisogno di grandi velocità
quindi va bene anche un quarzi a freq.
minore di 4MHz, anzi meglio,
Il PIC ringrazia consumando meno corrrente.
Il quarzo da 4MHz è comodo perche' cosi'
ogni istruzione dura esattamente 1us
e questo semplifica il calcolo della
durata della routine.
Rimangono in ogni caso i problemi legati
alla tolleranza del quarzo.
Sarei curioso di sapere se qulcuno
ha provato a misurare con un frequenzimetro
a quale freq.effettiva oscilla un PIC
con quarzo da 4MHz, c da 27pF a 20 °C.
O anche con altri valori e se ha riscontrato
differenzze sensibili dai valori nominali.
Solo in questo caso potrei
consigliare l'utilizzo di un quarzo ad
una particolare freq. oppure cecare di fare
tutto via software.
Ciao.

 ha scritto:

Forse non mi sono spiegato bene:
Allora, mettiamo ke uso un quarzo da 3,2768 MHz.
Setto il prescaler a 128 e lo assegno a TMR0.
Lascio andare TMR0 in free runner e nell'interrupt vector, ad 
ogni overflow di TMR0, decremento un registro ke setto a 25.
In preatica, ogni secondo esatto (a parte la tolleranza del 
quarzo) mi ritrovo il mio registro a zero.
Poi, una volta ottenuto l'hertz, faccio quello che devo fare 
nel loop principale.
Ci siamo, oppure ho tralasciato qualcosa?
Ipotizzando NULLA la tolleranza del quarzo, riuscirei ad avere 
la frequenza precisa di 1 Hz?
GRAZIE!!!
Inviato da 
www.mynewsgate.net

 la frequenza precisa di 1 Hz?
Si, e' il modo in assoluto piu' semplice e sicuro... anche se questo qui
dice di averla ottenuta anche da 4MHz:
http://www.ozitronics.com/docs/k73.pdf
 (ma non ho ancora capito come...)
Claudio F

 con quarzo da 4MHz, c da 27pF a 20 °C.
Per non disturbare in alcun modo l'oscillatore forse e' meglio generare un
onda quadra a software e misurare la sua frequenza (magari con uno strumento
che apprezza anche i decimi di Hz). La seguente routine dovrebbe generare
esattamente CLOCK/32 Hz con duty del 50%:
 bsf PORTB,0
 nop
 nop
 nop
 bcf PORTB,0
 nop
 goto $-6
Ogni Hz di errore corrisponde a 32 Hz di errore del del clock.
Claudio F

 dice di averla ottenuta anche da 4MHz:
Scusate il ritardo, ho aperto solo adesso questo thread.
Anni fa, in alcuni progetti avevo usato questo scheletro di routine,
che genera interrupt periodici con i 16C/F84:
--------
interrupt       movwf   w_temp          ; salva registri W,STATUS
		swapf	STATUS,w
		BANK0
		movwf	status_temp
		movf    TMR0,w
		addlw   d'256'-TICK+5	; aggiorna timer
		movwf   TMR0
 
		; .... inserire QUI il codice da eseguire periodicamente
 
irq_end		swapf	status_temp,w		; ripristina W e STATUS
		movwf	STATUS
		swapf	w_temp,f
		swapf	w_temp,w
		bcf	INTCON,T0IF		; resetta flag interrupt
		retfie
--------
Il prescaler va impostato a 1:1, TICK è il periodo di ripetizione
dell'interrupt (in cicli macchina, cioè fclock/4). Es: con un quarzo da
4MHz e TICK=100 si hanno 10000 interrupt al secondo.
E' passato molto tempo, mi sembra che avevo trovato questa routine in
qualche app-note microchip. Il trucco sta nel blocco di tre istruzioni
centrali: invece di ricaricare TMR0 con un conteggio fisso (che non
tollera variazioni nel ritardo tra l'overflow del timer e la sua
riscrittura), si somma un valore fisso al timer. La costante + 5 è un
fattore di correzione: se non ricordo male, si ricava tenendo conto che
tra l'istruzione "movf TMRO,w" e "movwf TMR0", il timer si incrementa
di 3 cicli, e che dopo la scrittura del timer, questo rimane fermo per
2 cicli.
Non sono sicuro che questa costante vada bene sui nuovi PIC, ma ricordo
bene che a suo tempo avevo testato tutto questo sugli '84 con un paio
di bsf/bcf in modo da generare un impulso esterno ad ogni interrupt:
all'oscilloscopio gli impulsi erano perfettamente distanziati, e il
frequenzimentro confermava la frequenza di ripetizione teorica.
Ciao
Adriano

Ke vuol dire:
goto $-6???
GRAZIE
Inviato da 
www.mynewsgate.net

 che apprezza anche i decimi di Hz).
Tutto vero e sicuramente da provare.
Non disponendo di un'attrezzaatura adeguata ho
provatoa lasciare funzionare il mio orologio con
PIC e 4 display LED 7 segmenti per un giorno intero
insieme a un cronometro digitale fatto partire allo stesso istante.
All'inizio i due tempi coincidono.
Lascio TMR0 in free-run utilizzando la solita routine
4MHz / 4 / 16 (prescaler) / 256 (TMR0) / 244 (contatoreinterrupt)
ottenendo un intervallo di 999424us.
L'orologio con PIC va quindi 576us + veloce ogni secondo.
Dopo 24 ore dovrebbe andare avanti di circa 50 secondi.
Il mio prototipo dava al cronometro molti secondi in piu dei 50 previsti.
Ciao.

 la frequenza precisa di 1 Hz?
Direi che ci sei.
Col TMR0 in free-run
ti togli dalle pa**e
la grana dei us persi dal prescaler
e della perdita di sincronismo
alla scrittura sul TMR0.
Ottieni il tuo bel periodo
da 1 secondo.
Tolleranza del quarzo permettendo.
Rimango comunque perplesso
sul fatto di dover ricorrere a
quarzi di freq. particolare.
E' paradossale dover progettare
il quarzo sulla base dell'applicazione
disponendo di un uchip programmabile.
Mi convinco ancora di piu' vedendo
l'application notes AN590 della Microchip
dove utilizzano un quarzo da 4MHz
per fare proprio un orologio.
Non ho studiato il programma ma dicono
che sbaglia di 1,5 secondi all'anno,
"exept for cristal frequency drift"
Ciao.

 "exept for cristal frequency drift"
Ho guardato anch'io quella an ieri, correggendo in modo un po'diverso si
arriva benissimo a zero ms di errore in un anno....."exept for cristal
frequency drift" naturalmente;) Ma va fatta una correzione al minuto (+8),
una all'ora (+26) e un'altra ogni 24 ore (+6). Benche' il tempo globale sia
corretto, lo scadere dei singoli minuti puo' avere un jtter di 100mS
(soprattutto verso la fine dell'ora)... lo si potrebbe ridurre facendo
correzioni intermedie piu' frequenti.
Claudio F

 movwf   TMR0
Grande! Sapevo che c'era un'alchimia da qualche parte;)
Quando ne avro' l'occasione la provero'... si, dovrebbe funzionare, anche se
si lasciano passare molti cicli prima di riaggiornare il tmr0 proprio
perche' ne tiene conto nella somma. Pero' obbliga ad usare interrupt a
frequenza molto elevata... dai 5kHz in su:(
Claudio F

 in piu dei 50 previsti.
Per una base tempi e' meglio prevedere sempre un qualche sistema di taratura
della frequenza, i quarzi sono si stabili, ma comunque fuori di parecchie
decine di Hz... (dipende anche dal circuito in cui sono inseriti).
Probabilmente facendo i conti a ritroso con i secondi eccedenti era anche
possibile risalire all'esatta frequenza del quarzo... a meno che a sbagliare
non fosse il cronometro di riferimento.
Claudio F

 frequenza molto elevata... dai 5kHz in su:(
Giā, e comporta uno spreco di cicli tra il 10% e il 20%, ed eventuali
accorgimenti nella stesura del codice (cosė da rientrare dall'interrupt
prima che arrivi il successivo). Ad esempio macchine a stati, in modo da
spezzare routine lunghe in tanti blocchi pių brevi, e/o far largo uso di
flag (passati tra main e interrupt in modo da creare una sorta di
multitasking).
Ai tempi in cui i pic con l'UART erano ancora rari, avevo usato questa
routine (di solito a 9600) in parecchi progetti, per implementare RS232
via software, campionare segnali di telecomandi, ecc...
Certo che con un timer a 16 bit si potrebbe scendere parecchio in
frequenza, arrivando a 20Hz... peccato che il TMR1 sia ancora pių
schizzinoso del TMR0 riguardo le operazioni di scrittura! :-(
Adriano