RTV forum PL | NewsGroups PL

Jak efektywnie synchronizować komunikację z miernikiem RLC w C++ WinAPI?

Do tych co tu piszą w C++

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Jak efektywnie synchronizować komunikację z miernikiem RLC w C++ WinAPI?

Goto page 1, 2, 3, 4  Next

4CX250
Guest

Wed Jan 25, 2012 2:15 pm   



W C++ piszę taki mały programik do odczytywania pomiarów z miernika RLC.

Wszystko w WinApi.

Najpierw muszę to urządzenie zainicjować i robię to tak:

strcpy ( Buffer_write, "//\x1B""2\x0A" ); // polecenie
ESC2 - przejście urządzenia w tryb REMOTE
WriteFile( hPort, Buffer_write, strlen ( Buffer_write ), &ile, 0 );

strcpy ( Buffer_write, "*CLS;ese 255\x0A" ); // Wyzerowanie
urządzenia
WriteFile ( hPort, Buffer_write, strlen ( Buffer_write ), &ile, 0 );

Następnie chcę sprawdzić czy komunikacja z urządzeniem jest prawidłowa.
Robię to pytaniem o identyfikator urządzenia.

strcpy ( Buffer_write, "*idn?\x0A" ); // Niech się
urządzenie teraz przedstawi
WriteFile ( hPort, Buffer_write, strlen ( Buffer_write ), &ile, 0 );


W następnej części programu mam problem. Nie bardzo wiem, co zrobić aby
program odczekał skutecznie tylko tyle czasu ile jest niezbędne, aż w
buforze odbiorczym COM pojawią się wszystkie dane wysłane przez urządzenie.

Narazie robię to w bardzo nieelegancki sposób za pomocą opóźnienia

Sleep (1000);

Jest coś skuteczniejszego?

Dalej w programie jest tak.
Po odczekaniu 1000ms program przystępuje do odczytania bufora.
Najpierw sprawdzam ile jest znaków w buforze COM do odczytania

Result = ClearCommError( hPort, &Errors, &ComStatus );
Buffer_lenght = ComStatus.cbInQue; // Sprawdzenie ile bajtów oczekuje w
buforze wejściowym COM

Następnie czyszczę bufor odbiorczy ale nie wiem czy to jest właściwy
sposób.
Gdy tego nie robiłem to były w nuforze śmieci z poprzednich odczytów

strcpy(Buffer_read, " "); // Wyzerowanie
bufora odbiorczego

Ostatecznie odczutuję zawartośc bufora

Result = ReadFile( hPort, Buffer_read, Buffer_lenght, &ile, NULL );

Wynik trafia do okienka na ekranie

SetWindowText( g_hText1, Buffer_read );

Pominąłem polecenia if oraz while które pilnują aby nie próbować czekać w
nieskończoność aż coś się pojawi w buforze.
W analogiczny sposób odpytuję urządzenie o wyniki konkretnych pomiarów
wartości RLC i tam też mam taki sam problem.


Marek

Waldemar Krzok
Guest

Wed Jan 25, 2012 2:47 pm   



Am 25.01.2012 14:15, schrieb 4CX250:
Quote:
W C++ piszę taki mały programik do odczytywania pomiarów z miernika RLC.

Wszystko w WinApi.

Najpierw muszę to urządzenie zainicjować i robię to tak:

strcpy ( Buffer_write, "//\x1B""2\x0A" ); // polecenie ESC2 - przejście
urządzenia w tryb REMOTE
WriteFile( hPort, Buffer_write, strlen ( Buffer_write ), &ile, 0 );

strcpy ( Buffer_write, "*CLS;ese 255\x0A" ); // Wyzerowanie urządzenia
WriteFile ( hPort, Buffer_write, strlen ( Buffer_write ), &ile, 0 );

Następnie chcę sprawdzić czy komunikacja z urządzeniem jest prawidłowa.
Robię to pytaniem o identyfikator urządzenia.

strcpy ( Buffer_write, "*idn?\x0A" ); // Niech się urządzenie teraz
przedstawi
WriteFile ( hPort, Buffer_write, strlen ( Buffer_write ), &ile, 0 );


W następnej części programu mam problem. Nie bardzo wiem, co zrobić aby
program odczekał skutecznie tylko tyle czasu ile jest niezbędne, aż w
buforze odbiorczym COM pojawią się wszystkie dane wysłane przez urządzenie.

Narazie robię to w bardzo nieelegancki sposób za pomocą opóźnienia

Sleep (1000);

Jest coś skuteczniejszego?

