__CONFIG

Un microcontroller è progettato per svolgere un consistente numero di funzioni concentrate in un solo chip. 

L' idea di integrare in un unico supporto l' unità centrale, la memoria programma, la RAM e le funzioni di I/O ha aperto la strada alla possibilità di controllare processi di ogni genere con un numero minimo di componenti. Lo sforzo dei progettisti è quello di far si che un solo oggetto di piccole dimensioni possa essere il cuore del maggior numero possibile di applicazioni.  Questo risultato è ottenuto principalmente con l'integrazione di numerosi moduli che possano offrire all' utilizzatore non solo le funzioni di I/O digitale, ma anche quelle di comunicazioni seriali e parallele, di conversione AD e DA, di temporizzazione, PWM, comparazione, ecc.

E' chiaro che i pin del componente non potranno essere usati contemporaneamente per funzioni diverse, per l' impossibilità di accedere nello stesso momento, da parte di differenti moduli, alla stessa uscita fisica.
Per questo, i moduli funzionali sono governabili interamente dal programma, attraverso opportuni registri: possono essere accesi, spenti, configurati a volontà dell' utente durante l' esecuzione delle istruzioni, a seconda delle necessità. 

Però è comune un ulteriore ampliamento della flessibilità di impiego con l' aggiunta di varie opzioni, anche queste definibili dall' utente, che permettono diversi contesti del supporto hardware. Esse sono pensate per variare le risorse di base del componente in modo da potersi adattare meglio alle più diverse configurazioni.  Queste opzioni modificano il comportamento di alcune funzioni nel microcontroller, su cui si baserà il funzionamento del programma;  quindi, devono essere definite, da parte dell' utilizzatore, in un momento ANTECEDENTE all' avvio del programma stesso.

Per capire meglio questo aspetto, consideriamo qualche esempio.

Un modulo timer deve avere la possibilità di essere configurato in modo diverso nelle varie parti del programma. Qui, il microcontroller mette a disposizione dei registri (SFR) specifici e il programmatore, attraverso le istruzioni, potrà avviare il timer, spegnerlo, modificarne i parametri, ecc.
Lo stesso si può dire di un I/O digitale, che può essere ingresso o uscita durante il programma per svolgere le azioni volute.

Per quello che riguarda, invece, un  elemento fondamentale del sistema, come il modo con cui generiamo il clock, la situazione è diversa. Dal clock dipende qualsiasi attività del microcontroller, tra cui la fase di avvio all' arrivo della tensione di alimentazione: se non c'è clock, il processore non si avvia. Questo comporta che, se anche in alcuni casi il programma potrà modificare la frequenza del clock, esso deve essere perfettamente operativo PRIMA dell' arrivo della tensione. Spesso i chip offrono molteplici modi di generazione del clock, interno o esterno, ed occorre che la scelta della giusta opzione NON sia definita nel programma, ma sia predisposta e debba PRECEDERE l' avvio del programma stesso. 
Con un esempio in ambito diverso, se la vostra auto dispone di numerosi tipi di pneumatici opzionali, prima di avviare il motore, dobbiamo scegliere quelli adatti e INSTALLARLI, altrimenti non si potrà certo partire.

Dovrebbe essere ora più chiara la differenza tra il comando via software dei moduli e le opzioni di configurazione del supporto hardware.

• I moduli integrati sono avviabili e comandabili attraverso il programma: l'UART potrà essere utilizzato o meno e quindi è facoltà del programmatore di accenderlo o spegnerlo. Così pure il modulo ADC, i timer, ecc.
• Il supporto hardware su cui si basa il funzionamento del chip, invece, dovrà essere definito PRIMA di avviare il programma: il modo di funzionamento dell' oscillatore del clock dovrà anticipare l' avvio del programma.

Queste opzioni di modifica dell' hardware prendono il nome di CONFIGURAZIONE (Configuration o CONFIG) e, nei PIC (ma in ogni altro microcontroller la situazione è analoga), sono corrispondenti ai CONFIGURATION BITS.

Essi sono raccolti in registri detti Configuration Registers; questi non sono SFR in RAM, ma sono allocati nell' area della Flash, pur non facendo parte della memoria programma. La ragione è evidente: una volta impostata la configurazione, essa deve essere mantenuta anche in mancanza di tensione.
In generale, questi registri non sono previsti per essere accessibili da programma, nè in lettura, nè in scrittura, proprio per la loro particolare funzione, anche se in alcune famiglie di chip questo è possibile.

Va ora compreso che si tratta per la maggior parte di "opzioni obbligatorie". 

Per capire meglio questa obbligatorietà, facciamo riferimento ancora al problema dell' oscillatore: se intendiamo utilizzare un quarzo da 32kHz o da 1 MHz o da 20 MHz, il circuito esterno è grosso modo analogo: due condensatori, forse una o due resistenze, oltre al cristallo. Due pin saranno dedicati a questa funzione, fornendo i gate adeguati a realizzare l' oscillatore voluto. Questa scelta deve essere ovviamente effettuata prima che il programma sia avviato.

