La programmazione del PIC16F877A, come tutti i PIC, avviene in modo seriale: si entra in questo

Transcript

1 Presentazione Questa è una dispensa sulla programmazione del microcontrollore PIC16F877A. Le informazioni valgono anche per gli altri microcontrollori della famiglia PIC16, che condividono tutti lo stesso set d istruzioni. La programmazione del microcontrollore PIC16F877A di Ippolito Perlasca La programmazione del PIC16F877A, come tutti i PIC, avviene in modo seriale: si entra in questo modo di programmazione tenendo bassi i piedini RB6 e RB7, mentre si porta il piedino MCLR dalla tensione di alimentazione normale V DD ( + 2 V +5. 5V ) alla tensione di programmazione ( + 12 V + 14V ). A questo punto RB7 diventa disponibile come input/output seriale; il clock che temporizza il trasferimento va applicato a RB6. In questo modo è possibile passare al PIC opportuni comandi di programmazione e le istruzioni da memorizzare nella memoria flash. Un opportuno comando manda RB7 in uscita, permettendo di leggere e verificare il contenuto della memoria di programma. Per i particolari, che sono gestiti in modo trasparente dai software di programmazione, si rimanda alla documentazione Microchip. Il PIC16F877A (e gli altri PIC FLASH della stessa famiglia) ha però un ulteriore possibilità: se, in fase d inizializzazione, MCLR è lasciato alla normale tensione di alimentazione V DD, e viene portato a V DD anche il piedino RB 3/ PGM, il microcontrollore, purché configurato per farlo, entra in modalità di programmazione a bassa tensione e può essere programmato anche in circuito (ICSP, In-Circuit Serial Programming). In questo modo si può modificare il software di un applicazione già istallata, purché naturalmente si rinunci ad utilizzare i piedini RB3, RB6 e RB7, e si garantisca l accessibilità di MCLR. Esistono numerosi sistemi hardware/software per la programmazione e lo sviluppo di applicazioni con i microcontrollori PIC, sia di produzione Microchip che di terze parti. Nella fascia alta ci sono i sistemi di sviluppo basati su un emulatore. Un emulatore, che è specifico Una buona scelta per un laboratorio scolastico è quella di utilizzare un programmatore/debugger incircuito Microchip ICD2. Le prestazioni di debugging sono limitate rispetto a quelle di un emulatore vero e proprio (che costa dieci volte tanto!) 1, ma sono accettabili in un uso didattico. 1 Ricordiamo che un emulatore è un dispositivo, controllato da un PC, che, grazie a un integrato dedicato appositamente sviluppato, imita completamente e in tempo reale un microcontrollore. Rispetto alla CPU originaria, il programma che gira su un emulatore può essere interrotto al verificarsi di condizioni particolari per permettere l accesso ai registri, può essere eseguito passo-passo, può essere fatto oggetto di statistiche o di misure di tempi d esecuzione, ecc. L emulatore è dotato di adattatori ( pod ) specifici per ogni CPU della famiglia che può supportare, ciscuno con un connettore stessa piedinatura del microcontrollore, che va inserito sul circuito in prova al posto del microcontrollore stesso. 1

2 L ICD2 è un padellotto che si connette da un lato al PC (via USB o RS232), dall altro all applicazione target (che deve avere a bordo il microcontrollore ed essere dotata di clock), Il programmatore/debugger può programmare il PIC e mandarlo in esecuzione programma in una forma controllata (autoemulazione/autodebugging), in cui può essere interrotto o eseguito passopasso, visualizzando sul PC il contenuto dei registri e lo stato della CPU. L unico problema della modalità di autoemulazione è che ruba risorse di memoria (programma e dati), perché di fatto è gestita da un mini-sistema operativo che deve essere caricato sul microcontrollore. Per contenere le dimensioni del tutto, le prestazioni sono ridotte all osso (per esempio, è possibile impostare un solo punto di sospensione breakpoint alla volta). Inoltre, nel funzionamento in autodebugging sono perennemente impegnate tre linee di I/O, che non possono essere usate per altre funzioni. Oltre che a un circuito applicativo stand-alone, l ICD2 può essere collegato a una scheda programmatrice (che nel caso di Pic con memoria FLASH è poco più che un semplice zoccolo): in tal caso serve solo da programmatore, senza possibilità di debug. Vedi Figura 2.1; Figura 2.1 Collegamenti all ICD2 Il software di gestione dell ICD2 fa parte di un pacchetto chiamato MPLAB 2. Questo pacchetto, che gira sotto Windows, ed è un IDE (Integrate Development Environment, ambiente di sviluppo integrato) che comprende un gestore di progetti, un editor, l interfaccia con il programmatore/debugger, l assemblatore MPASM per i PIC16 (ma può integrare anche l assemblatore per i PIC della fascia più alta, nonché diversi compilatori C), un simulatore per testare i programmi senza hardware. Ci sono anche un linker, per gestire progetti complessi con file sorgente multipli e i sistemi operativi scaricabili per i PIC che supportano la modalità di autoemulazione. MPLAB è un ambiente complesso, con molte potenzialità e opzioni, e non è possibile darne qui una descrizione completa. Proviamo allora a descrivere il suo utilizzo nello sviluppo passo-passo di un semplice progetto, dalla scrittura del software all assemblaggio, alla simulazione, al download sul target e al debugging del programma. Come target su cui testare il programma supponiamo di avere una scheda sperimentale (demoboard) dotata di collegamento per l ICD2, come la PICDEM 2 PLUS della Microchip o la PVK40 della Asix; ma niente impedisce di pensare a una semplice realizzazione ad hoc su breadboard: dopotutto basta il PIC, il circuito di clock e un LED. Approfitteremo dello sviluppo del progetto anche per chiarire alcuni punti relativi alla sintassi e alla logica del software. Un progettino per cominciare 2 MPLAB è liberamente scaricabile dal sito della Microchip: 2

