Adam Dybkowski pisze:
> 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ć.

To teraz wyjaśnij jeszcze jak sobie wyobrażasz pracę programatora JTAG,
lub SPI, który z częstotliwością ~100kHz macha pinem zegara i w jego
takt wysyła i jednocześnie odbiera dane. Zakładając nawet, że oba zbocza
zegara wyślesz w jednej paczce, to i tak musisz poczekać na informację
czy stan linii wejściowych się zmienił, czy pozostał bez zmian. Bez
opóźnień się nie obejdzie.

> 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ą.

Link do takiego sterownika już padł w tym wątku. EP zrobiła z tego kit.

> 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.

W teorii wygląda pięknie. A w praktyce opóźnienia zabijają sens całej
zabawy.