Newsgroup: it.hobby.elettronica.digitale
Titolo: microchip: tecniche di debug ICD2 o MPLAB-SIM

L'icd è indubbiamente un debug piu "realistico", ma non tutti i micro
(quelli piccoli o i vecchi) lo supportano.
L'mplabsim è in sviluppo e miglioramento e mi permette di proseguire
con i miei lavori anche non avendo sottomano una scheda.
Voi usate entrambi i metodi di debug? Quale dei due preferite?
grazie

 Voi usate entrambi i metodi di debug? Quale dei due preferite?
Personalmente per il debug uso una seriale, un display lcd, un led, un 
cicalino... quello che offre la scheda insomma. Non ho mai usato il 
debugger dell'ICD2 e rarissimamente il simulatore. Dipende anche in che 
ambito lavori ma di solito se puoi "fermare il tempo" del tuo micro con 
il debugger il mondo attorno non si può fermare....
Ciao!
Marco / iw2nzm

 cicalino... quello che offre la scheda insomma.
Ciao Marco, anch'io faccio allo stesso modo.
Tuttavia a volte mi capita di avere schede senza seriale e display ..
e per valutare il valore ad esempio di una conversione AD diventa
scomodo.
Pensavo appunto quindi di provare un approccio piu da "softwarista" in
questi casi.
Ho visto che MPLAB-SIM addirittura permette di crearti dei segnali da
inviare in modo sincrono o asincrono come "stimolo" al micro. Non mi
sembra da sottovalutare.

 questi casi.
Io uso una porta libera ed un oscilloscopio in questi casi....
Ciao
CG 

 ha scritto nel 
messaggio news:47a9b9ee$0$17954$4faf...@reader1.news.tin.it...

In verita' stavo cercando  di fare il debug dei micro della Microchip ed ora 
anche degli Atmel, con gli opportuni progarammatori debuger, perche' finora 
avevo usatole vostre stesse tecniche riuscendo sempre a venirne a capo, ma 
leggendo quello che avete scritto mi rincuora, in special modo seguendo i 
post di Marco Trapanese che certamente progetta e realizza circuiti di una 
certa complessita' credevo proprio che usasse questi sistemi piu' evoluti, 
insomma mi sento un po piu' progettista anche io :-) 

debugger dell'ICD2 e rarissimamente il simulatore.
Io l'ICD2 l'ho appena acquistato.
Ho SEMPRE utilizzato il simulatore.
Utilizzandolo si scoprono tanti piccoli trucchi per lavorarci al
meglio e inserire anche l'influenza di fattori esterni.
In ogni caso.... il metodo migliore per debuggare comportamenti "non
previsti" è sempre stato quello di utilizzare la porta seriale per
visualizzare il flusso del programma.
Se non avessi utilizzato questo metodo non avrei mai scoperto ad
esempio che l'inserimento di un contattore nel mio circuito vicino ad
un pic (era il periodo in cui utilizzavo l'F84, uno dei primi della
serie F a quei tempi) provocava un salto da una riga di programma ad
un'altra casuale!
Un bug di questo tipo era nel disegno del layout del pcb e non nel
firmware del programma e... con il solo simulatore sarebbe stato
pressochè impossibile da scoprire.
Ciao
 Marcello
-Catania-

 insomma mi sento un po piu' progettista anche io :-) 
^__^
In questo NG c'è gente che ha molta più esperienza e che scrive firmware 
complesso sul serio! Al confronto sono un dilettante :)
/* Ca%%ata mode ON */
Curiosità: quando mi capita di sviluppare firmware su schede che hanno 
un cicalino, il debug lo faccio in morse... cioè i vari punti di 
controllo del programma (A, B, C ecc) o i valori di alcune variabili li 
converto in beep secondo codice morse.
/* Ca%%ata mode OFF */
Ciao!
Marco / .. .-- ..--- -. --.. --

 complesso sul serio! Al confronto sono un dilettante :)
Mi fai sentire nuovamente giů, se tu sei un dilettante allora io 
........................ :-) 

 ha scritto nel messaggio 
news:fbrjq3psmd8j3564d...@4ax.com...

Concordo con quello che hai scritto, personalmente nell' ultimo progetto 
(apricancello GSM molto molto particolare) dovevo controllare diverse 
variabili, usavo un PIC16F628A con tutti i pin in/out utilizzati, ho avuto 
la fortuna che utilizzando un modulo gsm questi non si curava se sulla 
stessa linea seriale venivano inviati oltre i comandi per il corretto 
funzionamento, anche diverse stringhe con dati che mi permettevano di capire 
se il programma stava facendo quello che volevo, se avessi usato (nel mio 
caso non credo sarebbe stato possibile perche' il debug con ICD2 prevede 
diversi piedini in/out liberi per se) ICD2 in ambiente Mplab questo sarebbe 
stato piu' semplice,  forse anzi sono abbastanza sicuro che avrei potuto 
vedere anche la situazione di eventuali stack in overflow. 

 /* Ca%%ata mode OFF */
OT: mi sono sempre chiesto come riconoscere un radioamatore davanti ad
un microcontrollore, oggi ho la risposta definitiva.
Meno OT: anch'io mi limito ad usare una combinazione delle tecniche
citate sopra: da un oscilloscopio su un'uscita libera, al display LCD
ai LED che si accendono se una certa condizione di diagnostica è
verificata nel codice, eccetera.
Per eventi particolari (segnali da sincronizzare, temporizzazioni
varie) è utile ripetere in loop il codice incriminato, per poter fare
le misure con l'oscilloscopio senza memoria.