Corso sui microprocessori e microcontrollori., Ovvero come i componenti elettronici possono fare miracoli.

4°PUNTATA

Come già scritto in precedenza il microcontrollore all'accensione deve essere resettato per avviare correttamente il programma.
La procedura di reset può essere automatica, nel senso che il microcontrollore può essere già dotato di circuito di accensione con reset incorporato.
Il PIC ha diversi sistemi di reset:
1)Power on reset che lo resetta all'accensione
2)Brown-out reset che lo resetta quando la tensione di alimentazione scende al disotto di un certo valore. Questa funzione è utile per evitare che durante le fluttuazioni della tensione di alimentazione il PIC faccia qualcosa di inaspettato, per esempio andare a sovrascrivere dei dati importanti, infatti appena la tensione scende ad un valore in cui il PIC potrebbe ancora funzionare, ma rischiando di non essere affidabile, scatta la condizione di reset che blocca il programma e lo rende bloccato fino a quando la tensione non sale nuovamente ad un valore accettabile.

Il reset può avvenire anche attraverso il collegamento del piedino di reset (chiamato MCLR) al negativo dell'alimentazione (VSS del PIC). Anche in questo caso appena il pin MCLR torna a livello logico 1 il program counter riparte dall'indirizzo 0.

L'ultimo blocco della figura sovrastante è rappresentato da 8 level stack.
Lo stack è presente in tutti i microprocessori/microcontrollori ed è una memoria speciale chiamata FILO (first input last output), ovvero una memoria in cui l'ultimo dato immesso è il primo ad uscire.
Lo stack ha diverse importanti funzioni:
1) Permette di memorizzare l'indirizzo di partenza quando il programma interrompe il suo normale flusso e va a gestire blocchi di programma particolari (questo concetto verrà ripreso in seguito).
2) Permette di depositare dei dati temporanei per poi poterli riprendere in seguito. Nel caso di utilizzo di linguaggi come il C lo stack viene spesso usato per memorizzare le variabili locali.

Il punto 1 si riferisce alla gestione delle cosiddette subroutines (sottoprogrammi).
Che cosa sono le subroutines?
Immaginiamo di avere, all'interno del programma, alcune parti che si ripetono o che devono comunque essere usare più volte (es. tutte le istruzioni necessarie a fare apparire una scritta sul display).
Il modo più banale per risolvere la questione sarebbe quello di ripetere la parte di programma adibita all'invio di un testo al display per ogni volta che occorre modificare il messaggio visualizzato.
Questa procedura impiegherebbe un'enorme quantità di memoria programma, dato che i messaggi potrebbero essere variati spesso ed ogni volta occorrerebbe riscrivere le stesse N istruzioni necessarie per l'aggiornamento.
Per evitare queste ripetizioni è prassi consolidata ricorrere alle cosiddette subroutines. Cosa sono esattamente?
Nel nostro esempio precedente abbiamo ammesso di dovere inviare il messaggio al display. Ebbene se tutte le istruzioni necessarie a questo invio vengono racchiuse in una subroutine sarà possibile richiamarle da più punti del programma; a tale proposito esistono, in assembler, 2 istruzioni specifiche per la loro gestione: CALL e RETURN.

Come funziona il tutto?

100 xxxxxx
101 xxxx
102 xxxxx
103 CALL VisualizzaMessaggio ("Ciao a tutti")
104 xxxxxx
105 xxxx
106 xxxxxxxx
107 CALL VisualizzaMessaggio ("Io sono un PIC che scrive messaggii")
108 xxxx
109 xxx
110 xxxxxx
111 xxxxx



VisualizzaMessaggio
210 xxxxx
211 xxxx
212 xxxxxxx
213 RETURN

