Goto page Previous 1, 2
Zbych
Guest
Fri Oct 09, 2009 7:07 am
Adam Dybkowski pisze:
Quote:
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.
Quote:
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.
Quote:
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.
Adam Dybkowski
Guest
Sat Oct 10, 2009 12:40 am
Zbych pisze:
Quote:
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.
Zbych
Guest
Sat Oct 10, 2009 6:41 am
Adam Dybkowski pisze:
Quote:
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).
Adam Dybkowski
Guest
Sat Oct 10, 2009 1:38 pm
Zbych pisze:
Quote:
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.
Zbych
Guest
Sat Oct 10, 2009 7:54 pm
Adam Dybkowski pisze:
Quote:
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.
Quote:
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ć.
Adam Dybkowski
Guest
Sun Oct 11, 2009 10:11 pm
Zbych pisze:
Quote:
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.
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.
Quote:
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ę.
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.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Zbych
Guest
Mon Oct 12, 2009 7:14 am
Adam Dybkowski pisze:
Quote:
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.
Spójrz na nazwę grupy, a potem przypomnij sobie w jakim kontekście na
grupie podają pytania o "konwerter USB->LPT":
http://groups.google.pl/group/pl.misc.elektronika/browse_thread/thread/d8bf91cfd9d648e/e1f41b238368bf0b?hl=pl&q=konwerter+usb+lpt+group:pl.misc.elektronika
Quote:
A tu mamy świetne rozwiązanie typu sprzętowy
[de]serializator FT2232 / FT4232H.
Który się do emulacji LPT nie nadaje, ale co szkodzi o nim wspomnieć.
Quote:
Zgadza się. Obawiam się jednak, że tak rozwiązany "emulator" będzie
bardzo wolno pracował,
No i znowu powinienem cię odesłać kilka postów wcześniej.
Goto page Previous 1, 2