3 Le specifiche Vogliamo realizzare un semplice sistema che conti i passaggi di oggetti (diciamo automobili) attraverso un traguardo fotoelettrico e attivi (portandola alta) una linea d uscita quando il conteggio arriva a un valore predeterminato N_ON. Quando il conteggio arriva a N_OFF > N_ON l uscita deve ritornare bassa e il conteggio ripartire da 0. Ulteriori specifiche e assegnazione degli I/O Supponiamo che il sistema sia alimentato a 5 V e che il traguardo fotoelettrico produca un uscita TTL-compatibile alta quando il sensore fotoelettrico è oscurato (passaggio di un oggetto). Abbiamo bisogno di una linea d ingresso e una di uscita. Possono essere della stessa porta: utilizziamo ad esempio RB0 (pin 0 di PORTB) per l input e RB4 (pin 4 della stessa porta) come output (in realtà la scelta di RB0 come input risulterà obbligata per una scelta che faremo nel seguito). Per semplicità, supponiamo che le soglie N_OFF e N_ON siano numeri (interi senza segno) di un solo byte ( 255). Il progetto del software La struttura in grande di un programma per microcontrollore è semplice e sempre la stessa (figura 2.2): START INIZIALIZZAZIONI LEGGI GLI INPUT ELABORA GLI INGRESSI E CALCOLA LE USCITE AGGIORNA LE USCITE Figura 2.2 Struttura di un programma per microcontrollore Ci possono essere uscite deviazioni dal ciclo principale in occasione di interrupt, ma è comunque importante tenere presente che un programma di un microcontrollore è concepito per non terminare 3

4 mai, perché l esigenza del controllo in genere non viene mai meno. Tutt al più il microcontrollore può andare in stand by (Sleep), ma per fermarlo del tutto l unico modo è togliere l alimentazione. Quindi la struttura principale di un programma è sempre un ciclo indefinito. Nel nostro caso, supponendo per semplificare di gestire l input in polling, cioè tramite un interrogazione ciclica, una prima approssimazione in linguaggio di progetto che viene in mente è del tipo: start inizializza le linee di I/O CONTATORE 0 ; CONTATORE è un definito dall utente RB4 0 ; Abbassa preventivamente l uscita ripeti leggi RB0 se RB0 = 1 ; se il fotosensore è oscurato allora CONTATORE CONTATORE +1 ; conta + 1 se CONTATORE = N_ON allora RB4 1 se CONTATORE = N_OFF allora inizia RB4 0 CONTATORE 0 fine vai a ripeti 3 Peccato che non funzioni. L errore, tipico, è di identificare l evento da contare (il passaggio dell oggetto) con il livello dell ingresso (in questo caso H). Perché in questo modo, nel nostro mondo normale di velocità lontane da quelle della luce, ogni oggetto viene contato un numero spropositato di volte!. Basta un semplice calcolo: supponiamo un clock tipico di 4 MHz, quindi un ciclo macchina T CY di 1 µs. Esageriamo, e supponiamo che il programma usi tutta la memoria (!). Allora il ciclo di programma è lungo 8192 istruzioni (in realtà un po meno, perché ci sono le inizializzazioni). A un T CY per istruzione, sono ms, un po per la presenza di salti che durano 2 T CY. Ci interessa solo l ordine di grandezza, approssimiamo per eccesso a 10 ms. Poiché quindi il traguardo viene interrogato 100 volte al secondo, un oggetto che l impegna per meno di un 3 La sintassi del linguaggio di progetto è abbastanza intuitiva e non rigida, basta mettersi d accordo. Ad esempio, poiché nell assembler i nomi dei registri, dei bit e delle linee di I/O sono indirizzi, si dovrebbe scivere a rigore (CONTATORE) (CONTATORE) + 1, (RB4) 0 e simili, per distinguere il valore (CONTATORE) ad esempio di un registro, e l indirizzo stesso CONTATORE. Ma è chiaro che si rischierebbe la pedanteria! Più importante è trovare un buon compromesso fra astrazione e vicinanza alla macchina. Ad esempio, tranne che in una fase molto iniziale del progetto, sarebbe meglio usare i nomi dei registri del micro, piuttosto che nome simboli di variabili qualunque: ciò rende più facile la successiva traduzione in assembler; d altra parte, una descrizone in linguaggio di progetto troppo analitica si ridurrebbe a una parafrasi del programma in assembler, con le stesse difficoltà di stesura e le stesse oscurità. 4

5 centesimo di secondo può venir perso, uno che l impegna per un tempo superiore può essere contato più volte (sicuramente almeno due se il tempo del passaggio è almeno due centesimi di secondo). Ora, per un auto lunga 5 m, un centesimo di secondo vuol dire una velocità di 5m = 500m / s = 1800km / h! Alla velocità di 90 km/h verrebbe contata intorno alle 20 volte s Il problema si risolve rilevando non i livelli, ma le transizioni L H. Sarebbe facile farlo anche mantenendo la tecnica del polling (vedi uno dei diversi esempi nella raccolta di file.asm), ma qui ne approfittiamo per parlare anche delle interruzioni e scegliamo di lavorare su interrupt da fronte di salita (con in mente questa soluzione è stato scelto RB0 come linea di input, perché è su questo piedino che il PIC può ricevere richiesta di interruzione su un fronte). A questo punto lo schema del programma principale diventa: start (programma principale) inizializza le linee di I/O configura richiesta interrupt da RB0/INT su fronte di salita CONTATORE 0 ; CONTATORE è un definito dall utente RB4 0 ; Abbassa preventivamente l uscita Abilita la CPU a ricevere interrupt ripeti se CONTATORE = N_ON allora RB4 1 se CONTATORE = N_OFF allora inizia RB4 0 CONTATORE 0 fine vai a ripeti Mentre la routine di gestione dell interrupt è organizzata così: gestore interrupt start salva stato e registro W CONTATORE CONTATORE + 1 recupera stato e registro W INTF 1 ritorna dall interrupt Ricordiamo che INTF è il flag del registro INTCON che segnala la richiesta di interrupt da RB0/INT. Poiché la risposta della CPU a una richiesta di interrupt è la stessa (salto a 004h) qualunque ne sia la fonte, in generale è necessario interrogare i flag di interrupt delle periferiche per scoprire chi ha chiamato, ma qui l unico interrupt abilitato è da RB0/INT, quindi non ci sono dubbi. Però bisogna ricordarsi di azzerare INTF prima del rientro dall interrupt per evitare che l interrupt si ripeta all infinito, indipendentemente dallo stato di RB0/INT. 5

6 Il salvataggio e il ripristino di stato ci garantiscono da falsi confronti dovuti all eventuale modificazione del flan di zero Z nel corso dell interrupt 4 ; già che ci siamo salviamo anche W. Notare che avremmo potuto mettere la verifica del conteggio e il controllo dell uscita direttamente nella routine di interrupt: sarebbe la scelta migliore, se il microcontrollore avesse altro da fare. Qui non l abbiamo fatto, per mettere in luce le possibili interazioni fra programma principale e routine d interruzione. 4 In realtà, dato che CONTATORE CONTATORE + 1 non può alzare Z, perché per le ipotesi fatte non arriva mai a 256, e nell ipotesi che non gli interrupt sono distanziati fra loro di almeno un ciclo del programma principale, non sarebbe necessario salvare i flag; ma è un caso così particolare che si fa prima a farlo che a giustificare perché non sarebbe necessario! 6

