Newsgroup: it.hobby.elettronica.digitale
Titolo: per esperti di PIC C e interrupt

Sapete darmi un'idea di quanto č la latenza di un interrupt con un 
compilatore C per PIC ?
Esempio:
prendo un PIC della famiglia 18, clock a 8MHz, dichiaro due interrupt, uno 
sull'overflow del Timer1 e uno sul change di RB0.
Quanto tempo passa da quando nasce l'evento a quando viene eseguita la prima 
riga di codice nel mio interrupt handler ?
Tanto per avere un'idea, 5uS, 50, 100 ...
Marco 


La latenza dell'interrupt è indipendente dal compilatore e, a braccio,
vale da 1 a 4 cicli. Trovi il dato esatto nel datasheet.
Invece, quello che cambia è la latenza del codice di tuo interesse,
poichè la gestione degli interrupt con un compilatore può implementare
il salvataggio in stack di una serie di registri in più.
A braccio, direi sui una decina di cicli, ma lo puoi vedere da te
analizzando brevemente l'asm generato.
simone.bern

analizzando brevemente l'asm generato.
Appena ? Io non ho modo di vederlo perchè non ho mai lavorato in C e non 
sono organizzato.
Chiedevo a chi lo usa, dovrebbe essere sicuramente un dato ben noto, appena 
appena che vuoi fare girare un timer con interrupt a intervalli fissi ti 
trovi a scoprirlo.
Marco

 trovi a scoprirlo.
Quello che faccio io è, prima, una stima dell'overhead, poi, misuro
l'intervallo con un oscilloscopio. Al termine dell'interrupt provvedo
a ricaricare il timer con un valore appropriato, in modo da effettuare
il "tuning" del timer interrupt. Anche perchè tu non sai nè quanto è
lungo l'overhead, nè quale è il tempo di esecuzione della routine di
interrupt. Oppure ti guardi il codice asm, dopodichè, al contrario, lo
sai con precisione.
saluti,
simone.bern

a ricaricare il timer con un valore appropriato, in modo da effettuare ....
adesso ci capiamo, ed è quello che faccio io (non con il C che non conosco 
se non non sarei qui a fare questa domanda).
Cerco di completare meglio la domanda:
Sto sperimentando alcune aggiunte del PicBasicPro che consentono di gestire 
gli interrupt in "diciamo real-time" sempre scrivendo in basic.
Sono su un Pic18 a 8MHz e dichiarando due o tre handler vedo che il 
compilatore, per salvare quello che sa lui che deve salvare, impiega una 
cinquantina di uS, poi viene eseguita la prima vera mia istruzione in 
interrupt. Immagino che variando le situazioni possando diventare 30 o 70, 
ma poichè a sensazione mi sembrano un po' tanti, mi chiedevo se anche con il 
C si parla più o meno di questi numeri
o se le prestazioni del C in questo senso sono di gran lunga superiori.
Marco

 o se le prestazioni del C in questo senso sono di gran lunga superiori.
in questo e in tutti gli altri sensi, ovviamente.
Con un uso oculato delle variabili nella routine di interrupt (studia
i termini: scope delle variabili, variabili locali e globali,
variabili volatili) l'overhead può essere minimizzato.
In ogni caso l'overhead DIPENDE dal compilatore e dalle impostazioni
generali.
simone.bern

Ma perchè girarsi tanto le scatole ? Mah...
Ma perchè pretendere che altri usino strumenti che tu usi e con cui tu ti 
trovi bene ? Mah ...
Io non mi giro affatto le scatole, mi piace molto, mi ci trovo benissimo 
(con i suoi limiti, certo) e non ho nessuna voglia e tempo di cimentarmi in 
altri linguaggi. Sono semplicemente curioso di confrontarlo.
Il motivo per cui non ho citato il PBP nel post era per evitare i soliti 
scontati commenti di questo genere.
Grazie dell'intervento.
Marco

 Sapete darmi un'idea di quanto è la latenza di un interrupt con un 

