Corso programmazione microcontrollori PIC® in C (aggiornamento) – Transizione da MPLAB IDE 8 a MPLAB X IDE e da Hi-Tech PICC a XC8

Dato che in molti me l’hanno chiesto, ho pensato di “rispolverare” i vecchi sorgenti del mio Corso di programmazione microcontrollori PIC® in C (la cui prima lezione risale al 2009) per poterli adattare al nuovo MPLAB X IDE e al nuovo compilatore XC8.

Anche se è possibile continuare ad utilizzare il vecchio MPLAB IDE e i vecchi compilatori Hi-Tech PICC, C18, C30, C32  è chiaro che se un po’ alla volta passiamo ai nuovi software ne gioveremo in termini di assistenza, manutenzione, tempi di sviluppo, features e quant’altro. Il nuovo MPLAB X IDE, difatti, è basato su una piattaforma consolidata da tempo: Netbeans, il che vuol dire che verrà sempre aggiornato e sarà sempre ricco di nuove interessanti funzionalità grazie alla possibilità di installare plugins: incomincio col dire che ci sono tools integrati che permettono di settare graficamente i registri dei picmicro, la config word, ci sono librerie dedicate e tante altre bellissime cose.

Il nuovo IDE è perfettamente utilizzabile anche dagli utenti Linux e Mac, nonchè online in qualsiasi browser utilizzando la versione online che si chiama MPLAB Express, che, tra l’altro, ci consente anche di salvare i nostri progetti sul cloud e condividerli con altri utenti, senza il rischio di perderli.

Anche i compilatori sono stati aggiornati: ad esempio non c’è più quella diatriba tra Hi-Tech per pic18 e il compilatore C18 della Microchip, a cui dovevamo aggiungere anche Hi-Tech PICC se volevamo programmare i soli PIC10/12/16: adesso tutti i PIC® ad 8 bit hanno un unico compilatore: XC8 che racchiude tutte le cose buone dei compilatori precedenti: la sintassi del C18 e l’efficienza dell’Hi-Tech PICC (il nuovo XC8 è difatti il vecchio compilatore Hitech aggiornato!). Lasciatemi dire: Finalmente!

Sono quindi disponibili: il nuovo compilatore per tutti i pic a 16 bit (PIC24, dsPIC) che è l’XC16 (almeno il nome ha più senso… prima si chiamava C30!) e il nuovo compilatore per i PIC32: XC32. I compilatori sono tutti molto simili tra loro il che vuol dire che con piccole accortenze e un minimo sforzo è possibile portare il codice da una piattaforma all’altra. Utilizzando poi le funzioni offerte dal Code Configurator, integrato in MPLAB X IDE, portare il codice è ancora più semplice.

Avevo iniziato tempo fa a convertire i sorgenti del mio corso per le nuove piattaforme e solo adesso mi sono deciso a pubblicarle, purtroppo il tempo libero va diminuendo. Incomincio col dire che i nuovi articoli saranno molto spiccioli: ci saranno i sorgenti da scaricare e poche altre informazioni: vorrei che cominciaste anche voi a fare questo lavoro, che tra l’altro è molto semplice, e se riuscite a portare vecchi codici che avete trovato qui (mi riferisco ad applicazioni complete) e funzionano potete anche inviarmeli così da condividerli con tutti.

Mettete il link di questo articolo nei segnalibri perchè vi sarà sempre utile dato che ci sono anche tutti i collegamenti importanti. Bene, incominciamo a vedere come usare i nuovi ide e compilatori cercando di capire le differenze con i vecchi sistemi.

Downloads

Qui vi do tutti, ma proprio tutti i links utili. Cominciamo innanzitutto a scaricare il materiale che ci serve, e cerchiamo di tenerlo aggiornato. Il nuovo ide si chiama MPLAB X IDE ed è possibile scaricarlo gratuitamente da qui: http://www.microchip.com/mplab/mplab-x-ide.

