Suggerimenti, in ordine sparso

Un messaggio di errore

Il primo impatto con i prodotto Microchip, hardware e software, è spesso segnato dalla confusione. A ciò si aggiungono un numero impressionante di bug e malfunzionamenti... A volte si tratta solo di dettagli a carattere pratico, ma succede che sono la ragione del fallimento di un progetto.

Questa pagina cerca di mettere una pezza.

Gli SFR: TRISC, PORTC, Timer0...

SFR significa Special Function Register, registro con funzione speciale.

Quella che appare come una normale variabile a volte è in realtà il registro fisico di una periferica, predefinito. La definizione di tale variabile può essere vista cliccandola con il tasto desto (Navigate → Go To Declaration). Per esempio:

extern volatile unsigned char TRISC @ 0xF94; Variabile di 8 bit senza segno, quindi con valore compreso tra 0 e 255 (un byte), con indirizzo fisso 0xF94.

Alcuni SFR (o parte di essi) sono a sola lettura, altri a sola scrittura, altri ancora possono essere sia letti che scritti, ma le due operazioni hanno effetti diversi da quanto ci si potrebbe attendere pensando al solo software. Inoltre non sono necessariamente composti da 8 bit, ma a volte alcuni bit sono "mancanti". In genere tali definizioni sono incluse in un file con una riga simile alla seguente:

#include <pic18f25k50.h>

In assembly la definizione corrispondente è:

TRISC EQU H'0F94'

Contenuta con una direttiva simile alla seguente:

#include "p18f26k22.inc"

LATx e PORTx

Queste due coppie di registri hanno un simile comportamento, il che li rende a volte interscambiabili. Ma occorre comprendere la loro diversa funzione.

Si può comprendere il diverso comportamento anche osservando la versione semplificata di un pin di una qualsiasi porta, dove in rosso sono indicati i Chip Select dei tre registri ed in blu il Data Bus. La versione completa la trovate su fogli tecnici di tutti i PIC18

Schema semplificato di un pin del PIC

Per questo motivo le operazioni che:

Visto che è facile sovrapporre il primo ed il terzo caso, è comodo utilizzare la seguente regola:  Always read inputs from PORTx and write outputs to LATx (leggere gli ingressi da PORTx e scrivere le uscite in LATx)

L'alimentazione

Occorre prestare la massima attenzione ad utilizzare la tensione di alimentazione corretta, in genere compresa tra 3 V e 5 V, a seconda del modello. Un errore potrebbe causare il mancato funzionamento oppure la rottura del microcontrollore o di altri componenti.

Prestare la massima attenzione alle informazioni presenti sul foglio tecnico. In breve:

I problemi di PICkit e ICD

A volte fallisce il collegamento con tra PC e ICD nel momento della programmazione o del run. La soluzione, per tentativi: riprovare il comando → scollegare l'ICD, ricollegarlo e riprovare → scollegare, terminare MPLAB X e riprovare → spegnere il PC e riprovare (per fortuna cosa rara...).

A volte fallisce la programmazione del PIC18. In genere, a meno di problemi hardware, potrebbe dipendere:

Impostare l'alimentazione

Strani errori nell'editor

A volte righe di codice perfettamente legittime vengo evidenziati come corretti...

Per esempio il seguente spezzone di codice è perfettamente compilabile ed eseguibile, in piena conformità ai fogli tecnici.

Riga con errore... sbagliato!

La soluzione che a volte funziona: Project Propreties → Apply (senza modificare nulla)

Revisione dell'hardware

Molti PIC hanno un hardware modificato rispetto ad altri con la stessa sigla, a causa dei bug e dei miglioramenti che nel tempo vengono introdotti. La documentazione è riportata in documenti aggiuntivi ai fogli tecnici, in genere evidenziati come errata.

Occorre quindi individuare l'esatta revisione del componente che si sta utilizzando. Questa può essere vista mentre si programma il dispositivo. La doppia immagine seguente mostra per esempio a sinistra un PIC18F14K50 revisione A6 e a destra un più recente PIC18F14K50 B0.

PIC18F14k50, revisione A6 e B0

PicKit e Windows 8.1

Il PICkit 2 ed il PICkit 3 hanno un problema che impedisce il loro funzionamento con Windows 8.1. Funzionano invece correttamente con Windows 8 e con Linux; nessuna incompatibilità infine tra Windows 8.1 e ICD3.

Il problema sorge nel momento in cui si programma il PIC: The target circuit may require more power than the debug tool can provide. An external power supply might be necessary. Connection Failed.

The target circuit may require more power than the debug tool can provide. An external power supply might be necessary. Connection Failed.

La causa è l'errata gestione del risparmio energetico "avanzato". La soluzione: occorre modificare una voce del registro di Windows, con ill programma regedit.exe. La voce da modificare è: HKEY_LOCAL_MACHINE → SYSTEM →  CurrentControlSet → Enum → USB → VID_04D8&PID_900A → BURxxxxxxxx → Device Parameters → EnhancedPowerManagementEnabled che va impostata a dword:00000000 (e non a dword:00000001, come invece è). Occorre quindi scollegare il PICkit3 e ricollegarlo.

HKEY_LOCAL_MACHINE → SYSTEM →  CurrentControlSet → Enum → USB → VID_04D8&PID_900A → BURxxxxxxxx → Device Parameters → EnhancedPowerManagementEnabled

Se avete un PICkit2, la voce di registro è leggermente diversa in quando il dispositivo è identificato dal codice PID 0033 invece che 900A.

L'operazione deve essere ripetuta per ciascun PICkit in vostro possesso in quanto cambia il codice BUR: la cosa piuttosto fastidiosa per esempio in un laboratorio scolastico. La soluzione, che caldeggio, è usare Linux, magari in ambiente LTSP oppure una macchina virtuale XP (le recenti versioni di MPLABX sembrano funzionare senza problemi solo con VirtualBox 5).

XC8, C99 e Linux

Durante l'installazione di XC8 2.05 (e forse anche altre versioni) viene creato un file eseguibile solo da root che impedisce la compilazione usando lo standard C99 (predefinito):

vv@vv-i7:~# ls -l /opt/microchip/xc8/v2.05/pic/bin/clang
-rwxrw-r-- 1 root root 28222276 ott 19 17:12 /opt/microchip/xc8/v2.05/pic/bin/clang

Due soluzioni:

Variabili "non riconosciute"

Durante il debug del codice esistono due modi per conoscere il contenuto di una variabile:

A volte nessuno dei due metodi sembra funzionare: il primo non mostra nulla (neppure un errore o un messaggio), il secondo indica che la variabile è Not Recognised.

Variabile "Not Recognised"

Il motivo deriva dal fatto che, se la variabile non è utilizzata, l'ottimizzazione del compilatore la sopprime. Questo comportamento è ovviamente ottima cosa nel codice di produzione, ma fastidioso durante lo sviluppo. Due soluzioni:


Data di creazione di questa pagina: marzo 2016
Ultima modifica: 20 luglio 2019


Licenza Creative Commons Attribuzione 4.0 Internazionale


Pagina principaleAccessibilitàNote legaliPosta elettronicaXHTML 1.0 StrictCSS 3

Vai in cima