Interrupt o polling?

[aduri]

Salve a tutti,
Vorrei un consiglio di programmazione.
Nel momento in cui ricevo un impulso di comando devo compiere conversioni A/D per circa 5msec.
Questa successione è periodica e si ripete 7 volte.
Io, inizialmente, pensavo di usare gli interrupt su RB0 e impostare il timer1 per contare fino a 5msec.
Leggendo, però, alcune discussioni sembra che quando i segnali sono periodici e quindi non eventi casuali (ad esempio una tastiera) è preferibile la tecnica del polling.
Sul primo INT su Rb0 penso basti controllare lo stato del pin RB0 e se si verifica l’evento si va al sotto programma dell’ADC.
Riguardo il timer avete dei consigli su cosa fare.
Il timer inteso come delay non credo mi possa essere utile.

Ciao
Antonio

[crestus]

dipende se devi fare anche qualcos'altro....

non hai niente da fare? sono assolutamente equivalenti come procedure.. devi

anche elaborare i dati, ti direi di utilizzare gli interrupt che così ti porti avanti con i calcoli...

se c'è qualche motivazione di fondo però, non saprei..

[c1b8]

...Nel momento in cui ricevo un impulso di comando devo compiere conversioni A/D per circa 5msec.
Questa successione è periodica e si ripete 7 volte. ...

Non mi è molto chiaro...
Devi leggere 7 valori dal ADC, acquisizioni distanziate 5ms l'una dall'altra, oppure devi eseguire delle acquisizioni ADC alla massima velocità, acquisizioni che durano circa 5ms e ripetere questo insieme di acquisizioni per 7 volte?
Se, come credo, stiamo parlando della seconda ipotesi allora non puoi utilizzare il timer e l'interrupt associato.
Potresti utilizzare l'interrupt su RB0 come trigger, per avviare il processo di acquisizione, ma poi nessun trigger e nessun timer. Una cosa fondamentale da tenere a mente quando usi gli interrupt è che ti servono 3 (per gli interrupt generati dai dispositivi interni) o 4 (per gli interrupt esterni) cicli macchina prima di entrare nella routine di interrupt: questo è infatti il tempo di latenza necessario al PIC.
A questo tempo minimo devi aggiungere le istruzioni necessarie a gestire l'interrupt stesso: salvataggio di alcuni registri fondamentali, loro ripristino alla fine della routine, test e ripristino dei flag di interrupt, ecc.
In definitiva l'interrupt va bene se hai "molto" tempo a disposizione per gestirlo e, sopratutto, se passa molto tempo tra un interrupt ed il successivo.

[aduri]

Innanzitutto grazie della risposta.
E' il solito progetto tesi (ho finito la parte analogica) il trigger su Rb0 viene da un NE555 usato come zero crossing che ogni 10msec manda l'impulso, forse basta il polling senza scomodare l'interrupt?
E' come pensi tu, una volta che arriva l'impulso di trigger partono le acquisizioni sui due canali e devono durare 5msec (da 0 a Vmax).
Per simulare il campionamento contemporaneo utilizzo la tecnica della media.
Campiono in questa successione ADC1- ADC2 - ADC2 - ADC1 faccio la media:
adc1new = (adc1.1 + adc1.2)/2) e adc2new (adc2.1 + adc2.2)/2).
Avevo dei dubbi anche riguardo gli interrupt nidificati....e tu me li hai dissipati.
Farò dei test e vedo quanti campioni riesco a fare in quell'intervallo di tempo 5msec.
L'altro dubbio è la creazione dell'array di dati e l'invio alla seriale.
Facendo due conti supponendo 2 serie di misure da 36 campioni x 2 (x media) avrei:
36 x 2 x 2=144 byte, con start e stop sono 1440 bit a 115.200 bps ---->1/80 = 0.0125
ci vogliono 12,5 ms..... non ce la faccio in 5ms neanche riducendo della metà i campioni.
Avevo fatto qualcosa sui buffer circolari in Java all'università ma devo trovare gli appunti.

ciao
Antonio

[c1b8]

Per quanto riguarda l'avvio dell'acquisizione, ossia all'arrivo dell'impulso dal NE555, credo sia indifferente l'impiego di un interrupt o del polling se lì'impulso ha una durata sufficientemente alta e se durante l'attesa non devi fare altro.
Mi spiego meglio. Se il ciclo di polling per testare l'entrata (cioè l'impulso) durasse ad esempio 50 micro secondi, il tuo impulso dovrà durare più di 50 micro secondi, altrimenti rischi di non vederlo. Se l'impulso può durare meno di quel tempo allora devi utilizzare l'interrupt.
E' a mio avviso conveniente utilizzare l'interrupt anche nel caso in cui si debba ad esempio testare l'input da tastiera o da seriale perché, in attesa dell'impulso, possono arrivare parametri di configurazione o altro da altri dispositivi. Questa situazione renderebbe infatti il tuo ciclo di polling di durata non esattamente definibile e potresti ricadere nella situazione precedente.

In quanto all'invio dei dati via seriale sei sicuro che sia un problema non riuscire ad inviare i dati in 5 ms? Voglio dire che essendo il segnale da campionare periodico, perdere un periodo potrebbe non essere un problema.
Avere i dati di tutti i periodi o solo dei periodi 1, 3, 5, ecc. non dovrebbe cambiare l'informazione che otterrai alla fine.

[aduri]