Dopo averlo installato può lui stesso scaricarvi i compilatori XC (viene visualizzata una finestra alla fine dell’installazione in cui vi viene chiesto se volete farlo). In genere io li scarico sempre a parte mentre scarico anche l’IDE per risparmiare tempo dato che si tratta comunque di files corposi. I compilatori XC8 (valido per TUTTI i PIC® ad 8 bit: PIC10/12/16/18), XC16 (valido per tutti i pic a 16bit: PIC24,dsPIC) e XC32 (valido per i pic a 32bit: PIC32), li potete scaricare in versione gratuita (con limitazione sull’ottimizzazione del codice) dal link seguente andando nel tab “Downloads”: http://www.microchip.com/mplab/compilers

In quella stessa pagina se andate al tab “Documentation” trovate tutte le Guide utente (che sono comunque già incluse nel download del compilatore), le guide di migrazione (se usavate il C18, consigliato scaricare la guida relativa) e i manuali delle librerie.

La cosa bella del nuovo IDE è che quando ci sono aggiornamenti (dell’IDE stesso, dei compilatori, dei plugin) ve lo segnala e può fare l’aggiornamento automatico.

Librerie Microchip

Come dicevo nell’introduzione, MPLAB X IDE include il Code Configurator che può aiutare molto nella realizzazione delle librerie per le periferiche. Questa nuova funzionalità la sto studiando da poco aiutandomi con un libro del mio autore preferito, Lucio Di Jasio, ma di questo forse ne parleremo più in la.

Per i PIC32 la Microchip ha addirittura creato un tool apposito che genera già tutte le librerie e che si chiama MPLAB Harmony.

Altro download molto utile è quello relativo alle Microchip Libraries for Application (MLA, che una volta si chiamava MAL, le parole dell’acronimo sono le stesse ma cambia leggermente il senso) che contiene esempi completi di applicazioni, interessanti quelle relative all’USB. Gli esempi sono comunque legati alle schede di sviluppo della Microchip. Il download della MLA è disponibile qui.

E’ disponibile una pagina con il download di librerie addizionali, a questo link e un’altra con esempi di codice qui

In aggiunta la Microchip ha creato un sito in cui vengono aggiunti snippet di codice ed esempi: embeddedcodesource.com

Downloads Legacy

Per i PIC24 in molti trovano difficoltà dato che erano abituati ad utilizzare le librerie PLIB (Periphearl LIBraries) che ora non vengono più installate in automatico perchè sorpassate dalle funzionalità del plugin MPLAB Code Configurator. Ad ogni modo è possibile installarle a parte anche se ora vengono dichiarate come Legacy (ovvero: non più supportate, obsolete) e rimaste al 7/3/2016, potete scaricarle qui.

La Microchip come avete visto non butta via niente. Si possono addirittura scaricare le vecchie versioni sia dei compilatori che di MPLAB (anche il vecchio, addirittura a partire dalla versione 5.4). Nel caso in cui dovreste averne bisogno, sappiate che il vecchiume è sempre disponibile nei menù “Downloads Archive” nella parte sinistra delle pagine oppure direttamente in questa pagina: http://www.microchip.com/development-tools/downloads-archive

Creazione del progetto

Questa operazione è molto simile a quella che facevamo con MPLAB IDE 8: File -> New project. Si apre una finestra in cui dobbiamo scegliere il tipo di progetto. Abbiamo addirittura la possibilità di importare un vecchio progetto dal vecchio MPLAB IDE 8, ma, almeno per ora, ve lo sconsiglio: bisogna aver acquisito almeno un po’ di dimestichezza col nuovo modo di programmare, perchè al risultato dell’importazione è quasi sempre necessario lavorarci ulteriormente.

Per creare un progetto standard per picmicro lasceremo le selezioni di default (Microhip Embedded – Standalone Project):

Premiamo quindi Next. Ci viene chiesto di selezionare il dispositivo da utilizzare:

Premiamo Next. Ci viene chiesto quale tool di programmazione/debug utilizzare. Se affianco al tool c’è il pallino rosso, vuol dire che quel tool non si può utilizzare per il picmicro che avete scelto. Se il pallino è giallo vuol dire che il supporto è solo parziale (magari funziona solo il debug ma non la programmazione), se è verde… tutto ok. Nel caso in cui abbiate già collegato il vostro programmatore, sotto al suo nome compare anche il seriale, come nel mio caso:

Come vedete nell’elenco ci sono anche degli starter kits (che sono schede di sviluppo che includono un programmatore a bordo). In ogni caso, se il programmatore non ce l’avete, potete selezionare una cosa qualsiasi, poi si può modificare in seguito.

Premiamo Next. Vi viene chiesto quale compilatore utilizzare tra tutti quelli installati e compatibili con il PICmicro che avete scelto (se avete scelto un PICmicro ad 8 bit, chiaramente vi verranno elencati solo i compilatori utilizzabili con quello):

mpasm è il compilatore per l’assembler che viene sempre installato di default insieme al nuovo IDE. Come vedete a me viene visualizzato anche il vecchio Hi-Tech che usavo anni fa. Nel nostro caso selezioneremo l’ultima versione dell’ XC8, che si trova in cima alla lista.

Premiamo Next. Questa è l’ultima finestra. Dobbiamo scegliere il nome del progetto e la cartella in cui salvarlo:

MPLAB X IDE creerà una cartella, in quella specificata da “Project Location”, con il nome che avete scelto per il progetto a cui aggiungerà anche l’estensione X. I progetti di MPLABX IDE sono difatti intere cartelle con estensione X.

Fate caso al check su “Set as main project”. Questo è da non sottovalutare per un semplice motivo: nella finestra dei progetti potete tenere aperti tutti i progetti che volete. Ma quando andrete a premere i pulsanti per la compilazione/programmazione, non verranno compilati i progetti che avete aperto ma solo quello contrassegnato come “main project”.

Dico questo perchè a capita spesso un intoppo:  MPLAB X  di default, all’avvio, mette nella finestra tutti i progetti a cui avete lavorato. Si comincia quindi a lavorare su uno della lista (che so, aprite il main di un progetto per editarlo) e quindi lo si vuole provare sulla scheda di sviluppo (premendo il pulsante compilazione+upload) e succede l’inaspettato perchè MPLAB X, giustamente, non compila il progetto su cui stiamo lavorando ma quello contrassegnato come main project che di default, all’avvio, è l’ultimo su cui stavate lavorando prima di chiudere il programma. Quindi, nel momento in cui lavorate ad un progetto, ricordatevi prima di settarlo come main project: basta andare nella finestra dei progetti, cliccare col tasto destro sul nome del progetto e selezionare “Set as main project”:

Includere files nel progetto

Nella finestra “Project” è mostrata la struttura logica del progetto (files raggruppati per categoria), che non corrisponde necessariamente a quella fisica (files così come si trovano sull’hard disk). Ogni progetto ha affianco il simbolo di un circuito integrato. Sapete già che quando affianco ad un elemento dell’albero c’è il segno di + nel quadratino, cliccandoci sopra si espande e viene visualizzato tutto ciò che c’è dentro.

In genere si lavora solo sulla struttura logica. Per includere un nuovo file (es.: il main) basta cliccare con il tasto destro su una cartella logica e selezionare New -> [quello che ci serve]. Quello che ci serve lo vediamo al paragrafo successivo.

Struttura dei progetti, files C e H

Molti avevano sempre difficoltà con la questione dell’inclusione dei file C, H, di dove/come/quando si dovevano includere e qui, quando si sbagliava, erano errori su errori spesso non facili da capire. Ora la gestione è più pulita ed ha un senso: a livello logico i progetti sono separati in cartelle (anche se a livello fisico, cioè sul nostro harddisk, dicevamo, potrebbe non essere così): ogni progetto ha una sua struttura ben organizzata. Focalizziamo l’attenzione su due cartelle importanti: “Source Files” e “Header Files”.

