Butek pisze:

> Swoja droga, czemu jeszcze nikt nie wpadl na 'profesjonalne'
> przejsciowki pod tytulem:
>
> [DB-25]<->uC<->USB<->soft emulujacy LPT na poziomie jadra dogadujacy sie
> z uC
>
> A moze wpadl? Widzial ktos cos takiego?

a to:
http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund
%20um%20den%20PC/USB2LPT/index.html.en
?

--
Pozdr.
michał

do góry

On 6 Paź, 18:30, Sebastian Biały <h...@p...onet.pl> wrote:
> Opisz jaki to sprzęt.

Pospieszyłem się i nie sprawdziłem, okazało się że producent
się wykazał i zrobili niedawno swój interface.

http://tinyurl.com/y9n492w

A sprzęt to omicron cmc156

Na razie póki co spróbuję z pcmcia może ruszy...

Pzdr.
L.

do góry

Adam Dybkowski schrieb:
> Waldemar Krzok pisze:
>
>>> Poszukuję porządnej przejściówki usb-lpt, żeby podłączyć sprzęt
>>> serwisowy
>>> do laptopa. Przypuszczam że taki interface za 20 zł będzie niezbyt
>>> działał,
>>> czytałem że są problemy z programatorami np.
>>> Czy ktoś ma jakiś namiar na takie urządzonko o nieco lepszych
>>> parametrach?
>> 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.
>
> 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 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 ;-)

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

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

do góry

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

do góry

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.

do góry

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.

do góry

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

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
http://dybkowski.net/

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

do góry

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

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

do góry

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

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
http://dybkowski.net/

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

do góry

Adam Dybkowski pisze:
> Zbych 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.
>>> 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.
>> 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).
>
> 1. Bez możliwości zmiany w programie pecetowym pies jest pogrzebany i
> tyle.

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

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

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

do góry