Supponiamo di aver deciso di utilizzare un oscillatore a quarzo e, di conseguenza, abilitare questa opzione nella configurazione. Però, è un errore pensare che, semplicemente, collegati questi componenti ai due pin dedicati all' oscillatore, il tutto funzioni come atteso. Non è affatto così, in quanto occorre che i gate interni siano configurati in modo da poter pilotare adeguatamente il cristallo scelto. Un cristallo da orologeria (32768 Hz) richiede una minima energia per il funzionamento, molto minore di quella richiesta da uno a 20 MHz. Se colleghiamo il quarzo low power ad un gate configurato per fare oscillare con sicurezza un quarzo da 20 MHz, otteniamo una oscillazione, ma non sulla fondamentale, bensì su frequenze, anche casuali, 100 o più volte maggiori, con situazioni instabilità che rendono il sistema inutilizzabile. E se cerchiamo di fare oscillare un cristallo da 20 MHz collegando a pin che sono stati configurati per low power, non otterremo alcuna oscillazione, perchè i gate non forniscono l'energia sufficiente. E' evidente, quindi, che se l' oscillatore non è configurato per il giusto hardware, al minimo, non avrò alcun funzionamento del microcontroller, mancando il clock, oppure avrò un funzionamento casuale e irregolare.  Facciamo l' esempio del clock, in quanto è una delle opzioni di configurazione principali, una di quelle più determinanti e che, inoltre, può disporre di un elevato numero di scelte. Tanto per citare, un tipico PIC18F permette almeno 10 modi possibili:

• quattro modi di oscillatore a cristallo, dedicati ad ottimizzare un particolare genere di quarzo o risonatore
• due modalità con RC esterno
• due modi di oscillatore interno
• due modi di oscillatore esterno

E solo uno di questi modi (possibilmente quello adatto alla vostra applicazione...) DEVE essere impostato nella configurazione hardware del microcontroller PRIMA che sia avviato il vostro programma.

Questo lungo preambolo e questa insistenza sul "prima" e sul "deve" è necessario perchè questa possibilità di configurare l' hardware di base del microcontroller e, di conseguenza, le sue opzioni, sono ignorate o misconosciute da una parte troppo grande degli hobbisti che si avvicinano alla programmazione di questi componenti.  Il risultato è una serie di difficoltà e delusioni solo per l' omissione di una semplice riga nel sorgente del programma.  Una volta compresa la funzione di questa configurazione che precede il programma, sicuramente ci si presterà maggiore attenzione.

I Configuration Bits nei PIC

Nei PIC i bit di configurazione sono descritti nel  foglio dati, nella sezione " Special Features of the CPU" .

I bit di configurazione del dispositivo consentono all' utente di personalizzare alcuni aspetti necessari per l'applicazione, dato che il loro stato determina il modo che, quando viene applicata la tensione di alimentazione, il dispositivo utilizza per l' oscillatore del clock, il watchdog, il power timer, il brown out detector e altre opzioni che possono diventare assai numerose a seconda della "complicazione" del chip. 

Essendo tutti i PIC generati dalla stessa idea di base, osservando questi fogli dati, si troverà che anche la struttura dei Configuration Registers è piuttosto simile tra i diversi processori, presentando molte opzioni identiche, alle quali si vanno ad aggiungere tutte quelle che le diverse famiglie e tipi rendono disponibili.
Differenze sensibili si avranno con l' aumento della complessità del chip: dove sono presenti poche funzioni, i bit di configurazione saranno pochi e si avrà una sola Configuration Word che li raccoglie. Per PIC dotati di un elevato numero di opzioni, si avranno più Configuration Words. 

Le opzioni principali, che troviamo praticamente in tutti i PIC, sono queste:

Esistono,  poi, decine di opzioni che dipendono dalle caratteristiche del componente. Eccone alcune:

Va considerato che alcuni chip dispongono di numerose possibilità e possono esserci leggere variazioni nelle label. Ad esempio, si potrà trovare _BOREN, ma anche _BODEN, oppure _WDT e _WDTE P. Particolarmente pasticciata è la situazione delle label relative alle modalità dell' oscillatore, mentre alcune opzioni non hanno la classica scelta _ON/_OFF, ma altre label, ad esempio _CCP2MX che ha le opzioni _PORTBE/_PORTC .

Occorre consultare il foglio dati del componente per definire le opzioni possibili e le label corrette.

Queste informazioni si trovano con semplicità editando il file pxxx.inc relativo al processore utilizzato e che si trova correntemente in C:\Programmi|Microchip|MPASM Suite\.

Per chiarire, esemplifichiamo alcuni casi che rendono bene l' idea.

Prendiamo il classico 16F84: essendo molto semplice, lo è anche nelle sue possibili configurazioni. Inoltre, osservando i modelli successivi, si potrà apprezzare meglio il collegamento tra le prestazioni fornibili e la necessità di espandere le scelte di configurazione, senza però perdere di vista una matrice unica che guida i progettisti dei PIC in un tentativo abbastanza riuscito di consentire un facile passaggio da un modello ad un altro.
Consultando la sezione Special Features of the CPU del foglio dati, troviamo la seguente situazione: 

Il registro di configurazione è unico. Da notare che, come tutte le word della memoria programma per questo tipo di chip, ha una ampiezza di 14 bit. Ogni bit ha una diversa funzione, come indicato nell' immagine qui sopra. In particolare:

Solo queste 4 sono le opzioni della configurazione hardware. Si tratta di elementi di base che ritroveremo in altri PIC, anche più complessi. Il file p16F84A.inc ci consente di trovare immediatamente le definizioni corrette per le label della configurazione

