MPLAB ICD2 rappresenta una soluzione hardware/software messa a disposizione dalla Microchip per permettere a professionisti e hobbisti di tutto il mondo di programmare e fare il debug dei microcontrollori PIC in modalità ICSP (In Circuit Serial Programmation) e ICD (In Circuit Debugger)
Kit content:
- 1- MPLAB ICD2 - ICSP/ICD tool P/N:10-00397-R4;
- 1- cavo USB A-B M-M;
- 1- cavo seriale RS232 M-F;
- 1- alimentatore 220VAC – 9VDC / 0,75A;
- 1- cavo di alimentazione con spina giapponese per il collegamento alla rete dell’alimentatore in dotazione;
- 1- manuale “MPLAB IDE Quick Start Guide” che si propone come guida rapida all’utilizzo dell’ambiente di sviluppo MPLAB (affronta le fasi da seguire per un nuovo progetto dalla creazione al debug del codice utente);
- 1- manuale “MPLAB ICD2 In-Circuit Debugger User’s Guide” che rappresenta la vera e propria guida all’utilizzo dell’ICD2 (si va dalla descrizione dettagliata del principio di funzionamento del sistema di sviluppo per spaziare poi dai requisiti hardware/software che il sistema di debug richiede ai passi da compiere in ambiente MPLAB IDE per operare con la fase di programmazione e debug del PIC target);
- 1- CDROM contenente il software MPLAB IDE in una delle versioni 8.x e diversi manuali di istruzione e application notes in formato PDF;
- 1 volantino-scheda da compilare per la registrazione del prodotto e la garanzia.
MPLAB ICD2 full version kit.
MPLAB ICD2 rappresenta una soluzione hardware/software messa a disposizione dalla Microchip per permettere a professionisti e hobbisti di tutto il mondo di programmare e fare il debug dei microcontrollori PIC in modalità ICSP (In Circuit Serial Programmation) e ICD (In Circuit Debugger).
Lo strumento di svilippo ICD2 oggetto della recensione si presenta, visivamente, come uno scatolotto di forma cilindrica con un’altezza di poco superiore al centimetro e avente lungo la superficie laterale i vari attacchi per la connessione al PC e al PIC target (USB, RS232, RJ11 e il connettore per l’alimentatore esterno). Sulla faccia superiore colorata (con i colori rosso, bianco e blu) e marchiata con la dicitura “Microchip MPLAB® ICD2” sono presenti tre led che indicano lo stato del programmatore: “Power”, sempre acceso quando l’ICD2 è alimentato; “Error”, acceso e di colore rosso quando entrambe le connessioni PC-ICD2 e ICD2-PIC non sono correttamente inizializzate; “Busy”, acceso durante il trasferimento di dati tra il PC e il PIC target attraverso l’ICD2.
Come ICD2, la "10-00397-R4" è l’ultima versione prima dell’uscita di ICD3, contenente al suo interno, per la gestione della connessione USB, un PIC della serie 18F al contrario della prima versione che adoperava, per la medesima funzione di transcever USB, un microcontrollore della Cypress. La "10-00397-R4" (kit DV164007) è l’unica versione di ICD2 per la quale sono disponibili i driver per Windows7.
Secondo quanto dichiarato dalla stessa Microchip, l’ICD2 è in grado di programmare tutti i PIC delle serie 12F, 16F, 18F, 24F, dsPIC30, dsPIC33 prodotti entro il settembre del 2010. Tutti i modelli successivi potranno essere gestiti utilizzando ad esempio l’ICD3 (o uno tra i possibili tool di sviluppo riportati nel datasheet del PIC specifico).
Principio di funzionamento, vantaggi e limitazioni dell’utilizzo di ICD2.
Come sistema di supporto alla programmazione dei PIC micro, l’interfaccia ICD2 si presta ad essere utilizzata dallo sviluppatore di firmware per la diagnosi del proprio codice, ossia per programmare ma soprattutto per debuggare il codice da eventuali errori o sviste. Per fare questo è necessario che il progettista abbia una visione più ampia su quello che è il comportamento del microcontrollore in un determinato passo di firmware e ad un corrispondente comportamento dell’hardware esterno (sensori e attuatori).
Tralasciando la fase di semplice programmazione, i veri vantaggi e limiti di tale sistema di sviluppo si riscontrano sulla procedura di debug dove è necessario poter impostare dei breakpoint all’interno del codice e visionare variabili e SFR (Special Function Register) in corrispondenza degli stessi. Il limite fondamentale di ICD2, superato con la nuova proposta di casa Microchip ICD3, sta proprio nel ridotto numero di breakpoint impostabili all’avvio del firmware sotto debug (anche solo uno come nel caso della maggior parte dei PIC della seria 16F87x). Questo perché ogni microcontrollore su cui è possibile fare il debug deve contenere al suo interno un certo quantitativo di memoria programma da riservare ad uno stralcio di codice che viene caricato nel microcontrollore target durante la fase di preparazione al debug. Quest’aggiunta di codice, che non è necessaria durante la programmazione del microcontrollore per il funzionamento in stand alone, serve a rendere dipendente l’esecuzione del codice utente dai comandi impartiti dall’ambiente di sviluppo software MPLAB. Inoltre, per quanto riguarda il numero di breakpoint impostabili in contemporanea nel codice, questo dipende dalla disponibilità e dalla quantità di particolari registri dedicati proprio al debug. Nel dettaglio, quando il programmatore fissa un breakpoint nel codice tramite l’interfaccia grafica di MPLAB IDE, l’indirizzo dell’istruzione a cui punta il breakpoint è salvato all’interno di speciali registri di debug del PIC target. Una volta avviato il debug tramite un apposito pulsante di “Run”, l’esecuzione del firmware parte dall’indirizzo zero della memoria programma per bloccarsi all’indirizzo dell’istruzione successiva a quella salvata nel registro di breakpoint (un sorta di breakpoint runtime può essere impartito tramite un comando di “Halt” che pone il firmware in una condizione di attesa). Una volta che il firmware si inchioda nell’esecuzione, l’ICD2 comunica con MPLAB inviando lo status del breakpoint e MPLAB risponde a ICD2 richiedendo una serie di informazioni sul PIC target, come il contenuto dei registri e lo stato della CPU.
Quanto detto finora viene sintetizzato graficamente dalla figura seguente tratta dal manuale di ICD2 ©Microchip
nella quale è da evidenziare la porzione di memoria programma “Debug Executive” che rappresenta la parte di codice che in debugger mode viene programmato nel PIC target insieme al codice utente e che serve a rendere il firmware controllabile tramite i comandi impartibili da MPLAB IDE.
Dal funzionamento del processo di debug appena descritto si evincono dunque i pregi e le limitazioni che in breve possono essere riassunte nell’elenco seguente:
PREGI:
- possibilità di analizzare il proprio codice e ricercare errori e sviste di programmazione inevitabili soprattutto quando il firmware inizia a diventare complesso e strutturato su più file;
- eseguire il firmware in modalità step by step per analizzare possibili cicli infiniti o salti condizionati mancanti;
- avere un controllo diretto e “realtime” delle variabile e della memoria dati (includendo anche l’”Hardware Stack” e l’”EEPROM”) in modo da poter ricollegare al comportamento dell’hardware connesso al PIC target il relativo comportamento interno del MCU.
LIMITAZIONI:
- possibilità di impostare solo 1-2 (tipicamente) breakpoint per volta (dipende dal PIC specifico), anche se questa non rappresenta tutto sommato una limitazione stringente in quanto è possibile modificare la posizione del breakpoint a debug avviato;
- riservare delle risorse hardware/software per poter effettuare il debug e in particolare:
- RB6 e RB7 sono usati dall’ICD2 per la comunicazione seriale con il PIC target e non possono essere utilizzati per scopi diversi da questo;
- alcuni livelli dello stack del PIC target (tipicamente non più di 2) sono usati dall’ICD2 durante la fase di debug ed è necessario tenerne conto quando si effettuano chiamate in cascata a subroutine annidate;
- locazioni di memoria programma all’interno del PIC target espressamente dedicate al codice aggiuntivo di debug.
È da precisare, comunque, che le limitazioni non vanno intese come tali in senso stretto perché o risultano trasparenti al progettista (come l’occupazione di area di memoria programma o l’utilizzo di registri per il debug) oppure possono essere aggirate facilmente come nel caso del limitato numero di breakpoint all’avvio del debug (è limitato il numero di breakpoint all’avvio dell’esecuzione del codice ma è consentito spostare il breakpoint in maniera dinamica a debug avviato, con il risultato che è possibile bloccare il firmware in qualunque punto si voglia) ridonando all’ICD2 quella validità e professionalità tanto scelta dai progettisti per la loro programmazione e analisi del codice.
Breve tutorial sulla sinergia hardware/software ICD2-MPLAB IDE.
L’articolo proposto prosegue illustrando l’ICD2 come sistema di sviluppo completo messo a disposizione dei progettisti dalla Microchip e che tramite la sinergia Hardware/Software con l’ambiente di sviluppo MPLAB è possibile non solo la ICSP (In Circuiti Serial Programmation) ma anche e soprattutto l’ ICD (In Circuit Debug). Non si potrà quindi parlare in senso stretto di ICD2 se a questo non si associa il software MPLAB che segue il progettista interfacciandosi all’hardware sia nella programmazione che nel debug del codice utente.
Prima di procedere con la guida all’utilizzo di MPLAB associato a ICD2, è bene fare chiarezza su alcuni aspetti di carattere hardware necessari perché si instauri una corretta comunicazione tra ICD2 e il PIC target.
Considerazioni di carattere hardware.
L’ICD2 comunica serialmente con il PIC target attraverso le due linee PGC e PGD, rispettivamente RB6 e RB7. Inoltre necessita dei collegamenti di GND (VSS), VDD e MCLR. Il pin MCLR, in fase di programmazione è portato dall’ICD2 ad una tensione non inferiore ai 12.4V (VPP), mentre durante la fase di dubug tale pin viene posto a livello logico basso (VSS) per il reset del PIC target e a livello logico alto tramite una resistenza di pull-up da 10kohm (indispensabile perché l’uscita dell’ICD2 è di tipo open collector) per far partire l’esecuzione del firmware.
Sulle linee PGC e PGD non devono essere connessi componenti aggiuntivi come capacità di bypass verso massa o resistenza di pull-up di qualunque valore. Questo perché un condensatore in parallelo alla linea contribuisce con la resistenza interna all’ICD2 alla formazione di un filtro passabasso del primo ordine che, limitandone la banda, blocca le transizioni veloci dei segnali lungo la linea. Lo stesso vale per la linea VPP/MCLR. La resistenza di pull-up su una qualunque delle due linee contribuisce alla formazione di una partitore resistivo con la resistenza di pull-down (da 4.7kohm) interna all’ICD2 provocando una riduzione del livello di tensione attribuito al livello logico alto del segnale transitante lungo la linea. Sono da evitare anche diodi posti in serie alle linee PGC e PGD poiché trasformano le stesse da bidirezionali a unidirezionali.
Quando si è in debugger mode, il codice caricato all’interno del PIC target viene posto in esecuzione e quindi è necessario che il PIC sia alimentato e che disponga di un segnale di clock opportunamente generato (quarzo, rete RC, clock generato internamente), cosa che non è necessario che si verifichi durante la semplice programmazione del codice per la modalità di funzionamento stand alone.
Ultimo dettaglio hardware prima di addentrarci nell’utilizzo di MPLAB è relativo al cavo modulare 6+6 pin che connette l’ICD2 al connettore RJ-11 da predisporre sulla prototyping board, sede del microcontrollore da programmare e debuggare. La figura riportata di seguito mostra il collegamento fisico ICD2 - PIC e il pinout del connettore RJ-11 sulla prototyping board vista lato bottom (©Microchip).
Note aggiuntive per un corretto utilizzo dell’ICD2.
- Se è possibile, connettere l’ICD2 al PC tramite la connessione USB 2.0 per diverse motivazioni, prime tra tutte la maggiore velocità di trasmissione dei dati da e verso il PC e la maggiore stabilità della procedura di debug;
- Alimentare la prototyping board con alimentazione separata e non tramite l’ICD2;
- Seguire sempre la precisa sequenza di alimentazione delle parti costituenti il sistema di debug e in particolare PC -> ICD2 -> PIC target (o protoboard sede del PIC target). Una volta terminato il debug, per disalimentare le parti, è importante seguire l’esatta sequenza inversa ovvero protoboard -> ICD2 -> PC.
MPLAB IDE: programmazione del PIC target.
Premessa: al fine di focalizzare l’attenzione sulla sinergia ICD2 - MPLAB IDE, in questo paragrafo e nel seguente si supporranno scontati e preventivi i passi da seguire per la creazione di un nuovo progetto in MPLAB e ci si concentrerà su come effettuare la programmazione e il debug attraverso i comandi messi a disposizione dall’IDE.
Ipotizzando di aver creato un nuovo progetto e scritto il codice, una volta compilato il tutto tramite il comando “Build All”, MPLAB permette di trasferire il codice eseguibile sul microcontrollore target attraverso i programmatori hardware supportati visualizzati nell’elenco presentato dal menù MPLAB “Programmer -> Select Programmer”. Se l’ICD2 è stato correttamente installato, tramite i driver disponibili con l’installazione di MPLAB, allora comparirà tra le voci selezionabili dal menù Programmer. Selezionando quindi il programmatore Microchip ICD2 verranno visualizzati nella barra degli strumenti i seguenti pulsanti:
Il pulsante abilitato nella figura permette di effettuare la connessione software tra PC e ICD2. Quando l’ICD2 è connesso fisicamente sia al PC (è consigliabile tramite porta USB) che alla protoboard (tramite cavetto apposito, vedi manuale Microchip), è possibile effettuare il download del programma appena compilato con il comando “Programmer -> Program”. Se la connessione è andata a buon fine, allora la barra degli strumenti visualizzata precedentemente si arricchisce di pulsanti abilitati che permettono di programmare, leggere e verificare il PIC target senza dover accendere al menù a tendina “Programmer”. Passando con il mouse sui vari pulsanti, compare una label ad indicare la funzione del singolo pulsante. Se, al contrario, la connessione PC-ICD2 è andata a buon fine (lo si riscontra dai messaggi di errore/warning riportati nella finestra output ICD2 dell’IDE) mentre non si riesce ad instaurare un dialogo tra l’ICD2 e il PIC target, allora si tratta certamente di ricercare un problema hardware lato protoboard. Per poter capire dove sia l’errore è comodo consultare lo “Status Tab” richiamabile dal menù MPLAB “Programmer -> Settings -> Status” e guardare nel riquadro “Self test”. A titolo puramente esemplificativo, di seguito sono riproposte le finestre dello Status della connessione nel caso in cui manca la resistenza di pull-up sul pin MCLR e nel caso in cui la mancanza hardware viene ripristinata con conseguente corretta comunicazione tra ICD2 e protoboard.
MPLAB IDE: debug del codice utente su PIC target.
Oltre che a programmare, come già menzionato in precedenza, l’ICD2 permette all’utente di debuggare il proprio codice in tempo reale impostando un certo numero di breakpoint e monitorando in realtime la variazione di registri e variabili con l’importante scopo di estendere la visione del progettista a ciò che sta accadendo all’interno del PIC target in corrispondenza di un determinato passo di firmware.
Per usufruire delle funzionalità di debug messe a disposizione da MPLAB occorre fare riferimento al menù a tendina “Debugger”. Da tale menù, è anzitutto necessario selezionare la modalità con cui si desidera eseguire il debug dell’applicazione sviluppata, in funzione degli strumenti che si hanno a disposizione. Ad esempio, nel caso specifico dell’ICD2 è sufficiente selezionarlo come debugger (menù “Debugger -> Select Tool”) e procedere come visto per la programmazione del PIC target. A questo punto l’esecuzione del firmware programmato nel PIC è comandata direttamente tramite l’interfaccia di MPLAB, attraverso la barra grafica seguente:
nella quale sono presenti i pulsanti per l’avvio e l’arresto del programma, l’esecuzione step by step con salto all’interno delle funzioni o oltre le funzioni e il reset del microcontrollore (per fare ripartire il firmware dall’inizio).
A questo punto, una volta entrati nella mera modalità di debug, dal menù “View” di MPLAB è possibile impostare la visualizzazione del contenuto “simulato” del PIC target, come ad esempio la Program Memory, i File Register (Memoria RAM), gli Special Function Registers (SFR), l’Hardware Stack, la memoria non volatile EEPROM e così via. Se si vogliono tenere sotto controllo solo alcuni particolari SFR, allora è possibile impostare la finestra “Watch” (“View -> Watch”) andando a sceglierli nell’elenco “Add SFR” (di seguito è riportato lo screenshot della schermata MPLAB con il debug in funzione).
Conclusioni.
Spero che questa mia recensione/guida/articolo possa rappresentare un riferimento per tutti coloro che intendono accostarsi per la prima volta all’acquisto e all’utilizzo di un sistema di sviluppo completo come ICD2 per la programmazione e il debug dei microcontrollori di casa Microchip.
Dato che in commercio è già da tempo disponibile l‘ICD3, è molto probabile che l’ICD2 si riesca ad acquistare usato o a prezzo notevolmente basso, facendo però attenzione alla versione: la versione "10-00397-R4" (kit DV164007) illustrata in questo articolo è l’unica supportata da Windows7 quindi, se volete acquistare un prodotto che vi duri e che sia compatibile con l’ultimo sistema operativo Windows, vi consiglio di scegliere questa versione.
Ringraziamenti.
Ringrazio Elettronica Open Source per l’iniziativa Review4U che mi ha permesso di disporre di un ICD2 personale con il quale lavorare senza dipendere dall’attrezzatura universitaria. Grazie ancora e magari, in futuro, potrò proporre qualche progetto interessante da condividere con la comunità di EOS.
Conclusioni.
Spero che questa mia recensione/guida/articolo
possa rappresentare un riferimento per tutti coloro che intendono accostarsi
per la prima volta all’acquisto e all’utilizzo di un sistema di sviluppo
completo come ICD2 per la programmazione e il debug dei microcontrollori di
casa Microchip.
Dato che in commercio è già da
tempo disponibile l‘ICD3, è molto probabile che l’ICD2 si riesca ad acquistare
usato o a prezzo notevolmente basso, facendo però attenzione alla versione: la
DV164007 illustrata in questo articolo è l’unica versione supportata da
Windows7, quindi se volete acquistare un prodotto che vi duri e che sia
compatibile con l’ultimo sistema operativo Windows, vi consiglio di scegliere
questa versione.
Ringrazio Elettronica Open Source
per l’iniziativa Review4U che mi ha permesso di disporre di un ICD2 personale
con il quale lavorare senza dipendere dall’attrezzatura universitaria. Grazie
ancora e magari, in futuro, potrò proporre qualche progetto interessante da
condividere con la comunità di EOS.
Microchip ICD2 in vendita da Farnell.
Ottima recensione del prodotto, ma niente di diverso da ciò che si può leggere dalla documentazione presente sul sito della Microchip. Penso che se l’assegnazione dipende da “indicazioni sull’utilizzo, immediato o futuro, della Board con eventuali applicazioni ed idee”, quanto meno nella recensione ci debba essere un riferimento a quelle idee, delle foto dell’applicazione, un minivideo magari del funzionamento di un circuito in modalità debug ad esempio, visto che c’è tempo 1 mese per recensirlo. Intendo dire che ci dovrebbe essere quel qualcosa in più che faccia capire che lo si è utilizzato davvero, fosse anche solo far lampeggiare un led. Perchè altrimenti per aggiudicarsi un kit qualsiasi basta solo spararla grossa e poi girare come recensione la traduzione in italiano di un manuale un datasheet o una guida qualsiasi.
Saluti.
Sinceramente nutro anch’io dubbi, e qualche rimorso,sulla gestione di tale iniziativa. La critica non parte da questo articolo, dato che la maggior parte delle recensioni sembra seguano tale politica. Sono comunque molto contento perché mette a disposizione potenti strumenti ad hobbysti (e non) che ci penserebbero un bel pò prima dell’acquisto.Inoltre ce ne sono ben pochi di siti disposti a tanto.
Il nostro è solo un consiglio affinché la serietà del sito (o, come si dice, “impact factor”) cresca…
Un saluto a tutti
Lucio
Vi ringrazio per i commenti, sicuramente i vostri suggerimenti sono utili e ne terremo conto!
Ma vorrei approfondire:
@FabioA
quello che dici è sacrosanto, ma come attuarlo?
Mi spiego meglio. Anche a me farebbe piacere vedere una recensione che mette in pratica l’idea, ma questo molte volte è difficilmente realizzabile in 30gg ed ancor di piu controllabile. Come posso essere sicuro, una volta inviata la scheda, di ricevere una recensione, o meglio una applicazione di qualità? Ovviamente senza contratti e fidejussioni che decimerebbero la community. Sarebbe poi comunque opinabile, dovrei PRIMA vedere l’articolo, ma come , senza la board?
Da questo nasce l’idea di proporre applicazioni valide, ed io verifico che non la si “spari grossa”, ma poi la richiesta è per la recensione, o il “getting started”. Certo se l’autore riesce a proporre qualcosa di interessante, buon per la community, ma soprattutto buon per lui, dato che le pubblicazioni sono nominative.
Insomma io ho avuto l’idea, gli sponsor li ho trovati, i prodotti ci sono, molti ne abbiamo dati e molti ne daremo…. che dire, sta solo a voi meritarli!
La community è bella anche perche varia, si scrive, si critica, si cresce insieme!
@lucioverde
>Sinceramente nutro anch’io dubbi, e qualche rimorso,sulla gestione di tale iniziativa
Facci parteci dei tuoi dubbi, ma come ho scritto sopra è difficile controllare a posteriori senza risultare troppo fiscali con contratti ed altro… siamo progettisti non avvocati.
comunque ti ringrazio per i complimenti finali 🙂
@alex87
La tua recensione, a mio avviso, è accettabile, anche se i due commentatori non la pensano cosi, quindi:
@lucioverde @ FabioA
dico, se voi sapete fare di meglio di “girare come recensione la traduzione in italiano di un manuale un datasheet o una guida qualsiasi”, benissimo,allora fatevi avanti, ho una demoboard (ICD2) a disposizione per ciascuno di voi!
Se vai a rileggere il commento per cui mi sono aggiudicato ICD2, ti renderai conto che la mia recensione è aderente a ciò che avevo promesso di scrivere, appunto un getting started sull’utilizzo di questo tool di sviluppo di casa Microchip. Quindi non l’ho sparata grossa ma penso di aver dato ad Elettronica Open Source ciò che cercavano!