Newsgroup: it.comp.programmare.win32
Titolo: Communicazione tra driver e applicazione

Ciao a tutti,
ho una domanda da fare a tutti voi... ecco: abbiamo realizzato un driver per
NT per pilotare una carta d'acquisizione A/D (Analogica/Digitale). Ogni
(circa) 5ms, la carta crea un'interruzione (IRQ5) sul Bus del PC. Ecco, il
nostro driver, quando vede che l'interrupt. 5 é azionata chiama una routine
(funzione) definita dalla nostra applicazione visuale (fatta in Builder
4.0). Chiaramente l'applicazione visuale setta il driver!!!
Ecco il problema: se lasciamo lavorare il computer senza toccarlo, tutto va
bene, ma se iniziamo ad aprire e chiudere delle applicazioni, ci siamo resi
conto che il driver non arriva più a comunicare a intervalli precisi con
l'applicazione. (infatti se prima comunicava a intervalli di 5ms, a volte
passano anche 20-30ms prima che il driver ricominichi con la nostra appli.)
Dunque, io vorrei sapere: secondo voi dov'é il problema. È tra carta A/D et
driver o tra driver et l'applicazione.
Secondo me, ma non sono sicuro, il problema si trova tra driver e
applicazione. È possibile che, se il PC é troppo "caricato", qualche
messaggio tra driver e appli sia perso??? Se si come risolverlo.
Grazie mille per i consigli e per delle spiegazioni
--
Matteo Ferrini

 wrote in message
news:8ek2lk$7j5$1...@news1.sunrise.ch...


NT per pilotare una carta d'acquisizione A/D (Analogica/Digitale). Ogni
[snip]
Cinque ms non è un tempo molto stretto, però non è una
buonissima idea gestire "problematiche" quasi real-time
con i soli driver. Non conosco la natura della vostra
applicazione, ma - a meno che di non andare a morire
di PCI bus-mastering, DMA o altre menate, sarebbe bene
incorporare nel vostro hardware una logica di controllo
associata ad una memoria. I due principali vantaggi che 
potreste ottenete sarebbero: a) la capacità di immagazzinare
un po' di dati nel caso che il PC non fosse "pronto" a prenderli
sul momento; appena il PC "si libera" un burst transfer potrebbe
essere usato per flushare i dati sul PC. b) La possibilità di
gestire gli istanti di campionamento con una precisione
estrema magari riducendo il jitter pressoché a zero (come
saprete, il jitter nei campionamenti comporta un fenomeno
di spreading dello spetttro del segnale campionato
riducendo - a volte anche di molto - la qualità del risultato).
Bisogna anche dire che, se le "cadenze" sono generate
dal converter, il problema è già risolto. la logica all'interno
della vostra scheda di acquisizione, potrebbe essere
fatta con un microcontrollore (o un DSP o un DSP/microcontrollore) 
che semplificherebbe di molto la gestione del buffering.
Bisogna comunque dire che la scelta di utilizzare una moderna
logica programmabile (FPGA) permette di accedere 
a librerie che offrono building-blocks per la gestione del
bus PCI (anche in master) e per la gestione di dual-port RAM.
Le scelte architetturali son molteplici: dipendono molto
dal costo e dalle prestazioni. Il tradeoff è tutto.
Benché in ambito windows non abbia mai realizzato nulla che sia
troppo a contatto con l'hardware, sei anni fa mi sono cimentato
con la progettazione di un campionatore audio stereo per
PC. Era una schedaccia ISA a 16 bit. La scheda campionava
a 48KHz su due canali con un flusso a 16 bit. Il transfer rate
verso il PC era quindi 48000 * 2 canali * 2 bytes al secondo.
Cioè 192Ks/s ad 8 bit. tropo per un interrupt handler. Avevo
 utilizzato un canale DMA del PC . Si configurava quest'ultimo 
