serielle Kommunikation über COM mit WINAPI



  • Frederick schrieb:

    Wir halten also fest: RS232 ist trivial, nur der Zugriff unter Windows nicht. Gut. Aber irgendwie *muss* es gehen.

    Was hindert Dich daran den Source der von mir vorgeschlagenen Lösung anzuschauen???

    Warum sollen wir hier Lösungen abieten, die schon zig Mal gemacht wurden?



  • Ich habe mir den Quellcode gelesen, allerdings muss ich sagen er mir ähnlich komplex und umfangreich erscheint wie Betriebssystem Kernel. Was ich aber (glaube ich) erkennen konnte, war dass dort im Prinzip die selben Funktionen mit den gleichen Parametern verwendet werden, wie ich sie verwendet habe. Insgesamt hilft mir das also nicht weiter.

    Was hindert dich daran dir mal meinen Code anzusehen, der im übrigen sehr viel kürzer und primitiver ist, und vielleicht einen entdeckten Fehler mit zu teilen. Die WinMain kannst du überspringen, das Interessante steht in WM_CREATE und WM_TIMER. Bei CreateFile und SetCommState tritt kein Fehler auf, was heißen könnte, dass diese Zeilen stimmen. Nur beim Senden stimmt was nicht.



  • Ich habe noch was entdeckt:

    Der von WriteFile oder TransmitCommChar zurückgegeben Fehlercode hat die Nummer 6 und heißt 'ERROR_INVALID_HANDLE'. Allerdings werde ich daraus nicht schlau, denn wenn der von CreateFile zurück gelieferte Handel ungültig wäre, hätten die beiden oberen Überprüfungen auch schon ansprechen müssen.



  • schreib ein 'static' vor der definition von 'HANDLE RS232;'
    🙂



  • Das ist einer jener Momente in denen ich mich in den A_____ beißen könnte!!!

    So oft habe ich dieses verfl___ static vergessen und so oft bin ich dahinter gekommen.

    Aber letztendlich ist der Zugriff auf COM *doch* trivial!

    Vielen, Vielen Dank.



  • Frederick schrieb:

    Aber letztendlich ist der Zugriff auf COM *doch* trivial!

    ist er auch. nur nicht unter windoofs 😉



  • So, dass Problem mit dem Senden ist ja jetzt gelöst, nur wie empfängt man Daten?

    Irgendwo hab ich was von der WM_COMMNOTIFY Nachricht gehört, nur existiert diese angeblich seit WIN 3.1 nicht mehr. Als Ersatz gibt es eine Funktion die offenbar darauf wartet dass ein Ereignis eintritt: WaitCommEvent. Nur stelle ich mir die Sache dann etwas schwierig vor: Was ist wenn kein Ereignis eintritt? Ist dann meine gesamte Anwendung blockiert? Das wären ja Methoden aus dem Mittelalter. Da kann ich ja gleich alle 10ms ReadFile ausführen und hoffen das was ankommt?

    Kann mir jemand erklären was WaitCommEvent wirklich tut, bzw welche Alternativen es gibt?



  • Frederick schrieb:

    ..., bzw welche Alternativen es gibt?

    Zuerst einmal blockiert ReadFile nur so lange wie man es einstellt. Dazu gibt es die Funktion SetCommTimeouts.

    Man kann auch vor dem Lesen erst nachschauen wieviele Bytes im Eingangspuffer liegen, das geht mit ClearCommError.

    Wer es kompliziert mag, kann auch die Schnittstelle im Overlapped Modus öffnen, da kommt ReadFile immer gleich zurück und man kann mit GetOverlappedResult nachschauen, ob das Lesen fertig ist.



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


Anmelden zum Antworten