Programmatore PIC

[AcmeMan]

Colpa del destino cinico e baro.

A parte le battute facili, mi diresti perché ti stai impuntando su questa cosa? Perché usare sistemi obsoleti ed inaffidabili per programmare un PIC?
Lo fai per mera sperimentazione, per scrivere un articolo su "come si faceva una volta, nel neolitico superiore"?

Sono solo curioso.

Niente del genere. Inizialmente non pensavo ci fossero tutte queste difficolta poi una volta realizzato me le sono ritrovate. Però pra che l'ho fatto e mi farebbe piacere vederlo funzionare.

Superato l'ostacolo del convertitore USB-Seriale ora dovrebbe funzionare... invece...

[posta10100]

mi diresti perché ti stai impuntando su questa cosa?

perché no? Anche io ne ho uno su porta parallela e funziona benone con pochissimi accorgimenti.

ora dovrebbe funzionare... invece...

Attenzione che il dato in uscita è invertito. Hai configurato il software affinchè inverta i dati in uscita?

[Paolino]

Credo che TardoFreak, da buon microcontrollista, la veda un po' come me, cioè che un programer/debugger a 50 soldi (IVA e trasporto inclusi), toglie dal fuoco un bel numero di castagne, lasciando libera la mente di concentrarsi sul progetto.

Tutto qui.

Poi, un programmer muletto è utile. Personalmente ho un ICD3 e come muletto un PICKit3.

Ciao.

Paolo

[posta10100]

Perfettamente d'accordo, un programmatore professionale costa molto poco rispetto al tempo che si risparmia, ma nel mio caso il tempo è secondario, l'ho costruito per gioco (ne avevo un altro comprato per 2 spiccioli che funzionava maluccio) e visto che funziona l'ho eletto programmatore ufficiale.

un programer/debugger

So che tali programmatori hanno questa funzione ma non mi sono mai posto il problema.
Però adesso mi hai incuriosito: come funziona?
Controlla il clk del PIC facendolo avanzare step by step e andando a leggere i valori dei registri?
Conosci qualche documento che lo descrive?

[AcmeMan]

Attenzione che il dato in uscita è invertito. Hai configurato il software affinchè inverta i dati in uscita?

In realtà ho invertito tutti i segnali tramite PICPGM.

[posta10100]

Non li devi invertire tutti, solo quello in uscita.

[AcmeMan]

Ecco il file xml di configurazione del software:

Codice: Seleziona tutto

  <PgmIf name="JDM Programmer" typ="HVP" connection="COM">
        <PinCfg name="MCLR" pin="3" invert="0" />
        <PinCfg name="PGM" pin="0" invert="0" />
        <PinCfg name="CLK" pin="7" invert="0" />
        <PinCfg name="DOUT" pin="4" invert="1" />
        <PinCfg name="DIN" pin="8" invert="1" />
    </PgmIf>


Ed ecco il responso della console:

Codice: Seleziona tutto

server:/usr/local/picpgm# picpgm -port /dev/ttyS0 -delay 5

PIC Development Programmer Version 2.5.6.3
http://www.members.aon.at/electronics/PIC/picpgm
Copyright 2002-2011 Christian Stadler (ch.stadler@gmx.at)
(built on Jul 30 2011 at 05:29:15)
==================================================================

Autodetecting Programmer ...
Error opening port I/O driver!Programmer:  JDM Programmer
             at /dev/ttyS0

Autodetecting PIC ...
ERROR! Autodetection faild!


[posta10100]

Sotto linux io uso Piklab, prova ad installarlo e riprova il programmatore.

[Paolino]

come funziona?
Controlla il clk del PIC facendolo avanzare step by step e andando a leggere i valori dei registri?
Conosci qualche documento che lo descrive?

Purtroppo non ho documentazione a riguardo, dovrei cercare in rete. So di certo che una parte delle risorse FLASH e RAM, nonché una serie di pin, vengono assegnati al debugger non appena questo viene selezionato. Se si è a corto di RAM difficilmente si fa debug.

Comunque quello che dici è corretto: mediante l'IDE si piazzano i break-point qua e là sul codice sorgente. Il flusso del programma si interrompe quando viene incontrato un break-point e mediante finestre di watch è possibile valutare e modificare i valori di registri e variabili.

Con taluni debugger evoluti (non emulatori, ma proprio debugger) è possibile piazzare breakpoint "su condizione", ossia qualcosa del tipo: "ferma il flusso del programma se la variabile ANALOG_01 supera il valore 140".

L'esecuzione passo-passo permette inoltre di entrare nel corpo delle funzioni e vedere cosa accade.
Unico avvertimento: quando si impiegano compilatori con attivate le ottimizzazioni di codice, non è facile fare debug, in quanto sembra che il program counter salti a destra e a manca senza un preciso percorso. Questo è dovuto al fatto che il codice assembly eseguito è spesso differente da come ce lo immaginiamo, se è passato sotto le forche caudine dell'ottimizzatore.

Ciao.

Paolo.

[posta10100]

nonché una serie di pin, vengono assegnati al debugger non appena questo viene selezionato.

Quindi durante il debug alcuni pin non sono utilizzabili, sono gli stessi utilizzati per la programmazione (CLK e DAT) o ce ne sono altri?
perché in questo caso è una bella limitazione, soprattutto per i dispositivi con pochi pin.