Newsgroup: it.comp.lang.c++
Titolo: problema con Timer 8254

Ho riscontrato dei problemi usando il timer0 del 8254
programmato in modo 2, che credo sia il default per
windows.
Il problema e' che a volte la lettura del contatore
da' dei valori sbagliati. Ovviamente do' il comando
per il lacht e poi eseguo la lettura dei due bytes,
il tutto con interrupt disabilitato.
Per prova, ho letto ripetutamente il contatore e memorizzati
i valori in un array ed esaminando i risultati si nota
che qualche volta il valore fa un salto e poi riprende normalmente.
La frequenza con cui avvengono questi errori mi sembra che
sia dell'ordine di una volta ogni qualche centinaio di migliaia di
letture, ma e' sufficiente per rendere un programma poco
affidabile.
Qualcuno ha riscontrato questo problema e sa come risolverlo?
Oppure sono io che sto sbagliando qualche cosa?
Se puo' servire posso inviare il programmino in C che
mette in evidenza questo problema.
Grazie a tutti.
Luigi

Prova a mandarci il sorgente della funzione incriminata che ci diamo tutti
quanti un occhio. Non dovrebbero essere più di qualche decina di righe
A me succedeva la stessa cosa usando una scheda di acquisizione dati con un
8253; causa (nel mio caso): lo swappare del disco. Ovviamente il contatore
continuava a fare il suo dovere ma il processore, povero Pentium, aveva
altro da fare....
Tieni conto che Windows (da Win 3.0 a WinNT4.0) non è certo un bel sistema
operativo RealTime, nel senso che non ti può garantire tempi di risposta
prevedibili, MAI.... Il sospendere gli interrupt è inutile
OS: win95 o win3.11 o winNT ?
8254 di sistema o proprietario ?
Compilatore ?
CPU ?
========================
=  Vincenzo
=  
Vincen...@iname.com
========================

windows.
per fare queste cose dovresti prima sapere che un'applicazione con
privilegio 3 non puo` fare niente con l'hardware, percio` puo`
benissimo essere che quello che tu credi di aver programmato e` in
realta` un timer software. devi scrivere un VXD per essere a livello
kernel.
[Ranger, email: 
ran...@queen.it
]
[
www.zuzzurello.com/computer/ranger
]

kernel.
Non è sempre vero, nel senso che qualcosa si può comunque fare.
Lavorando con Win3.11 e Win95 è possibile scrivere senza problemi programmi
che usano hardware "vero", tipo gli 8254, anche senza scomodare tecniche di
programmazione non banali; la mia prima esperienza in C per Win di gestione
di convertitori AD/DA e timer è consistita semplicemente nel ricompilare le
vecchie funzioni TurboC che usavano le istruzioni INPORT e OUTPORT.
Il discordo cambia se vuoi usare interrupt (allora si che il casino comincia
e bisogna scrivere delle Vxd).
Ovviamente se usi HW di sistema occorre sapere se qualche processo lo sta
già usando (non penso che la cosa sia banale, io uso sempre HW non
standard).
WinNT è più "stronzo" perchè, come in tutti i SO degni di tale nome, la
gestione dell'I/O può essere fatta solo nel kernel e quindi eventuali
tentativi di OUTPORT vengono inevitabilmente bloccati come non permessi se
fatti da un programma qualunque.
Per fortuna esistono compilatori che convertono istruzioni di OUTPORT a
funzioni a livello di kernel che provvedono ad eseguire le operazioni di I/O
(inefficente ma utile, anche se poi così si perde la protezione che NT
dovrebbe garantire a tutti i programmi).
In effetti posso ricompilare qualunque programma DOS anche sotto NT con la
differenza che il compilatore trasforma un'istruzione OUTPORT in una
chiamata ad una funzione di kernel invece che in una semplice istruzione
assembler. Ovvio che la cosa dipende dal compilatore e vale solo se non uso
interrupt
Comunque non è possibile scrivere programmi che rispondono in un tempo certo
(anche se ho letto di versioni di NT per Real Time): in questi casi è meglio
il buon vecchio DOS (vero, non emulato)
--


 [
www.zuzzurello.com/computer/ranger
]
Quello che dici puo' essere vero, pero' non credo che
il timer 8254 venga simulato via software da
windows. Il timer 0  in particolare e' usato
come timer tick per generare circa 18 interrupt
al secondo e serve come riferimento anche per
l'orologio di sistema, quindi DEVE essere
necessariamente un qualcosa di hardware.
Comunque anche se il timer 0 fosse simulato
via software, il mio problema non cambierebbe.
Ecco in pratica che cosa leggo dal timer0:
...
0AED
0AE1
0AD6
0ACA
0ABE
0659 <---- valore sballato
0A8D 
0A81
0A76
0A6A
0A5F
0A52
...
Come si vede, tra una lettura e la sucessiva il timer
viene decrementato di circa 11-12 unita', che corrispondono
a circa 10 microsecondi che e' il tempo che il programma
impiega tra due letture.
A volte pero' viene letto un valore notevolmente piu'
basso di quanto non ci si aspetti. Potrebbe sembrare
che il programma fosse stato interrotto e quindi avesse
perso tempo in una isr, ma non e' cosi'.
Infatti le letture sucessive sono di nuovo in linea con
quelle precedenti alla lettura sballata.
Siccome non sono riuscito a capire se questo problema
dipende da miei errori o da che cos'altro, prego
chiunque che abbia esperienze nella gestione del
timer 8254 di darmi qualche idea.
Grazie.
Luigi

il buon vecchio DOS (vero, non emulato)
verissimo !!
Gianpaolo Bottin
- The truth is out there -

timer 8254 di darmi qualche idea.
come fai a leggere il timer ?
mi sembra che si possano leggere solo 8 bit alla volta, percio` solo
con 2 inp(0x40), giusto ?
potrebbe essere che un interrupt ti capiti proprio in mezzo ai 2
inp(0x40), percio` il valore e` sballato. per risolvere il problema
(se e` dovuto agli IRQ) dovresti disabilitare gli interrupt. peccato
che non puoi, se non fai un vxd.
[Ranger, email: 
ran...@queen.it
]
[
www.zuzzurello.com/computer/ranger
]