Dalej w programie jest tak.
Po odczekaniu 1000ms program przystępuje do odczytania bufora.
Najpierw sprawdzam ile jest znaków w buforze COM do odczytania

Result = ClearCommError( hPort, &Errors, &ComStatus );
Buffer_lenght = ComStatus.cbInQue; // Sprawdzenie ile bajtów oczekuje w
buforze wejściowym COM

Następnie czyszczę bufor odbiorczy ale nie wiem czy to jest właściwy
sposób.
Gdy tego nie robiłem to były w nuforze śmieci z poprzednich odczytów

strcpy(Buffer_read, " "); // Wyzerowanie bufora odbiorczego

Ostatecznie odczutuję zawartośc bufora

Result = ReadFile( hPort, Buffer_read, Buffer_lenght, &ile, NULL );

Wynik trafia do okienka na ekranie

SetWindowText( g_hText1, Buffer_read );

Pominąłem polecenia if oraz while które pilnują aby nie próbować czekać
w nieskończoność aż coś się pojawi w buforze.
W analogiczny sposób odpytuję urządzenie o wyniki konkretnych pomiarów
wartości RLC i tam też mam taki sam problem.

Po pierwsze możesz sobie zdefiniować stringi i posługiwać się nazwami,
ale to kwestia smaku. Ja tak lubię Wink.
Po drugie: nie wiem, czy twój miernik zwraca zero delimited string.
Jeżeli były śmieci, to prawdopodobnie nie masz końcowego zera w stringu.
Musisz je dopisać na końcu Buffer_read po ReadFile:
Buffer_read[ile] = 0x00;
Wtedy nie musisz zerować bufora. Warto sprawdzić, czy "ile" nie
przekracza długości bufora. Buffer overflow jest nieprzyjemnym
zjawiskiem i może doprowadzić do chroniczniej kurwicy gonad Wink. W
szczególności na początku, jak miernik coś wysyła, a program jeszcze nie
odbiera może się conieco uzbierać. Flush też by się przydał.

Co do sleep, to obejść możesz to właściwie tylko przez napisanie obsługi
przerwania. Dawno nie pisałem programu pod COMa, ale chyba istnieje
metoda klasy COMM, czy jak się ona tam nazywała, definiująca przerwanie.
Zamiast sleep możesz dać polling na ComStatus.cbInQue, choć powinna być
też metoda dająca wynik true, jak cokolwiek przyszło. Osobiście robię te
rzeczy na ogół przez polling, a timer załatwia sprawę, jak coś wisi.
Timeout też jest na ogół metodą przy COMM.

Waldek


--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.

Sebastian Biały
Guest

Wed Jan 25, 2012 5:10 pm   



On 2012-01-25 14:15, 4CX250 wrote:
Quote:
W C++ piszę taki mały programik do odczytywania pomiarów z miernika RLC.
Wszystko w WinApi.

WinAPI to nie C++.

Quote:
Najpierw muszę to urządzenie zainicjować i robię to tak:
strcpy ( Buffer_write, "//\x1B""2\x0A" );

To nie jest C++ tylko C--.

Quote:
W następnej części programu mam problem. Nie bardzo wiem, co zrobić aby
program odczekał skutecznie tylko tyle czasu ile jest niezbędne, aż w
buforze odbiorczym COM pojawią się wszystkie dane wysłane przez urządzenie.

Masz trzy wyjścia:

a) programować zdarzeniowo - abstrakcja portu COM sama poinformuje że ma
"coś w środku" do odczytu. Kwestia znalezienia abstrakcji na port COM z
takim ficzerem lub napisanie.

b) Odczytać *natychmiast* znak z bufora dbając aby ustawiony (w
systemie) był odpowiedni timeout czekania na znak. Program wróci
niezwłocznie gdy odbierze znak lub gdy skończy się timeout.

c) wątki i ich synchronizacja

Quote:
Jest coś skuteczniejszego?

Jest, a b c. Preferowane C, ale w realnym zasięgu masz B.

Quote:
Gdy tego nie robiłem to były w nuforze śmieci z poprzednich odczytów

W buforze COM nie ma śmieci tylko dane które odbierasz z urządzenia.

Quote:
W analogiczny sposób odpytuję urządzenie o wyniki konkretnych pomiarów
wartości RLC i tam też mam taki sam problem.

Zmień język na C++ + Qt lub zainteresuj się może C# który załatwi
problemy z WinAPi za sensownym interfejsem. Do wyboru masz jeszcze Jave.

4CX250
Guest

Wed Jan 25, 2012 8:37 pm   



Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:jfp9i6$71j$1@inews.gazeta.pl...
Quote:
On 2012-01-25 14:15, 4CX250 wrote:
W C++ piszę taki mały programik do odczytywania pomiarów z miernika RLC.
Wszystko w WinApi.