Ebbene le righe con xxxx si riferiscono alle varie istruzioni che compongono il programma. Il PIC prosegue ad eseguire le varie linee, partendo dall'indirizzo 100, e arriva all'indirizzo 103 dove trova l'instruzione
CALL VisualizzaMessaggio ("Ciao a tutti").
Il PIC memorizza ora il valore del program counter attuale+1 (ovvero 104) nello stack, poi porta il program counter a 210, dove trova la prima istruzione della sequenza necessaria alla scrittura del display.
Prosegue poi ad eseguire le istruzioni: 211, 212, 213. Quando il PIC eseguirà l'istruzione RETURN andrà a prelevare dallo stack il valore precedentemente memorizzato (ovvero 104) e lo memorizzerà nel program counter che riprenderà l'esecuzione da dov'era partito precedentemente.
L'esecuzione proseguirà fino a quando, all'indirizzo 107, troverà CALL VisualizzaMessaggio ("Io sono un PIC che scrive messaggii").
Anche in questo caso il pic salverà l'indirizzo seguente nello stack (ovvero 108) e salterà nuovamente all'indirizzo 210 dove c'è la subroutine di aggiornamento del display.
Anche in questo caso il RETURN porta al ripristino del program counter (che ora avrà valore 108, per poi proseguire con l'esecuzione del programma.

Il PIC16F876 ha 8 livelli di stack che permettono di fare in modo che il programma possa chiamare più subroutine da altre subroutine fino ad un massimo di 7 subroutine + il programma principale.

Le subroutine possono essere avviate in 2 modi diversi: tramite software o tramite interrupt.
La modalità software è stata appena descritta; la modalità interrupt è invece quella che è causata da un'interruzione nel flusso del programma (da cui interrupt).
Gli interrupt sono degli aventi ad altra priorità che portano il normale flusso del programma a fermarsi e costringendo il pic ad eseguire un'apposita subroutine d'interrupt che è a tutti gli effetti analoga ad una normale subroutine, ma in questo caso al posto di RETURN alla fine c'é RETFIE.
Altra particolarità dell'interrupt è che non viene avviato da una CALL, ma è il PIC che, quando riceve un evento che genera interrupt, carica nel program counter l'indirizzo 004, che è appunto il cosiddetto vettore di interrupt.
Il PIC, rispetto ad altri microcontrollori/microprocessori, ha un unico vettore di interrupt (fanno eccezione i PIC dalla serie 18Fxxxx in su che ne hanno almeno 2). Questo comporta che un qualsiasi interrupt farà saltare il programma all'indirizzo 004 e sarà all'interno della routine di interrupt che occorrerà verificare quale sorgente/periferica ha generato l'interrupt stesso mediante la verifica di appositi bit (detti flag) che cambiano di stato ad ogni evento di interrupt.
Gli interrupt possono essere scatenati da diversi eventi: variazioni dello stato di alcuni piedini, trasmissione/ricezione dati da porta seriale, scadere del tempo programmato all'interno di uno dei timer ecc.
Praticamente gli interrupt sono usati per gestire gli eventi veloci o comunque a priorità maggiore; questo evita, soprattutto in caso di programmi composti da molte istruzioni da eseguire (e quindi che impiegano anche qualche msec a essere eseguiti del tutto), di avere ritardi fra la variazione di un ingresso e la reazione da parte del microprocessore.

Per fare un esempio dell'utilizzo dell'interrupt si potrebbe pensare ad un orologio/cronometro completo di visualizzazione della temperatura.
Ebbene il programma dovrà occuparsi di gestire il display per la visualizzazione, i tasti di programmazione orario e di avvio/blocco cronometro, lettura del sensore di temperatura, eventuali calcoli per convertire la temperatura misurata in un valore corretto da visualizzare sul display. Come ultimo dovrà gestire l'avanzamento del cronometro, considerando magari una precisione al millisecondo.
Tutte le funzioni possono essere gestite senza problemi dal normale flusso del programma, ad eccezione delle funzioni di avanzamento cronometro che, se si vuole una precisione adeguata all'applicazione, devono essere gestite ad interrupt.
Il fatto di usare un interrupt, che in questo caso andrebbe agganciato ad uno dei timer interni al PIC programmato a 1msec, porta alla conseguenza che in qualsiasi istante, indipendentemente da quello che il pic sta facendo, allo scadere del millisecondo programmato nel timer il flusso del programma viene interrotto e il pic, eseguendo la subroutine di interrupt, va ad incrementare il cronometro e, terminato l'incremento, torna alla gestione del normale flusso di programma.
In questo modo si è sicuri che la temporizzazione sia sempre e comunque di durata pari ad 1msec, anche se il pic sta facendo operazioni molto complesse come moltiplicazioni o divisioni che rallentano enormemente il normale flusso di programma.

Con questa 4° puntata considero terminata la trattazione generale dei microprocessori/microcontrollori.
Dato che andare oltre significherebbe andare nei particolari ritengo che sia meglio attendere aventuali richieste o domande, affinchè sia possibile ragionare su qualcosa di concreto invece che astratto.

Edited by robo67 - 14/11/2008, 15:17

Beh, la terminologia alla fine conta poco, magari me la sono pure sognata io, magari una notte in cui avevo cenato con cappuccino e peperonata oppure l'ho letta un po' di anni fa da qualche parte, l'importante è il concetto (effettivamente LIFO è la stessa cosa).

Alla fine con le sigle e le abbreviazioni si può fare di tutto, anche gli anagrammi stile "Settimana enigmistica".

Cosa intendi per modo aperto? Vediamo se ho inteso quello che chiedi.

Il program counter viene incrementato automaticamente dopo l'esecuzione dell'istruzione e, in caso di istruzioni di salto (CALL e GOTO) salta direttamente al nuovo indirizzo. Lavora quindi in modo rigido.

Per resettare il watch dog c'é un'apposita istruzione (CLRWDT) che deve essere inserita nel programma in uno o più punti a discrezione del programmatore.
Chiaramente tanti più CLRWDT vengono inseriti e tanto più è facile che eventuali anomalie nell'esecuzione del programma passino inosservate perchè il watch dog viene resettato ugualmente.
La cosa migliore sarebbe inserire un solo CLRWDT e fare in modo che il programma passi ciclicamente in quella posizione; qualsiasi percorso alternativo provocherebbe il reset del PIC.

Non so se ho risposto alla tua domanda.

Mi viene una domanda, anche se uso poco il whatdog può servire, visto che va azzerato ad intervalli piuttosto brevi, penso che comunque la cpu venga caricata di lavoro in più, no?
Voglio dire, almeno 2-3 cicli macchina penso che vengano utilizzati, e di questo bisognerebbe tenerne conto in software che hanno bisogno di molta velocità di calcolo, o in routine che sfruttano ad esempio ritardi software, dico bene o è una stupidata?

Gila, ti consiglio di leggere questo post.

Per quello che riguarda lo sviluppo del software se hai a disposizione circa 200€ ti consiglio di comprare l'emulatore ICD3

Ha delle buone prestazioni in confronto al prezzo e ti serve sia per programmare i microcontrollori, sia per emularne il funzionamento.

5° PUNTATA

Riprendo il discorso dato che nel frattempo sono state fatte alcune richieste che mi hanno fatto capire di avere omesso dei dettagli importanti.

Vorrei parlare dei sistemi di sviluppo per microprocessori e microcontrollori.

Con "sistema di sviluppo" viene identificato un qualcosa, formato normalmente da software (e che include eventualmente anche dell'hardware) che permette di sviluppare un'applicazione su un microcontrollore.
Visto che ho iniziato parlando del pic proseguirò su questa strada, per evitare di fare un discorso troppo generico che finirebbe per essere noioso e inutile.

Gli ambienti di sviluppo comprendono normalmente un editor di testo (si potrebbe comunque usare un qualsiasi editor come lo stesso "Blocco note" di Windows).
Tramite l'editor di testo si scrive il sorgente del programma, rispettando la sintassi imposta dagli standard Microchip.

Il sorgente viene poi compilato dall'apposito software compilatore che genera files di diverso tipo: file .HEX per programmare il pic, file.LST dove viene riepilogato in modo testo quello che c'è dentro al file hex, più alcuni files che servono per gli emulatori e i simulatori.

Nel pacchetto c'è inoltre anche la sezione adibita al cosiddetto debug, ovvero all'eliminazione dei bug (in italiano "buchi") del software.
Il debug può essere effettuato in 2 modi diversi:
1) Tramite simulatore software
2) Tramite emulatore hardware (in circuit)

