Newsgroup: it.hobby.elettronica.digitale
Titolo: Interrupt Vs Convertitore analogico

Salve,
ho la necessità di misurare la velocità di 2 ruote tramite un sensore ad 
effetto Hall.
Per fare ciò potrei usare un microcontrollore con 2 interrupt (uno per 
ogni ruota) e 1 timer, misurare la distanza tra 2 interrupt consecutivi e 
da lì ricavarmi le rivoluzioni al minuto o al secondo.
Il problema di questa soluzione è che molto difficilmente si riesce a 
ottenere un sistema propriamente real-time.
Sto usando una board con un LPC2103 a 57mhz, anche alla massima velocità 
delle ruote (480hz) ho tutto il tempo per gestire un interrupt, poi 
l'altro o addirittura gestirli entrambi qualora capitano simultaneamente 
all'interno di uno stesso impulso, ma la frequenza degli arrivi è 
ovviamente proporzionale alla velocità delle ruote e la percentuale di 
tempo spesa all'interno delle routine di interrupt è diverso in base alle 
condizioni esterne...la cosa non creerebbe problemi se il MCU fosse 
dedicato solo a questa funzione, ma per sviluppi futuri ho in progetto di 
fargli fare tante altre cose (da qui la scelta dell'LPC2103) e vorrei che 
il tutto fosse perlomeno soft real-time.
L'alternativa è usare un convertitore F/V analogico, acquisire la 
frequenza tramite ADC a intervalli da me stabiliti e sapere quindi 
esattamente quanto tempo passerò nelle funzioni di interrupt o meno. Come 
convertitore pensavo all'LM2917, ma non ho esperienze in merito: che 
precisione posso aspettarmi e quali complicazioni può avere una soluzione 
del genere?
-- 
N1 under...
ZX-6r '04 Cocci & Dolori
R6 '06 *********
CRe 250 '99 Almost Glue
XS 400 "90" Nescafè Racer

 del genere?
Se come alternativa hai già considerato di aggiungere qualcosa di 
esterno (es. convertitore F/V) valuta l'idea di metterci un micretto che 
fa solo quello. Via seriale l'LPC1203 lo interroga e legge il valore 
"istantaneo" delle due velocità.
Tieni conto che in base al tipo di esigenza puoi anche contare più 
impulsi per ottenere una migliore precisione.
Oltre alla frequenza massima di rivoluzione è importante considerare 
anche quella minima.
Marco

 
fatto e mi sta bene che al di sotto di un tot non ci sia proprio 
rilevazione


 ottenere un sistema propriamente real-time.
...
Di solito si usano dei timer con capture: all'arrivo del fronte viene
salvato il valore del timer e generato interrupt.
La routine di gestione ha (quasi) tutto il tempo di leggersi il valore
esatto dell'evento.
L'ATmega128 ne ha 2.
Piccio.


Quoto Piccio.
In ogni caso, anche se non puoi/vuoi usare i timer capture, se il resto 
dell'applicazione è fatto bene, il tempo di risposta all'interrupt è 
molto breve.
Se la massima frequenza è 480Hz e la vuoi misurare con una accuratezza 
dell'1%, significa che devi servire un IRQ entro ~21uS, che è un tempo 
enorme in confronto ai tempi di latenza dell'IRQ sui microcontroller 
moderni.
-- 
  _|/ Francesco Sacchi - Develer S.r.l.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 
non è questo il problema.
Sono assolutamente certo di avere tutto il tempo per la gestione 
dell'interrupt, quello che non mi piace è che in questo modo la frequenza 
degli interrupt è legata alla velocità della ruota (il che è ovvio...) 
che in altri termini significa che il processore è tanto più carico 
quanto più gira la ruota. Per quanto siano eventi che richiedono 
un'esecuzione minima non è comunque un gran modo di fare le cose. 
Avendo una unità a parte che si occupa di leggere la velocità della ruota 
e di proporre in uscita il valore corrente io posso, sulla MCU centrale, 
allocare un TOT di tempo alla lettura ed elaborazione dei dati, 
indipendentemente dal valore di questi, sapendo che questo non varierà in 
nessun caso.


 nessun caso.
Vedi tu, io allocherei sempre il massimo (esagerando a 5uS) e vivrei 
felice, secondo me il problema non ce l'hai.


 un'esecuzione minima non è comunque un gran modo di fare le cose.
Puntodivistalmente parlando, dissento.
Il punto di forza dell'interrupt è espressamente la possibilità di
gestire eventi aperiodici.
Una volta stabilito che la ruota non può fisicamente girare più veloce
di un tot, si alloca come tempo di CPU il valore massimo
corrispondente.
Se la ruota gira più piano, si hanno maggiori garanzie sulla sicurezza
dell'elaborazione.
Supponendo di poter gestire la risposta ad ogni interrupt in 50
microsecondi, al massimo avrai un carico di CPU di 50 * 480 / 1000000
= 24 ms ovvero il 2,4% sul tempo di calcolo.
Interrogare una periferica esterna sarebbe certamente più oneroso,
semplicemente per il tempo di trasferimento dati.
Darebbe anche maggiore incertezza sul momento dell'acquisizione.
La conversione ADC, invece, sarebbe ulteriormente svantaggiosa per il
semplice tempo di conversione necessario, la risoluzione e l'impiego
di componentistica esterna.
Voto per l'interrupt: il software non si rompe, l'hardware sì.
Piccio.


 
sì ma il punto non è che la ruota possa causare un numero eccessivo di 
interrupt e quindi sovraccaricare la CPU, il problema (dal mio punto di 
vista che in questo caso è puramente perfezionistico dal momento che sono 
in stra-sovrabbondanza di risorse) è che se decidessi di eseguire 
determinate operazioni a intervalli stabiliti, l'aperiodicità di questi 
interrupt mi manda tutto in confusione. Ripeto: è campanilismo.
Ad ogni modo per risolvere la cosa ho pensato di fare come segue:
ho 4 timer (santo LPC2103). Ne imposto uno come timer vero e proprio e 
altri 2 come contatori. I contatori mi contano il numero di impulsi dalle 
2 ruote, il timer mi tiene il tempo e ogni TOT mi genera un interrupt, 
blocco l'esecuzione della CPU e leggo il valore dei 2 contatori.
Mi sembra pulito e assolutamente realtime:
- la frequenza degli impulsi non influisce sul carico della CPU
- so esattamente come e quando leggerò i 2 valori
- posso fare uno scheduling assolutamente preciso di cosa accade e quando 
accade (eccezioni/errori a parte)
...non avevo mai usato i timer come contatori e quindi inizialmente non 
avevo pensato a questa possibilità.
che ne pensi?


 avevo pensato a questa possibilità.
Dovrebbe essere ok, a parte il fatto che, come dicevo prima, è un po' 
sovradimensionato: usi 3 timer quando ne basterebbe uno, ma se ti 
avanzano è ok.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org

 
...è un progetto in divenire.
Volendo includere anche una sezione di logging e una di gestione di 
dispositivi esterni (in base ai dati in ingresso), puntare ad avere un 
sistema soft realtime e comunque deterministico dal punto di vista 
temporale mi sembra una solida base di partenza.
Al momento sono 3 parti del progetto che ho implementato su 3 board 
separate (di fatto sempre un LPC2103), vorrei riunirle e farle coesistere 
su un solo dispositivo.
Grazie per l'aiuto e le opinioni!