7 La stesura del programma A questo punto scriviamo fisicamente il file sorgente in assembly. Metterlo prima su carta sarebbe una pedanteria inutile e non aggiungerebbe nulla che non si possa capire lavorando (e correggendo) direttamente sull editor. Supponiamo di aver installato MPLAB 5, seguendo attentamente le istruzioni che compaiono a video e leggendo anche il file readme.txt sul CD. Colleghiamo l ICD2 attraverso la porta seriale o una porta USB (meglio farlo ora, a meno che non prevediamo di usarlo e di lavorare solo in simulazione), poi lanciamo MPLAB (Figura 2.3): Figura 2.3 Il desktop di MPLAB Appare un desktop tipico di un applicazione Windows, con una finestra di Output, in cui verranno visualizzati gli oggetti prodotti e le azioni portate a termine, e uno spazio di lavoro (per il momento senza titolo). Aprite subito il menu a tendina Configure e scegliete Select Device (Figura 2.4). Assicuratevi che in Device sia selezionato il microcontrollore che vogliamo usare (In realtà il PIC16F877A è un lusso per questa applicazione, andrebbe benissimo un fratellino minore, come il PIC16F84). Notate, che, selezionato il PIC, compaiono marcati in verde gli hardware e i software supportati. L importante è che ci siano ASSEMBLER, MPLAB SIM e MPLAB ICD2. Se tutto è a posto date OK (Figura 2.4). 5 All atto della stesura di queste note MPLAB era arrivato alla versione 7.40, ora (inizio 2009) siamo alla 8.15a. Comunque sono stati introdotti alcuni miglioramenti ma nessuna modifica sostanziale: le poche differenze dovrebbero essere facilmente padroneggiabili, eventualmente consultando la documentazione sul sito Microchip.com. 7

8 Figura 2.4 Sottomenu Select Device Adesso creiamo un progetto: Project>>Project Wizard>>Avanti. Vi si chiede di nuovo di confermare il PIC scelto, che potete cambiare anche da qui. Quando siete contenti cliccate ancora Avanti, e compare una finestra del tipo di Figura 2.5: 8

9 Figura 2.5 Selezione dei pacchetti (toolsuite) software Dovete selezionare Microchip MPASM Toolsuite come Active Toolsuite. In Toolsuite Contents devono apparire i tre programmi indicati. Se ne manca qualcuno o sono spuntati da una x rossa, andate a cercarli e a selezionarli uno per uno tramite il pulsante Browse Quando avete fatto, date Avanti e selezionate un nome Project Name per il progetto (senza estensione) noi abbiamo scelto Prima_prova - e la cartella dove mettere il relativo file (Project Directory). Se scrivete direttamente il nome della cartella, ricordatevi di specificare il disco (drive). 9

10 Altrimenti andate a cercarla (o a crearla) con Browse (Figura 2.6). Figura 2.6 Specificazione del progetto Dopo Avanti compare una finestra in cui vi si chiede di aggiungere file al progetto. Se non state lavorando su un progetto già in corso, ignoratela e andate Avanti. Compare una finestra riassuntiva dei parametri del progetto, cui rispondete con Fine, a meno che non vogliate tornare indietro a cambiare qualcosa. Vi ritrovate con la finestra di workspace che adesso contiene il progetto, anche se le cartelle dei file relativi sono ancora tutte vuote. Andate in File>>Add New File to Project e dalla finestra di dialogo che si apre create un nuovo file con estensione.asm, che sarà il file sorgente del nostro programma (Figura 2.7). Noi lo abbiamo chiamato Programma 1.asm, ma gli si poteva dare anche lo stesso nome del progetto: 10

11 Figura 2.7 Creazione del file sorgente Si apre allora la finestra dell Editor (a destra in Figura 2.8), notate nella finestra del workspace che il file.asm è stato aggiunto ai Source Files del progetto: Figura 2.8 Finestra dell Editor Allargate la finestra dell Editor a piena pagina e cominciamo: Tutto quello che c è dal punto e virgola (;) e la fine linea, evidenziato in verde, è un commento, che viene ignorato dall assemblatore ma è essenziale per il programmatore, perché il linguaggio 11

12 assembly è troppo vicino alla macchina per essere immediatamente comprensibile, e senza ampi commenti un programma scritto in assemby rischia di essere incomprensibile (anche allo stesso autore, a qualche mese di distanza!). Per rendere più leggibile il programma si possono anche inserire liberamente linee vuote. Le parole in blu sono invece direttive: non sono istruzioni per il microcontrollore, ma informazioni per l assemblatore sulle configurazioni da assumere e sul valore di alcuni parametri. La prima, list, ha una doppia funzione: l argomento p=16f877a seleziona il microcontrollore, quella r=dec stabilisce che la radice numerica di default è la decimale, che cioè i numeri che scriveremo nel file senza accorgimenti particolari sono da intendersi in base 10. Vedremo poi come scrivere i numeri in binario e in esadecimale. La seconda, #include, carica all atto dell assemblaggio, nella posizione in cui è messa, il file di testo specificato. E come se il contenuto del file fosse scritto qui, ma voi non lo vedete. Il nome del file deve essere racchiuso fra parentesi acute < > In questo caso il file è p16f877a.inc (file di inclusione), dove sono specificati tutti i nomi simbolici relativi al microcontrollore: per esempio, in questo registro STATUS è posto uguale a 003h, di modo che STATUS può essere usato come nome del registro di indirizzo 003h. C è un file.inc per ogni microcontrollore supportato da MPLAB. La terza direttiva, CONFIG (occhio al doppio carattere di underscore in testa!) ha numerosi argomenti separati da & (che sta per AND) che in questo caso configura no il PIC con: La protezione del codice disabilitata Il timer di watchdog disabilitato Il reset su bassa tensione di alimentazione disabilitato Il ritardo di stabilizzazione all accensione abilitato La programmazione in bassa tensione disabilitata Clock con cristallo di quarzo _CP_OFF _WDT_OFF _BODEN_OFF _PWRTE_ON _LVP_OFF _XT_OSC Sono impostazioni più o meno standard, almeno per un applicazione didattica. E abbastanza evidente che se vogliamo ad esempio abilitare il watchdog si deve cambiare _WDT_OFF con _WDT_ON e simili. Se non abbiamo preoccupazioni di precisione e stabilità per la frequenza di clock, possiamo usare un gruppo RC al posto del quarzo (vedi Datasheet), mettendo _RC_OSC al posto di _XT_OSC. Il ritardo di stabilizzazione all accensione serve a garantire che l oscillatore del clock vada a regime, prima che l esecuzione del programma abbia inizio: probabilmente una preoccupazione eccessiva. Invece disabilitare la programmazione a bassa tensione è necessario se vogliamo utilizzare la modalità di debugging in autoemulazione, perché entrambe le funzioni impegnano il piedino RB3. Notare che il Pic era già stato selezionato in Configure>>Select device e che anche le altre configurazioni possono essere settate da menu in Configure>>Configuration Bits. Tuttavia è consigliabile usare list e CONFIG nel file sorgente, perché queste configurazioni prevalgono su quelle impostate nell IDE, e quindi si mantengono se spostate il file da un istallazione di MPLAB a un altra configurata diversamente su un altra macchina. Adesso definiamo le costanti N_0N = 10 e N_OFF = N_ON + 10 = 15. Per definire una costante si usa la direttiva: Etichetta EQU Valore 12

