Zbych pisze:

>> nie wystarczy, trzeba zrobić na 2.0. Jedynym problemem (zakładając
>> działający hardware) to napisanie takiego drivera, który miałby
>> odpowiednio duży bufor, by "machanie nóżką" zamienił na pakiety i na
>> odwrót zachowując timing po stronie portu równoległego.
>
> A jak chcesz zapakować w pakiety i dostarczyć programowi stan linii
> wejściowych? Program czyta stan linii i twój driver musi wstrzymać jego
> działanie, aż przyjdzie odpowiedź po USB. Czyli ~125us. Jakbyś chciał w
> ten sposób emulować LPT dla programatora JTAG, albo SPI to uzyskasz
> oszałamiającą prędkość rzędu 4kb/s.

Nie, to trzeba zrobić całkiem odwrotnie. Powiadamiać komputer przez USB
o każdej zmianie stanu linii wejściowej - a w zainteresowanym stanem
linii programie odczyt zostanie przeprowadzony błyskawicznie (wydanie
stanu linii z pamięci, odebranego wcześniej przez USB). Myślę, że
FT4232H dałoby się do tego sensownie zatrudnić.

Cały problem jednak rozbija się o napisanie własnego sterownika takiego
"wirtualnego" portu LPT, udającego jak najdokładniej zachowanie
tradycyjnego sprzętowego portu równoległego, a przy tym za pomocą innego
mechanizmu współpracującego ze zdalną częścią sprzętową. I czy to będzie
USB, czy może komunikacja na 100m przez Ethernet (plus doczepiona na
końcu kabelka płytka Ethernut) - to już nie ma znaczenia i da się
oddzielić od sterownika. Ale jako że sterowniki 64-bitowe dla Windows
Vista i Windows 7 wymagają podpisania (certyfikat kosztuje AFAIR coś
koło $300) - to rozwiązanie "domowo-rzemieślnicze" jest pogrzebane. A
nie oszukujmy się, że każdemu obecnie wystarczy 3GB RAMu i śmiga z
chęcią na systemie 32-bitowym...

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.