WinAPI to nie C++.

Najpierw muszę to urządzenie zainicjować i robię to tak:
strcpy ( Buffer_write, "//\x1B""2\x0A" );

To nie jest C++ tylko C--.

Programuję w DevC++. Dopiero się uczę tego języka i sam nie wiem co jest
czym. Z czasem się poukłada :)


B, czyli odbieram pojedyncze znaki i sklejam do kupy. Tak myślałem bo to
najprostrze będzie.


Quote:
Zmień język na C++ + Qt lub zainteresuj się może C# który załatwi problemy
z WinAPi za sensownym interfejsem. Do wyboru masz jeszcze Jave.

Nie. Mój rozum zbankrutuje jak tak zacznę szaleć Smile I tak już mi się
bardziej nie chce niż chce tego języka się uczyć. Dotychczas ASM Turbopascal
i Clipper mi wystarczały. Jako że na AVRy się przesiadłem to i zacząłem w
C++ coś dłubać.

Marek

Grzegorz Niemirowski
Guest

Wed Jan 25, 2012 8:40 pm   



4CX250 <tarnusmtv@poćta.łonet.pl> napisał(a):
Quote:
B, czyli odbieram pojedyncze znaki i sklejam do kupy. Tak mylaem bo to
najprostrze bdzie.

Nie musisz pojedynczo. Odbierasz to, co jest. Po to przecież masz jako
parametr &ile. Wiesz dokładnie ile przyszło teraz i ile masz do tej pory.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 17 hours, 26 minutes and 17 seconds

4CX250
Guest

Wed Jan 25, 2012 8:42 pm   



Użytkownik "Waldemar Krzok" <waldemar@zedat.fu-berlin.de> napisał w
wiadomości news:9oaff1Fv8qU1@mid.uni-berlin.de...

Quote:
Po pierwsze możesz sobie zdefiniować stringi i posługiwać się nazwami, ale
to kwestia smaku. Ja tak lubię Wink.
Po drugie: nie wiem, czy twój miernik zwraca zero delimited string.
Jeżeli były śmieci, to prawdopodobnie nie masz końcowego zera w stringu.
Musisz je dopisać na końcu Buffer_read po ReadFile:
Buffer_read[ile] = 0x00;

Tak zapewne jest ale teraz nie mam możliwości sprawdzić.

Quote:
Warto sprawdzić, czy "ile" nie przekracza długości bufora. Buffer overflow
jest nieprzyjemnym zjawiskiem i może doprowadzić do chroniczniej kurwicy
gonad Wink. W szczególności na początku, jak miernik coś wysyła, a program
jeszcze nie odbiera może się conieco uzbierać. Flush też by się przydał.

Oczywiście tak zrobię, pożyteczna rada.

Quote:
Co do sleep, to obejść możesz to właściwie tylko przez napisanie obsługi
przerwania. Dawno nie pisałem programu pod COMa, ale chyba istnieje metoda
klasy COMM, czy jak się ona tam nazywała, definiująca przerwanie. Zamiast
sleep możesz dać polling na ComStatus.cbInQue, choć powinna być też metoda
dająca wynik true, jak cokolwiek przyszło. Osobiście robię te rzeczy na
ogół przez polling, a timer załatwia sprawę, jak coś wisi. Timeout też
jest na ogół metodą przy COMM.

Wykorzystam timer, będzie najprościej chyba.

Dzięki.

Marek

Sebastian Biały
Guest

Wed Jan 25, 2012 8:48 pm   



On 2012-01-25 20:37, 4CX250 wrote:
Quote:
Najpierw muszę to urządzenie zainicjować i robię to tak:
strcpy ( Buffer_write, "//\x1B""2\x0A" );
To nie jest C++ tylko C--.
Programuję w DevC++. Dopiero się uczę tego języka i sam nie wiem co jest
czym. Z czasem się poukłada Smile

Wyrzuć książki w których ktoś coś bredzi o strcpy w dowolnym
współczesnym zastosowaniu GUI.

Quote:
B, czyli odbieram pojedyncze znaki i sklejam do kupy. Tak myślałem bo to
najprostrze będzie.

Nie. Znacznie wygodniej jest:

std::string a;
....
while( ... ) { a+= znak; }

Wygodniej bo nie musisz dbać o szczegóły implementacji realokacji
pamięci. Tylko tyle i aż tyle.

Quote:
Zmień język na C++ + Qt lub zainteresuj się może C# który załatwi problemy
z WinAPi za sensownym interfejsem. Do wyboru masz jeszcze Jave.