13 Etichetta (label) è una qualunque combinazione di lettere, cifre e _, senza spazi e che non può cominciare con una cifra. E assolutamente necessario che un etichetta inizi in prima colonna, altrimenti non è riconosciuta come tale. Nessun altra cosa (commenti a parte) può iniziare in prima colonna (è comodo usare il tasto di Tab). EQU sta per equal, uguale. Valore è un numero intero relativo (in complemento a 2) al massimo di 4 byte, quindi da a Il risultato è semplicemente quello di chiamare il numero con il nome dell etichetta: se ad esempio PEPPO EQU 67, l assemblatore sa che in tutto il programma quando incontra PEPPO deve sostituirci 67. La definizione di N_ON fa capire che l assemblatore può fare calcoli sulle costanti (in aritmetica intera). Le successive definizioni di variabili rischiano d essere fuorvianti: non sono variabili (che a rigore non esistono in assembly), sono ancora definizioni di costanti come quelle di prima. Però hanno valori che rientrano nel range degli indirizzi dei registri RAM d archivio (del blocco 0), quindi danno un nome a dei registri, e i registri possono essere considerati come variabili; ma i nomi sono numeri: ad esempio CONTATORE è il numero esadecimale 71, che a sua volta è l indirizzo di un registro usato come contatore. Diciamo, per intenderci, che in questo modo definiamo dei registri. A proposito, notate che per specificare che un numero è in esadecimale bisogna preporgli 0x, come in C. Naturalmente andava altrettanto bene scrivere CONTATORE EQU 113, che è l equivalente in decimale di 0x71, ma è d uso esprimere gli indirizzi in Hex: Oltre al registro contatore, definiamo due registri per contenere durante l interrupt le copie di W e del registro di stato (i PIC non hanno uno stack accessibile al programmatore). Prima di incorrere in guai, è bene ricordare che le etichette, e quindi anche i nomi di registri, sono case-sensitive, cioè il maiuscolo non è la stessa cosa che il minuscolo: se avete definito CONTATORE, non potete poi usare contatore per riferirsi a quel registro. Lo stesso vale per i registri specializzati, i cui nomi sono definiti nel file.inc: non potete riferirvi al registro di sato con status, dovete scrivere STATUS. Invece istruzioni e direttive sono case-sensitive: potete scriverle come più vi piace. La direttiva successiva, org 0x000, dice all assemblatore che da qui in avanti le istruzioni che incontrerà andranno assemblate, cioè tradotte in linguaggio macchina, a partire dalla locazione di memoria programma 0x000 (org sta per origine ). E importante, perché all accensione o dopo un reset il program counter si posiziona su 0: è da lì che devono partire tutti i programmi. Ora finalmente possiamo cominciare con le istruzioni. Se non ci fosse da gestire l interrupt, potremmo 13

14 andare avanti da qui a scrivere il programma principale; ma in caso di interrupt, la CPU (o meglio, il program counter) salta alla locazione fissa 0x004, da dove deve necessariamente iniziare la routine di interrupt, o esserci un salto alla routine stessa. Quindi il programma principale deve essere messo dopo la routine di interrupt, o almeno dopo la locazione 0x004; ma se il programma parte da 0x000, bisogna scavalcare la gestione dell interrupt per arrivarci: ecco perché la prima istruzione è un goto start, cioè un salto incondizionato alla locazione dove inizierà il programma principale: start (nome non obbligato) è l etichetta che ne marcherà l inizio. Facciamo i puristi: poiché non è elegante mettere la routine di interrupt prima del programma principale, in 0x004 limitiamoci a metterci un salto goto interr alla routine, che verrà scritta in fondo a tutto (anche qui, interr è solo un etichetta dal nome significativo ma arbitrario: l unica cosa da evitare nella scelta delle etichette è che coincidano con parole riservate: istruzioni o direttive). Per essere sicuri che l istruzione di salto vada in 0x004, premettiamoci org 0x004. (lasciamo un buco di 3 locazioni, ma pazienza). La prima parte del programma è dedicata alle inizializzazioni: il pin RB3 viene dichiarato in uscita, RB0 (e tutti gli altri pin di PORT B) in ingresso, scrivendo 1 in corrispondenza dei pin in ingresso e 0 in corrispondenza di quelli in uscita nel registro di controllo TRIS B. Notare la costante numerica scritta in binario, tra apici e prefissata da b (o B): è più leggibile scrivere i numeri in binario, quando hanno significato i singoli bit, ma al posto di b si sarebbe potuto benissimo scrivere 0xF7 o 247. Non esistono istruzioni per scrivere una costante in un registro d archivio: bisogna scriverlo in W, poi copiarlo da W al registro. Il registro TRISB, come gli altri registri TRIS, sta nel banco 1: ci si deve ricordare di settare il bit RP0 (il n. 5) di STATUS per accedervi (le costanti RP0 = 5 e RP1 = 6 sono definite nel file.inc). Quando si vuole ritornare al banco 0, RP0 va abbassato. Si deve anche azzerare il registro contatore, il cui contenuto iniziale è casuale, e abbassare l uscita (quest ultima operazione più per pulizia logica che per altro, perché è già 0 di default). Notare che i pin delle porte vanno indicati con il numero d ordine corrispondente, perché purtroppo nei file.inc non sono definiti i loro nomi simbolici (non ci sono RB3 e simili). Il valore dell etichetta start, che marca la prima linea di questa sezione (come anche interr, che si riferisce invece alla routine di interruzione) è calcolata direttamente dall assemblatore, ed è l indirizzo in memoria dell istruzione marcata. Per poter gestire in riferimenti in avanti (come lo start di goto start), l assemblatore funziona in due passate: nella prima lascia in sospeso i rimandi a etichette non ancora calcolate, e li aggiusta nella seconda, quando ha ormai incontrato e calcolato le etichette relative. 14

