prędkość machania LPT

Tak, dokladnie o tym myslę.

A da się zrobić SPI 9 bit z ustawionym na stale ostatnim bitem na ileś ? Bo jakiś $%^#*@ zrobił mi wlaśnie coś takiego...

Reply to
Sebastian Biały
Loading thread data ...

Wszystjo wskazuje na to że to koniec przydatności LPT :/ Chyba jednak poświęcę chwilkę i zrobie coś na USB.

Reply to
Sebastian Biały

to, że program w User Space nie widzi hardware tylko HAL (hardware abstraction layer). Wchodzisz na wirtualnym porcie, a wychodzisz na hardware. Po drodze jest driver HAL.

dokładnie tak. Tylko to outb nie będzie na wirtualnym porcie, jak w programach w User Space, tylko idzie bezpośrednio na hardware. Każde twoje outb prowadzi do zmiany kontekstu w obie strony, a to chwilkę trwa.

Waldek

Reply to
Waldemar Krzok

Zalezy co chcesz osiagnac .. ale tak - koniec przydatnosci LPT, i koniec LPT w ogole. Jesli nie jest to cos doraznego - czas na USB, a i w doraznych latwiej opanowac jakiegos procka z USB i sie nie meczyc z windowsami :-).

J.

Reply to
J.F.

Jesteś w stanie ocenić ten narzut? czy HAL w tym wypadku nie robi po prostu outb->real_outb ? Bo tutaj traci się za dużo mocy procesora i prędkośc tej operacji prawie nie zalezy od predkości CPU.

Reply to
Sebastian Biały

Ale ja pod innym kątem: zamiast męczyć się z debugowaniem w uC kodu wole napisać go i przetestować na PC. Czesto wsad po wrzuceniu w uC działa mi od razu poprawnie, a przyjemnośc debugowania na PC jest znaczna. Dlatego czasem coś podpinam pod LPT "na szybko" zeby sprawdzić komunikacje z jakims scalakiem i znaleźć buga. Po to mi LPT. Ale własnie mam w tej chwili problem, bo urzadzenie wymaga szybkiej komunikacji a LPT nie wyrabia się dostatecznie. Więc zaczynam się rozglądać za FTDI jakimś co by mi pasowal do potrzeb.

Reply to
Sebastian Biały

Mi wygenerowal 290kHz :D

Wygląda na to że:

a) mam badziewny hardware b) hal-e windowsa i linuxa są identyczne :) c) czas kupić coś na USB

Reply to
Sebastian Biały

w zależności od implementacji jaja może być dużo. Kompletne przełączenie kontekstu z user na kernel i na oborot trochę może potrwać, rzędu kilkadziesiąt ns do pojedynczych mikro-s. Możesz poszukać jakiegoś rt-kernela, ale tu chyba nie będzie szybciej, ale za to z definiowalnym opóźnieniem. Wszystkie SO multitasking lepiej sobie radzą z pakietami danych: sterownik operuje bezpośrednio na nóżkach, a dane dostaje (i ew. wysyła) w pakietach. Wtedy ograniczasz zmiany kontekstu do minimum. Spróbuj napisać mały sterowniczek z twoim programem i zobacz ile hardware naprawdę może. Albo ściągnij sobie free-dos z sieci i przetestuj na real-mode w DOSie. Aha, USB też pracuje najlepiej przetwarzając dane pakietami, więc dużo chyba nie zyskasz, oprócz tego, że USB ma teraz każda husteczka do nosa, a LPT jest dinozaurem ;-).

Waldek

Reply to
Waldemar Krzok

Jak znajdę gdzieś TurboC w wygodnej wersji to z ciekawości sprawdze.

Ja mam wlasnie pakietowo - najczęsciej to dane SPI. Jesli tylko scalak bedzie w stanie mi przygarnąć cała ramkę i wypluć ją na SPI to luksus.

Reply to
Sebastian Biały

no to spróbuj z driverem Linuxowym. Tu ło masz artykuł:

formatting link
Na stronie 11 jest listing drivera LPT. Musisz go przerobić tak, by brał twój cały pakiet i wypluwał za jednym zamachem. A najpierw zrobić tylko driver testowy, który przy init_module startuje mruganie a przy exit_module zwalnia port.

Waldek

Reply to
Waldemar Krzok

Mysle ze ograniczenie jest sprzetowe i nawet driver nie pomoze.

Ewentulanie korzysta on z mozliwosci ECP/DMA i czysto programowo nie zadziala.

No ale z ciekawosci sprobowac mozna.

J.

Reply to
J.F.

Ciekawostka: caly zakres niskiego IO powoduje jakies poważne opóźnienia. Gdzie bym nie robił outb tam zawsze jest poczekalnia. Czas czekania jest różny, akurat LPT ma najwiekszy, ale nie udało mi się wyjśc poza 1 mln outb/sek testujac parenaście portów (zajetych i wolnych).

Hmm, czy ISA emuluje sie obecnie na I2C :P ?

Reply to
Sebastian Biały

Nie, po prostu ISA tak spowalniana byla. Byc moze nadal chipset spowalnia na wszelki wypadek, mimo ze juz nawet ISA nie obsluguje :-)

Za to ciekawe co jest z reszta - brak spowalniania, czy moze system operacyjny odmawia dostepu, co mu szybko idzie :-)

J.

Reply to
J.F.

Czekaj, o ile minie pamięć nie myli w ISA mozna było wciskać bajty z prędkością 8MHz. Nijak to nie pasuje, tutaj mamy jakies 20x wolniej.

Jak znajde jakis mały hdd to postaram się zapuscić freedosa + tc i pobawić się.

Prawdopodobnie dlatego też, że output z LPT widziany na oscyloskopie przy tych 290kHz przypomna morze w czasie sztormu, oscylacje na zboczach mają 1.5V (!). Pewno przy 1MHz miałbym sinusa 5MHz :). Nie chciało im się tego prostować, to zrobili HALT i już ... ;)

Reply to
Sebastian Biały

8MHz to bylo w najszybszych trybach, 8-bitowy out trwal wiele cykli. Blizej 1us.

dyskietke jeszcze masz ? :-)

J.

Reply to
J.F.

ale to już jakieś hajspid ISA. Normalnie miałeś 1/3 z 4.77MHz, czyli

1.58MHz.

Nie wiem jaki czip tam u ciebie biega i czy błąd nie leży po stronie pomiaru. Drivery serii 74LS244 i podobne biegają całkiem dobrze i przy

10MHz.

Waldek

Reply to
Waldemar Krzok

Hmmmm pamiec nie ta, ale może.

A czy DOS + TC wchodził na 1.44 ?

Reply to
Sebastian Biały

O ile tam sa _te_ drivery ;) Przeciez to wszystko zalane plastikiem.

Reply to
Sebastian Biały

Co najmniej 1.5 us - po 0.5 us przed i po !STROBE a samo !STROBE też minimum 0.5 us

;)

Reply to
RoMan Mandziejewicz

Mowie o pojedynczym rozkazie out, nie calym protokole Centronicsa.

J.

Reply to
J.F.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.