Configurare clock 32MHZ

[bobina]

Più che il bit PLLEN con SPLLEN = 1 il 4x PLL doveva abilitarsi come spiega il paragrafo 6.2.1.4 del datasheet.
Non vedendo tutto il codice è difficile dirlo, ma in realtà quello che è accaduto potrebbe essere che il quarzo interno ancora non aveva raggiunto il clock giusto ed il 4x PLL non si è abilitato quando gli veniva richiesto.
Il datasheet dice: "The input frequency for the 4x PLL must fall within specifications."
Infatti per verificare che il quarzo interno sia pronto conviene verificare i bit HFIOFR e HFIOFS del registro OSCSTAT e volendo c'è anche questo PLLR per vedere se il 4x PLL è pronto.
Se vuoi toglierti lo sfizio puoi provare a ripristinare il vecchio codice ed inserire i controlli sui bit. In fase di init metti un while che controlla i bit e non vai avanti finché non sono pronti.
Io farei una cosa del genere

Codice: Seleziona tutto

while(!OSCSTATbits.HFIOFR && !OSCSTATbits.HFIOFS){} // wait internal oscillator for ready
OSCCON = 0b11110000;
while(!OSCSTATbits.PLLR){} // wait PLL for ready


[Davide90]

E' un ottima idea , la implementerò, in effetti non ci avevo pensato!

Grazie

[bobina]

Ripensandoci il primo ciclo while è sbagliato, uscirebbe appena l'oscillatore è pronto e non stabile.

Codice: Seleziona tutto

while(!OSCSTATbits.HFIOFR){}
while(!OSCSTATbits.HFIOFS){}


così è meglio

[TardoFreak]

Di solito si mette un limite ai cicli perché il PLL potrebbe anche non funzionare.

[Davide90]

Una volta appurato che il PPL é disponibile e stabile, si manterrà in questo stato per tutta la vita del programma, oppure potrebbe non risultare non disponibile in qualsiasi momento durante l'esecuzione?? In tal caso , quali sono le condizioni che ne determinano la momentanea indisponibilità ? Immagino un calo di tensione e poi cos'altro?

[TardoFreak]

Una volta che è stabile lo è per tutto il programma.
Ha solo bisogno di un po' di tempo per stabilizzarsi.
La timeout serve più che altro per evitare che, magari a causa di un quarzo esterno che non funziona bene, si resti bloccati nell' aspettare una stabilizzazione che non avverrà mai. E' un discorso generale, prima o poi si prende l' abitudine nel farlo perché la sequenza per avere un clock sicuro (parlo di quarzo esterno) è questa:
- Si parte con l' oscillatore interno RC
- Si abilita l' oscillatore esterno
- Si accende il PLL
- Si aspetta che questo sia stabile
- Se tutto va bene si cambia la sorgente di clock collegandolo all' uscita del PLL, altrimenti si lavora con l' RC interno per gestire il malfunzionamento.

[Davide90]

Grazie, veramente utile!!!

[Davide90]

Ragazzi ancora una cosa, secondo voi , settare il ciclo while in questo modo va bene ?

Codice: Seleziona tutto

OSCCON  = 0b11110000; //32 MHz
while(!OSCSTATbits.HFIOFR && !OSCSTATbits.HFIOFS); // attendo che il quarzo interno sia pronto
while(!OSCSTATbits.PLLR);   //Attengo che il PLLR sia pronto e quindi avere i 32mHZ

Tecnicamente il PIC attende che il primo while sia verificato, dopo di che esegue il secondo while, finché rimane verificato, poi, secondo quanto detto da TardoFreak , il PIC non dovrebbe destabilizzarsi.

che ne pensate?

[bobina]

Hai saltato il secondo messaggio in cui dicevo che il primo ciclo while era meglio suddividerlo in 2 while, aspetta prima che l'oscillatore è pronto e poi è stabile al 0,5%. Così appena l'oscillatore interno è pronto passa avanti.
Inoltre TardoFreak ha detto di inserire un eventuale timeout così eventualmente da segnalare l'errore.

[TardoFreak]

Non è obbligatorio farlo, ma è buona abitudine.