Osserviamo che esistono alias della stessa funzione, come ad esempio quelle relative al WDT, per cui si può usare tanto _WDTE che _WDT  o per l' oscillatore, dove _FOSC_EXTRC è alternativo a _RC_OSC.
Queste equivalenze sono introdotte per la compatibilità con possibili variazioni del testo sorgente.

In realtà, la scarsissima "stabilità" dei termini usati da Microchip a riguardo della configurazione, specialmente per quanto concerne l' oscillatore, ma non solo, possono essere fonte di imbarazzo per il programmatore che si ritrova con segnalazioni di errore del compilatore per "label non definita". Ad esempio:

Le label corrette per quelle dato processore sono quelle indicate nel relativo file .inc.
Volendo utilizzare le stesse label per tutti i vari processori in usao non resta che modificare i .inc o inserire nel sorgente degli equates.

In PIC più complessi di 16F84, come 16F876A le opzioni di configurazione sono maggiori. Anche qui prendiamo direttamente dal foglio dati l' immagine della sezione Special Features of the CPU.

Trattandosi sempre di un PIC della famiglia Midrange, la word di configurazione è ampia 14 bit. 
Qui, però,  la situazione è molto più articolata, dato che il microcontroller ha molte più opzioni del precedente.
Troviamo ancora i bit di controllo del clock, del WDT, del PWRT e della protezione del codice in posizioni che i progettisti hanno cercato di mantenere il più possibile identiche, ma troviamo anche alcune nuove possibilità che non sono presenti nel 16F84A. 
Questa situazione più ampia deriva dalla maggiore quantità di funzioni integrate nel chip, che, di conseguenza, richiede più bit per definirne le opzioni possibili:

Come si vede bene, si tratta sempre di opzioni che vanno decise prima di avviare il programma, in quanto determinano come l' hardware del chip si comporterà successivamente.

Un chip più complesso, come ad esempio il 18F2550, che dispone di un set di funzioni più ampio di quello del 16F876A, avrà un altrettanto ampio set di bit per la configurazione. Anche nel foglio dati di questo processore, esiste la sezione Special Features of the CPU. Osserviamo la sola table 25-1

Vediamo che ben 12 registri a 8 bit, in coppie H-L, sono impegnati dalle opzioni di configurazione ! Inoltre, altri due registri sono dedicati al Device ID Register. Osserviamo che nella famiglia PIC18F le words della Flash sono a 16 bit : per le Configuration Words sono utilizzati solo i primi 8.

Non scendiamo nel dettaglio delle funzioni, dato che le informazioni relative sono facilmente deducibili dal foglio dati e che varie voci richiedono una conoscenza dettagliata delle caratteristiche di quello specifico microcontroller.  Diciamo che anche qui troviamo i bit delle opzioni di base visti per i due PIC precedenti, ai quali si aggiungono numerosissimi altri relativi alle caratteristiche proprie della famiglia 18F (alcuni dei quali presenti anche nei più recenti Enhanced Midrange), oltre a funzioni esclusive del chip, come il port USB. Possiamo riassumerli:

• bit di controllo delle molteplici modalità di clock, che espandono le poche presenti nei PIC visti prima. Qui sono presenti un oscillatore interno configurabile su vari modi, oltre a un PLL e ad una complessa struttura di scambio delle sorgenti di clock e di gestione di sicurezza dello stesso 
• bit di assegnazione del valore di soglia del BrownOut Detector, che è programmabile in un range abbastanza ampio 
• impostazione del WDT che dispone di un postscaler che estende a tempi estremamente lunghi l' azione del watchdog 
• la possibilità di definire MCLR come un I/O 
• la possibilità di definire l' energia del gate dell'oscillatore esterni di Timer1 
• il re indirizzamento delle uscite del modulo CCP 
• la possibilità di usare il set esteso di istruzioni e di modi di indirizzamento, dedicati principalmente ai compilatori C 
• la possibilità di abilitare un reset per un errore di gestione dello stack 

Anche le protezioni da lettura/scrittura si amplificano in una serie di possibili scelte che definiscono aree e modalità particolari.
Per contro, PIC minimali, come i Baseline, hanno registri di configurazione altrettanto ridotti. Ad esempio, PIC10F200: sono disponibili solo 3 opzioni.

Per ogni altro PIC che vi trovate in mano, il foglio dati vi chiarirà la funzione dei Configuration Bits. 

__CONFIG

Come metto in pratica tutto questo?  Innanzitutto va detto che: 

• nei PIC l' idea guida è che i registri di configurazione siano accessibili solo all' atto della programmazione del chip, proprio perchè riguardano impostazioni che non vanno modificate durante l' esecuzione del programma. Negli Enhanced, volendo, si può accedere a questi registri, ma, evidentemente, è una operazione che può assumere aspetti molto critici, in quanto modifica le risorse su cui si basa l' esecuzione del programma. 
• ne deriva che i registri di configurazione, in gran parte dei chip sono accessibili solamente durante la fase di programmazione, e la loro scrittura dipende da quanto scritto nel sorgente o impostato nell' ambiente di sviluppo.
• nei Midrange tipicamente il registro di configurazione si trova all' indirizzo 2007h, che è al di fuori dell' area accessibile dal programma. Nei PIC18F i registri di configurazione sono situati nell' area a partire da 30000h, anch' essa al di fuori dell' area della memoria programma.
• si tratta comunque di un' area di Flash, il cui contenuto permane anche se non è applicata la tensione di alimentazione

