Odczyt danych z portu i watek

Forum poświęcone programowaniu w Delphi

Odczyt danych z portu i watek

Postprzez jh_no-email » 4 maja 2012, o 21:53

- W wątku głównym klasa odbiera w callbacku (procedura drivera -
stdcall) dane.

- Podczas startu odbierania klasa uruchamia wątek, w którym jest kolejka
FIFO (lista wskaźników), oraz obiekt TEvent.

- W Execute wątku (pętla while not Terminated) pobieram (FIFO.Pop)
pierwszy element z list i resetuje obiekt TEvent.

- Jeśli pobrany element nie jest nil to wołam metodę, która w
Synchronize wywołuje zdarzenie (dla przykładu) OnData.

- Jeśli w Execute pobrany element to nil, to znaczy, że lista jest
pusta, wątek więc czeka WaitForSingleObject(50). To 50 ms to po to, żeby
można było go łatwo zamknąć, jak było nieskończenie długo, to WaitFor
dla tego wątku też czekało nieskończenie długo ;)

- W metodzie wątku, w której dodaje nowe elementy do kolejki
(FIFO.Push), po dodaniu ustawiam TEvent (Set).

- Wątek ma FreeOnTerminate := True. Z wątku głównego zatrzymuję go
poprzez Terminate, a po WaitFor robię mu Free.

1.
Czy taka metoda zapewni mi możliwie najkrótszy odczyt danych w callback
(i zapis do bufora), a jednocześnie w miarę powolny odczyt danych? Sama
kolejka FIFO oparta jest na kodzie grupowicza
(http://www.emadar.com/fpc/lockfree.htm). Dane z jednego portu
przychodzą z maksymalną prędkością ok. 30 Kbps.

2.
Czy zasadne jest to, że dla każdego portu (a może ich być nawet
kilkanaście) mam niezależny wątek z kolejką? Czy lepiej mieć jeden wątek
z kolejką dla wszystkich portów?

3.
Teoretycznie mógłbym przenieść cały odczyt danych (zamiast procedury
callback) do wątku, ale to trochę komplikuje kod i tracę jedną istotną
funkcjonalność. Tylko, czy to nie jest najwłaściwsza metoda?

jh
jh_no-email
 
Posty: 347
Dołączył(a): 14 cze 2012, o 13:18

Re: Odczyt danych z portu i watek

Postprzez egon_4 » 4 maja 2012, o 23:12

Access Violation in module <jo1j49$pon$1@inews.gazeta.pl>at address
"jh". See explanation below:

- W Execute wątku (pętla while not Terminated) pobieram (FIFO.Pop)
pierwszy element z list i resetuje obiekt TEvent.

- Wątek ma FreeOnTerminate := True. Z wątku głównego zatrzymuję
go poprzez Terminate, a po WaitFor robię mu Free.


Czyli wątek while(not Terminated) sobie działa, po czym w wątku
głównym ustawiasz mu flagę Terminated, wątek wychodzi z pętli,
wywoływany jest jego destruktor i wraca do wątku głównego, a w tym
momencie ten nieistniejący już obiekt zwalniasz przez Free? Prosta
droga do AV / UB.

1.
Czy taka metoda zapewni mi możliwie najkrótszy odczyt danych w
callback (i zapis do bufora), a jednocześnie w miarę powolny odczyt
danych? Sama kolejka FIFO oparta jest na kodzie grupowicza
(http://www.emadar.com/fpc/lockfree.htm). Dane z jednego portu
przychodzą z maksymalną prędkością ok. 30 Kbps.


Czyli nieco ponad 3 tysiące bajtów na sekundę. Wywołując za
każdym razem synchronizację (i mając na względzie że portów może
być więcej) możesz się nie wyrobić z obsługą wszystkiego. Może
opracuj sobie jakiś bufor na określoną wielkość danych lub upływ
czasu?
Ewentualnie: wrzucaj dane do kontenera (tablicy / listy / wektora /
etc.) wątku głównego bez synchronizacji (nie potrzebujesz o ile nie
ingerujesz w VCL) i synchronizuj raz na jakiś czas? Wtedy masz
pewność że wątek nie zmienia danych w kontenerze i możesz zrobić
cokolwiek co potrzebujesz w wątku głównym.

2.
Czy zasadne jest to, że dla każdego portu (a może ich być nawet
kilkanaście) mam niezależny wątek z kolejką? Czy lepiej mieć
jeden wątek z kolejką dla wszystkich portów?


To już zależy od Ciebie i charakterystyki aplikacji. Jeśli wiesz,
że max będzie ich np. 15 to zrób jak Ci łatwiej, ale jeśli
możliwe że będzie więcej, to nie jest dobrym pomysłem tworzenie
tylu wątków.
IMHO lepiej jest mieć jeden wątek niż fafnaście obiektów
próbujących się synchronizować z wątkiem GUI, bo może się w
pewnym momencie okazać, że czas potrzebny na obsługę istniejącej
kolejki synchronizowanych wątków nie pozwala im na odbieranie danych
:-)

3.
Teoretycznie mógłbym przenieść cały odczyt danych (zamiast
procedury callback) do wątku, ale to trochę komplikuje kod i tracę
jedną istotną funkcjonalność. Tylko, czy to nie jest
najwłaściwsza metoda?


Czy ja wiem czy komplikuje? W wątku odczytu tworzysz sobie tablicę
np. 10 elementową i po każdym odczycie sprawdzasz dwie rzeczy:
a) ile jest elementów w tablicy
b) ile upłynęło czasu od ostatniej synchronizacji

