Newsgroup: it.comp.os.win.win2000
Titolo: E' possibile gestire aplicazioni real-time ?

Ho fatto delle prove con VB6 utilizzando l'oggetto timer e mi sono
accorto che il minimo interrupt software che riesce a fare con Win 2000
è di 10 mS , mentre con Win 98 è di 54 mS legato al clock interno.
Mi ricordo che molto tempo fa qualcuno mi aveva detto che c'e' un
programma di win che riesce a dare una priorità maggiore al processo
desiderato.
Io ho sostanzialmente bisogno di andare a fare dei controlli
sistematicamente ogni 2 mS utilizzando VB6 con eventualmente chiamate
esterne ecc.
Ho visto che nell'help win 2000 lo da come sistema real time.
Come si fa a settarlo per i 2 mS ???
Potrei simularlo con un interrupt hardware magari dall'esterno ? (Sto
pensando alla seriale) Come ?
Grazie
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Mazza, una delle domande + curiose che abbia visto qui.
Non so esattamente se potrà servirti, ma attraverso il task manager è
possibile(tramite menu) impostare la priorità di un processo a "real time".
Ciao

 esterne ecc.
2ms mi sembra molto "pesante", soprattutto se si tratta di codice VB. Perchè
non provi ad utilizzare direttamente il C/C++ ? Oltretutto settare
un'applicazione con priorità real-time rischia di togliere tempo perfino
allo stesso sistema operativo. Sei sicura di volere questo?
Toglimi una curiosità: puoi dire di che tipo di controlli si tratta? (sempre
che non vìoli la segretezza del progetto su cui stai lavorando...)
-- 
"tanto va la gatta al largo che affoga"
(per rispondere personalmente leva IlDitoDalCulo)

 time"
ma a che serve? la prima volta che il thread si metterà in attesa verrà 
rimesso in coda dallo scheduler, e potrebbe perdere l'interrupt. Se non 
si mette mai in attesa, d'altra parte, sarà l'unico thread attivo e non 
si potrà eseguire altro in risposta all'interrupt. L'ideale sarebbe una 
macchina biprocessore, in modo che i due thread possano essere eseguiti 
contemporaneamente. Altrimenti vedo due soluzioni:
 - usare due thread real-time, che si schedulino a vicenda con un'event
   pair (cioè due Event a reset manuale a cui scambiare atomicamente lo
   stato con SignalObjectAndWait)
 - eseguire in un unico thread real-time due fiber, che si schedulino a 
   vicenda con SwitchToFiber
Per non introdurre attese estranee che potrebbero togliere al thread il 
diritto alla CPU, come clock non può essere usato un waitable timer, ma 
andrà usato un ciclo di busy wait, da ricalibrare a ogni esecuzione sul 
performance timer, per tener conto del tempo "perso" a gestire l'evento 
precedente. Per azzerare la possibilità di context switch e page fault, 
i due thread (se si sceglie questo modello) dovrebbero fare parte dello 
stesso processo, e i loro stack, il codice che eseguono e i dati di cui 
si occupano andrebbero bloccati in RAM con VirtualLock. Ovviamente fare 
I/O su disco o avere un qualsiasi tipo di interazione con l'utente sono 
cose assolutamente impensabili, a meno che non si abbia un biprocessore 
e si possa dedicare la seconda CPU interamente alla parte time-critical 
(di suo, Windows dovrebbe usare solo la prima CPU e lasciare la seconda 
libera). Ultima cosa: interrompere questo mostro su un uniprocessore è, 
come si può intuire, una bella sfida, dato che monopolizza tutta la CPU 
per sè. Possibile soluzione: un altro thread real-time tenuto in attesa 
con una ReadFile di 1 byte su una periferica (per esempio una seriale), 
che, appena sveglio (cioè appena la periferica mette a disposizione dei 
dati), uccida gli altri thread con TerminateThread. Personalmente penso 
che fare tutto questo con Windows, per di più senza un driver dedicato, 
sia una follia, ma se a Teresa serve fare dell'hard real-time in queste 
condizioni, sappia che è così che dovrebbe procedere
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.4. C, C++ and ASM developers
                               and beta testers are welcome!

 Potrei simularlo con un interrupt hardware magari dall'esterno ?
solo in kernel mode. In nessun modo con Visual Basic


 pensando alla seriale) Come ?
IMHO la seriale e' da pensione sposta direttamente il progetto su usb 2
se non serve dell HW


Come è possibile utilizzare il kernel mode di cui parli ? 
E le relative maschere interrupt ?
Si puo' fare da VB ?
Hai qualche esempio ?


Non sai se c'e' in giro gi' qualcosa scritto in C ,come tu suggerisci,
che possa essere utilizzato da me con chiamate VB ?
Oppure se volessi usare una porta USB per gestire un interrupt con 2 mS
posso ricevere l'evento da VB ? Come ? 


Complimenti per la risposta. Non è sempre facile trovare delle persone
con la tua preparazione.
Volevo pero' chiederti (vista la mia poca esperienza in real-time)
qualche esempio in VB, se possibile,
che riassuma le tue considerazioni
Tieni conto che i i 2 mS mi servirebbero per calcolare la velocità con
la quale sta viaggiando
un motore in continua e in funzione della velocita' devo interagire con
lo stesso.
Vorrei evitare di usare 2 PC (uno master e uno slave che fa solo questo)
perche' avevo pensato di usare un PC con un applicazione DOS che
interagiva
con il PC con Windows.
Se fosse possibile usare un PC solo sarebbe molto comodo.


 posso ricevere l'evento da VB ? Come ?
Teresa scusa la franchezza ma questo non si puň assolutamente fare in Visual
Basic, nemmeno con tutte le ottimizzazioni che puoi pensare. Per ottenere il
controllo che richiedi, ti faccio un riassuntino di tutte le soluzioni
proposte qui:
- Se vuoi tenerti Windows: macchina biprocessore, uno dei due dedicato
esclusivamente alla tua applicazione, l'altro per il sistema operativo (cosa
che mi sembra un po' costosetta)
- Senza windows: macchina dedicata (anche poco potente) ma con S.O. DOS
- Linux, con un'installazione particolarmente calibrata per le tue esigenze
(cioč poco piů del kernel, una shell testuale e solo i driver
indispensabili)
- Scheda di controllo customizzata oppure I/O su porte USB (lascia perdere
le seriali RS232)
Qualunque sia la soluzione hardware che sceglierai, la soluzione software č
sempre e comunque la stessa: programmazione in C, o meglio ancora ASM, a
livello kernel. É l'unica che ti consente di ottenere la precisione che
cerchi.
In bocca al lupo


 che interagiva con il PC con Windows.
generalmente, per questi casi ci si compra un microcontrollore (costano 
pochissimo), lo si programma e lo si controlla tramite cavo seriale. E' 
più facile di quello che potrebbe sembrare a prima vista: sono computer 
semplicissimi, gli strumenti non mancano e la comunità di programmatori 
è numerosa