Per quanto riguarda il sorgente, la Configuration Word viene modificata semplicemente usando uno statement _CONFIG, accettato da tutti i linguaggi in forme più o meno simili, inserito nel teso del sorgente. 

I compilatori (Assembly, BASIC, C e qualsiasi altro), durante il loro lavoro creano il file .hex che il dispositivo di programmazione copierà nel chip. Senza entrare in dettagli, che potete trovare qui, il file hex è organizzato in modo da fornire al dispositivo di programmazione i byte da scrivere nella memoria del chip, ma anche DOVE questi vanno scritti. Per cui si scriveranno di certo gli hex degli opcodes nella memoria programma, ma si potrà scrivere anche nell' area della EEPROM e quella parte di Flash in cui stanno i registri di configurazione e quelli di identificazione (ID).

Per renderci conti direttamente di come quanto detto sia determinante per i risultati pratici, vediamo cosa succede a compilare due sorgenti, diversi solo perchè il primo non contiene alcun CONFIG mentre il secondo sì.

Se osserviamo, la differenza consiste solo nella penultima linea, dove si dice al dispositivo di programmazione di scrivere 3D32h all' indirizzo 2007h.

La sintassi della direttiva è semplice:

__CONFIG  non deve essere in prima colonna ed è iniziata con una doppia sottolineatura, cosa riservata solamente agli elementi propri dell' Assembler.
<expr>  può essere una qualunque espressione adeguata.

Quale è stato l' effetto della direttiva __CONFIG sul compilatore? 

Il senso vero è proprio della direttiva è quello di mettere nel file hex quanto indicato nell' espressione in modo tale che sia programmato nel Configuration Register del chip che si sta usando.

Essa fa si che il compilatore interpreti l' espressione e costruisca il byte o i bytes adatti per il processore definito, creando nell' .hex i giusti valore esadecimali. Quindi la direttiva è legata al modello di chip dichiarato nel sorgente o nell' ambiente di sviluppo e dai files .inc e .lkr relativi (messi a disposizione dall' Assembler) ricavi quanto necessario alla compilazione.

Quale è l' effetto sul dispositivo di programmazione ? 
Come abbiamo visto nella tabella precedente, è molto importante capire che, in ogni caso, il dispositivo di programmazione scrive solamente i bytes indicati nella lista .hex. Quindi, nel secondo caso scriverà il Configuration Register, ma nel primo caso NON scriverà nulla in questo registro (dato che non appare nella lista). 
Ne deriva che, nel secondo caso, i Configuration Bits sono impostati come indicato nel sorgente, ma nel primo caso essi sono lasciati intatti nella situazione in cui si trovavano in precedenza. Ovvero tutti a 1 se il chip è stato cancella integralmente; al valore programmato nell' esperimento precedente se la memoria non è stata integralmente cancellata.

Sicuramente lo stato "tutti a 1" o "tutti a 0" ben difficilmente è adeguato ad una qualsiasi applicazione reale. Quindi:

il trascurare i bit di configurazione è un grave errore

perchè il PIC, privo di configurazione adatta, probabilmente non parte neppure.

Una nota: la linea __CONFIG non impegna alcuna risorsa nell' esecuzione del programma e nella compilazione occupa microsecondi per essere sistemata: l' ometterla non porta certo vantaggi.

Pratiche da evitare

Attorno alla non conoscenza delle funzioni dei bit di configurazione, sono nate diverse pratiche che vanno decisamente abolite, in quanto se non auto-dannose, per lo meno insensate.

1. Ignorare la necessità della configurazione.
   A parte la non conoscenza dell' argomento, questa stupidaggine deriva, purtroppo, dal copiare programmi sul WEB. Si tratta evidentemente di spazzatura. Infatti, se torniamo ad osservare il registro di configurazione del 16F84, protagonista spesso di queste mistificazioni, vediamo che una configurazione non eseguita lascia tutti i bit a 1 ottenendo:
   - protezione del codice disabilitata, che per le prove va bene
   - PWRT disabilitato, che può essere accettabile
   ma:
   - WDT abilitato, che non va affatto bene perchè se il programma non lo gestisce, ne renderà impossibile il funzionamento
   - oscillatore RC, che non va certo bene per il solito quarzo da 4MHz.
    
2. Inserire la configurazione come numero esadecimale. 
   Ad esempio:
      __CONFIG 0x3FF1

   questa modalità è accettata dal compilatore in  quanto l' espressione che accompagna la direttiva viene considerata un valore valido e copiata nel file .hex. E', però, una stupidaggine, tra l' altro molto comune. Perchè stupidaggine? Semplicemente perchè chi sa dire, senza consultare il foglio dati, quale è la configurazione che corrisponde a quell' esadecimale?
   La configuration word in esadecimale non è per niente chiara e non è neppure gestibile con facilità essendo un valore assoluto. Non si sarebbe certo perso maggior tempo a scrive invece, usando le label che i file di riferimento dei processori mettono a disposizione:
   
   __CONFIG _CP_OFF & _HS_OSC & _WDT_OFF & _PWRTE_ON
   
   da cui chiunque rilegga il sorgente può comprende come il chip sia configurato. E non ha nessun valore dire che "il testo è più lungo e perdo temo a scriverlo". Se siamo ridotti così male, basta scrivere le configurazioni comunemente usate in un qualsiasi foglio di testo e passarle con il copia-e-incolla all' editor del sorgente.
   Ovviamente, se sto copiando da internet un esempio e non mi interessa capire cosa sto facendo, l' esadecimale è la conseguenza obbligata. Tutto dipende da cosa volete essere e fare.
    