jeśli z a) wyszło 9 to dodajesz odebrany bajt i wywołujesz
synchronize + reset tablicy + reset licznika czasu
jeśli z b) wyszło np. >100 ms -->synchronize niezależnie od
zapełnienia tablicy + reset tablicy + reset licznika czasu

no bo jak się domyślam tą funkcjonalnością jest "real-time"
wyrzutu na ekran / parsowania danych. Przy odpowiednich wartościach
licznika czasu nawet niezauważalne będzie opóźnienie a ilość
synchronizacji zmniejszysz nawet i 10-krotnie.
_______
| ___|.-----.-----.-----.
| ___|| _ | _ | |
|_______||___ |_____|__|__|
|_____|
egon_4
 
Posty: 2
Dołączył(a): 14 cze 2012, o 13:47

Re: Odczyt danych z portu i watek

Postprzez _address_is » 5 maja 2012, o 12:15

"Egon" <nie.chce@spamu.com>wrote:
Access Violation in module <jo1j49$pon$1@inews.gazeta.pl>at address
"jh". See explanation below:


>- Wątek ma FreeOnTerminate := True. Z wątku głównego zatrzymuję
go poprzez Terminate, a po WaitFor robię mu Free.


Czyli wątek while(not Terminated) sobie działa, po czym w wątku
głównym ustawiasz mu flagę Terminated, wątek wychodzi z pętli,
wywoływany jest jego destruktor i wraca do wątku głównego, a w tym
momencie ten nieistniejący już obiekt zwalniasz przez Free? Prosta
droga do AV / UB.


Oczywiście, mój błąd w opisie, jest FreeOnTerminate := False, inaczej nie
miało by sensu Free...


Czyli nieco ponad 3 tysiące bajtów na sekundę. Wywołując za
każdym razem synchronizację (i mając na względzie że portów może
być więcej) możesz się nie wyrobić z obsługą wszystkiego. Może
opracuj sobie jakiś bufor na określoną wielkość danych lub upływ
czasu?


No właśnie o tym buforze ten wątek.

Ewentualnie: wrzucaj dane do kontenera (tablicy / listy / wektora /
etc.) wątku głównego bez synchronizacji (nie potrzebujesz o ile nie
ingerujesz w VCL) i synchronizuj raz na jakiś czas? Wtedy masz
pewność że wątek nie zmienia danych w kontenerze i możesz zrobić
cokolwiek co potrzebujesz w wątku głównym.


Te dane czytane z portów są często jednocześnie retransmitowane do innych
(wyjściowych), a wcześniej mogą być modyfikowane, inne dane są używane do
sterowania programem, a wszystkie zapisywane. Z wyjątkiem tych ostatnich
timing jest bardzo ważny.

