Grazie Max per i chiarimenti e quel frammento di codice; è proprio quello che mi serviva.
Riguardo alla confusione, per fortuna, è molta di più quella che riesco a fare nei messaggi che scrivo, rispetto a quella che ho veramente in testa che, comunque, basta da sola e avanza !
Se questo fosse utile per le prossime volte, sto utilizzando il 16F1847.
Ho una mia idea che sto sviluppando, alla quale sono riuscito a dare un notevole sviluppo, grazie al brutto tempo di questo ponte-fine-settimana, che mi ha costretto in casa e ai tuoi consigli e a quelli di Mauro. Per questo non mancherò di condividere i risultati.
La mia idea è generata da una necessità alla quale non posso rinunciare nei miei progetti: quella di avere a disposizione una base dei tempi che non intralci l'esecuzione del programma, scartando a priori un orologio-periferica.
Sono a buon punto e ti farò sapere.
Intanto ti anticipo che utilizzo, insieme, la funzione SLEEP e le inturrupt generate da EUSART e dai registri del timer interno. Il programma resta dormiente, inattivo e parsimonioso (consuma poco) per la stragrande maggioranza del tempo, per poi svegliarsi con la necessità di utilizzare fino a 10 temporizzazioni simultanee.
La base dei tempi ha un periodo MOLTO più lungo di quello della frequenza di esecuzione, tanto da non incidere sui tempi di esecuzione, ma non superiore a 1 decimo di secondo, poiché determina anche l'errore massimo che avranno le temporizzazioni generate. La necessità di avere una base dei tempi non decimale, determina 3 sole opzioni di periodi utilizzabili: 1 decimo, 1 centesimo, 1 millesimo di secondo.
Lo stato di SLEEP, inoltre, consente anche la dormienza del generatore della base dei tempi.
Non ho ancora provato l'aìharware ed ho un dubbio: nel datasheet del 16F1847, relativamente al clock nello stato SLEEP, è scritto:
"Un circuito oscillatore 32,768 kHz dedicato a bassa potenza è INCORPORATO trai pin T1OSI (ingresso) e T1OSO (Uscita). Questo circuito interno deve essere utilizzato in collegamento con un cristallo esterno 32,768 kHz.
L'oscillatore continuerà a funzionare durante SLEEP"
Cosa vuol dire ? Forse che la circuiteria dell'oscillatore è INCORPORATA ma necessita del quarzo esterno ???
In poche parole, questa frequenza c'è, o bisogna mettere il quarzo esterno tra T1OSI (pin RB6) e T1OSO (pin RB7) ???
Fino a qui ho tutto chiaro e quasi già fatto, devo però risolvere un problema non da poco.
Lo stato di SLEEP, se ho compreso bene, impedisce la ricezione dei dati dalla porta EUSART (RB1 nel 16F1847), che non può generare nessun interrupt fintanto che permane lo stato di SLEEP. Il problema è: chi mi sveglia la EUSART ?
Per il momento, ho pensato di risvegliarla con una chiamata da un altro ingresso della PORTB, capace di risvegliarla da SLEEP. Ma questa chiamata non è "standard" per i dispositivi che utilizzano la trasmissione dati da ricevere.
Le mie conoscenze a riguardo sono limitate e posso solo immaginare e sperare. Ad esempio ipotizzo 2 condizioni:
- un tipo di sequenza seriale alla EUSART che, almeno, non debba arrivare OBBLIGATORIAMENTE DOPO il risveglio da SLEEP, seguendo la logica del "prima memorizza, che poi qualcuno leggerà";
- l'utilizzo del clock interno a 32KHz capace di pilotare EUSART in SLEEP, durante la quale è attivo il clock a 32KHz.
Hai qualche suggerimento da darmi in proposito ?