3. Definire la configurazione nel software del programmatore o nell' ambiente di sviluppo. 
   Entrambi i metodi derivano da situazioni di decenni fa, quando ancora si programmavano le EPROM con banchi di interruttori. Oggi, un compilatore deriva dalla linea di__CONFIG , o altra forma equivalente, il giusto .hex. 
   Se questa linea è stata scritta nel sorgente, entra a far parte della documentazione immediatamente accessibile. A distanza di tempo chiunque potrà  programmare correttamente quel chip per quel firmware, avendo il sorgente in sè, come documentazione, tutti i parametri necessari. 
   Se lascio la configurazione nell' ambiente di sviluppo, non ne ho alcuna documentazione e distanza di tempo neppure io posso ricordare come diavolo era la configurazione corretta; devo disporre dell' intero progetto e del suo ambiente di sviluppo.
   Ancora peggio è il fissare la configurazione nel software che comanda il dispositivo di programmazione: in questo caso, chiusa la sessione di programmazione, i dati di configurazione sono persi. Occorre leggere e decodificare il file .hex per recuperarli.
   Questa pessima pratica non è tutta colpa degli utenti, in quanto vari ambienti di sviluppo hanno la "facility" dell' impostazione dei bit di configurazione in uno dei menù; questo evita a chi scrive il programma di inserire la configurazione nel sorgente.  Però, questo "facilitare" è un falso senso di supporto al programmatore, il noto "easy", dove l'utente però perde il contatto con la realtà dell' hardware su cui vuole lavorare.  "Easy" dovrebbe essere il rendere facile l' impiego di un qualcosa di tecnologico, non il far si che l' utente possa usarlo senza l' obbligo di capire qualcosa di quello che sta facendo! E questo, importante in ogni ambito, in relazione ai microcontroller è particolarmente significativo in quanto non è possibile utilizzare compiutamente uno di questi chip senza avere una sufficiente conoscenza di quali sono le sue caratteristiche.
   La scelta di inserire i bit di configurazione nel testo del sorgente consente di averne coscienza, mentre  lascia al compilatore il carico di metterli al giusto posto.
   Nei casi in cui l' unica soluzione per la configurazione è quella fornita dall' ambiente di sviluppo, che non accetta altre vie, è buona norma indicare comunque nel sorgente come è stata definita questa configurazione, sotto forma di una linea di commento; in questo modo il sorgente è documentazione completa, mentre se non si facesse questo, si dovrebbe disporre dell' intero progetto con il suo ambiente per avere tutti gli elementi necessari a programmare il chip.
    
4. Configurare solo una parte dei bit. 
   Anche questa non è una pratica molto esatta: se programmo solo una parte dei bit, chi assicura che i rimanenti siano al livello che serve per l' applicazione?  Certamente la situazione di alcune opzioni può essere ininfluente su lavoro in corso, come ad esempio le protezioni da rilettura del codice, ma, programmando tutte le opzioni, ho due vantaggi:
   - so con certezza la situazione desiderata
   - conosco tutte le possibili opzioni.
    E, in caso di dubbio, la linea _CONFIG mi dice immediatamente come ho configurato il processore e posso verificare se c'è un errore e correggerlo in un istante. 

Nel merito del __CONFIG

La linea tipica del __CONFIG appare, a prima vista, quanto mai criptica:

__CONFIG _CP_OFF & _HS_OSC & _WDT_OFF & _PWRTE_ON

ma, seguendo quanto detto ora, dovrebbe essere chiaro il suo significato. Non è qualcosa che si deve sapere a memoria senza comprenderne il principio.

Se editiamo il file p16F84.inc troviamo una lista di label realtive a bit e registri, che associano all'abbreviazione mnemonica il loro valore o indirizzo esadecimale. In questa lista sono presenti anche le label delle opzioni possibili per la configurazione, ognuna con il relativo equivalente esadecimale. 

Vediamo nella tabella qui sotto quelle relative al 16F84, assieme al corrispondente patter binario dei soli primi 4 bit (LSB). Gli altri, non usati, sono tutti a 1; solo attivando la protezione da rilettura _CP_ON  si vanno a toccare questi rimanenti bit più alti:

Quindi, in sostanza, _CP_ON, _PWRTE_OFF, ecc. sono solo ed esclusivamente label pre definite. 

Al limite, potrei anche modificare l'.inc cambiandole in 

_ATTIVAPROTEZIONE            EQU H'000F'
_NOPERDITEMPOALLAVVIO  EQU H'3FFF'

e simili.
Per ognuna di esse una direttiva equate (EQU, cioè =) assegna una valore esadecimale, il che vuol dire semplicemente: se indico la situazione di _LP_OSC, i bit 1 e 0 vanno a livello 0. Per _WDT_OFF il bit 3 è a zero. E così via. Ricordiamo che i bit non programmati della flash sono a livello 1, quindi l' azione del dispositivo di programmazione consiste nell' agire solo su quelli che vanno a 0. 