Nella cartella Source Files vanno messi soltanto i files C. I files C generalmente non vanno mai inclusi in nessun modulo (in genere in un file C non dovrete mai mettere un include ad un altro file C). Tutto quello che si trova in Source Files viene compilato e unito nell’HEX alla fine del processo (ecco perchè non è necessario includerli). Nella cartella Header Files vanno soltanto i files H.

Ricapitoliamo: in Source Files ci vanno i C, in Header Files ci vanno gli H, fin qui non dovrebbe essere difficile. Ma questo vale solo se rispettate le regole per scrivere i files C e H.

Possiamo creare nuovi files nelle cartelle logiche semplicemente cliccando su una cartella con il tasto destro: New -> C main File (se vogliamo creare un file C, non solo il “main.c” ma qualsiasi file c) oppure New -> C Header File se vogliamo creare un file H.

Cosa devono contenere i files C e H?

I Files H generalmente contengono soltanto: variabili globali (quelle definite al di fuori delle funzioni e che possono essere utilizzate da qualsiasi funzione), Defines (ovvero i nomi mnemonici che assegniamo a bit e registri) e prototipi funzione (ovvero la funzione dichiarata senza tutta la parte tra le parentesi graffe). Nel file H molti, me compreso, al prototipo funzione aggiungono la parola chiave “extern” che al compilatore in realtà non serve a nulla, più che altro serve al programmatore (intendo l’essere umano, non il PICkit!) a capire che quella funzione è definita per intero in un altro file (esterno).

Nei files C vanno inclusi, generalmente, soltanto i files H e vanno scritte le funzioni vere e proprie. Esempio: nel file pippo.c abbiamo bisogno di una funzione che viene definita in pluto.c? Allora in pippo.c includeremo il file header di pluto.c ovvero pluto.h. In genere quando creiamo funzioni (librerie personalizzate ecc), tranne che per il main, c’è sempre un file principale (C) e un file header  (H).

Header sta per “intestazione”, e difatti il file header contiene solo le intestazioni ovvero i nomi (variabili, funzioni, mnemonici) prima di utilizzarli realmente. Serve per dire al compilatore: “Hey, prima o poi incontrerai qualcosa che si chiama pincopallino ma non lo so cosa fa, io ti ho avvisato”.

xc.h

Va incluso xc.h all’inizio del main così come facevamo con htc.h del compilatore Hi-Tech. La funzione è la stessa: verranno caricati tutti i nomi mnemonici del PICmicro che abbiamo scelto nel progetto nonchè numerose utili funzioni precotte tipo quelle di delay, la ei() che abilita gli interrupt, la di() che li disabilita ecc.:

#include <xc.h>

Un elenco delle funzioni incluse lo trovate nel manuale dei compilatori all’Appendice A “Library Functions” per l’XC8, all’appendice G “Built-in Functions” per l’XC16 + documento “16-Bit_Language_Tools_Libraries_Manual.pdf” e Appendice D “Built-in Functions” per XC32.

I documenti PDF dei compilatori (leggeteveli!) si trovano in C:\Program Files (x86)\Microchip\xc[8,16 o 32]\v[versione]\docs

Alcune funzioni descritte nei documenti potrebbero necessitare dell’inclusione di altri header, come stdio.h e stdlib.h, ma in ogni caso è sempre specificato.

In realtà xc.h include htc.h. Htc.h include altra robetta e quindi pic.h. In pic.h sono definite le funzioni di delay, alcune macro assembler (tra cui il _nop e le macro per precaricare i dati sulla eeprom interna) e quindi a sua volta include pic_chip_select.h che in base al PICmicro definito del progetto include il file header del PICmicro scelto e che contiene tutte le definizioni della memoria e dei registri con i nomi mnemonici associati.

Funzioni di ritardo