15 Adesso predisponiamo l interrupt: Il bit INTDEG di OPTION_REG (che sta in banco 1) posto alto seleziona l interrupt su fronte di salita; alzando INTE di INTCON, si abilita l ingressso RB0/INT a chiedere interrupt. Portare basso il flag d interruzione della periferica (qui INTF) è una buona norma, per rimuovere eventuali interrupt pendenti (qui potrebbe verificarsi un fronte spurio su RB0/INT all atto dell accensione). Infine si deve attivare l abilitazione generale all interrupt, portando a 1 GIE. Per tutti questi particolari riferirsi al paragrafo sugli interrupt. Il ciclo di programma in cui il microcontrollore gira in attesa dell interrupt, controlla a che punto è arrivato il conteggio e alza/abbassa l uscita di conseguenza: I confronti sono fatti per sottrazione, copiando CONTATORE in W e poi sottraendo da W la soglia: se i due valori sono uguali si alza il flag di zero Z, che viene sentito dalle istruzioni di skip. Notare la logica al contrario : se i valori sono diversi Z cleared si scavalca btfsc l azione da compiere. Per il secondo confronto CONTATORE va ricaricato in W, perché W è stato sporcato dalla precedente istruzione sublw (il risultato della sottrazione va in W); qui l azione da fare nel caso la condizione sia verificata non può essere scavalcata, perché è costituita da più di un istruzione: allora lo scavalcamento è sul verificarsi della condizione, e l istruzione scavalcata è un salto che rimanda all inizio ciclo. 15

16 Per finire, la routine di gestione interrupt: Il gioco apparentemente complicato di salvataggio ripristino di STATUS e W è spiegato nella sezione sugli interrupt. Per STATUS_TEMP e W_TEMP è una buona scelta scegliere indirizzi nella fascia 0x70 0x7F, perché sono raggiungibili indipendentemente dallo stato di RP0e RP1, cioè indipendentemente da quale banco RAM sia attivo al momento in cui viene chiamato interrupt: semplicemente, non dobbiamo preoccuparcene, anche se in realtà nel nostro programmino il problema non c è, perché durante l esecuzione del programma principale è sempre attivo il solo banco 0. Attenzione comunque che questa mappatura di un blocco di registri utente su tutti i banchi RAM non c è in tutti i modelli di PIC!. Importante alla fine ricordarsi di abbassare il flag d interruzione (INTF) della periferica che ha chiamato interrupt: come spiegato nella sezione sugli interrupt, se non lo si fa, appena si rientra dalla routine di gestione e GIE si rialza automaticamente, la CPU sente di nuovo interrupt e la storia si ripete all infinito. Ricordarsi l end finale, che non è la fine del programma, ma semplicemente un modo di dire all assemblatore che il testo del programma è terminato, e non deve cercare altre cose oltre. Per sicurezza, File>>Save All. L assemblaggio e la correzione degli errori di sintassi A questo punto proviamo ad assemblare il programma, cioè a tradurlo in linguaggio macchina: Project>>Build All Durante l assemblaggio compare una finestrella temporanea con una barra di avanzamento ma, se avete scritto il programma esattamente come abbiamo fatto noi, a un certo punto la barra di avanzamento passerà dal verde al rosso, segnalando un errore. Sparita la finestrella di assemblaggio, nella finestra di output compare una cosa del genere (Figura 2.9): 16

17 Figura 2.9 Segnalazione di errore nell assemblaggio Qui sono importanti due righe: l ultima ( BUILD FAILED, assemblaggio fallito), che ci dice che qualcosa è andato storto, e quella marcata Error[113], che spiega sinteticamente l errore: nella riga 36 del sorgente.asm c è un simbolo (interrupt) che non è stato definito. Non è detto che sia l unico errore, ma i default l assemblatore si ferma quando si verifica il primo (c è scritto nella penultima riga). Per capirci meglio si clicca due volte sulla riga d errore e ci si ritrova nell editor (Figura 2.10): Figura 2.10 Segnalazione d errore nell Editor con una freccia verde che indica la posizione dell errore nel sorgente. Qui l errore è semplice: abbiamo scritto goto interrupt, ma l etichetta interrupt non è definita da nessuna parte; il salto dovrebbe essere alla routine di interrupt, ma se andate a vederla, è contrassegnata dalla etichetta interr (come affermato nel testo), non interrupt. Cambiamo interrupt con interr (o vicerversa) e riassembliamo (di nuovo Project>>Build All). Se non ci sono altri errori la barra di avanzamento resta verde e alla fine nella finestra di output compare un messaggio rassicurante (Figura 2.11): 17

18 Figura 2.11 Assemblaggio riuscito BUILD SUCCEEDED: Asseblaggio riuscito. I due Message[302] non sono errori, ma warnings, avvertimenti. I warnings ci avvisano di fare attenzione per ché lì potremmo avere dimenticato qualcosa; in questo caso corrispondono a un operazione su un registro che si trova in uno dei banchi RAM superiori (ad esempio, il primo, riga 42, è l istruzione movwf TRISB, e TRISB è nel banco 1), e ci dicono di controllare se abbiamo settato opportunamente i bit RP0, RP1, come è richiesto per accedere a tali banchi. Noi lo abbiamo fatto (bsf STATUS, RP0), ma purtroppo l assemblatore non è abbastanza intelligente per accorgersene. In generale, la diagnostica è un po spartana e la segnalazione degli errori non sempre chiarissima: ad esempio, se mettete un'etichetta dopo la prima colonna, il messaggio d errore non sarà questo, ma si limiterà a segnalare un istruzione sconosciuta, perché l assemblatore non può sapere che nelle vostre intenzioni quella doveva essere un etichetta. L assemblaggio produce una serie di file di servizio con lo stesso nome del sorgente ed estensioni diverse. Il più importante è un file di testo con estensione.hex, che si possono visualizzare con lo stesso editor. Ecco Programma 1.HEX: : FA : D1 : F : F B168B10C0 : B A3C F3C86115D : F200030EF300F10A730E8300F20E92 : E8B :02400E00313F40 : FF Sono i codici esadecimali delle parole di 14 bit che costituiscono la traduzione in linguaggio macchina del codice assembly, ma sono difficilmente riconoscibili, sia perché sono scritti con il byte basso prima di quello alto, sia perché sono annegati fra altri byte di controllo. E comunque un formato standard con cui il codice viene passato al programmatore. Più leggibile e utile per capire come è organizzato il codice è l altro file di testo 18