nie jest dobrym pomysłem tworzenie tylu wątków.


IMHO lepiej jest mieć jeden wątek niż fafnaście obiektów
próbujących się synchronizować z wątkiem GUI, bo może się w
pewnym momencie okazać, że czas potrzebny na obsługę istniejącej
kolejki synchronizowanych wątków nie pozwala im na odbieranie danych
:-)


Ok, stąd też moje wątpliwości. Jak powinna więc wyglądać struktura tej
części aplikacji, gdzie chcę możliwie szybko pozbywać się danych z
callbacka, a jednocześnie mieć zapewnione szybkie zrzucanie danych z
bufora, jeśli spływających dany będzie chwilowo dużo?

I jeszcze jedna istotna sprawa. Chcę zaburzyć FIFO :) Uaktywnienie jednej z
funkcji aplikacji skutkuje wysyłaniem danych (tylko 3 bajty) z najwyższym
priorytetem i w ściśle określonych odstępach czasu (taka forma zegara).
Czyli, te dane musiały by wejść na początek kolejki natychmiast po ich
wygenerowaniu, przed pozostałe dane w buforze. Przy czym całe to
wysyłanie/retransmitowanie może odbywać się w wątku pobocznym, nie w
głównym, za to z wyższym priorytetem.

jeśli z b) wyszło np. >100 ms -->synchronize niezależnie od
zapełnienia tablicy + reset tablicy + reset licznika czasu


Takie wartości w ogóle są niedopuszczalne, realnie 20 ms jest już
upierdliwe:)
jh
_address_is
 
Posty: 1
Dołączył(a): 14 cze 2012, o 17:10

Re: Odczyt danych z portu i watek

Postprzez neuron » 5 maja 2012, o 13:07

I jeszcze jedna istotna sprawa. Chcę zaburzyć FIFO :) Uaktywnienie jednej
z
funkcji aplikacji skutkuje wysyłaniem danych (tylko 3 bajty) z najwyższym
priorytetem i w ściśle określonych odstępach czasu (taka forma zegara).
Czyli, te dane musiały by wejść na początek kolejki natychmiast po ich
wygenerowaniu, przed pozostałe dane w buforze. Przy czym całe to
wysyłanie/retransmitowanie może odbywać się w wątku pobocznym, nie w
głównym, za to z wyższym priorytetem.


To nie wkkladaj ich do kolejki.
Niech proces wysle znacznik, potem n elementw kolejki, potem znowu znacznik,
potem znowu n elementow kolejki etc.
Ponadto muszisz zachowac powsciagliwosc w wierze w priorytety poszczegolnych
watkow - jak bys tego nie zorganiaowal to system decyduje ktory watek
dostanie czas i czasmai moze to bys nie po twojej mysli mimo teoretycznie
wiekszego priorytetu.
Nie wiem co to ma byc, pewnie midi ale ja bym zrobil tyle pojedynczych
procesoe ile jest portow i jeden wspolny, wiryualny zbor danych logicznych
( pozbawionych wszytskich informacji z ramki ktora moga uzupelnic procesy
obslugi portow) a na dokladke wrzuci to w usluge (gdybym potrafil ;) ) albo
oddzielny program a komunikowal sie przez tcp/ip
z programem glownym


>jeśli z b) wyszło np. >100 ms -->synchronize niezależnie od
zapełnienia tablicy + reset tablicy + reset licznika czasu


Takie wartości w ogóle są niedopuszczalne, realnie 20 ms jest już
upierdliwe:)




__________ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur wirusów 7113 (20120505) __________

Wiadomoœć została sprawdzona przez program ESET NOD32 Antivirus.

http://www.eset.pl lub http://www.eset.com
neuron
 
Posty: 370
Dołączył(a): 14 cze 2012, o 15:15

Re: Odczyt danych z portu i watek

Postprzez egon_0 » 5 maja 2012, o 13:10

Access Violation in module
<943774212357910675.242937address_is-invalid.invalid@inews.gazeta.pl>
at address "<address_is@invalid.invalid>". See explanation below:

