serielle Kommunikation über COM mit WINAPI
-
Es gibt doch schon für jeden Sch____ Windows Nachrichten, warum wurde die bereits vorhandene Nachricht wieder abgesetzt?
Wenn man nähmlich case WM_COMMNOTIFY: schreibt akzeptiert das der Compiler, nur bei den Ereignissen wie CN_RECEIVE streikt er.
-
Frederick schrieb:
Es gibt doch schon für jeden Sch____ Windows Nachrichten, warum wurde die bereits vorhandene Nachricht wieder abgesetzt?
Mit seriellen Schnittstellen arbeitet man in Workerthreads. Da gibt es keine Nachrichten.
-
Ich nehme doch auch keinen Thread wenn ich darauf warten will, dass der Benutzer eine Taste drückt!
Meiner Meinung nach mimmt man dann Threads wenn zb eine langwierige Berechnung im Hintergrung laufen soll, aber nicht wenn man auf einen Interrupt wartet. Da Der UART sowieso mindestens einen Interrupt an die CPU schickt wenn er Daten empfängt, bräuchte Windows ihn lediglich in Form einer Nachricht an die Anwendung weiter zu leiten. Dass man ein Ereignis ständig abfragt ist doch blanker Unsinn!
PS: in MSDN findet man fast alles, sogar eine Liste aller Windowsfunktionen und Datentypen, aber wo findet man eine Liste von Windows Nachrichten???
-
Frederick schrieb:
Meiner Meinung nach mimmt man dann Threads wenn zb eine langwierige Berechnung im Hintergrung laufen soll,
Oder eine langwierige Datenübertragung ...
Frederick schrieb:
Dass man ein Ereignis ständig abfragt ist doch blanker Unsinn!
Natürlich. Das macht man ja auch bei seriellen Schnittstellen nicht.
Frederick schrieb:
PS: in MSDN findet man fast alles, sogar eine Liste aller Windowsfunktionen und Datentypen, aber wo findet man eine Liste von Windows Nachrichten???
Was hat das mit dem Thema zu tun ?
Es gibt keine Windows Nachrichten für die serielle Schnittstelle. (Mit Ausnahme der Nachrichten die z.B. gesendet werden, wenn eine am USB angeschlossene Schnittstelle entfernt wird.
-
nn schrieb:
Natürlich. Das macht man ja auch bei seriellen Schnittstellen nicht.
Entweder wartet ReadFile bis alle Bytes gelesen sind oder der Timeout abgelaufen ist. => Du brauchst einen Thread, weil sonst die Oberfläche hängt.
Beim Overlapped IO wartet man z.B. mit WaitForSingleObject.
=> Du brauchst einen Thread, weil sonst die Oberfläche hängt.Die einzige Variante, wo man in gewisserweise aktiv wartet ist die Variante mit ClearCommError. Das macht man entweder mit einem Timer oder in einem Thread, der den Buffer checkt und danach eine Weile mit Sleep wartet.
-
OK, danke.
(Sch_____ Windows)
-
Frederick schrieb:
OK, danke.
(Sch_____ Windows)
Also im Prinzip geht es unter Linux nicht viel anders.
Die API-Funktionen sind andere, aber nicht das Funktionsprinzip.Wenn man herausgefunden hat, wie es geht ist es eigentlich doch trivial.
-
Wenn man herausgefunden hat, wie es geht ist es eigentlich doch trivial.
Ich programmiere bis jetzt hauptsächlich u-Kontroller (in C), meine PC Programme dienen vornehmlich Tests dieser Systeme. Bis jetzt setze ich zur seriellen Kommunikation Treiber wir ComOpen, ComWr, ComWrByte, ... ein.
Ich möchte aber auf eine etwas 'modernere' Variante umsteigen, die auch problemlos unter XP läuft.Das Programm von Frederick habe ich probiert, läuft super!
Gibt es auch eine Quellcode, die Datenempfang mit einbezieht?
Danke für eure Hilfe!
Guido
-
GP schrieb:
Gibt es auch eine Quellcode, die Datenempfang mit einbezieht?
??? Was poste ich denn hier die ganze Zeit!?
http://www.codeproject.com/system/serial.asp
-
Hallo Jochen,
Ich arbeite mit einer freien Entwicklungsumgebung (MinGW) und erhalte immer Fehler beim compilieren, serial.h ist im Verzeichnis vom Quellcode.
'undefined reference to 'Cserial::Open(char ...'
Ich denke, dass ich die Bibliotheken nicht richtig angegeben habe. Welche brauche ich in welchem Verzeichnis um fehlerlos zu compilieren/ linken?Tschuldige, aber jeder fängt mal an!:)
Guido
-
Du brauchst keine Bibliotheken... der Source ist komplett dabei...