19 Programma.lst (il cosiddetto disassemblato). Eccone un frammento: Immediatamente davanti all istruzione o alla definizione di costante c è un numero di 5 cifre decimali che è il numero di linea di testo nel file sorgente: ad esempio la definizione di CONTATORE è alla linea 00023, cioè 23. Notare che sono numerate anche le linee vuote. Più a sinistra, se è una definizione di costante c è il valore della costante stessa in 8 digit esadecimali (4 byte): ad esempio è il valore della costante (indirizzo) CONTATORE, ovviamente coincidente con il valore 0x71 attribuitole dalla direttiva EQU. Se è un istruzione, troviamo 4 digit esadecimali che sono il suo indirizzo in memoria e altri 4digit esadecimali che ne rappresentano il codice-macchina a 14 bit. Ad esempio 0004 è l indirizzo in memoria dell istruzione goto interr e 2819 ( in binario su 14 bit) il suo codice. In fondo al file c è una lista riassuntiva dei simboli (costanti) definiti nel programma. Ci sono quelli creati da noi (CONTATORE, interr, ecc) e tutti quelli definiti nel file.inc, tra cui tutti i nomi dei registri speciali. La simulazione In MPLAB c è un simulatore molto potente, che permette di testare il programma senza hardware aggiuntivo. Comunque, anche se disponete del target fisico, una passata preliminare al simulatore conviene sempre, per capire se abbiamo commesso errori nella logica del programma. Le uniche limitazioni del simulatore riguardano le periferiche: in generale è possibile simularle forzando i valori nei relativi registri, ma i tempi (in termini di cicli macchina) possono essere imprecisi. Ma alcuni casi, come per la porta PSP, le periferiche non sono implementate. Per accedere al simulatore, si deve selezionarlo come strumento di debug: Debugger>>Select Tool>>2 MPLAB SIM Il menu di Debugger, da cui voce Select Tool abbiamo appena selezionato il simulatore, ha numerose altre voci (Figura 2.12): 19

20 Figura 2.12 Menu Debugger Per il momento ci interessano quelle di esecuzione del programma: Run (tasto di scelta rapida F9) Fa partire l esecuzione (in simulazione) alla massima velocità consentita dal PC host. La visualizzazione dei registri è possibile, ma non in tempo reale. Halt (tasto F5) Ferma l esecuzione, senza resettare la CPU. Animate L esecuzione è rallentata, un puntatore indica l istruzione in corso di esecuzione. Possibile la visualizzazione dei registri. Step Into (tasto F7) Come in animate, ma e istruzioni vengono eseguite passo-passo. Tra un passo e l altro è possibile modificare i registri. Step Over (tasto F8) Come Step Into, ma le subroutine vengono eseguite in un solo passo, come se fossero un unica istruzione. Step Out Per terminare in un solo passo l esecuzione di una subroutine e uscirne Reset Accede a diverse possibilità di reset. La più usata resetta il PIC come all atto dell accensione, ed è Reset>>Processor Reset F6 (tasto rapido F6). Prima di partire abbiamo però bisogno di un paio di altre cose: Dobbiamo avere la possibilità di osservare i registri che ci interessano, in particolare CONTATORE e PORTB (per osservare l uscita). Potremmo farlo da View>>4 File Registers, ma vedremmo una mappa di tutti i registri RAM, in un abbondanza poco leggibile. Meglio aprire una finestra di watch (osservazione) con View>>9 Watch. Le finestre a disposizione sono 4, noi usiamo solo la prima, Watch 1, quella di default. 20

21 Aprendo il menu a tendina a destra del pulsante Add SFR (aggiungi Special File Register, registro d archivio specializzato) si può selezionare qualunque registro specializzato, compreso W (anche se non è un registro d archivio). A noi interessano PORTB, TRISB, INTCON, W (Figura 2.13): Figura 2.13 Finestra di Watch, selezione dei registri Il registro selezionato nel menu a tendina compare va confermato cliccando su Add SFR. Il registro CONTATORE è però un simbolo definito da noi, e lo dobbiamo cercare nel menu a tendina a fianco del bottone Add Symbol (Aggiungi Simbolo), sui cui abbastanza ovviamente si deve cliccare per confermarlo. 21

22 Alla fine la finestra di watch contiene tutti i registri selezionati (Figura 2.14): Figura 2.14 Registri selezionati per l osservazione Notate che a fianco di ciascun registro d archivio compare il suo indirizzo (Address) in esadecimale, e che il registro W è indicato con WREG. Di default il contenuto dei registri è visualizzato sia in esadecimale, che in decimale che in binario. L altra operazione da fare è decidere come simulare l input. Il modo professionale di farlo è di creare un file di stimoli, che contiene la successione dei valori che vogliamo iniettare negli ingressi e la specifica dei tempi (cicli macchina) a cui ciò deve avvenire. Rimandiamo per i particolari all help del simulatore (Help>>Topics >>MPLAB SIM) e qui usiamo il metodo più immediato di forzare gli ingressi da mouse in modo asincrono rispetto all esecuzione del programma: Debugger>>Stimulus Controller>>New Scenario. Nella finestra che si apre (Figura 2.15), cliccate nella prima casella della prima linea bianca (sotto Pin/SFR) e, dal menu tendina che appare e che contiene tutti i pin, selezionate INT0 (o RB0, che è lo stesso): 22

23 Figura 2.15 Selezione ingressi da stimolare Cliccando sulla casella a fianco (sotto Action) si apre il menu degli eventi che si possono associare al pin: Set High Il pin va alto, e ci resta. Set Low Il pin va basso, e ci resta. Toggle Il pin cambia stato (da alto a basso, o da basso a alto). Pulse High Il pin va alto per un ciclo-macchina, poi torna basso. Pulse Low Il pin va basso per un ciclo-macchina, poi torna alto. Dovendo simulare un interrupt su fronte di salita, scegliamo Pulse High. Per confermare si clicca su una qualunque casella vuota, o si sposta il cursore del mouse sulla colonna grigia a sinistra (Fire). Compare un > bottone che andrà cliccato per attivare l evento (Figura 2.16): 23