La linea tipica del CONFIG

__CONFIG _CP_OFF & _HS_OSC & _WDT_OFF & _PWRTE_ON

quindi, non è nient' altro che una direttiva dell' Assembler seguita da una espressione che è costituita da una catena di AND e  che dice al compilatore le seguenti cose:

• fai il prodotto logico (AND, caratteri & nella linea, che indica un AND bitwise) dei valori corrispondenti alle label indicate 
• metti il risultato nell' hex in modo che vada a finire nel registro di configurazione 

In pratica la lunga stringa di label è semplicemente una catena di AND (&), del tutto analoga all' aver scritto:

 (_label1 & _label2 & _label3 & _label4)

Una label, ricordiamo, è solamente un simbolo che sostituisce un valore numerico. Se si trova "strana" una label che inizia con _, va detto che questo è del tutto normale: l' Assembler MPASM consente questa scrittura.  Solitamente la scelta di scrivere _label piuttosto che labell serve ad identificare che non si tratta di una label generica, ma di qualcosa di particolare o riservato. In effetti, le label definite nei file .inc o nelle librerie, come gli opcodes, sono riservati e non sono utilizzabili altrimenti che per il loro senso. 

Quindi, il risultato dell' AND è un valore numerico. 

risultato_logico = (_ label1 & _ label2 & _ label3 & _ label4)

e sarà uguale al prodotto logico eseguito dalla catena di AND.
In altre parole, la linea della direttiva ordina al compilatore di prelevare dal file di definizione del processore i valori equivalenti alle label indicate (consideriamo qui sempre solo i primi 4 bit, che sono tutti a 1) e di eseguirne l' AND:

quindi, il compilatore calcolerà come risultato la word 11111111110001b = 3FF1h , che carica nella locazione 2007h. 
Come fa a sapere che è proprio lì che va il risultato? Semplicemente perchè, per quel dato processore, il compilatore associa __CONFIG alla giusta locazione di memoria da programmare. Per un diverso processore, è possibile che la destinazione sia diversa oppure che il risultato vada diviso su vari registri di configurazione, tutte azioni che il compilatore svolge in automatico.

Perchè, quindi, fare a mano calcoli col rischio di sbagliare se, automaticamente e senza fatica, il compilatore fa da sè?   Oltre tutto, stiamo esemplificando il PIC con la configurazione più meschina. Pensate al lavoro manuale per calcolare i pattern in un 18F con 10 o più registri.

Cosa non è il __CONFIG

1. Il __CONFIG non è una opzione trascurabile.
2. Non è una istruzione del processore. 
3. Non viene eseguito durante il programma. 
4. Non occupa memoria programma. 

Il __CONFIG è, semplicemente, una direttiva dell' Assembler che fa agire il compilatore come abbiamo visto qui sopra.

Il CONFIG in ambienti diversi

Uno statement di config è accettato in frme diverse da quasi  tutti i compilatori, ma va da se che ognuno potrà avere le sue preferenze sulla forma in cui esprimere le selezioni. Ad esempio in C18 è comune una struttura del genere:

#pragma config OSC = HSPLL
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config PWRT = ON

che fa uso di #pragma. MPLAB C18 (ver. 2.30) permette:

#pragma romdata CONFIG
 _CONFIG_DECL (_CP_ON_1L,
        _OSCS_ON_1H & _OSC_LP_1H,
        _PWRT_ON_2L & _BOR_OFF_2L & _BORV_42_2L, 
        _WDT_OFF_2H & _WDTPS_1_2H,
        _CCP2MUX_OFF_3H,_CONFIG4L_DEFAULT);

Altre situazioni possono accettare diverse strutture. Ad esempio l' Hitech:

  __CONFIG(XT & WDTEN & PWRTEN & BOREN & UNPROTECT)

 o il C30:

__FOSC(CSW_FSCM_OFF & XT_PLL16);

In Microchip XC8, & diventa una virgola:

#pragma config MCLRE=ON, CP=OFF, BOREN=OFF

ma è possibile pure scrivere:

__CONFIG (MCLRE_ON & CP_OFF & BOREN_OFF)

Un Basic può usare linee simil-Assembly precedute dal simbolo @ e che comprende la specificazione del PIC a cui è diretto il risultato:

@ device pic16F877, hs_osc, wdt_on, pwrt_on, lvp_off, protect_on

In ogni caso, una consultazione della documentazione del linguaggio usato permette di verificare quali sono le forme accettate per il settaggio dei bit di configurazione.

Da notare, come è molto chiaro nell' ultimo esempio, che la configurazione è legata al modello di PIC utilizzato. Questo è indispensabile perchè, come abbiamo visto, ogni PIC o famiglia di PIC ha risorse diverse, quindi necessita di configurazioni adeguate.

Ma devo proprio sapere cosa fanno i bit di configurazione per usarli ?