Come ti hanno già detto dipende da molti fattori, per cui non è fisso.
in ogni caso mi aspetto che un buon compilatore contenga al minimo il 
prologo dell'interrupt. Considerando poi che il PIC ha pochi registri 
anche de dovesse salvarli tutti non mi aspetto che vengano persi più di 
una 20na di cicli macchina, che a 2MHz fanno circa 10uS.
Se nel tuo caso sono sui 50uS significa che l'interprete BASIC perde 
parecchio tempo. Potrebbe essere anche che per qualche ragione gli 
interrupt vengono disabilitati molto spesso e/o per molto tempo.
Ciao

 parecchio tempo.
Quello che mi sembra di avere capito è che l'interprete, o meglio queste 
aggiunte al PBP per la gestione degli interrupt, salvino non solo i registri 
(che poi in buona parte lo fa già il PIC in un nulla) ma anche altre 
variabili d'ambiente del compilatore, in modo che chi scrive non si debba 
preoccupare di nulla se non di scrivere solo il proprio codice.
Insomma, io scrivo ad esempio:
INT_CREATE   TMR0_INT
TMR1H=0
TMR1L=100
Flag=1
INT_RETURN
e non mi preoccupo di niente altro
nel C invece un esempio simile come sarebbe ? Bisogna aggiungere manualmente 
istruzioni per salvare e ripristinare registri, etc ?
A parte i registri del PIC, nella gestione di un interrupt in C non c'è un 
"ambiente" del compilatore che deve essere salvato e poi ripristinato ?
Marco 

 "ambiente" del compilatore che deve essere salvato e poi ripristinato ?
Direi proprio di no, non devi salvare niente di più di quello che 
salveresti se programmassi in assembly.
Ciao

 salveresti se programmassi in assembly.
Ok, grazie mille.
Ciao
Marco

 ha scritto nel messaggio
news:46079afd$0$10620$4faf...@reader2.news.tin.it...


 ha scritto nel messaggio 
news:46079afd$0$10620$4faf...@reader2.news.tin.it...

Concordo in pieno con te, io proprio non riesco a capire l'accanimento nel 
dire che il C e' migliore per sistemi embedded tipo i micro ad 8 bit della 
microchip, io parto dal fatto che non ci sia niente meglio dell'assembler ed 
i compilatori non fanno altro che generare dei file assembler quindi alla 
fine producono lo stesso risultato, si dice ma credo non sia stato mai 
dimostrato che il C generi codice assembler migliore. 

 migliore.
mentre è stato dimostrato che parlare di cose che non si conoscono genera le 
baggianate migliori...
simone.bern 

 dire che il C e' migliore ....
no, io sono abbastanza convinto che il C sia migliore e più performante ma 
questo non mi obbliga ad usarlo ...
Marco

 Effettivamente 50 uS sono tanti, a 8 MHz corrispondono a 100 istruzioni,
Questo è il prezzo che pago per tanta comodità. Ero curioso di capire quanto 
fosse più caro rispetto al C e mi avete risposto.
Grazie a tutti
Marco

 ha scritto nel messaggio 
news:eud1dg$8hk$1...@aioe.org...

Hai una classe da far invidia, quelli come te sicuramente non hanno lacune 
in nulla (ti avvcini o sei la perfezione?) a parte gli scherzi (la tua 
definizione la condivido) io parto dal fatto che gli stessi produttori 
vendono compilatori  in C  in Basic e Pascal  per lo stesso micro, quindi da 
quasi ignorante in materia penso che in linea di massima i tre compilatori 
producano a grandi line lo stesso codice assembler, poi tu che sicuramente 
ne sai molto ma molto piu' di me potresti dire perche' questo pensiero 
esprime una baggianata? 

