Threads, Events oder ... zur Steuerung des Zugriffs auf eine Serielle Schnittstelle?



  • Hallo,
    ich habe gerade folgendes Problem.
    Ich möchte ein Gerät über eine Serielle Schnittstelle ansteuern.
    Ich habe also eine Serielle Schnittstelle, auf die ich sende und empfange.
    Mein Problem ist jetzt welcher Ansatz da der beste ist.

    Ich würde gerne das Ganze über Threads machen (ein Sendethread, ein Empfangsthread, die sich die Schnittstelle teilen).
    Hab aber auch gehört, dass die nicht ganz zu einfach zu implementieren sind. Welche Ansätze sind denn da am sinnvollsten?
    bzw. wo liegen denn die Unterschiede?

    Schonmal Danke im Voraus, an alle, die sich melden.
    Gruß



  • DOS und Win32-Konsole
    Arbeiten mit DOS oder der Win32-Konsole? Konsolen-API (Farben?) oder Ströme lenken (COM-Port?) - das kommt hier rein! Vorher bitte die FAQ durchsuchen, danke!

    Für Threads schu im WInAPI Forum (oder wahlweise Linux, je nachdem) nach.

    COM IO, alternativ musst du auf OS API Funktionen zurückgreifen.

    Unterschiede wozwischen?

    Gruß
    FreaK



  • Hi!

    Schau dir mal bei CreateFile() das FILE_FALG_OVERLAPPED attribut an. außerdem ist WaitCommEvent() auch sehr hilfreich.´ 😉 Schau eifnach mal ob ud zurechtkommst ind er MSDN.



  • hallo, ich hatte schon in den FAQ geguckt, meine Schnittstellen Klasse basiert auch auf dem Code, der unter Ströme lenken zu finden ist.
    Das funktioniert auch prima nur halt sequenziell.

    Ich glaube nur, dass ich den Zugriff auf den COMport irgendwie steuern muß und dazu eine leseThread und einen schreibeThread brauche.

    Ich hätte das nämlich am liebsten so, dass das Programm benachrichtigt wird, wenn es was zu empfangen gibt. Weiß aber nicht wie man das mit C++ realisiert.

    Unterschied war gemeint zwischen Event und Thread.

    gruß



  • Naja, irgend jemand muß ja den Port beobachten, um letztendlich das Event zu feuern. Ich habe leider noch nie den COM-Port abgehört, und wen es das von der WinAPI nicht fertig gibt, würde ich mir da selber was basteln:

    boost::thread zum beobachten des COM-Ports. Und boost::signal um dann das "Event" zu feuern, an alle die es wissen wollen. Mit diesen zwei Klassen kannste zumindest dein Konzept umsetzen. Um letztenendlich auf den COM-Port zu zugreifen, kann ich dir aber nicht weiter helfen. Da muß dann wirklich die WinAPI herhalten.

    Und wie immer gilt: die Boost-Library ist Pflicht für jeden C++ Programmierer! ⚠



  • Danke,
    wie gesagt, der Zugriff auf den COMport funktioniert einwandfrei. Der Zugriff auf den COMport sollte dann wohl durch *WaitCommEvent* geschehen. Und die threads sollten dann über die boostgeschichte gemacht werden, wenn ich das jetzt richtig verstehe, oder?

    An den Fragen kann man auch glaube ich sehr gut sehen, dass
    mein Problem eher in der Entwicklung eines geeigneten Konzepts für z.b. Threads liegt. Die Problematik bei der Umsetzung / Implementierung mein ich damit noch nicht mal.

    Mein Problem ist, dass ich mit Events/Threads,etc. noch nichts zu tun hatte und mir deswegen die Ideen für ein sinnvolles Konzept fehlen.

    Würdet Ihr das als zwei Threads (für lesen und fürs schreiben) aufbauen oder kann man das irgendwie schlauer machen?
    Oder ist der Aufwand gar nicht nötig und ich kann es viel einfacher machen?

    Ich schau mir mal erstmal die boost-geschichte an, danke.

    Gruß Jower



  • Boost::Threads sind doch weitestgehend plattformübergreifend, insbesondere Windows und Linux, einsetzbar, oder?



  • Ja, wenn mich nicht alles täuscht auch auf MacOS X, Solaris und andere Unixe.



  • lese thread:
    mit SetCommMask() events setzen die du angeziegt haben willst
    mit WaitComm() + WaitForMultipleObjects() auf events wraten
    wenn was angekommen is --> mit read file lesen --> und das ganze fängrt wieder von vorne an

    schreib thread:
    schreib einfahc wann du willst
    vorraussetung: FILE_FLAG_OVERLAPPED bei createfile angegeben



  • Man kann auch mit SetCommTimeouts() den RS232 Treiber so einstellen, daß ReadFile/WriteFile nicht-blockierend arbeiten. Dann kommt man ohne Threads aus, oder eben OVERLAPPED, wie schon erwähnt.

    Artchi schrieb:

    Und wie immer gilt: die Boost-Library ist Pflicht für jeden C++ Programmierer! ⚠

    Ich hab' mal gehört, daß die beim Build ca. 1GB Plattenplatz verbrät und auch sonst viele Binaries enthält. Das ist ein richtiges Monster, man braucht schon gute Gründe um sich sowas anzutun.



  • Mal gehört... ein Freund von nem Freund meines Onkels hat mal gesagt...

    Alles klar.

    Boost braucht nach dem Build knapp 600 MB, korrekt. Aber es sind dann auch alle DLLs, LIBs sowohl in Release, Debug, MultiThread-Release und MultiThread-Debug vorhanden. Also eigentlich ist es nur 1/4 groß.

    Weiterhin ist Boost modular aufgebaut. Beispiel: Wenn ich nur boost::thread benutze, werden nicht mal 61 KByte verlinkt (so groß ist die boost-thread-LIB)! 61 KByte!!! Hallo??? Was spricht dagegen, wenn die EXE 61 KByte größer wird, wenn ich dafür Multiplatform-Threads habe und mit 1 (einer!) zusätzlichen C++-Zeile in meinem Code Multithreading habe?



  • Artchi schrieb:

    Wenn ich nur boost::thread benutze, werden nicht mal 61 KByte verlinkt! 61 KByte!!! Hallo???

    Was? Unglaublich! Bedenke daß die meisten Systeme auf denen Boost läuft natives Threading kennen und wenn dieser schäbige Boost-Wrapper dafür 61KB verballert ist das echt mies!

    Artchi schrieb:

    wenn ich dafür Multiplatform-Threads habe und mit 1 (einer!) zusätzlichen C++-Zeile in meinem Code Multithreading habe?

    Schon mal was von Zeilenumbrüchen gehört? Manche sollen sowas in ihren Codes verwenden. Probier's aus, der Code wird leserlicher dadurch oder übst du für'n obfuscated C Contest?



  • Bug schrieb:

    Artchi schrieb:

    wenn ich dafür Multiplatform-Threads habe und mit 1 (einer!) zusätzlichen C++-Zeile in meinem Code Multithreading habe?

    Schon mal was von Zeilenumbrüchen gehört? Manche sollen sowas in ihren Codes verwenden. Probier's aus, der Code wird leserlicher dadurch oder übst du für'n obfuscated C Contest?

    Sehr kompetenter Kommentar von dir... <ironie>Man merkt, du hast boost::thread schon mal benutzt.</ironie>

    Das Thema ist für mich hier abgeschlossen.



  • Nun sei nicht gleich angepißt. Um einen Thread zu erzeugen braucht man im einfachsten Fall eine Threadprozedur und einen Aufruf um den Thread zu starten. Du mußt zugeben, daß es blöd aussieht, wenn man das alles in eine Zeile quetscht.


Anmelden zum Antworten