Sfortunatamente si. Un problema gravissimo è che molti sanno qualcosa, o anche molto, di un linguaggio, BASIC o C, ma a conoscenze di elettronica siamo a zero. Nell' usare i microcontroller embedded ci troviamo di fronte a problemi ben diversi da quelli dati da un gestionale. Questo lo risolvo a tavolino, con le librerie del linguaggio e quelle del sistema operativo, che "ci pensano loro" a maneggiare i bit necessari alla presentazione a video o alla interrogazione del disco.
Nel programmare un microcontroller, anche usando le librerie fornite dal linguaggio, posso prescindere da una conoscenza dettagliatissima dell' hardware, ma devo comunque averne una certa conoscenza. E' come se, usando DLL e librerie facessi fare il lavoro ad un' altro, limitandomi ad una attività direttiva-organizzativa, ma, nel momento in cui il lavoro manuale devo farlo io, occorre che abbia almeno idea del come farlo.
Questo non vuol dire che si debba diventare super esperti, ma che si abbia almeno una visone di insieme di cosa posso o non posso fare al chip e come.

Oltre ad una lettura, almeno generica, del foglio dati, una via semplice per chi inizia, è quella di usare un template. Dal template abbiamo in ogni momento disponibile l' intera gamma delle selezioni possibili. Copiandolo nel sorgente e decommentando le linee scelte (e anche cancellando quelle inutili), abbiamo un valido mezzo per evitare errori. 

FAQs

Perchè è meglio non usare la configurazione offerta dall' ambiente di sviluppo ?
Un codice sorgente è fatto per funzionare con una ben precisa configurazione hardware.
Se cambi la config word, nella maggior parte dei casi ottieni un sistema non funzionante o, nel caso migliore, malfuzionante.
Quindi è concettualmente sbagliato tenere come cose separatele programma e configuration bits: i due sono interdipendenti.
Inoltre se oggi scrivo un programma so perfettamente quale config devo metterci per farlo funzionare e posso anche impostarlo nel software del programmatore o nell' ambiente di sviluppo. Ma se riprendo in mano il sorgente dopo qualche tempo, come posso pensare di ricordarmi cosa ho impostato in quella particolare circostanza? Peggio ancora, se lo passo ad un' altra persona.
Dovrei passare l' intero progetto e potrei ricreare la situazione solo nello stesso ambiente (se ho usato l' ambiente di sviluppo. Se ho impostato i bit di configurazione nel software del programmatore, non ne ho alcuna traccia, se non decodificando l' .hex... ).
Non è più semplice avere la configurazione nel sorgente?
Dove non c'è alternativa al menù dell' ambiente di sviluppo, si deve inserire nel sorgente una linea di commento che descriva la configurazione applicata a quel progetto.

La riga di config è abnorme: non c'è modo di ridurla?
Pienamente d'accordo che una linea del genere

__CONFIG _CP_OFF & _DEBUG_OFF & _WRT_ENABLE_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _PWRTE_ON & _WDT_OFF & _HS_OSC

è un po' fuori dal normale. Ma più sono le opzioni che configuro, più la linea si allunga (e non si può mandare a capo con un return, che spezzerebbe la catena degli AND). 

Se la riga offende il vostro gusto estetico, o, semplicemente, è difficile da leggere, ricordando di cosa si tratta, possiamo spezzarla in due parti: 

CONFIG_A  = (_CP_OFF & _DEBUG_OFF & _WRT_ENABLE_OFF & _CPD_OFF)
CONFIG_B  = (_LVP_OFF & _BODEN_OFF & _PWRTE_ON & _WDT_OFF & _HS_OSC)

  __CONFIG CONFIG_A & CONFIG_B

Per comprendere come funziona, basta considerare che CONFIG_A  e CONFIG_B sono due label a cui è assegnato il valore dell' AND delle relative espressioni.  __CONFIG  ha come espressione l' AND dei due valori precedentemente definiti.

Dove possibile, meglio, ricorre alla modalità a linee singole consigliata da Microchip, lunga in verticale, ma più leggibile:

  CONFIG  CP    = OFF
 CONFIG  DEBUG = OFF
 CONFIG  WRT   = OFF
 CONFIG  LVP   = OFF     
 CONFIG  CPD   = OFF
 CONFIG  BODEN = OFF
 CONFIG  WDT   = OFF 

Nell' ambiente dei vari linguaggi, si potranno adottare scritture analoghe o saranno disponibili altre modalità di scrittura. Ulteriore possibilità è quella di scrivere il config in un file esterno ed includerlo nel sorgente.


Uso per abitudine il valore esadecimale: non posso mettere un commento esplicativo?
Una cosa del tipo in tabella qui sotto ?

;Setup configuration bits
;XT oscillator, Disable WDT, Enable PWRT, Disable CP

  __CONFIG    0x3FF1

Così non cambia nulla! Quale è la relazione tra il valore esadecimale e le varie opzioni della configurazione?
Anche col commento, non lo posso capire senza avere davanti il foglio dati. 
E se devi cambiare una impostazione, ad esempio disattivare il PWRT, come fai? Devi consultare il foglio dati per sapere quale bit toccare, quindi ricalcolare l' hex... Assurdo.
Se per rendere chiara la configurazione hai bisogno di aggiungere i commenti, allora perchè non scrivere direttamente la configurazione in forma estesa con le opportune keyword?
Basta osservare che se scrivessi:

__CONFIG _CP_OFF & _HS_OSC & _WDT_OFF & _PWRTE_ON