in modo che generasse un interruzione solo dopo
che avesse ricevuto un certo numero di bytes. A quel punto
i dati erano già in memoria. Bastava solo "retriggerare"
la scheda ed attendere che arrivasse il resto, ovviamente in
un'area di memoria diversa dalla precedente. Nel frattempo
il PC salvava i dati (quelli presenti nel buffer appena riempito)
su disco. Sulla scheda era montato un DSP56001 che, oltre 
ad eseguire un po' di filtraggi, gestiva il FIFO che "tratteneva"
i dati finché il DMA del PC non era stato ancora retriggerato.
Sulla scheda c'era anche una glue logic fatta con diverse
PLD. Funzionava tutto molto bene. Però ormai è storia: roba 
che girava sotto piattaforma DOS a 16 bit con un hardware
a tutt'oggi obsoleto.
Comunque ... buona fortuna.
Ciao!
Giuliano

 wrote:
Guarda che, "checchésenedica", l'Asino è un animale
molto intelligente.
Adieu!
Giuliano

 NT non e' un vero Real-Time OS.
Non e` paragonabile ai veri RTOS, ma 5 ms sono un'eternita` per un PC
moderno. Negli RTOS si parla di pochi microsecondi, o meno.
---
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

 [...]
Chiarisci meglio questo punto. Avete scritto il driver "alla carlona",
ossia andate semplicemente a interrogare il PIC in polling? In quel caso
e` chiaro che va a schifo e perde dei segnali. Queste cose si dovrebbero
fare "veramente" interrupt-driven, sfruttando i meccanismi della CPU e
dell'OS per la gestione degli IRQ. Purtroppo non ti so dire di piu`
perche` per ora non ho ancora toccato i kernel-mode drivers (anche se
presto o tardi, piu` presto che tardi, lo dovro` fare).


 Bye! Lorenzo Lutti
No, non abbiamo fatto niente alla "carlona"!!!
Se vuoi, l'applicazione chiama il driver dicendogli, per esempio, che quando
l'iRQ5 é attiva deve chiamare la funzione void TrattaIrq() che si trova
nella nostra applicazione.
In questo modo, il driver, SENSA fare del polling ma utilizzando i
meccanismi hardware della CPU, aspetta che l'iRQ5 venga azionata e a questo
momento chiamerà la funzione TrattaIrq() che abbiamo scritto nella nostra
appli.
Cosa credi, che non facciamo le cose al serio!!!
A proposito, il nostro driver, di nome MapMemPlus, é disponibile
GRATUITAMENTE (sensa source...
quelle devi pagarle) al sito: 
http://www.einev.ch/iai/activite/mmp.htm



 
http://www.einev.ch/iai/activite/mmp.htm
Lo scarico senz'altro, queste cose vengono sempre utili.


 assegnati a lei, e quindi degli IRQ andranno persi.
Quindi una task in user mode viene eseguita in multipli di 10 ms: corretto ?
Conosci i tempi necessari per il passaggio da una task all' altra ?
Grazie e Ciao!
Fabrizio

 all' altra ?
Penso che si si tratti di qualche microsecondo, o forse anche meno.


 interattivi).
"Standard" nel senso che puo' essere cambiato dall' utente ? Posso cambiare
il time slice senza dover ricorrere ad NTRT ?
Ciao e Grazie
    Fabrizio

 ?
Beh, intendevo "standard" perche` era quello usato da un po' tutti gli
OS sulle maggiori piattaforme... comunque sotto a NT la durata dello
slice si puo` effettivamente cambiare. Hai presente quella vecchia
storia secondo la quale, modificando qualche voce del registry, si
poteva "trasformare" un sistema NT Workstation in un sistema NT Server?
Ecco, si tratta sempre delle stesse chiavi (NT Server usa uno slice piu`
lungo, proprio perche` non deve essere usato in modo interattivo).
Dubito che su MSDN abbiano riportato la procedura ;-). Tempo fa ho
scaricato un programmino che modifica diversi parametri dello scheduler
dal solito posto, la madre di tutti i siti sullo smanettamento di
Windows:
www.sysinternals.com