I Delays! Non c’è cosa statisticamente più richiesta dei Delays! Come già accennato abbiamo disponibili le funzioni __delay_ms(x) e __delay_us(x) per specificare ritardi rispettivamente in millisecondi e microsecondi. Non è necessario includere niente di particolare per poterli utilizzare, per i pic ad 8 bit, basta solo definire _XTAL_FREQ con il valore in Hertz dell’oscillatore (sia esso esterno o interno) prima di poter utilizzare le funzioni:

#define _XTAL_FREQ 8000000 // 8MHz

per i pic a 16 bit (con compilatore XC16) vale la stessa cosa ma anzichè _XTAL_FREQ bisogna definire FCY.

Il valore massimo passabile alla funzione varia a seconda della frequenza dell’oscillatore: più aumenta il valore dell’oscillatore più diminuisce il valore massimo passabile alle funzioni di ritardo (che in realtà sono macro). I PIC32 non hanno disponibili le librerie di ritardo standard perchè fanno uso di altre features per generare ritardi (il Core Timer).

La Config Word

Una cosa che statisticamente ha sempre fatto venire i mal di pancia è la Config Word. Ora Non si usa più la macro __CONFIG (anche se è possibile utilizzarla) ma le direttive #pragma. Ammetto che nemmeno a me quella word di configurazione scritta così non mi è mai piaciuta!

Ci viene in aiuto il tool integrato accessibile da menù Window -> Pic Memory Views -> Configuration Bits. Compare un riquadro in basso, dove c’è la finestra di output, con tutti i fuses di configurazione del PICmicro scelto per il progetto e la loro descrizione:

Nella colonna option abbiamo le caselle di scelta per ogni singolo fuse, cambiando i valori cambia la descrizione, che ci aiuta a capire cosa stiamo facendo. Alla fine dei settaggi possiamo premere il pulsantone “Generate Source Code to Output” che genera tutte le direttive #pragma per i fuse nella finestra di output: da li possiamo copiare e incollare nel nostro sorgente, dopo l’inclusione di <xc.h>. In genere io metto i fuses di configurazione in un file H che includo nel main.

Riferimento ai singoli bit

Eravamo abituati ad utilizzare, ad esempio, RA1=1 per portare a livello logico alto l’uscita della porta RA1, TRISA1=0 per impostare RA1 come uscita ecc. Questa cosa scordatevela. La sintassi che si utilizza adesso è più logica e portabile. I nomi dei registri rimangono sempre gli stessi: possiamo fare riferimento al PORTA, TRISA ecc quando dobbiamo fare riferimento a TUTTO il registro. Se vogliamo fare riferimento al singolo bit (o a piccoli gruppi di bit) del registro, la sintassi da utilizzare è:

[nome registro in maiuscolo][parola “bits”].[nome bit in maiuscolo]

Se vogliamo, ad esempio, portare a livello alto la porta RA1, dovremo scrivere:

PORTAbits.RA1=1;

oppure, se il banco ha il registro LAT:

LATAbits.LATA1=1;

vogliamo impostare la sola porta RB5 come ingresso?

TRISBbits.TRISB5=1;

e così via. Il senso dovrebbe essere chiaro. I nomi dei bit e dei registri ora, con i nuovi compilatori, sono gli stessi, identici, che trovate sui datasheet, non dovete nemmeno sbattere a cercare nei file H del pic selezionato.

Sbattere a cercare nel file H è comunque un’operazione che, secondo me, forma molto il programmatore. Gli header dei PICmicro sono contenuti in C:\Program Files (x86)\Microchip\xc8\v[versione]\include).

Gli interrupt

La routine di interrupt, a cui possiamo dare un nome a piacere, deve essere preceduta dalla parola chiave __interrupt o solo interrupt senza i due underscore che precedono (i due modi sono equivalenti, quest’ultima modalità è uguale alla vecchia):

void __interrupt nomefunzione(void)
void interrupt nomefunzione(void)

