Newsgroup: it.hobby.elettronica.digitale
Titolo: debug con interrupt

Salve!
Mi chiedevo quando dovete collaudare una applicazione su microcontrollore, 
volendo fare il debug ed esistendo fonti di interrupt tipo timer e/o 
periferica uart, come procedete? 

 periferica uart, come procedete?
se non devi simulare in real-time basta piazzare l'interrupt nella isr;
altrimenti ti serve un ICE e qui, in genere, gli hobbysti si arrendono
-ice- 


Scusami potresti spiegarmi la cosa? la ISR e' la funzione-routine di 
interrupt "Interrupt Service Routine" cosa significa mettere l'interrupt 
nella isr? 

 nella isr?
nulla, ho sbagliato a scrivere :)
volevo dire "mettere il break-point" dentro la ISR... cioè il firmware gira 
in real-time e quando la ISR viene chiamata il debug si ferma;
è proprio quello che succede con i brekpoint normali ma, se ben ricordo, 
quelli messi nelle isr devono essere breakpoint hardware (cioè che il micro 
sa gestire di suo);
esistono infatti anche breakpoints software aggiunti alla bisogna dal 
programma che usi per debuggare
in alternativa potresti usare delle linee di i/o libere da far commutare 
quando passi in certi punti del programma... esempio ogni volta che scatta 
il timer;
non è molto e non puoi farlo sempre ma è già qualcosa... però serve poi un 
oscilloscopio multitraccia
è questo quello che volevi sapere?
forse non ho colto la questione con precisione...
-ice- 

 oscilloscopio multitraccia
Questo lo facevo gia' quando usavo il Basic, mi sembra una buona soluzione e 
insieme all' uso della seriale, cosi' da vedere in quale parte di programma 
ci si trova con la possibilita' di monitorare le variabili stringhe ecc..
Forse la domanda che ho fatto era per capire perche' ICD2 della Microchhip 
e' stato spacciato come un potente mezzo di debug quando in realta' si fa 
molta fatica a monitorare come gira un programma che sfrutti certe librerie 
e qualche periferica integrata nel microcontrollore. 

 librerie e qualche periferica integrata nel microcontrollore.
Con l'ICD2 e anche il pickit2 (se usi la serie da 18 in su ...), riesci a 
vedere tutto ciò che ti serve con minimi compromessi da accettare ovvero 
l'occupazione (trasparente) di circa 300bytes di rom nella parta alta della 
flash e qualche locazione di ram.
Con il nuovo ICD3 (e relativo pickit3) uscito da qualche mese, la velocità 
di programmazione è aumentata di quasi un ordine di grandezza e sono 
possibili anche breakpoint avanzati.
Non riesco a capire quali siano i problemi ai quali accenni: se hai i 
sorgenti, puoi impostare fino a 3 break dove vuoi tu.
Se invece utilizzi librerie precompilate e linkate come oggetto al tuo 
codice...i problemi li avresti anche con un emulatore 'vero'.
I break ed il funzionamento a step li hai ugualmente, ma li devi impostare 
nel codice disassemblato.
Per le periferiche interne, puoi monitorare tutto ciò che è presente 
all'interno del micro e impostare break su interrupt da timer, seriale, usb, 
i2c,spi,...
Non ho mai incontrato una limitazione del monitorare ram/rom/eeprom/registri 
speciali.
L'emulatore al posto del debugger, consente di impostare i limiti e le 
condizioni dei break in modo ulteriormente articolato e non richiede risorse 
ram/rom al micro. 


Vorrei imparare a fare il debug, forse sto sbagliando in qualcosa,  sto 
facendo il debug sotto IDE del compilatore CCS,  succede che vado in debug 
con ICD2 originale Microchip premo su SINGLE STEP fino ad un certo punto 
vedo la freccia verde che si sposta ad ogni pressione su SINGLE STEP, poi si 
arriva da qualche parte la freccia verde scompare ed ho un messaggio nella 
finestra di debug di running, a questo punto dovrei da tastiera digitare dei 
caratteri ma non succede piu' nulla, questo succede esattamente a " 
c=getc();" inutile dire che se faccio girare il programma normalmente 
funziona tutto correttamente.
void get_string(char* s, unsigned int8 max) {
   unsigned int8 len;
   char c;
   --max;
   len=0;
   do {
     c=getc();
     if(c==8) {  // Backspace
        if(len>0) {
          len--;
         putc(c);
         putc(' ');
         putc(c);
        }
     } else if ((c>=' ')&&(c<='~'))
       if(len<=max) {
         s[len++]=c;
         putc(c);
       }
   } while(c!=13);
   s[len]=0;
} 

     if(c==8) {  // Backspace
[...]
In questi casi serve un minimo di esperienza e di malizia...
La getc() in questione è una istruzione bloccante che ritorna solo quando 
nel buffer è presente un carattere.
Potrebbe attendere un carattere da un dipositivo o dalla seriale che 
potrebbe essere a sua volta hw o sw.
Nel caso di seriale sw è impossibile fare eseguire il polling se sei in 
modalità single step.
Per vedere cosa accade effettivamente, puoi visualizzare il codice 
disassemblato e proseguire nella modalità single step al suo interno.
Prima della getc() è buona norma avere sempre una istruzione kbhit() che non 
è bloccante e ti consente di proseguire con la getc solo in presenza 
effettiva di un carattere nel buffer.
Se vuoi proseguire nel debug del tuo programma così comè, è sufficiente che 
metti un breakpoint nella istruzione successiva alla getc() ed esegui il 
programma in run (non single step),avrai così l'arresto del programma con il 
carattere già nella variabile 'c'.
Nota personale: perchè utilizzi l'ambiente di debug ccs e non direttamente 
mplab ? Il ccs lo trovo estremamente 'fuori standard' e poco intuitivo... 

 mplab ? Il ccs lo trovo estremamente 'fuori standard' e poco intuitivo...
magari perchè programma con il C della CCS? :)
-ice- 

 ha scritto nel messaggio 
news:3qhEl.209733$Ca.3...@twister2.libero.it...

Il c della CCS si integra perfettamente con MPLAB, lo uso pure io da diversi 
anni.
Ultimamente lo utilizzo anche con il pcd x i pic24.
Nella finestra di watch riesci a vedere il contenuto di tutte le variabili, 
strutture complesse comprese.
Imposti i breakpoint complessi (es. sul cambiamento di valore di una 
variabile, o fdopo un n. di passaggi x un certo punto,...)
Durante l'editing hai il completamento automatico delle variabili e delle 
strutture, sintax highlighting ed il codefolding, ricerca su file o su 
progetto,...
E' sufficiente impostare i riferimenti al linguaggio nelle direttive di 
complazione ed installare la dll x l'interfacciamento con il ccs x il debug 
con icd.
Considerato che l'iterfaccia utente e gli shortcuts sono molto simili ad 
altri editors/debuggers, cosa invece molto differente dall'editor nativo 
ccs, mi è sembrato logico porre la domanda: forse ha trovato nell'editor ccs 
qualcosa che ancora a me è sfuggito... 

 ccs qualcosa che ancora a me è sfuggito...
no, non ti sfugge nulla, l'editor/debugger ccs sono primitivi e imho
piuttosto scarsi;
il compilatore invece lo preferisco a tanti altri
-ice-

 il compilatore invece lo preferisco a tanti altri
E' quello che penso anche io:ora il compilatore mi sembra stabile ed 
affidabile, sia per la versione pcw che la pcd, che fino a qualche mese fa 
commetteva insidiosi errori di compilazione.