"Egon" <nie.chce@spamu.com>wrote:
Access Violation in module <jo1j49$pon$1@inews.gazeta.pl>at
address "jh". See explanation below:


Ewentualnie: wrzucaj dane do kontenera (tablicy / listy / wektora /
etc.) wątku głównego bez synchronizacji (nie potrzebujesz o ile
nie ingerujesz w VCL) i synchronizuj raz na jakiś czas? Wtedy masz
pewność że wątek nie zmienia danych w kontenerze i możesz
zrobić cokolwiek co potrzebujesz w wątku głównym.


Te dane czytane z portów są często jednocześnie retransmitowane
do innych (wyjściowych), a wcześniej mogą być modyfikowane, inne
dane są używane do sterowania programem, a wszystkie zapisywane. Z
wyjątkiem tych ostatnich timing jest bardzo ważny.


W sumie, żeby odpowiedzieć na pytanie "jak zorganizować program"
trzeba by znać całą jego architekturę i logikę. Bez wiedzy jak
skomplikowane są modyfikacje, czy i od czego są one zależne, czy
operują na pojedyńczych bitach / bajtach czy na łańcuchach, etc.
trudno jest jednoznacznie wskazać. Spróbuj zaimplementować całość
najprościej jak potrafisz, sprawdź czasy wykonywania poszczególnych
etapów i wtedy dopiero myśl (jeśli w ogóle będzie to potrzebne) o
optymalizacji czy zmianie.

>nie jest dobrym pomysłem tworzenie tylu wątków.

IMHO lepiej jest mieć jeden wątek niż fafnaście obiektów
próbujących się synchronizować z wątkiem GUI, bo może się w
pewnym momencie okazać, że czas potrzebny na obsługę
istniejącej kolejki synchronizowanych wątków nie pozwala im na
odbieranie danych :-)


Ok, stąd też moje wątpliwości. Jak powinna więc wyglądać
struktura tej części aplikacji, gdzie chcę możliwie szybko
pozbywać się danych z callbacka, a jednocześnie mieć zapewnione
szybkie zrzucanie danych z bufora, jeśli spływających dany będzie
chwilowo dużo?


Zapewnić wystarczająco duży bufor na kompensację czasu w innych
częściach programu, wrzucenie gdzie się da QueryPerformanceCounter i
próba stresowa. Być może w ogóle niepotrzebnie dywagujemy nad 3
tysiącami bajtów na sekundę, z których obsługa każdego zajmie
tysiąc cykli (czyli 10 MHz ;) ), podczas gdy procesor nawet nie
zauważy takiego obciążenia. Fakt, że synchronizacja potrafi zabrać
sporo cykli skłaniałoby mnie do ograniczenia ich ilości do minimum.

I jeszcze jedna istotna sprawa. Chcę zaburzyć FIFO :) Uaktywnienie
jednej z funkcji aplikacji skutkuje wysyłaniem danych (tylko 3
bajty) z najwyższym priorytetem i w ściśle określonych odstępach
czasu (taka forma zegara). Czyli, te dane musiały by wejść na
początek kolejki natychmiast po ich wygenerowaniu, przed pozostałe
dane w buforze. Przy czym całe to wysyłanie/retransmitowanie może
odbywać się w wątku pobocznym, nie w głównym, za to z wyższym
priorytetem.


O ile urządzenie odbiorcze nie ma sprzętowych przerwań to raczej
trudno będzie zagwarantować, że to co wysyłasz (3 bajty) w
określonych odstępach czasu i w określonym momencie będzie odebrane
w takich samych odstępach czasu. Ale co do samego konceptu: być może
zamiast ingerować w kolejkę, do której insert na przód kosztuje
więcej niż sam zapis, lepiej jest stworzyć osobną zmienną na te
trzy bajty i za pomocą flagi dawać znać wątkowi, że ma wysłać te
trzy bajty? Patrzę na to w ten sposób:
- jest sobie kolejka np. 100 bajtów do wysłania
- robimy insert do kolejki:
- całą kolejkę trzeba przepisać z przesunięciem o 3 bajty
- można kontynuować