di me potresti dire perche' questo pensiero esprime una baggianata?
In linea di principio, un buon compilatore Basic, Pascal o Bergamasco, può 
anche generare un buon codice. Ma il livello di astrazione di un linguaggio 
come il Basic tende a produrre strutture pesanti e difficilmente 
integrabili. Poichè un micro può fare una sola cosa alla volta, questo 
rappresenta un limite pesante, e più pesante tanto più piccolo è il micro.
E' inoltre un'imprecisione quella di ritenere che il risultato della 
compilazione sia migliore o peggiore in funzione del linguaggio compilato. 
Diversi compilatori C danno origine a codice diverso, e non necessariamente 
equivalente in termini di risorse utilizzate e velocità di esecuzione.
Per esempio, ci sono dei confronti tra HI-TECH e CCS sul solito 
www.microchipc.com
Poi, cercando di andar veloce, per la mia esperienza vale la roba seguente:
- In assembler si fanno poche cose, tranne casi particolari. In ambito 
industriale embedded si lavora in C.
- Eventualmente si usano sistemi ancora a più alto livello di astrazione, 
come i tool di generazione automatica del codice (che, per l'appunto, 
generano C). Esempio, Psoc Express di Cypress, Target Link, ecc.
- Il C è per costruzione "vicino" all'hardware e poco avido di risorse 
(puntatori, tipo e scope delle variabili, ecc.).
- Il C è un linguaggio estremamente adatto ad scrivere software modulari, a 
fare porting tra micro e tra sistemi, a sviluppare in team.
- Inoltre, in C hai degli strumenti per l'analisi statica del codice (es. 
LINT).
Tutto questo ti permette di lavorare in C in modo molto strutturato e 
efficiente, indipendentemente dalla bontà del codice asm generato. Che 
comunque è data per scontata con ogni compilatore decente.
-- 
simone.bern
Mr. Heisemberg is not the only one who can affect a measurement by looking 
at it (Robert A. Pease)
zsimone...@zliberoz.it
 (Rimuovere i caratteri di zorro per rispondere 
via mail)

 comunque è data per scontata con ogni compilatore decente.
Ecco una spiegazione, ora posso capire il perche' della superiorita' del C 
rispetto al Basic, cosa consigleresti per avvicinarsi al C non avendo grosse 
conoscenze in programmazione? possibilmente documentazione in italiano. 

 conoscenze in programmazione? possibilmente documentazione in italiano. 
Bhe non posso far altro che consigliarti l'ultraclassico "C programming 
language" di Kernighan, B. W. & Ritchie, D. ; esiste anche in italiano 
sotto il titolo "Il linguaggio C" edizioni Milano, Pearson 2004.
Ciao


Aggiungerei che molti compilatori C sono in grado di ottimizzare
moltissimo l'assembler prodotto, sia in prestazioni che in dimensioni.
Cosa che compilatori di altri linguaggi non fanno, per la ragione che
questo non è molto richiesto nell'ambito di uso di quei linguaggi.
Ad esempio un Basic difficilmente è indirizzato ad ambiti
professionali,
e quindi il produttore non si impegna ad ottimizzarlo più di tanto.

e quindi il produttore non si impegna ad ottimizzarlo più di tanto.
Se il produttore fa solo quello l'unico suo interesse è rendere il tool 
sempre più ottimizzato e performante.
Marco 

 sempre più ottimizzato e performante.
Questo non è detto. Magari l'interesse è vendere più copie del tool,
ampliando
il mercato rispetto a quello rigorosamente professionale, il quale,
come
altri hanno detto, apprezza in modo particolare il C.
Il punto è che sul C si è lavorato tantissimo per ottimizzare, sul
Basic no. Parlo in generale, non del singolo prodotto.

 Marco
Concordo la Melabs fa solo compilatori in Basic quindi si presume che si 
impegni nell' ottimizzare il codice prodotto, comunque il Pic Basic Pro non 
lo butterei tanto giu' (in verita' se dovessi basarmi su quello che ho letto 
piu' volte su questo news dovrei buttarlo) ho visto dei progetti realizzati 
interamente con questo compilatore anche di una certa complessita', infatti 
Elettronica IN ha presentato cose tipo  microspie gsm , localizzatore gsm 
con gps, quindi qualcosa di buono deve pur averlo questo compilatore, si 
deve comunque ammettere che chi usa i micro professionalmente non si 
sognerebbe mai di usare il basic.
La mia personalissima opinione da quasi ignorante in programmazione: se 
leggo un listatto in Pic Basic Pro riesco a capire cosa fa e ad assimilare i 
concetti di funzionamento, se invece leggo un listato in C non riesco a 
capire granche', mi piacerebbe tanto capire e fare qualcosa con questo 
linguaggio ma non trovo niente che possa servire veramente a chi vuole 
imparare partendo da zero.

 quelli verranno col tempo.
Grazie!! 

si puo' fare anchein debug con ICD2 sempre sotto Mplab?
Si, anche se ormai io ne faccio a meno e uso l'istruzione "debug" in diversi 
punti del programma per mandare sulla seriale stringhe, variabili e capire 
se ci sono errori nel programma .
Marco