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

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

On 2012-01-25 20:57, 4CX250 wrote:
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.

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.

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.

Wybacz ale nie bardzo rozumiem Twojej niechęci do WinAPI.

Jego idea i
sens żyje tak długo jak istnieją Windowsy - od czasów kiedy ówczesne
maszyny potrafiły niewiele więcej "uciągnąć" niż Windows i trochę GUI.

Owszem masz 100% racji że dzisiaj istnieją o wiele wygodniejsze sposoby
ale to wszystko to tylko kolejna warstwa, natomiast wiedza z zakresu
"jak to faktycznie działa" naprawdę potrafi się mocno przydać.

Venioo- jaki MS - Visual ??? Duzo lepsze jest QT Nokia i do tego
free. SUPER !
polecam http://qt.nokia.com/

było by lepsze. COKOLWIEK co nie leży na poziomie WinAPI będzie lepsze.

Pomijasz jeden fakt. Programy (lub raczej programiki) pure win32 api sa

Niestety musisz uważać, poradniki w sieci piszą te same tysiące
Dlatego papierowa ksiazka jest lepsza.

Venioo- jaki MS - Visual ??? Duzo lepsze jest QT Nokia i do tego
free. SUPER !

polecam http://qt.nokia.com/

Wiem wiem lacza sa szybkie, dyski sa tanie....

Pomijasz jeden fakt. Programy (lub raczej programiki) pure win32 api sa
mega krotkie (bynajmniej nie mam na mysli zrodel . Przyklad z
praktyki - Ile zajmie program monitorujacy dostepnosc jakiegos serwisu
www (chodzi o binarna ikonke w tray) w C++ z uzyciem frameworkow (pytam
a cala instalke wraz z bibilotekami) z ile czyste win32 api ?

On 2012-01-26 21:42, Marek Borowski wrote:
Pomijasz jeden fakt. Programy (lub raczej programiki) pure win32 api sa
mega krotkie (bynajmniej nie mam na mysli zrodel . Przyklad z
praktyki - Ile zajmie program monitorujacy dostepnosc jakiegos serwisu
www (chodzi o binarna ikonke w tray) w C++ z uzyciem frameworkow (pytam
a cala instalke wraz z bibilotekami) z ile czyste win32 api ?

Podaj choć jeden powód dla którego miało by to być:

a) argumentem w tej dyskusji

b) argumentem w dowolnej dyskusji po roku 2000.

Zdawalo mi sie iz temat jest o sensnownosci uzywania winapi.

Zdawalo mi sie iz temat jest o sensnownosci uzywania winapi.

Dodam jeszcze szczatkowe utilzacje
pamieci.

Jako programista - wiem doskonale o i ile latwiej i szybciej
sie pisze z uzyciem bardziej wysokopoziomowych bibliotek.

On 2012-01-26 22:34, Marek Borowski wrote:
Zdawalo mi sie iz temat jest o sensnownosci uzywania winapi.

... do pisania małych duperelek korzystajacych z portu COM.

Z punktu widzenia programisty faktycznie nie ma sensu. Zrobienie

Dodam jeszcze szczatkowe utilzacje
pamieci.

Jesli masz na myśli GC to postęp się poczynił na tyle duży że warto
przemysleć stare argumenty. Ponadto Qt nie używa GC. W ogóle dobra
abstrakcja nie musi mieć GC. Tu o abstrakcję nad API tylko chodzi.

Piszac o pamieci mialem na mysli wiecej zaladowanych biliotek, wiecej

Jako programista - wiem doskonale o i ile latwiej i szybciej
sie pisze z uzyciem bardziej wysokopoziomowych bibliotek.

O co zapewne chodzi autorowi wątku zamiast rozwiązywać zagadki z
czeluści MSDNa.
Moze i masz racje.

On 2012-01-26 19:45, Robert Zemła wrote:
Wybacz ale nie bardzo rozumiem Twojej niechęci do WinAPI.

Znasz cos poza nim? Qt? .NET? JRE? Bo ja znam.

Jego idea i
sens żyje tak długo jak istnieją Windowsy - od czasów kiedy ówczesne
maszyny potrafiły niewiele więcej "uciągnąć" niż Windows i trochę GUI.

Naprawdę chcesz z tego wyciągnąć tezę że to co było dobre w czasach 386
dzisiaj jest również doskonałe?