albo zamiast powyższego:
- jest sobie kolejka
- do zmiennej już zaalokowanej wrzucamy 3 bajty do wysłania i
ustawiamy flagę priorytetu
- wątek wysyłający nie dotyka kolejki, tj. nie traci czasu na jej
przepisywanie, tylko wysyła 3 bajty i zdejmuje flagę
- wątek wraca do wysyłania z kolejki z punktu w którym skończył

>jeśli z b) wyszło np. >100 ms -->synchronize niezależnie od
zapełnienia tablicy + reset tablicy + reset licznika czasu


Takie wartości w ogóle są niedopuszczalne, realnie 20 ms jest już
upierdliwe:)


jesteś w stanie zauważyć 2 setne sekundy? Oko ludzkie reaguje na
około 35-40 ms (20-30 klatek na sekundę) i uznaje to za płynną
animację, częstszych zdarzeń (jak 20 ms) po prostu nie zauważa :D
Ale ok, może Twój program potrzebuje ;)
[ ___ ]
[ (_ _ ] Pozdrawiam!
[ /__(/()/) ]
[ _/ ] http://www.radsoft.pl/
egon_0
 
Posty: 7
Dołączył(a): 14 cze 2012, o 13:47

Re: Odczyt danych z portu i watek

Postprzez neuron » 5 maja 2012, o 13:34

>Takie wartości w ogóle są niedopuszczalne, realnie 20 ms jest już
upierdliwe:)


jesteś w stanie zauważyć 2 setne sekundy? Oko ludzkie reaguje na
około 35-40 ms (20-30 klatek na sekundę) i uznaje to za płynną
animację, częstszych zdarzeń (jak 20 ms) po prostu nie zauważa :D
Ale ok, może Twój program potrzebuje ;)

--

Niektore protokoly, np modbus rtu uzywaja ograniczen czasowych jako
dodatkowy, poza suma kontrolna czynnik weryfikacji transmisji - jesli
jakikolwiek bajt ramki zostanie opozniony to cala ramka jest ignorowana.
Generalnie problemem nie jest czas realizacji pozczegolnych operacji -
problemem jest to ze jadro wywlaszcza watki na czas ktorego nie da sie
okreslic - moze byc tak
ze wysylamy ramki co 1ms ale co jakis czas nastepuje przerwa kilkuset
milisekund bo system uznal ze twoj watek jest mniej wazny od np watkow
systemow plikowych i go "zamrozi"

Wiele walczylem z timerami ktore daly by mi synchronizacje na poziowmie 1ms
i niestey - zegar zrobiony w zdarzeniu wywolywanym 1000 razy na sekunde
spoznia sie srednio 4-5 godzin na dobe ;(
Udalo mi sie podejrzec i podrobic timer kotry dal mi spoznienie rzedu kilku
minut na dobe ale kosztem calkowitego zawlaszczenia jednego rdzenia -
komputer musi miec dobre chlodzenie bo inaczej sie zjara ;)

Najczesciej to co chce zrobic pytacz powierza sie zewnwtrznym urzadzeniom bo
to co mozna uzyskac (czasy liczone w 10 mikrosekund) na amelu z zegarem
12Mhz dla najsilniejszego nawet komputera z windowsem jest niestety
niedostepne.
No chyba ze potrafisz pisac na poziomie systemowym i napiszesz wlasny
sterownik ktory zintegruje sie z jadrem systemu ;)



__________ Informacja programu ESET NOD32 Antivirus, wersja bazy sygnatur wirusów 7113 (20120505) __________

Wiadomoœć została sprawdzona przez program ESET NOD32 Antivirus.

http://www.eset.pl lub http://www.eset.com
neuron
 
Posty: 370
Dołączył(a): 14 cze 2012, o 15:15

Re: Odczyt danych z portu i watek

Postprzez egon_b » 5 maja 2012, o 14:21

Access Violation in module <jo3ack$8at$1@mx1.internetia.pl>at address
"neuron". See explanation below:

>Takie wartości w ogóle są niedopuszczalne, realnie 20 ms jest już
upierdliwe:)