Nie. Mój rozum zbankrutuje jak tak zacznę szaleć Smile

Używasz języka C (bo to nie C++) a więc czegoś z lat 80 w środowisku
WinAPI które pochodzi koncepcyjnie z grubsza rzecz biorąc tamtego czasu.
Do dnia dzisiejszego inżynieria dorobiła się *znacznie* wygodniejszych
narzędzi. Zwróć się w kierunku C#/Java. To języki o identycznej składni
z dokładnością do dupereli a *automatycznie* pozwolą na wykorzystanie
choćby technik zdarzeniowych które rozwiążą Ci wszelakie problemy na tym
etapie na którym jesteś zamiast rękodzieła w jednym z najmniej wygodnych
API jakie istnieją.

Quote:
I tak już mi się
bardziej nie chce niż chce tego języka się uczyć.

C to fatalny wybór jeśli chcesz pisać GUI. FA-TAL-NY.

Quote:
Jako że na AVRy się przesiadłem to i zacząłem w
C++ coś dłubać.

Dłubiesz w C. Do C++ masz jeszcze kilka lat świetlnych. Jeśli dopiero
zaczynasz to to odpowiedni moment żeby *NIE* używać błędnych narzędzi
takich jak wybuchowa mieszanka C z WinAPI z powodu glupiej komunikacji z
COM.

4CX250
Guest

Wed Jan 25, 2012 8:51 pm   



Użytkownik "Grzegorz Niemirowski" <gnthexfiles@poczta.onet.pl> napisał w
wiadomości news:jfplt8$7ei$1@news.icpnet.pl...
Quote:
4CX250 <tarnusmtv@poćta.łonet.pl> napisał(a):
B, czyli odbieram pojedyncze znaki i sklejam do kupy. Tak mylaem bo to
najprostrze bdzie.

Nie musisz pojedynczo. Odbierasz to, co jest. Po to przecież masz jako
parametr &ile. Wiesz dokładnie ile przyszło teraz i ile masz do tej pory.

Tak pomyślałem gdyż będzie to wynikało raczej z tego że program śmiga dość
szybko i bufor nie zdąży się zapełniać więcej niż jednym znakiem.
Transmisja 9600baud.


Marek

4CX250
Guest

Wed Jan 25, 2012 8:57 pm   



Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:jfpm9r$na9$1@inews.gazeta.pl...
..
..
..
Quote:
Dłubiesz w C. Do C++ masz jeszcze kilka lat świetlnych. Jeśli dopiero
zaczynasz to to odpowiedni moment żeby *NIE* używać błędnych narzędzi
takich jak wybuchowa mieszanka C z WinAPI z powodu glupiej komunikacji z
COM.

Zapewne masz rację i z czasem sam to pojmę. Piszę często na przykładach
znalezionych w necie które dobieram je do własnych celów.
Nie mam takiej wiedzy abym mógł ocenić który jest OK a który passe. Na tym
etapie jakim jestem liczy się że coś działa.
Zapewne takich jak ja są tysiące bo przecież od nich te przykłady i
poradniki w necie ściągam.

Marek

venioo@interia.pl
Guest

Wed Jan 25, 2012 9:06 pm   



W dniu 2012-01-25 20:37, 4CX250 pisze:

Quote:

Nie. Mój rozum zbankrutuje jak tak zacznę szaleć Smile I tak już mi się
bardziej nie chce niż chce tego języka się uczyć. Dotychczas ASM Turbopascal
i Clipper mi wystarczały. Jako że na AVRy się przesiadłem to i zacząłem w
C++ coś dłubać.


to przesiadz sie na Visual Basic z darmowego pakietu MS Visual Studio
Express 2010 - napiszesz to szybko, latwo i przyjemnie.
Pewnie niektorzy nazwa Cie lamerem, bo to nie C++ tylko jakis Basic, ale
chodzi o to, zeby dzialalo jak najmniejszym nakladem pracy :)


Pozdrawiam


--
venioo -> GG:198909
Sprzedam AUDI 100 C4 '91 AAR 2.3 LPG
http://tablica.pl/oferta/audi-100-c4-czarna-gaz-lpg-mafia-look-IDvheh.html

Sebastian Biały
Guest

Wed Jan 25, 2012 9:09 pm   



On 2012-01-25 20:57, 4CX250 wrote:
Quote:
Dłubiesz w C. Do C++ masz jeszcze kilka lat świetlnych. Jeśli dopiero
zaczynasz to to odpowiedni moment żeby *NIE* używać błędnych narzędzi
takich jak wybuchowa mieszanka C z WinAPI z powodu glupiej komunikacji z
COM.