Il simulatore software permette di simulare il funzionamento del pic, eseguendo il programma compilato sul pc usato come "pic virtuale".
L'esecuzione del programma può avvenire in modo RUN, ovvero facendolo funzionare nel modo più simile alla normale esecuzione. Ovviamente, essendo una simulazione software, non sarà possibile notare nessun effetto fino a quando il programma non verrà bloccato. Solo a questo punto sarà verificabile il contenuto dei vari registri e lo stato dei piedini di uscita.

La seconda modalità di esecuzione è la cosiddetta ANIMATE ovvero avanzamento continuo in modalità passo-passo (un'istruzione alla volta).Durante l'esecuzione in modalità animate il contenuto dei registri viene visualizzato in tempo reale.

La terza e ultima modalità è il passo-passo. Il programma viene fatto avanzare manualmente un'istruzione per volta affinchè sia possibile vedere in ogni istante cosa succede.

Il simulatore software ha, ovviamente, molti limiti. Pur rivelandosi utile per verificare le subroutine relative a calcoli ed elaborazioni, praticamente tutte operazioni che modificano solamente i registri interni al pic, è invece quasi inutile, per non dire completamente inutile, quando si ha a che fare con i piedini di I/O. Per simulare le uscite è possibile leggere lo stato delle porte I/O (PORTA,PORTB,PORTC ecc.), anche se poi il risultato deve essere interpretato.
Per gli ingressi le cose si complicano, perché occorre simulare gli "stimoli" (nel simulatore del pic vengono chiamati proprio in questo modo), creando un apposito file che simuli le variazioni degli ingressi in sincronia con gli impulsi di clock.

Se la simulazione raggiunge un minimo di complessità è molto meglio usare un emulatore hardware che trasforma il pc in un simil-pic per quello che riguarda il contenuto dei registri, della memoria programma, dell'eventuale EEPROM ecc., mentre all'emulatore spetta il compito di interfacciare quello che avviene sul pc col circuito in cui la sonda dell'emulatore è stata inserita.

Le funzioni implementabili con l'emulatore sono le stesse del simulatore, con in più il fatto di poter vedere qualcosa che accade nel circuito definitivo (un display che visualizza un messaggio, la tastiera effettivamente funzionante, la scheda che comunica col pc, ecc.).
Ovviamente l'ipotesi dell'emulatore è enormemente più comoda del simulatore software e dà inoltre molte più soddisfazioni a realizzare qualcosa, dato che si vedono gli effetti delle evoluzioni nello sviluppo del programma piuttosto che numeri che cambiano di valore e che devono essere intesi come se fossero un led acceso, un tasto premuto ecc.
Microchip realizza per i pic vari emulatori che hanno potenzialità (e costi) molto diversi.

Io ho avuto modo di lavorare con l'ICD2 e l'ICE2000.

L'ICE2000 ha maggiore potenza, maggiore velocità, la possibilità di avere un numero infinito di breakpoint (spiegherò poi cosa sono) e alcune funzioni evolute che lo rendono uno strumento completo. Ha però bisogno, per ogni famiglia di pic, di apposite sonde hardware che possono costare tranquillamente 400-600€ e che non rendono economicamente conveniente scegliere un nuovo tipo di pic.

L'ICD2 (ora sostituito dall'ICD3 che penso sia ancora più versatile e potente) permette di emulare tantissimi pic semplicemente acquistando il processor module, una piccola scheda che ospita il pic da emulare in version speciale (a più pin), che ha un costo di poche decine di € (il costo dipende dal pic emulato).
Il limite più grosso dell'ICD2 rispetto all'ICE2000 è il fatto di avere un solo breakpoint e di richiedere un tempo più lungo per trasferire il programma appena compilato all'interno dal pc all'emulatore.
In ogni caso l'ICD2 mi sembra un buon compromesso fra costo e servizio svolto (l'ho usato anche per realizzare progetti abbastanza complessi), anche perchè oltre ad essere un emulatore è anche un programmatore che ad ogni ricompilazione riscrive il pic installato nel processor module con il programma appena compilato (da qui la maggiore lentezza rispetto all'ICE2000).

Ma cos'è un breakpoint? Breakpoint, ovvero punto d'interruzione, è un "segnale di stop" che viene inserito all'interno del programma per fare in modo che quando il program counter raggiunge l'indirizzo corrispondente al breakpoint stesso, l'esecuzione del programma si fermi e permetta di verificare lo stato dei registri, di modificarli e di riprendere l'esecuzione, magari anche in modo passo-passo.

Nel caso dell'ICD2 ogni volta che si inserisce un breakpoint in un punto del programma viene cancellato il breakpoint precedentemente impostato.

Con l'ICD3 puoi già fare tutti gli esperimenti che vuoi. Diciamo, tanto per fare un esempio che l'ICD3 è un'utilitaria, mentre l'ICE2000 e l'ICE4000 sono rispettivamente una berlina di grossa cilindrata e un'auto sportiva
L'unica cosa ricordati che se vuoi usare dei pic a 8, 14 o 18 pin oltre all'ICD3 devi acquistare il processor module che è dipendente dal pic che vuoi usare.
Questo link contiene una tabella dei pic supportati (device supported), dei pin relativi al processor module (MPLAB ICD2 header) e del codice per l'ordine (Partnumber).

Se vuoi usare il PIC16F876A O PIC16F877A (28 e 40 pin) all'ICD3 devi abbinare il seguente header (processor module).

Se usi i pic da 28 o 40 pin puoi fare a meno dell'header, se quando crei il circuito stampato rispetti le indicazioni di Microchip, inserendo un connettore per mettere il pic in comunicazione con l'ICD2 (ICD3), permettendone sia il debug che la programmazione.
Il connettore fa capo ai pin MCLR (reset), RB6 e RB7 (clock e dato per la programmazione) oltre al +5V e a GND.


Gli ST7 e i predecessori ST6 (che ho usato per 1 o 2 progettini) sono dei microcontrollori, simil-pic, ma non dei pic, dato che pic è una famiglia prodotta solo da Microchip, mentre gli STx sono prodotti da ST Microelectronics.
Malgrado la mia simpatia verso ST Microelectronics, che considero un'azienda all'avanguardia e decisamente interessante, in base alla mia esperienza ritengo che gli ST6 non fossero un granchè; avevano dei limiti in termini di velocità, caratteristiche elettriche e di set d'istruzioni notevoli.
Magari gli ST7 sono già migliori, ma i PIC li conosco da quasi vent'anni e mi ci trovo bene.
Magari ci sono parecchi altri microcontrollori di potenza e pezzatura analoga ai pic che costano anche meno, ma il fatto di risparmiare 0,5-1€ su un microcontrollore dovendo rivoluzionare tutto, sia in termini di conoscenze, sistemi di sviluppo, circuiti stampati ecc. solo per risparmiare pochissimo non mi attira neppure un po'.

Con l'ICD3 ti danno il CD con tutto il software per l'ambiente di sviluppo (pacchetto MP-LAB) contenente l'editor di testo, il compilatore e il software di programmazione.
L'MP-LAB è comunque scaricabile anche dal sito Microchip (anche se è decisamente voluminoso) che offre la versione aggiornata; se tu non hai intenzione di usare i pic appena usciti anche la versione su CD va benissimo.

Microcontrollori ne esistono quanti ne volete
Il punto e' che in fase di realizzazione bisogna optare per il migliore compromesso fra facilita'/velocita' di sviluppo e caratteristiche/costo necessarie.
Ad esempio, supponiamo che io debba usare un microcontrollore ed una memoria di una certa capacita' in un mio progetto. Sicuramente la soluzione pic+sram e' la migliore qualora la sram non costi troppo (parliamo di piccole capacita'). Ma supponiamo che il costo sia un fattore critico. Allora devo indirizzarmi su memorie meno costose e magari su banchi di ram commerciali. Supponiamo che sia in grado di interfacciare ad esempio un microcontrollore ad un piccolo banco di memoria per pc ma che il microcontrollore debba avere una certa caratteristica per farlo. Allora sono costretto a ricorrere ad un microcontrollore che magari a livello di sviluppo del software richiede piu' tempo ma servendomi per forza quel microcontrollore devo accettare la situazione. Per darvi dei numeri se pochi Kbit di sram costano davvero poco, un chip da 72 Mbit di sram costa sui 160 dollari. Capite che fra usare un chip di quel costo e magari un microcontrollore diverso ma su ram piu' comune, si opta per la seconda nel caso in cui il costo e' importante dato che molti microcontrollori supportano anche la ddr.
Ora, gli st7 sono MOLTO complessi da programmare e di solito conviene sostituirli con dei pic nei progetti. Ma se ad esempio vogliamo usare una USB e ci serve lavorare ad una certa velocita' che i pic non supportano, allora siamo costretti a buttarci sugli st.
In pratica ogni microcontrollore ha le sue caratteristiche e spesso le scelte dipendono dal progetto. Quando pero' uno puo' si sposta su microcontrollori che sono veloci da programmare.

I pic, dal punto di vista dell'interfacciabilità con memorie esterne, non sono certamente il massimo.
Qualche applicazione l'ho fatta aggiungendo dei chip esterni (latch o contatori), ma l'efficienza e la velocità di memorizzazione lasciano abbastanza a desiderare.
In genere i pic vanno presi per quello che sono: buoni microcontrollori "chiusi su se stessi" adatti per applicazioni di bassa-media complessità.

Certo Hellblow che tu di microcontrollori/microprocessori ne hai usati un tot. Immagino che non sia solo per hobby.....