jesteś w stanie zauważyć 2 setne sekundy? Oko ludzkie reaguje na
około 35-40 ms (20-30 klatek na sekundę) i uznaje to za płynną
animację, częstszych zdarzeń (jak 20 ms) po prostu nie zauważa :D
Ale ok, może Twój program potrzebuje ;)

--

Niektore protokoly, np modbus rtu uzywaja ograniczen czasowych jako
dodatkowy, poza suma kontrolna czynnik weryfikacji transmisji - jesli
jakikolwiek bajt ramki zostanie opozniony to cala ramka jest
ignorowana. Generalnie problemem nie jest czas realizacji
pozczegolnych operacji - problemem jest to ze jadro wywlaszcza watki
na czas ktorego nie da sie okreslic - moze byc tak ze wysylamy ramki
co 1ms ale co jakis czas nastepuje przerwa kilkuset milisekund bo
system uznal ze twoj watek jest mniej wazny od np watkow systemow
plikowych i go "zamrozi"


Zgadza się, co 1,5T ramka, 3 ramki ciszy między kolejnymi znakami itd.
Co nie zmienia faktu, że pisanie czegokolwiek real-time pod windows to
dosyć karkołomne przedsięwzięcie :-) A zgodnie z przysłowiem "jak się
nie ma co się lubi, to się lubi co się ma" trzeba się wpasować w
możliwości i ograniczenia windowsa albo pisać pod konkretny procesor /
oddać całość sterowania do urządzenia.

Wiele walczylem z timerami ktore daly by mi synchronizacje na
poziowmie 1ms i niestey - zegar zrobiony w zdarzeniu wywolywanym 1000
razy na sekunde spoznia sie srednio 4-5 godzin na dobe ;( Udalo mi
sie podejrzec i podrobic timer kotry dal mi spoznienie rzedu kilku
minut na dobe ale kosztem calkowitego zawlaszczenia jednego rdzenia -
komputer musi miec dobre chlodzenie bo inaczej sie zjara ;)


Używając QueryPerformanceCount uzyskasz prawdopodobnie jeszcze mniejsze
spóźnienie, a odpowiednio napisana pętla wątku nawet nie rozgrzeje
procesora :-)

I jeszcze multimedia timers:
http://msdn.microsoft.com/en-us/windows ... 63347.aspx

__________ Informacja programu ESET NOD32 Antivirus, wersja bazy
sygnatur wirusów 7113 (20120505) __________

Wiadomoœć została sprawdzona przez program ESET NOD32 Antivirus.

http://www.eset.pl lub http://www.eset.com


1) Uruchamiamy konsole programu dwukrotnie klikając ikonkę NOD'a
2) W konsoli wybieramy zakładkę Ustawienia
3) Następnie wybieramy Otwórz całe drzewo ustawień zaawansowanych
4) Wybieramy Ochrona poczty e-mail
5) W zakładce Alerty i powiadomienia wybieramy:
Oznacz otrzymaną i przeczytaną wiadomość e-mail: Nigdy
Oznacz wysyłaną wiadomość e-mail: Nigdy

to samo dla wiadomości grup dyskusyjnych

6) Klikamy OK
7) przestajemy śmiecić
[ __ ]
[ |_ _ _ _ ] Pozdrawiam!
[ |__(_)(_)| ) ]
[ _/ ] http://www.radsoft.pl/
egon_b
 
Posty: 7
Dołączył(a): 14 cze 2012, o 13:47

Re: Odczyt danych z portu i watek

Postprzez jh_address_is » 5 maja 2012, o 17:43

"Egon" <nie.chce@spamu.com>wrote:

>Takie wartości w ogóle są niedopuszczalne, realnie 20 ms jest już
upierdliwe:)


jesteś w stanie zauważyć 2 setne sekundy? Oko ludzkie reaguje na
około 35-40 ms (20-30 klatek na sekundę) i uznaje to za płynną
animację, częstszych zdarzeń (jak 20 ms) po prostu nie zauważa :D
Ale ok, może Twój program potrzebuje ;)


