Poszukiwana profesjonalna przej?ciówka USB - LPT

Typowe przejściówki USB-LPT działają raczej tylko z drukarkami. Temat wielokrotnie wałkowany na grupie, raczej polecane były porty LPT pod PCMCIA.

Pozdrawiam Konop

Lisciasty schrieb:

Na ogół przejściówki są ok, tylko programatory ich nie lubią. Trzymają się twardo przerwania na 7 lub 5 i adresów na 0x3BC, 0x378, 0x278. A czy międzymordzie za 20zł będzie działać, to kwestia wypróbowania.

Waldek

Opisz jaki to sprzęt.

Żadne może nie pasować jesli programista aplikacji był debilem. Więc opisz co to.

Waldemar Krzok pisze:

Przejściówki USB-LPT nie są OK - i nie da się tego zmienić żadnymi zaklęciami. Chyba że zamierzasz podłączyć tylko zwykłą drukarkę ale nie o tym mowa.

W moim ISP Programmerze bez problemu obsługuję m.in. porty LPT na kartach PCI, często o dziwnych adresach (0xE800). Ale nie widziałem jeszcze żadnego konwertera USB-LPT, który byłby widoczny przez Windows podobnie jak zwykły port LPT (w tym miał zestaw rejestrów I/O widocznych pod jakimkolwiek adresem, odwzorowujących zachowanie starego dobrego portu LPT i pozwalającego sterować niezależnie stanami pinów wyjściowych portu).

Dla porównania, dobrze działają karty LPT PCMCIA. Karty Express Card najczęściej nie działają jak trzeba, bo w środku siedzi "zaszyty" konwerter USB-LPT.

Lisciasty pisze:

Nie istnieje.

Szukaj karty LPT na PCMCIA (nie Express Card!).

Adam Dybkowski pisze:

Swoja droga, czemu jeszcze nikt nie wpadl na 'profesjonalne' przejsciowki pod tytulem:

A moze wpadl? Widzial ktos cos takiego?

Butek pisze:

Najprostsze rozwiązanie to układ FT2232: konwerter USB na "prawie wszystko". Umie po drugiej stronie zrobić 2 porty RS232, garść dowolnie sterowanych pinów I/O lub [de]serializować sprzętowo synchroniczne interfejsy szeregowe takie jak SPI czy JTAG. Na tym scalaku jest zrobionych wiele gotowych programatorów/emulatorów JTAG (np. do debugowania procesorów ARM).

Kwestia tylko obsłużenia we własnym sofcie takiego "kabelka" bazującego na FT2232. Robi się to całkiem inaczej, niż w przypadku dostępów do LPT (trzeba użyć DLLa ale za to są gotowe funkcje i nie trzeba kombinować z dostępami do chronionej w Windows przestrzeni I/O). Najbardziej uniwersalne programatory potrafiące współpracować z kabelkami o różnistej konstrukcji (a nie tylko będących permutacją STK200/300 czy Altera Byteblaster) obsługują takie wynalazki.

Ale aby dowolny stary soft do tego namówić - musiałbyś napisać własny sterownik udający wirtualny port LPT. Powodzenia.

Jaką przejściówkę RS485 (sprzęt)/USB (komputer, chętnie z Linuksem) z optoizolacją polecisz ? THX

-----

Butek pisze:

Był nawet taki projekt w EP. Sterownik na PC przechwytywał odwołania do LPT i przesyłał je przez USB do sterownika. Kumpel to sprawdzał z jakimś programatorem i słabo to działało (czytaj nie działało). Podstawowy problem to sposób działania USB - transakcje dla trybu Hi-Speed (480Mb) są wykonywane co 125us, więc nie uda się odwzorować machania pinem LPT z częstotliwością np. 100kHz tak jak to robią popularne programatory do np. AVR.

Butek pisze:

a to:

Adam Dybkowski schrieb:

W sumie jest to kwestia specyfikacji. Przejściówki są o tyle dobre, że spełniają swoje zadanie. A to, że ustrojstwa nie używają LPT w ramach specyfikacji tworzy problemy. Nie musisz zaczynać flejma. Problem widzę i znam z autopsji, ale tylko tak to sobie powiedziałem ;-)

Tylko teraz zaczyna być ciężko ze zdobyciem laptopa z PCMCIA. Dużo nowych ma wyłącznie ExpressCard.

W sumie wygląda na to, że jest zapotrzebowanie na prawdziwe symulatory lpt podłączone przez USB. Dość ciekawy projekt. W każdym razie USB 1.1 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. Myślę, że sądzę, że jakiś microcontroller z USB 2.0 na burcie by to zmógł. Ktoś zainteresowany?