24 Figura 2.16 Lo stimulus Controller è pronto Non dimenticare di salvare la configurazione di stimolo: Save Scenario. Il nome del file può essere lo stesso del sorgente. Assicuriamoci per finire che siano visibili la finestra dell editor con il sorgente, quella di watch e quella degli stimoli. Se ne abbiamo persa qualcuna, si può vedere se sono nascoste da qualche parte (Window). Se proprio non ci sono, il sorgente può essere recuperato da View>>Project alla voce Source Files; la finestra di watch da Wiew>>Watch e la finestra degli stimoli recuperando il file relativo da Debugger>>Stimulus Controller>>Open Scenario. Al posto del sorgente, se si preferisce, si può utilizzare il file.lst (disassemblato), richiamandolo da View>>1 Disassembly Listing. Chiudiamo eventuali altre finestre e ridimensioniamo quelle che ci servono cercando di avere una vista la più confortevole possibile 6. E adesso partiamo cominciamo con la: Esecuzione passo-passo Possiamo attivarla da menu, ma è più semplice usare il tasto di scelta rapida Step Into (F7). Selezioniamo la finestra del sorgente (editor) cliccandoci dentro e diamo un reset (F6) per sicurezza. Compare una freccia verde che punta alla prima istruzione (goto start): la freccia punterà sempre alla prossima istruzione da eseguire: rappresenta di fatto l azione del Program Counter (PC). Nel contempo (finestra di watch) i bit di TRISB vanno tutti a 1 (e la riga corrispondente diventa rossa). E giusto, perché i registri TRIS al reset (e all accensione) asumono di default il valore b , perché tutti i PORT di default hanno tutte le linee in ingresso. Il cambiamento di colore indica che il registro è stato modificato. Se adesso premiamo ripetutamente F7 possiamo 6 In ogni momento si può sospendere il lavoro, basta rispondere sì alla domanda Do you wish save the workspace before closing? (Volete salvare lo spazio di lavoro?), che appare quando cercate di uscire da MPLAB. Per riprendere il lavoro, con tutte le configurazioni in atto e le finestre aperte al momento della sospensione, recuperate il progetto da Project>>Open 24

25 osservare il progredire del programma e il modificarsi dei registri in conseguenza dell esecuzione delle varie istruzioni (Figura 2.17): Figura 2.17 Esecuzione passo-passo Alla fine il programma si intrappola nel ciclo loop goto loop. Adesso fermiamoci un attimo, prendiamo nota dell istruzione puntata dalla freccia verde e clicchiamo su > in corrispondenza di INT0 nella finestra degli stimoli; alla prossima pressione di F7 vediamo che: 1. Va in esecuzione, come sempre con F7, l istruzione puntata (se è un istruzione che modifica il registro, lo si vede controllando il registro stesso). 2. Si alza il bit INTF, che è il bit 1 di INTCON, segnalando la richiesta di interrupt. 3. La freccia salta alla locazione 0004h (risposta all interrupt). E da lì in avanti (con un salto a interr) viene eseguita la routine di interrupt. Quando si incontra retfie il programma ritorna all istruzione successiva a quella puntata per ultima prima dell interrupt 7. Notare che CONTATORE è stato incrementato. A questo punto comunque conviene passare alla modalità Animate Si attiva con Debugger>>Animate. Le istruzioni vengono eseguite una alla volta, a una velocità ridotta che permette di vedere il movimento della freccia (program Counter) e l adeguamento dei registri. E istruttivo, anche se non adatto a programmi (o cicli) troppo lunghi. Comunque, nel nostro caso, il funzionamento dell interrupt si vede bene, e così pure quello di tutto il programma nel complesso (tenete d occhio l uscita RB3, bit 3 di PORTB, per assicurarvi che il programma faccia quello che deve fare). 7 Nella simulazione passo-passo c è un imprecisione nel tempo di latenza dell interrupt: l istruzione puntata (la prossima) viene sempre eseguita, perché questa è la funzione di F7; nell interrupt reale viene solo termita l istruzione in corso. 25

26 La velocità di Animate si può regolare da Debugger>>Settings Si apre una finestra in cui, sotto il tab Animation / Realtime Updates, casella Animate Step Time si può fissare il passo con una risoluzione (approssimativa) di 1 ms (Figura 2.18). Figura 2.18 Simulator Settings Per fermare l esecuzione Halt dal menu Debugger o, se è attiva la finestra del codice, F5. Notare che la CPU si ferma dov è, non ritorna all inizio. Per quello dovete resettarla (F6). L ultima modalità di esecuzione in simulazione è: Run accessibile dal solito menu Debugger o con F9 se la finestra di codice è attiva. Qui la simulazione avviene alla massima velocità consentita dal PC host, senza animazione a video (la condizione di Run, oltreche da una barretta mobile in basso a sinistra al desktop, è segnalata dalla freccia verde che diventa semitrasparente e resta ferma all istruzione puntata al momento del lancio). Nelle versioni precedenti di MPLAB in Run non era possibile vedere i registri: bisognava fermare l esecuzione (Halt) per vedere il risultato complessivo delle modifiche fino a quel momento. A partire dalla versione 7.40 è possibile abilitare l update della finestre di watch in tempo reale, a intervalli multipli di 100 ms. Lo si fa dalla stessa finestra Simulator Settings in cui si regola la velocità di animazione (Figura 2.18, box Realtime Watch). I Breakpoint Un breakpoint (puntodi interruzione, di sospensione) è un segnalino che si può attaccare a un istruzione, e che determina l interruzione dell esecuzione immediatamente prima dell istruzione marcata. Dal breakpoint si può ripartire sia in Run, che in Animate o in Single Step. I breakpoint sono molto comodi per poter controllare risultati intermedi, per assicurarci che il programma passi effettivamente per un determinato punto, per analizzare passo-passo sezioni di programma senza doverlo eseguire tutto nello stesso modo. In simulazione non c è limite al numero di breakpoint. I breakpoint possono essere gestiti da menu: Debugger>>Breakpoints F2 (finestra richiamabile anche con il tasto di scelta rapida F2). Tuttavia è più semplice lavorarci direttamente dalla finestra 26

