Segnale di trigger

man 3 usleep ... ?? puoi specificare un intervallo espresso in microsecondi. Se ti serve una risoluzione ancora maggiore usa la nanosleep(2).

Se usi windows non so che dirti.

ciao! as

"Alessio Sangalli" ha scritto nel messaggio news:bo60sr$173fsm$ snipped-for-privacy@ID-157791.news.uni-berlin.de...

Se ti riferisci al "normale" Linux, queste funzioni non vanno bene per cio` di cui si parla in questo thread. Nei sistemi preemptive non realtime puoi avere soltanto garanzie di ritardi minimi, mai di ritardi massimi. I ritardi possono essere arbitrariamente allungati dalla prelazione dello scheduler, in multipli di tempi che a seconda dei casi variano fra i 10 e i 20 millisecondi.

Probabilmente esistono estensioni realtime per Linux (come pure per Windows) che ti permettono di farlo, ma in ogni caso non sarebbe affatto una buona idea tentare di risolvere questo problema via software: basta un monostabile da 10 centesimi collegato a un pin della porta parallela.

Ciao Quando esisteva il buon vecchio Qbasic era troppo facile ...e per questo ..l'hanno tolto !!!

Ciao Giorgio

Comunque:

REM out da pc porta parallela REM porta di controllo &h37A REM bit 0 per strobe (pin 1) bit 8 per select (pin 17) OUT (&H37A), 1 REM PRINT " mando 1" REM perdo tempo FOR i = 1 TO 1000: NEXT

OUT (&H37A), 0 REM PRINT "mando zero"

FOR i = 1 TO 2000: NEXT END

"Giorgio Montaguti" ha scritto nel messaggio news: snipped-for-privacy@news.tin.it...

Visto che sei un nostalgico del Basic, ti metto alla prova! Ti ricordi l'istruzione WAIT? Era miracolosa per interagire con l'hardware, ma aveva un piccolo difetto...

Ciao Valeria Purtroppo io usavo i computer quando fornivano esclusivamente Basic (Tek 4051 per comando strumenti programmabili HP, per collaudi elettronici automatici) E a casa il mitico Spectrum ..che pero' permetteva anche l'assembler !!! E il "purtroppo" e' nostalgia di ben altro.. che si chiama "gioventu' " !!!!

Comunque quella istruzione ,non ricordo bene perche', ma mi e' sempre stata antipatica, e usavo invece cicli di for-next per i ritardi (con la disapprovazione di chi si preoccupava della non trasportabilita' dei programmi) Mi sembra di ricordare che piu' che un Wait fosse una specie di Wait Until... che complcava le cose .

Raccontami ..il difetto.

Ciao Giorgio

"Giorgio Montaguti" ha scritto nel messaggio news: snipped-for-privacy@news.tin.it...

Uhm... no. L'istruzione wait era presente in alcune versioni degli interpreti Basic Microsoft (forse anche in qualche compilatore) e serviva per restare in attesa di una configurazione di bit su un port di input. Era molto comoda per interagire con l'hardware perche' ti evitava di fare un ciclo di lettura port if then goto che nel migliore dei casi ti portava via qualche millisecondo. Wait invece testava il port con un velocissimo ciclo in codice macchina che veniva eseguito in pochi microsecondi. L;unico problema e' che la CPU restava bloccata in quel ciclo fino a quando non si verificava la condizione prestabilita. Se questa condizione non si verificava o se per caso sbagliavi indirizzo del port, non c'era modo di uscire dal loop. L'unica soluzione era resettare o spegnere il computer! Io la usavo parecchio per colloquiare con strumenti di laboratorio che avevano delle particolari interfacce ed era normale durante lo sviluppo di programmi che si dovesse resettare tutto ad ogni test perche' il programma restava bloccato dentro a qualche wait. Per fortuna allora il boot era molto piu' veloce di oggi!

Ciao Valeria Ora ricordo, e forse l'ho usata per comandare strumenti con interfaccia HPIB (ora IEC488). Network e spectrum Analyzer HP e altri.

L'inconveniente e' tipico dei SW che toccano il PC nell'intimo, tipo i programmi in assembler. Il reset era velocissimo, ..ma il programma andava riesumato da ..cassetta sul Tek 4051 !!!!

Ciao Giorgio

P.S. Se e' lecita la domanda :che mestiere fai ???