Mi spiego meglio. Se il ciclo di polling per testare l'entrata (cioè l'impulso) durasse ad esempio 50 micro secondi,
il tuo impulso dovrà durare più di 50 micro secondi, altrimenti rischi di non vederlo. Se l'impulso può durare meno di quel tempo
allora devi utilizzare l'interrupt.

Credo che dovrò testarlo con l'HW.

In quanto all'invio dei dati via seriale sei sicuro che sia un problema non riuscire ad inviare i dati in 5 ms?
Voglio dire che essendo il segnale da campionare periodico, perdere un periodo potrebbe non essere un problema.
Avere i dati di tutti i periodi o solo dei periodi 1, 3, 5, ecc. non dovrebbe cambiare l'informazione che otterrai alla fine.

Quà ti seguo come concetto ma a livello sw come lo realizzeresti?

Io inizialmente pensavo di caricare in ram 2 array Va(n) e Vk(n) per 7 cicli di misura e la media (per guadagnare tempo prezioso) farla a livello sw su PC.
Potrei, a questi punti fare i campionamenti per tutta la durata dell'impulso positivo sinusoidale (10msec) per migliorare la precisione.

Il problema è che, fatta la prima serie di array per una certa tensione di griglia (Vg1=0, Vg2=1,5V ecc. fino a Vg7) l'array verrebbe sovrascritto
con i successivi valori acquisiti e se facessi l'invio alla seriale dopo un certo periodo invierei l'ultima serie e le altre si perderebbero.

In alternativa avevo in testa il buffer circolare che permetteva di disaccoppiare i tempi di r7w di buffer di dati
ma devo lavorarci su.

Forse mi stò aggrovigliando un po'.
Purtroppo i tempi sono stretti e se non riesco a risolvere questa parte sarò costretto a presentare una tesi che non mi soddisfa pienamente.


ciao
Antonio

[c1b8]

Se capisco bene quindi il segnale è periodico per 10ms, poi cambia qualche cosa (la Vg) e cambia il segnale da campionare. Giusto?
Se è così allora il segnale non può ritenersi periodico e i discorsi fatti prima non valgono.
Una soluzione potrebbe essere quella di comandare il cambio di Vg da PIC?
Se fosse possibile allora il tuo segnale non rimane più "stabile" per 10 ms ma per tutto il tempo che ti serve ad acquisire, elaborare, inviare, ecc. perché sarà il tuo sw a decidere quando cambiare i riferimenti.
Il buffer circolare può funzionare se il tempo di acquisizione di un campione equivale o è maggiore al tempo di invio del carattere stesso.
Due conti veloci. Se invii a 115200 bps avrai l'invio di un carattere ogni 86,8 micro secondi, ai quali aggiungere tempi di elaborazione per l'invio stesso, diciamo quindi 100 microsecondi a carattere. Ogni campione è di 2 caratteri e devi campionare 2 segnali: invii quindi un campione completo (4 byte) ogni 400 microsecondi.
Avresti una frequenza di campionamento non superiore a 2,5 kHz. Bastano?
Tieni presente che nei 10 ms che hai a disposizione riusciresti ad acquisire solo 25 campioni.

L'idea di elaborare i dati in un secondo momento e quindi su PC mi sembra una buona idea.
Anche se i 400 microsecondi visti prima potrebbero consentirti di acquisire i campioni e calcolare la media, lascerei il compito ad un sistema esterno dove potresti decidere di eseguire calcoli diversi in qualsiasi momento.

[aduri]

Mi è venuto in mente che potrei mettere i campioni in 2 array bidimensionali.
Premetto che il segnale da campionare passa da un partitore resistivo e da un operazionale collegato come
inseguitore di tensione (quindi bassa impedenza d'uscita) quindi potrei fare una ipotesi di 25uSec di campionamento e 5usec per il caricamento di un array bidimensionale in memoria otterrei in 10msec 10.000/30= 333 campionamenti per riuscire a cadere esattamente a 10msec
Chissà se i tempi sono reali.????
Potrei fare dei tentativi con dei delay:
2 cicli da 150 x 30us + 6us x150 = 2 x 150 x 30 + 6 x 150 = 9900 usec
7 gradini x 9.9msec= 69.3 anzichè 70msec alla fine dei cicli.

Cosa ne dici?
Mi sembra troppo semplice perché possa funzionare
In memoria ci staranno tutti questi dati?
300x7=210 word ----> 16bitx2100=33,6K
mi sembra che la ram sia 32 K magari riduco un po' i sampling.

ecco lo stralcio di codice in polling:

Codice: Seleziona tutto

k=0
delay_ms(10000)   'tempo preriscaldo filamento 10 sec

if rbo.1 =1 then                             'impulso di trigger
          for n=0 to 150
           Va[k,n]=read_adc(0)  'carico matrice anodica dove k indice tensione di griglia
           Vk[k,n]=read_adc(1)  'carico matrice catodica dove k indice tensione di griglia
         delay_us(6)        'ritardo per ottenere 9.9msec
      next n
      k=k+1

    if k=7 then usart
    next if
next if

ciao
Antonio

[c1b8]

Forse da qualche parte lo hai detto ma in questo momento mi sfugge: quale PIC e a quale frequenza di clock intendi utilizzare?
Te lo chiedo prima di provare a fare qualche calcolo...

[aduri]

Userei il PIC 18F4550 e 20Mhz di quarzo.

ciao