Do tych co tu piszą w C++

Jan 25, 2012 46 Replies

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


Am 25.01.2012 14:15, schrieb 4CX250:

Po pierwsze możesz sobie zdefiniować stringi i posługiwać się nazwami, ale to kwestia smaku. Ja tak lubię ;-). 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 ;-). 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

WinAPI to nie C++.

To nie jest C++ tylko C--.

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

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

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

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.

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.

Nie. Mój rozum zbankrutuje jak tak zacznę szaleć :) 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

4CX250 <tarnusmtv@poćta.łonet.pl> napisał(a):

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.

Użytkownik "Waldemar Krzok" snipped-for-privacy@zedat.fu-berlin.de> napisał w wiadomości news: snipped-for-privacy@mid.uni-berlin.de...

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

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

Wykorzystam timer, będzie najprościej chyba.

Dzięki.

Marek

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

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.

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ą.

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

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.

U¿ytkownik "Grzegorz Niemirowski" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:jfplt8$7ei$ snipped-for-privacy@news.icpnet.pl...

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

Użytkownik "Sebastian Biały" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:jfpm9r$na9$ snipped-for-privacy@inews.gazeta.pl... . . .

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

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

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

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.

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.

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.

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

Waldek

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

W dniu 25.01.2012 17:10, Sebastian Biały pisze:

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 ;)

formatting link
żyta biblioteka to
formatting link

W dniu 2012-01-25 22:13, Michoo pisze:

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

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

polecam

formatting link

W dniu 25-01-2012 14:15, 4CX250 pisze:

Żeby było elegancko powinieneś powołać osobny wątek do samej komunikacji z COM'em a do synchronizacji z GUI powinieneś użyć zdarzeń. Co do samej obsługi COM'a, powinieneś ustawić jeszcze time'outy. Przy okazji poczytaj o trybie overlapped i sam zdecyduj co ma największy sens w Twojej aplikacji.

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ć.

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

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

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. Zacznij uzywać środowisk *obiektowych* a zobaczysz gdzie jest miejsce WinAPI. Programowanie *dzisiaj* w tym cudzie z lat 80 wymaga

*naprawdę* solidnej wymówki. Przedstaw ją w kontekście tego wątku.

snipped-for-privacy@poczta.fm snipped-for-privacy@poczta.fm napisał(a):

Tak jakby Visual nie był i nie można było pisać w QT pod Visualem.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required