Owszem masz 100% racji że dzisiaj istnieją o wiele wygodniejsze sposoby
ale to wszystko to tylko kolejna warstwa, natomiast wiedza z zakresu
"jak to faktycznie działa" naprawdę potrafi się mocno przydać.

Nie. Naprawdę, nie interesuje Cie ile bajtów ma DWORD, dlaczego istnieje
różnica między unicodem a char i dlaczego notacja węgierska jest do
bani.

miejsce WinAPI. Programowanie *dzisiaj* w tym cudzie z lat 80 wymaga
*naprawdę* solidnej wymówki. Przedstaw ją w kontekście tego wątku.

Naprawdę chcesz z tego wyciągnąć tezę że to co było dobre w czasach 386
dzisiaj jest również doskonałe?
Nie, ale idąc tym tropem wychodzi że to cały Windows jest zły.

Prawdę mówiąc nie chciał bym pracować z człowiekiem który by nie
wiedział ile bajtów ma DWORD.

Po co programista ma w ogóle wiedzieć jak działa komputer?

Wystarczy że wie w jakiej kolejności trzeba wystukać komendy na
klawiaturze (albo gdzie i jak kliknąć myszką) żeby pojawiło się okienko
i guzik.

Co zrobi taki programista któremu "coś" nie zadziała?

Ah te obiektowe środowiska... ile rzeczy można zrobić myszką...

Natomiast do pisania pod WinAPI nie
potrzebuję wymówki.

On 2012-01-26 23:56, Robert Zemła wrote:
Naprawdę chcesz z tego wyciągnąć tezę że to co było dobre w czasach 386
dzisiaj jest również doskonałe?
Nie, ale idąc tym tropem wychodzi że to cały Windows jest zły.

Nie idź dalej tym tropem. WinAPI jest złe. Jest ciężkie, niespójne,
zagmatwane, czerpie całymi garściami z lat 80, ma się nijak do nowych
języków i technik programistycznych. To niskopoziomowe API systemu, nie
istnieje żaden argument aby z niego korzystać wprost poza jakimiś
promilami aplikacji wymagającymi ekstremalnych szybkości w brzegowych
zastosowaniach.

Prawdę mówiąc nie chciał bym pracować z człowiekiem który by nie
wiedział ile bajtów ma DWORD.

Prawdę mówiąc nie chciałbym pracować z człowiekiem dla którego napisanie
prostego programu do komunikacji po COM wymaga znajomości szczegołów
definicji DWORD. *Abstrakcja* jest ważniejsza od znajomości szczegołów
implementacji choćby z powodu przenośności, ba, nawet w samym Windowsie.

Po co programista ma w ogóle wiedzieć jak działa komputer?

Przesadzasz. Rzecz w tym po co programista ma wiedzieć jak działa
allokator pamięci i co zrobic żeby strcpy się nie wysypało. Otóż nie
powinien zaprzatać sobie głowy duperelami bo jego celem jest napisanie
kodu który działa. Wydajność, zajętość pamięci są trzeciorzędne,
szczególnie dla początkujących. Wazniejsze jest posiadanie zestawu
działających kontenerow, obiektowej biblioteki GUI, łatwych do użycia
komponentów, bibliotek zapewniających wsparcie w konkretnych zadaniach.

No tak. Nie ważne jak, ważne że działa. Potem niech się ewentualnie

Wystarczy że wie w jakiej kolejności trzeba wystukać komendy na
klawiaturze (albo gdzie i jak kliknąć myszką) żeby pojawiło się okienko
i guzik.

Tak działa Delphi. Początkujący, pozostawiony na pastwę tego środowiska
zaczyna pisać ciało funkcji w onclikach i tak juz mu zostaje. Dlatego
nie wolno pokazywac go początkującym uczącym się samodzielnie bo uczy
mimowolnie złych praktyk.

Co zrobi taki programista któremu "coś" nie zadziała?

Wiele rzeczy może, ale w WinAPI znacznie częściej nie będzie mu działać
i znacznie gorzej będzie debugować dlaczego.

Ah te obiektowe środowiska... ile rzeczy można zrobić myszką... :-)

Pomyliłeś programowanie obiektowe z RAD.

Natomiast do pisania pod WinAPI nie
potrzebuję wymówki.

Albowiem?