27 dell editor, sul sorgente.asm o sul file.lst. Vediamo un esempio: vogliamo nel nostro programma mettere un breakpoint all inizio della routine di interrupt, per verificare (anche se lo sappiamo già) che il programma senta effettivamente l interrupt. Basta puntare nel sorgente (o nel disassemblato) la linea che ci interessa (interr movwf W_TEMP), cliccare con il tasto destro e, nel menu a tendina che compare, selezionare Set Breakpoint (Figura 2.19): Figura 2.19 Introduzione di un breakpoint Il risultato lo si vede in Figura 2.20, dove il breakpoint è marcato da una B bianca cerchiata di rosso: 27

28 . Figura 2.20 Breakpoint attivo Se adesso mandiamo il programma in Run e dopo un po simuliamo un interrupt, vedremo l esecuzione bloccarsi sul punto prescelto, con la freccia verde sovrapposta al bollino del break point. Un breakpoint può essere cancellato (lo si punta, tasto destro, voce Remove Breakpoint nel menu a comparsa) o, molto utile, disabilitato senza cancellarlo (stesso menu, voce Disable Breakpoint). Un breakpoint disabilitato è segnato dal bollino rosso vuoto e la voce Disable Breakpoint è sostituita da Enable Breakpoint. Nel menu a comparsa c è anche una voce Breakpoints che rimanda alla possibilità di abilitare/disabilitare/cancellare tutti i breakpoint insieme. Il debugging in-circuit (autoemulazione) Se abbiamo la scheda target, possiamo adesso provare il software in real-time sul circuito finale. Supponiamo di aver già assemblato il programma (Project>>Build All) e di aver collegato l ICD2 al PC (meglio se prima di lanciare MPLAB) e il PC all ICD2. E consigliabile che il target abbia un suo alimentatore (Figura 2.1, immagine a sinistra): l ICD2 può alimentare il target, ma deve prendere l energia dalla porta USB del PC, e non è detto che la porta ce la faccia. E MOLTO IMPORTANTE COLLEGARE PRIMA L ALIMENTAZIONE AL TARGET, POI IL TARGET ALL ICD2, altrimenti si rischia di bloccare tutto! Anzitutto accertatevi che l ICD2 non sia già selezionato come programmatore: Programmer>>Select Programmer e spuntate la voce None (nessuno), se non lo è già. Poi selezionatelo come Debugger: Debugger>>Select Tool>>1 MPLAB ICD2. A questo punto, almeno per la prima volta, bisogna configurare l ICD2: Debugger>>MPLAB ICD2 Setup Wizard, poi Avanti e compare il box Communications (Figura 2.21): 28

29 Figura 2.21 Setup Comunicazione Che permette di selezionare (Com Port) il tipo di comunicazione PC ICD2. Se selezionate una porta seriale (COM 1, COM 2, ), poi dovete scegliere anche il Baud Rate. Qui supponiamo di usare la porta USB. Ancora Avanti e nel box successivo spuntate Target has own power supply (il target ha la sua alimentazione separata). Al nuovo Avanti vi si chiede se volete che l ICD2 si connetta automaticamente allo start del programma. Conviene di no (default), per avere più controllo sul sistema: lasciate le cose così come sono. Avanti, e adesso dovete decidere se il download (sull ICD2) del sistema operativo per il PIC che state usando deve essere automatico (default) oppure no. Non c è ragione perché dobbiate farlo a mano, lasciate così, Avanti. Compare un box riassuntivo della configurazione, se vi va bene (dovrebbe) Fine. Adesso connettetevi all ICD2: Debugger>>Connect. Se è la prima volta che usate il PIC selezionato, ci vorrà un po di tempo per il download del sistema operativo (barretta verde di progressione in basso a sinistra, Downloading Operating System). Però alla fine nella finestra di output (View>>Output se non si apre da sola) deve apparire qualcosa di simile (Figura 2.22): 29

30 Figura 2.22 Connessione avvenuta Dove l importante sono le ultime due righe: Passed / MPLAB ICD2 Ready (test superato / ICD2 pronto). Una cosa come in Figura 2.23, dove compaiono scritte in rosso: Figura 2.23 Comunicazione assente vuole invece dire che qualcosa è andato storto e non è stato possibile stabilire la comunicazione. Auguratevi che abbiate semplicemente dimenticato di collegare al PC l ICD2! 30

31 Se invece si apre il box di Figura 2.24: Figura 2.24 Device (microcontrollore) errato alla lettera significa che l identificatore del dispositivo non coincide con quello del microcontrollore che avete specificato nella considerazione. Può succedere se avete collegato un target con un microcontrollore diverso, ma il più delle volte significa semplicemente che il sistema non trova nessun microcontrollore: avete dimenticato di connettere il target all ICD2, o avete dimenticato di alimentarlo. Supponendo di aver risolto tutti i problemi, si programma il dispositivo: Debugger>>Program. In un tempo che può arrivare alla decina di secondi, se tutta o gran parte della memoria programma è da scrivere (non è il nostro caso!), il programma in linguaggio macchina viene caricato sulla flash del microcontrollore (insieme al minisistema operativo di debugging). Se tutto è andato bene nella finestra di output compare un messaggio alle cui ultime righe c è il fatidico:...programming succeeded (programmazione riuscita) A questo punto potete usare gli stessi modi di esecuzione (Step by Step, Animate e Run) che avevate a disposizione in simulazione: la differenza, sostanziale, è che adesso il programma gira sul microcontrollore del target, e interagisce con le periferiche di I/O reali, in tempo reale. Naturalmente il box degli stimoli simulati non è più attivo, e dovete provvedere a un vero fronte di salita in ingresso a RB0/INT per chiamare interrupt. Ci sono però alcune limitazioni, sostanzialmente dovute al fatto che la modalità di autoemulazione utilizza ruba alcune risorse hardware. Le più importanti sono: La comunicazione durante il debugging usa i pin, RB6 e RB7, che quindi non possono essere usati come I/O dal target per il suo programma. La comunicazione usa anche MCRL, che deve essere tenuto alto da una resistenza di pull-up, per permettere all ICD2 di abbassarlo se necessario. Inoltre va ricordato che questo piedino viene portato a una tensione alta (circa +15 V) in fase di programmazione: attenzione a cosa ci è attaccato! L interrupt funziona solo nella modalità Run, non è quindi possibile osservare l effetto degli interrupt in esecuzione Step by Step o Animate. Il sistema operativo che gestisce l autoemulazione utilizza un po di memoria programma e alcuni registri d archivio. Nel PIC16F877A la memoria occupata va da da 0x1F00 a 0x1FFF 31