Per i PIC18, a meno che non venga impostata la modalità compatibile PIC16 (modalità di default che prevede che tutti gli interrupt abbiano stessa priorità: RCONbits.IPEN = 0;), si specificano i due interrupt a diversa priorità mediante le parole chiave low_prority (per quello a bassa priorità) o high_priority (per quello ad alta priorità), che si possono usare sia come qualificatore che come argomento, quindi se usavate il C18 il modo di scrivere la routine di interrupt è cambiato (non si usa più la direttiva #pragma per specificare il vettore):

void __interrupt low_priority isrL(void) // interrupt a bassa priorità
void __interrupt high_priority isrH(void) // interrupt ad alta priorità
void __interrupt isrL(low_priority) // stessa cosa: interrupt a bassa priorità
void __interrupt isrH(high_priority) // stessa cosa: interrupt ad alta priorità

Per i PICmicro a 16 e 32bit la situazione rimane invariata rispetto a prima, c’è sempre la parola chiave __attribute__ che permette di specificare i diversi tipi di interrupt. Per ulteriori informazioni su questo argomento potete fare riferimento a questo mio vecchio articolo (saltando la parte relativa alla scrittura degli interrupt sui PIC18 che è obsoleta): la gestione degli interrupt sui pic12-pic16-pic18-pic24-dspic.

In aggiunta io vi consiglio sempre di leggere il manuale del compilatore: XC8 Capitolo 5 paragrafo 9, XC16 e XC32 capitolo 14.

Tipi variabili

Interi

Vi illustro un’altra cosa buona che molti utilizzano già da tempo e che, secondo me, si DEVE radicare. Non si tratta di una nuova feature ma di un modo universale di riferirsi ai numeri interi. Capita difatti che non tutti i compilatori, ad esempio, abbiano definiti tipi di variabili come il “BYTE” (che molti usano su Arduino come intero senza segno ad 8 bit, equivalente al CHAR) e capita che diversi compilatori possano intendere lo stesso tipo con segno o numero di bit diversi. Raccomando quindi di utilizzare le definizioni di interi presenti in stdint.h che sono universali. In pratica, dopo aver incluso <xc.h>, gia che ci troviamo, includiamo anche stdint.h:

#include <stdint.h>

in questo modo possiamo utilizzare definizioni universali per i numeri interi:

uint8_t n; // definisce "n" come Unsigned Int a 8 bit
int8_t m; // definisce "m" come Signed a 8 bit
uint16_t v; // definisce "v" come Unsigned Int a 16 bit
int16_t b; // definisce "b" come Signed a 16 bit

e così via anche per i numeri a 32 e  64 bit. Avrete capito regola utilizzata per definire questi tipi: se il numero è senza segno, il tipo inizia per “u” (che sta per unsigned), segue quindi “int” (che sta per integer, ma va?), il numero di bit (8,16,32,64) e infine _t (underscore t, dove t sta per “type”).

Chiaramente nulla ci vieta di continuare ad utilizzare i tipi standard di intero che abbiamo sempre usato:

Ma onestamente mi ricordo più facilmente uint64_t (e preferisco anche scriverlo) piuttosto che unsigned long long. Poi l’INT non mi ricordo mai se è a 8, 16 o 32 bit anche perchè programmando lato PC con altri linguaggi faccio spesso confusione dato che ogni compilatore interpreta il tipo INT a modo suo. Poi se passo ad un’altra MCU diversa da quelle della Microchip, il compilatore potrebbe non capire, per dirne una, l’unsigned long long mentre uint64_t si o ancora potrebbe interpretare l’int come 16 bit anzichè 32…. Insomma nei miei programmi da ora in poi è raro che troverete una definizione di variabile come “unsigned char” e cose così. Quindi abituatevi a queste nuove definizioni per gli interi. Anche su Arduino. Anche su agli compilatori.

Bit

E’ un tipo che può valere chiaramente 0 o 1. Questo però si può usare solo con l’XC8. I compilatori XC16 e XC32 non supportano il tipo bit!

Bool

Non è un tipo standard del C, lo si ha includendo <stdbool.h>. Si usa generalmente con i valori true (1) e false (0) che a me, per esempio, piace di più utilizzare invece di scrivere 1 o 0 perchè mi danno più il senso del flag. Dovrebbe essere come il tipo bit, che a noi piace  un sacco per risparmiare 7 bit, ma purtroppo non lo è: coi compilatori XC si ciuccia un byte intero, è difatti definito come char:

typedef unsigned char bool;

Se siamo su XC8, e ci serve un flag, allora conviene usare il tipo bit, oppure definire un nuovo tipo bool senza includere lo stdbool.h, poi definiamo true e false per conto nostro. Su XC16 e XC32 il tipo bit non c’è e ci arrangiamo, ma tanto su quei pic la memoria è tantissima.

Float e Double

Qui c’è un piciopacio a seconda del compilatore utilizzato. Riassumo con le tabelle prelevate dai manuali dei compilatori che faccio prima. Per XC8 abbiamo:

Come vedete per i pic a 8 bit, di default i valori con la virgola sono sempre a 24bit sia che li dichiariamo come float, che come double che come long double. Per avere il tipo a 32 bit bisogna cambiare le opzioni del compilatore.

Per XC16 e xC32 la situazione è simile (la tabella è presa dal manuale XC16, su quello dell’XC32 manca la parte con l’asterisco):

Ricerca implementazione/definizione

La nuova funzionalità che mi piace di più (e che uso di più) sapete qual’è? Quando nel sorgente cliccate il tasto destro su una qualsiasi parola, è possibile visualizzare quella parola da dove proviene/dove punta e dato che io sono curioso, sta cosa mi piace una cifra. Ve lo spiego con un esempio: in cima al main ho incluso <xc.h>, clicco col tasto destro in un punto qualsiasi della stringa <xc.h> e seleziono Navigate -> Go to Declaration/Definition

et voilà: mi si apre il file xc.h.

Fate la stessa cosa su, ad esempio, uint8_t : vi si aprirà il file stdint.h nel punto in cui uint8_t viene dichiarato. Vi sembrerà assurdo ma questa cosa è di un’utilità pazzesca. Se il menù “Go to Declaration/Definition” è disabilitato, vuol dire che quella parola è nativa, cioè definita a livello compilatore.

Il Programmatore

Edit: è finalmente disponibile il PICkit 4 e vi consiglio di prendere questo lasciando perdere tutti gli altri. C’è anche l’MPLAB SNAP che costa ancora meno (ma dovete controllare la compatibilità coi PIC che volete programmare).

Croce e delizia: lo so, il PICkit 3 è lento, capriccioso, si autoriprogramma ogni volta che cambiamo fascia di pic aumentando la lentezza del processo, di default non fornisce l’alimentazione al circuito e quando avete capito come fare… si lamenta pure! Per pochi soldi c’è solo questo, e se volete usare i pic nuovi ci siete costretti, purtroppo il 2 non lo supportano più. Io uso sia il PICkit2 che il 3. Molti di voi opteranno per i cloni cinesi. Ne abbiamo discusso per anni: funzionano bene ma hanno delle magagne, del tipo che quasi tutti cancellano i valori di calibrazione degli oscillatori interni. Non mi chiedete consigli su questo… volete comprare quello cinese… non posso criticarvi, anzi vi do ragione, ma mettete a conto comportamenti strani dopo la programmazione e problemi inspiegabili per i quali ne io ne altri possono esservi d’aiuto. Dovrei dirvi comprate sia il PICkit2 che il 3 originali ma vi assicuro che basta solo il 3 e che abbiate pazienza. E poi si trovano anche usati. Se poi usate il JDM o cose così, chiudo il sito e me ne vado.

Ad ogni modo ho scritto un articolo in cui illustro i vari errori del PICkit3 e come risolverli. Potete leggerlo qui.