Waldek

Waldemar Krzok pisze:

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.

Zbych pisze:

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 pisze:

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.

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

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

Zbych pisze:

Jeżeli nie wymagasz jakiegokolwiek protokołu szeregowego, a tylko powyższe JTAG i SPI - sprzętowo [de]serializację zrobi pięknie FT2232. I to z zegarem do kilku MHz. A jeżeli chcesz jeszcze szybciej - to FT4232H.

BTW: Pięknie się dopiero robi przy USB 3.0 (Superspeed). Sprzętowy fullduplex i małe opóźnienia przywracają sens życiu. Urządzeń oczywiście. :)

Adam Dybkowski pisze:

Chyba straciłeś wątek, albo ja nie rozumiem twojej odpowiedzi. Może napisz jak serializacja w FTDI pomoże w emulacji portu LPT, którym steruje program do programowania jakichś uC (dla ustalenia uwagi weźmy twój programator do AVRów).

Zbych pisze:

1. Bez możliwości zmiany w programie pecetowym pies jest pogrzebany i tyle. Dotyczy to np. specjalnego oprogramowania i kabelków na LPT do programowania sterowników PLC, obsługi równoległych programatorów scalaków podłączanych przez LPT itd.
2. Jeżeli panujemy nad softem (np. avrdude) - wystarczy przenieść fragmenty "podstawowe" (np. wysyłanie bloku danych protokołem SPI albo JTAG) na stronę urządzenia i wykorzystać możliwości układu FT2232.
3. W tym celu oczywiście zmieniamy częściowo kabel programujący (przykładowo jeżeli był STK200/300 to do bufora '244 lub '245 podczepionego oryginalnie do portu LPT dołączamy układ FT2232 a całość do komputera przez USB). Oczywiście można zrobić to jako oddzielną "przyczłapkę" do sondy STK200/STK300/Wiggler itp. ale trzeba koniecznie znać pinout czyli z jakich sygnałów LPT oryginalnie korzysta.
4. W sofcie programatora usuwamy podstawowe operacje (wyślij bit, odczytaj bit) i zamieniamy funkcje wyższego poziomu (wyślij blok bajtów, odczytaj blok bajtów) na odpowiednie wywołania DLL'a dostarczanego przez FTDI. Są tam też funkcje do kręcenia parametrami transmisji, prędkością, wyborem aktywnego zbocza sygnału zegara itp.
5. W praktyce robi się to najczęściej tak (na przykładzie openocd - programu do gadania z różnymi procesorami przez JTAG, będącym pomostem między kabelkiem programującym a debuggerem gdb), że dodaje do programu obsługę nowego typu kabla (FT2232 z określonym pinoutem), równolegle pozostawiając możliwość korzystania z tradycyjnych kabelków na LPT.

Adam Dybkowski pisze:

No to teraz spój parę postów wcześniej co napisałem na temat sensowności robienia emulatora LPT.

A ty znowu mieszasz dwa systemy walutowe. Wątek tyczy emulatora LPT. Tutaj nic więcej jak przechwytywanie instrukcji IN i OUT nie wchodzi w grę. A to, że jak masz dostęp do kodu źródłowego to możesz go przeorganizować, to już "oczywista oczywistość" i nie ma sensu się nad tym rozwodzić.

Zbych pisze:

Wątek oryginalnie dotyczył emulatora LPT, ale - jak widać w pierwszym z powyższych cytatów - ktoś (nie chce mi się już szukać w historii wątku kto dokładnie) ograniczył zagadnienie tylko do interfejsów szeregowych SPI i JTAG. A tu mamy świetne rozwiązanie typu sprzętowy [de]serializator FT2232 / FT4232H. I do protokołów dobrze ustandaryzowanych (jak np. programowanie/debugowanie procesorów ARM) zaczęły się pojawiać kabelki programujące oparte o ten układ, z odpowiednim wsparciem softwarowym oczywiście, które potrafią zastąpić stary dobry programator na LPT typu Wiggler.

Zgadza się. Obawiam się jednak, że tak rozwiązany "emulator" będzie bardzo wolno pracował, właśnie z powodu niedopasowania protokołu współpracy przez LPT (zmiana pojedynczych bitów wyjściowych i oczekiwanie na stan bitu wejściowego) do możliwości łącza USB (szybki transfer całej paczki danych ale długie odstępy pomiędzy transferami). Zapewne nawet kilka razy wolniej niż stary oryginalny bufor na LPT.