Zapewne masz rację i z czasem sam to pojmę. Piszę często na przykładach
znalezionych w necie które dobieram je do własnych celów.

OK, nie neguję tego, ale wybierasz akurat jedno z najgorszych możliwych
rozwiązań. Cięzko mi to przez klawiaturę przechodzi, ale nawet Delphi
było by lepsze. COKOLWIEK co nie leży na poziomie WinAPI będzie lepsze.

Quote:
etapie jakim jestem liczy się że coś działa.

Nie zapominaj że ucząc się złych rozwiązań z czasem zaczniejsz je
powielać. A wymówka że na AVR też w C będziesz pisał jest tego
doskonałym przykładem.

Quote:
Zapewne takich jak ja są tysiące bo przecież od nich te przykłady i
poradniki w necie ściągam.

Niestety musisz uważać, poradniki w sieci piszą te same tysiące którzy
miesiąc wcześniej się z nich uczyli. Rekurencja i głuchy telefon.

Waldemar Krzok
Guest

Wed Jan 25, 2012 9:23 pm   



Sebastian Biały wrote:


Quote:
Nie. Mój rozum zbankrutuje jak tak zacznę szaleć :)

Używasz języka C (bo to nie C++) a więc czegoś z lat 80 w środowisku
WinAPI które pochodzi koncepcyjnie z grubsza rzecz biorąc tamtego czasu.
Do dnia dzisiejszego inżynieria dorobiła się *znacznie* wygodniejszych
narzędzi. Zwróć się w kierunku C#/Java. To języki o identycznej składni
z dokładnością do dupereli a *automatycznie* pozwolą na wykorzystanie
choćby technik zdarzeniowych które rozwiążą Ci wszelakie problemy na tym
etapie na którym jesteś zamiast rękodzieła w jednym z najmniej wygodnych
API jakie istnieją.

I tak już mi się
bardziej nie chce niż chce tego języka się uczyć.

C to fatalny wybór jeśli chcesz pisać GUI. FA-TAL-NY.

Jako że na AVRy się przesiadłem to i zacząłem w
C++ coś dłubać.

Dłubiesz w C. Do C++ masz jeszcze kilka lat świetlnych. Jeśli dopiero
zaczynasz to to odpowiedni moment żeby *NIE* używać błędnych narzędzi
takich jak wybuchowa mieszanka C z WinAPI z powodu glupiej komunikacji z
COM.

Ach, nie przesadzaj. Da się też. Ale masz rację, że są wygodniejsze metody.

Waldek

--
My jsme Borgové. Sklopte štíty a vzdejte se. Odpor je marný.

Sebastian Biały
Guest

Wed Jan 25, 2012 10:04 pm   



On 2012-01-25 21:23, Waldemar Krzok wrote:
Quote:
Ach, nie przesadzaj. Da się też.

To jest *bardzo* słaby argument za tym aby jednak próbować dłubać GUI w
C i WinAPI.

Michoo
Guest

Wed Jan 25, 2012 10:13 pm   



W dniu 25.01.2012 17:10, Sebastian Biały pisze:
Quote:
Zmień język na C++ + Qt lub zainteresuj się może C# który załatwi
problemy z WinAPi za sensownym interfejsem. Do wyboru masz jeszcze Jave.
Co do Qt to jako, że niedawno w ramach zaliczenia z kolegą popełniliśmy

aplikację rozmawiającą po serialu z FPGA, to załączam link do screena
aplikacji i całego kodu przez nas napisanego Wink
http://grota.be/~michoo/smieci/pwmserial.png
Użyta biblioteka to http://code.google.com/p/qextserialport/

--
Pozdrawiam
Michoo

Zbych
Guest

Thu Jan 26, 2012 8:09 am   



W dniu 2012-01-25 22:13, Michoo pisze:
Quote:
W dniu 25.01.2012 17:10, Sebastian Biały pisze:
Zmień język na C++ + Qt lub zainteresuj się może C# który załatwi
problemy z WinAPi za sensownym interfejsem. Do wyboru masz jeszcze Jave.
Co do Qt to jako, że niedawno w ramach zaliczenia z kolegą popełniliśmy
aplikację rozmawiającą po serialu z FPGA, to załączam link do screena
aplikacji i całego kodu przez nas napisanego Wink
http://grota.be/~michoo/smieci/pwmserial.png

Pokazałeś fragment z _wysyłaniem_ danych, który pod gołym winapi/posixem
wyglądałby równie skompilowanie.

Goto page 1, 2, 3, 4  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Jak efektywnie synchronizować komunikację z miernikiem RLC w C++ WinAPI?

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map