Instrumenty wirtualne, żeby być w miarę komfortowymi do grania korzystają
ze sterowników audio, które schodzą do realnego opóźnienia nawet poniżej
1ms. Przeciętna latencja 5-10 ms jest do przyjęcia. Powyżej tego granie
staje się co najmniej niewygodne, a przy wartościach powyżej 50 ms nie jest
akceptowalne. Chodzi o czas jaki upływa od wciśnięcia klawisza w sterowniku
MIDI, do momentu, kiedy usłyszysz dźwięk. Ucho ma nieporównanie większą
"rozdzielczość" czasową od oka. Dzięki temu rozróżniamy kierunki. Jeżeli
przyjmiesz średnią prędkość rozchodzenia się fal dźwiękowych na te 340 m/s
to dla przykładu: masz źródło dźwięku 1 m przed sobą, czyli dociera on do
Twojego ucha po ok. 2,9 ms. Wystarczy, że przesuniesz je nawet o
kilkanaście cm w lewo lub prawo, a Twoje uszy potrafią to odnotować, choć
różnica w dotarciu fali dźwiękowej do obu uszu jest grubo poniżej 1 ms.
MIDI jest dosyć wolne, ale jeżeli korzysta się z tych instrumentów
wirtualnych, to tym bardziej każda ms jest cenna.
jh_address_is
 
Posty: 3
Dołączył(a): 14 cze 2012, o 17:11

Re: Odczyt danych z portu i watek

Postprzez jh_address_is » 5 maja 2012, o 17:43

"neuron" <neuron@grupydyskusyjne.pl>wrote:

Ponadto muszisz zachowac powsciagliwosc w wierze w priorytety poszczegolnych
watkow - jak bys tego nie zorganiaowal to system decyduje ktory watek
dostanie czas i czasmai moze to bys nie po twojej mysli mimo teoretycznie
wiekszego priorytetu.


Świadom tego jestem...

Nie wiem co to ma byc, pewnie midi


Kaszpirowski. :D Tak, to do wieloportowych kart MIDI.

ale ja bym zrobil tyle pojedynczych
procesoe ile jest portow i jeden wspolny, wiryualny zbor danych logicznych
( pozbawionych wszytskich informacji z ramki ktora moga uzupelnic procesy
obslugi portow) a na dokladke wrzuci to w usluge (gdybym potrafil ;) ) albo
oddzielny program a komunikowal sie przez tcp/ip
z programem glownym



W sumie to przerobiłem to już. Zrobiłem listę, do której wstawiam dane w
wątku głównym. Wg opisu autora jest to thread safe. Po wstąpieniu ustawiać
ewentualnie, a w wątku tylko zdejmuję dane z kolejki, niestety to jest z
synchronize, ale musi. Ewentualnie zrobię podobnie, do Twojego pomysłu,
czyli w jednym synchronize zdejmę ileś tam danych.
jh_address_is
 
Posty: 3
Dołączył(a): 14 cze 2012, o 17:11

Re: Odczyt danych z portu i watek

Postprzez jh_address_is » 5 maja 2012, o 17:49

"Egon" <nie.chce@spamu.com>wrote:

Co nie zmienia faktu, że pisanie czegokolwiek real-time pod windows to
dosyć karkołomne przedsięwzięcie :-) A zgodnie z przysłowiem "jak się
nie ma co się lubi, to się lubi co się ma" trzeba się wpasować w
możliwości i ograniczenia windowsa albo pisać pod konkretny procesor /
oddać całość sterowania do urządzenia.


Bo widzisz, ale jednak się da. Masz programy audio/video, gdzie w
synchronizacji względem siebie pracuje kilkanaście urządzeń, komputerów i
nic nie ma prawa rozjechać się nawet o jedną próbkę, co przy 384 KHz
oznacza dokładność do 1/384000 sekundy...



Bez tego to ani rusz. Właśnie to MMTimers generują mi wspomniany zegar.
jh_address_is
 
Posty: 3
Dołączył(a): 14 cze 2012, o 17:11

Następna strona

Powrót do Delphi

 


  • Powiązane tematy
    Odpowiedzi
    Wyświetlone
    Ostatni post

Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 0 gości