Szybki odbior danych z LPT

0

Heya wszystkim!!!
Udalo mi sie w koncu zrobic szybki timer :) z uzyciem QueryPerformanceCounter i wielowatkowosci.Wyglada na to,ze udaje mi sie uzyskac czas nawet 1 mikrosekundy.Z taka czestotliwoscia chcialbym odczytywac dane z portu LPT pod <font color="blue">XP</span>.CZy jest to realne?Jesli nie to ile najwiecej mozna wyciagnac z w/w portu??
Pozdrawiam/smalski

0

skoro masz taki timer- to najlepsza droga sprawdzenia - podłacz coś pod LPT i sprawdź...

0

jesli zrobiles timera z rozdzielczascia 1us to jestes zajebisty ;-)
Ps. tylko nie mow ze na kompie z procesorem 300Mhz :-P

A jesli chodzi tobie o max. predkosc sprawdzania portu to ciezko okreslic, podlacz sobie mikroprocka, lub drugiego kompa i wysylaj dane z coraz wieksza predkoscia (najlepiej przez swojego timera :-D )

0

Hej!

Potrzebuję funkcji która obliczłaby czas 0,1 milisekundy. Przeczytałem że zrobiłeś taki właśnie Timerek, mam prośbę jeśli mógłbyś udziel mi informacji jak można taką funkcję stworzyć

Pozdrawiam i z góry dziękuję.

Piszę fajną gierkę hakerską :)

0

Ja również potrzebuję szybkiego Timerka...
Mogę prosić o jakieś wskazówki (wiadomo - najlepiej kodzik ;) )...
Ew. link do komponentów, które zapewne powstały...

0

Szybki timer opisany jest w wersji asemblerowej tu:
Jak zmierzyć czas wykonywania operacji
i w wersji WinAPI tu:
Jak zmierzyć czas wykonywania operacji (inny sposób)

Ten timer może służyć do pomiaru czasu między dwoma punktami w kodzie, ale nie nadaje się do wywoływania procedury (np. przeglądania LPT) z zadaną częstością.

Są dwa sposoby szybkiego wywoływania procedury z zadaną częstością, i oba oferują najmniejszy możliwy odstęp ok. 1 ms. Jedna to MMTimer, druga to Thread-induced waitable timer (TWI timer).

MMTimer jest oferowany przez system, działa więc raczej niezawodnie, nie obciąża maszyny, i co ważne procedura podpięta pod timer jest wykonywana w niesłychanie wysokim priorytecie, więc wywłaszcza inne wątki.

TWI timer jest opisany tu: http://espresso.cs.up.ac.za/publications/janno_grobbler_etal_saicsit2005.pdf
Polega na sprytnym ustawieniu dwóch wzajemnie się blokujących wątków. Zdaniem autorów (jak również wg moich testów opisanych tu: http://groups.google.com/group/comp.os.ms-windows.programmer.win32/browse_thread/thread/c90a43a119418441 ) TWI oferuje znacznie większą precyzję wywoływania procedury co 1 ms niż MMTimer. Wadą jest większe obciążenie procesora. Ponadto procedura jest wywoływana w takim priorytecie, w jaki są wykonywane wątki. Nawet jeśli da się wysoki priorytet, to będzie niższy niż dla MMTimer. Trudno też przewidzieć co się stanie, jeśli w systemie spotkają się dwa programy wykorzystujące TWI timer - przypuszczam, że będzie kłopot. Nie znam też testów TWI w warunkach bojowych: moje testy były robione na programie który tylko testował, nie robił nic innego.

Natomiast MMTimer wbudowałem do sporej aplikacji w której służy on do przeglądania LPT co 1 ms. LPT jest w każdym wywołaniu timera przeglądany pięciokrotnie, a ewentualne zmiany obserwowanych linii portu są zapisywane z dokładnym czasem z QueryPerformanceTimer.

Dokładniej, zapisywany jest czas aktualnego wywołania procedury (czyli pierwszego wywołania po danej zmianie na porcie) oraz czas poprzedniego wywołania (czyli ostatniego wywołania przed zmianą na porcie). Wielkość różnicy tych czasów odpowiada nieokreśloności wyznaczenia czasu zmiany na porcie.
Aplikacja oprócz przeglądania portu miksuje dźwięki, odgrywa je, updatuje kilka wykresów, generalnie się nie leni.
Na przywoitym, ale nie szaleńczo wypasionym kompie pod odchudzonym o niepotrzebne usługi i wodotryski graficzne XP uzyskałem następujące wyniki.

W mierzonym okresie 22144 razy na pewnej linii portu stan zmienił się z 0 na 1, co było zapisywane.
22.2% razy nieokreśloność wyniosła mniej niż 52 us. To są najpewniej wyniki uzyskane w trakcie pięciokrotnego przejrzenia portu w czasie jednego wywołania procedury timera.
33% razy nieokreśloność wynosiła mniej niż 0.7 ms
Większość nieokreśloności była między 0.7 a 0.8 ms: poniżej 0.8 ms było ponad 87% z nich.
96% nieokreśloności było poniżej 1.38 ms.
Było jeszcze widoczne zgrupowanie nieokreśloności około 1.75 ms - 99.5% było poniżej 1.78 ms.
Najwyższa zanotowana nieokreśloność wyniosła 2.239 ms.

0

Czas podajemy w mikrosekundach.

procedure DELAY(czas:integer);
var
zm1,zm2 : int64;
cykle : int64;
begin
cykle:=round(czas/1000000*(frequency));
QueryPerformanceCounter(zm1);
repeat
QueryPerformanceCounter(zm2);
until zm2-zm1 > cykle;
end;

Tylko,ze zuzycie procesora jest na maxa... :-(

1 użytkowników online, w tym zalogowanych: 0, gości: 1