Prędkość odczytu na LPT

Shrajbnij prościutki program pod dosa z użyciem funkcji outportb/inportb i odczytem zegara systemowego i zobacz czy wydoli 23ms. Pod windowsem trudno powiedzieć. Żeby nie pisać sterownika to znajdź w google gotowca typu WinIo.

Pozdrawiam Paweł

Witam! Czy podając impulsy prostokątne z prędkością 23ms (zwieranie do masy) na port LPT będzie on w stanie zliczyć mi je wszystkie? Czy może to już jest poza technicznymi możliwościami portu?

W jakim systemie operacyjnym chcesz odczytywac ten lpt? Bo Windows wcale ci nie gwarantuje, ze twoj program bedzie sie wykonywal w jakichkolwiek przewidywalnych odstepach czasowych, musialbys napisac wlasny driver niskiego poziomu.

No "niestety" jest to Windows. Podglądając programem monitorującym port LPT widzę, że dość szybko reaguje na te impulsy (stan 1 zmienia się na 0 bardzo szybko). Tylko czy na wszystkie ?? to właśnie chciałem ustalić czy czasem nie jest to poza granicami technicznymi portu LPT.

Może jest jakiś gotowy programik co zlicza impulsy na porcie LPT to bym przetestował czy łapie mi wszystkie? Mam generowane 3777 imp. w 87s trzeba je zliczyć na LPT.

Port nie stanowi tu ograniczenia, to nie ten rząd częstotliwości. Pod jaki system operacyjny chcesz napisać program, który to będzie robił?

TP.

Technicznie na lpt 23ms to nie jest problem. Problemem jest OS, ktory moze wydziedziczyc twoj program na czas znacznie dluzszy i co gorsze zupelnie nieprzewidywalny, w efekcie zgubisz te impulsy. Ratunkiem jest napisanie wlasnego drivera (sys), bedzie on jednak zajmowal sporo czasu procesora. IMHO najlepiej jest jednak dolaczyc jakies rozwiazanie hardwarowe - maly procek, ktory to bedzie zliczal, a ty tylko przez lpt, rs, usb, czy co tam chcesz bedziesz sciagal wyniki.

Tak jak napisałem wcześniej, ma to być po Windows.

Pod Windows nie da się. Coś napisać się da, ale gwarancji na zliczenie

TP.

Użytkownik "Darek" snipped-for-privacy@piwnica.net napisał w wiadomości news:e27n8q$1v2b$ snipped-for-privacy@node1.news.atman.pl...

Pod DOS na 386 kolejne odczyty portu wypadały prawie dokładnie co 1us (robiłem sobie kiedyś analizator stanów - mogłem obejrzeć 3s 5 przebiegów (port nie był dwukierunkowy) z rozdzielczością 1us). P.G.

Proponuję rozwiązanie z serii dziwnych: użycie portu RS232. Ustawić go na choćby 300 bps 8N1 i wystawianie na linię RX impulsu 0 o długości 3.33 ms. Port odbierze to jako znak ascii(255) i wygeneruje przerwanie. Do tego prosty program obsługujący port szeregowy i liczący odebrane znaki. Wszystkie współczesne komputery mają bufory FIFO na portach RS232 i są w stanie nawet pod Win9x nadążyć z odbiorem nawet znacznie szybszego strumienia.

Witam Skoro do LPT się nie da to może możnaby podpiąć do wejścia RxD portu szeregowego (po ustaleniu odpowiedniej polaryzacji i czasu trwania). Impulsy te byłyby traktowane jako znaki przychodzące na RS232 (bit startu + kilka "0" przy prędkości 300 baud) i pakowane do niskopoziomowych buforów sterownika VxD więc na pewno byś nie stracił ilości impulsów. Pozdrawiam Jacek Poźniak

Użytkownik "Darek" snipped-for-privacy@piwnica.net napisał w wiadomości news:e27on1$1v92$ snipped-for-privacy@node1.news.atman.pl...

Tyle to wiemy JAKI system. Na 98 dało by się... na 2000 chyba też ale proces swojej aplikacji musiał byś ustawić na real-time albo chociaż high... Z liczeniem jeszcze nie pisałęm progamó ale z generowaniem szybko już pisałęm :)

jeśli chcesz mieć 100% pewności, że nie zgubisz, to podłącz do RS-232 jakiegoś jenoukładowca. Niech on zlicza i na żądanie z PCta wyśle stan licznika (nb. 12 bitowego).

A jeśli jednak podłączenie do LPT, to podłącz sygnał do ACK (jeśli dobrze pamiętam), bo sygnał na trj nodze generuje przerwania.

Dosc wolno. Podlacz te impulsy pod strobe albo ack, i daj zapis jakiegos dlugiego bufora na port. Potem sprawdz ile bajtow poszlo.

strobe to zazwyczaj wyjście :-)

Ale pewnie i tak trzeba bedzie uzyc jakiejs prostej logiki (bramka, przerzutnik itp) pomiedzy strobe, ack i tym sygnalem zewnetrznym. Zaleta jest taka ze nie obciazamy CPU bo impulsy wchodza jako przerwania.

Thu, 20 Apr 2006 18:42:08 +0200, na pl.misc.elektronika, Jarek Andrzejewski napisał(a):

Tak najprościej, ale dla praktykującego użytkownika mikrokonrolerów.

Pod Win z tych przerwań i tak nic mi nie przyjdzie jeśli nie umiem napisać ( a nie umiem ) własnych sterowników - z poziomu zwykłej aplikacji przerwania pozostają niedostępne. Jeśli potrzeba jest pilna a koszty mniej znaczące - można zainwestować w jakieś sterowniki uniwersalne ( ew. pakiet do ich szybkiego tworzenia ). To jednak na ogół droga sprawa - na tle cen dość korzystnie wypada :

Tak naprawdę to dawno są pod Win różne sposoby na uniezależnienie transmisji LPT od wielowątkowości, zawieszeń itp. Są tryby EPP i ECP pracy portu korzystające z wewnętrznych buforów, jest możliwość użycia DMA itd. Tyle tylko, że opisy działających praktycznych rozwiązań są dość rzadkie - i nadal dominują w hobbystycznej elektronice starożytne metody jak bezpośrednia obsługa rejestrów. Tutaj np. można sobie wyobrazić dobudowanie malutkiej wejściowej przystawki, która przy każdym impulsie wygeneruje sekwencję odczytu ECP ( i wtedy odczytując port masz znaleźć odpowiednią liczbę bajtów - ich zawartość nie ma znaczenia ). Natomiast nigdzie do końca nie doczytałem, czy podstawowy driver systemowy lpt będzie umiał w takim przypadku obsłużyć odbiór ( z użyciem zwykłych CreateFile, ReadFile itd. ). Ktoś próbował może ? Jeśli nie zadziała to wraca temat sterowników.

BTW - zabawne : dużo łatwiej zrobiło się na USB . Bierzesz elementy: Ft245R (18PLN netto ), gniazdko, parę kondensatorków i jakiś zwykły przerzutnik, który przy zboczu impulsu zrobi potrzebny przebieg na wejściu WR. Ft245 ma własny spory bufor więc jest w znacznym stopniu uniezależniony od systemu - a sterowniki i proste w użyciu API dostępne od ręki, bez żadnych dociekań, poszukiwań i wydatków.

Spinacz biurowy, T.M.F. snipped-for-privacy@nospam-mp.pl!

Chyba że powie się schedulerowi, żeby tego nie robił...