C'è un senso nel fatto che alcuni bit vadano a 1 e altri a 0?
In generale, sì. Le corrispondenze tra stato dell' opzione e il relativo valore del bit non sono casuali, ma seguono una precisa linea guida.
Dato che il configration register, se vuoto, ha tutti i bit a 1, i progettisti hanno cercato di assegnare al valore 1 tutte le scelte ottimali per il default, che, normalmente,  tendono a minimizzare la corrente assorbita. Così si arriva alla impostazione dei port come ingressi analogici; quindi, dove il port permette questa opzione, essa è il default, con il bit a 1. Per disabilitarla occorrerà mettere il bit a 0. Altrettanto per il Power On Timer (PWRT) che potrebbe non essere necessario in molte applicazioni e quindi è disabilitato con il bit a 1. Ancora, si nota che la protezione da rilettura è abilitata con il bit a 0, per evitare di trovarsi per default con la protezione attivata. E così via. Si potrà essere poco d'accordo con alcune scelte, ma questo è generalmente dovuto al fatto che le nostre applicazioni non ne fanno uso e ci risulta scomodo dover pensare sempre a modificare default che, a volte, sono vere trappole per l' utente inesperto, come appunto i port analogici o i comparatori attivi. 
Però va compreso che le scelte dei progettisti, anche se soggettivamente opinabili, sono fatte in base a considerazioni più generali. E, d'altronde, alcune sono inevitabili. Ad esempio, nei chip vergini, dove esiste la possibilità della programmazione LVP, essa è attiva per default, altrimenti non sarebbe possibile utilizzarla al primo uso (mentre è possibile cambiarla in HVP con la prima programmazione HVP).

Ho il config nel sorgente. Posso scavalcare la selezione dall' ambiente di sviluppo?
Solitamente si. Ad esempio, MPLAB, nelle opzioni dei dispositivi di programmazione permette di scegliere se la configurazione arriva dal sorgente oppure è impostata manualmente. Però ogni modifica apparirà nell' .hex, ma non nel sorgente. Per una documentazione completa devo trasmettere o conservare l' intero progetto e il suo ambiente.

Il compilatore segnala un errore nella configurazione...
In genere questo è dovuto alla scelta sbagliata delle label delle opzioni, che possono essere leggermente diverse in diversi PIC. 
E, tra l' altro, possono anche essere diverse da ON o OFF. 
Ad esempio, la pre assegnazione di PORTB a funzione digitale (è analogica per default nei PIC18F), potrebbe essere definita con PBADEN=DIG. Così pure le selezioni dell' oscillatore sono label diverse da ON e OFF.
Inoltre è possibile che le label siano leggermente diverse anche da compilatore a compilatore. Ad esempio, MCLR_OFF in PM diventa MCLRE_OFF quando si utilizza MPASM.
E' fondamentale che la configurazione scelta non solo si adatti alle aspettative del programma, ma sia anche adeguata al processore usato, dato che diversi processori possono avere diverse risorse e quindi configuratori diversi.
La documentazione del componente o il file .inc relativo permettono di individuare la giusta scrittura.

Che differenza c'è tra OTP, chip windows e Flash?
Un bit OTP, una volta programmato a 0, non può più essere modificato. 
Un chip con finestra, ad esempio una EPROM, può essere scritta, ma va cancellata esponendo la finestra ad una luce UV particolare. 
In una Flash, invece, il bit può essere cancellato e riscritto a piacere alla tensione di alimentazione.

Cercando di leggere un PIC, si ottengono tutti 0. E' guasto?
Non necessariamente. E' possibile che sia guasto, ma è anche possibile che la memoria programma sia protetta alla rilettura. In questo caso il software del dispositivo di programmazione dovrebbe avvisare della protezione attivata.

La protezione da rilettura attivata può essere rimossa?
Si, ma occorre cancellare i configuration bits, cosa in questo caso possibile solo cancellando tutto il chip (appunto perchè si tratta di una protezione che impedisce l' accesso al codice dall' esterno per evitarne la copia)

Fuses? No, grazie.

Nei PIC F, dove F sta per FLASH, la memoria programmabile è realizzata in questa tecnologia e può essere scritta e cancellata e riscritta a volontà. 

NON ESISTE PIU' ALCUN "FUSE" !!!

I fuses erano le strutture di programmazione degli OTP, che venivano letteralmente bruciate durante la programmazione (e quindi non erano riprogrammabili).
Definire "fuses" i bit programmabili in flash è, per lo meno, indice di superficialità, se non di ignoranza dell' argomento. Nel secondo caso non si ha se non una vaga idea di quello che si maneggia (e quindi, come lo si può maneggiare correttamente?). Nel primo caso non si fa che replicare una terminologia recepita, ma non digerita.  Sfortunatamente, la colpa non è tutta attribuibile all' hobbista o al redattore di pagine sul WEB, ma è, per prima, di vari professional e ambienti di sviluppo che utilizzano a sproposito il termine "fuses" per mantenere una "tradizione". 
Questo non è un peccato capitale, ma è fortemente fuorviante e fa si che, anche se riconoscessimo l' esistenza dei Configuration Bits, fino a che non ci rendiamo conto della loro funzione, si tratterebbe sempre di "fuses", parola usata per fare "tendenza" e non perchè corrisponde a realtà.
Di conseguenza, si finisce per cercare "fuses" dove non li possiamo trovare, perchè non esistono e il costruttore, nella sua documentazione, ovviamente non può citare, dato che chi sa di cosa sta parlando tenderà a non utilizzare termini impropri, anche se "tradizionali".