Wenig Ahnung viel Glück



  • Hi,

    seit 40 Jahren arbeitet man mit dem Serialport, und bis zum heutigen Tage gibt es freudige neue Überraschungen.

    Da werden duzende von Geräte erfolgreich unterhalten, und dann kam eines hinzu wo das Serial device das man sich hergelitten hat , nicht mehr funktioniert.

    Schon seiner Zeit hat man dann seine eigene Implementation von Serial open Close write , durch eine aus dem Netz sehr Konforme Version ersetzt.

    Das Master-Example für Serial lautet also :
    https://github.com/eliben/code-for-blog/blob/master/2005/perl_serial_comm/Serial.cpp

    Und alle Probleme waren beseitigt, auch komplexe DTR/RTS Controller konnten nun freudig bedient werden.

    Und niemand muss mehr an dem Serial Device wirken, leider Gottes nur bis zum heutigen Tag, da kommt ein FTI Chip einher, der einen serport bildet, und schwupp.. nun geht das auch nicht mehr, aber der alte Code von 1998 funktioniert damit tadellos.

    Wie kann das Thema Serial endlich begraben werden ?
    Immer neue Exkursionen haben nun mehr einen Quellentext von 1300 Zeilen erreicht.

    Nach Open steigt Write aus weil angeblich ein Overlapped Transfer nicht beendet sei, wartet man 1.5 Sekunden ist das Problem erloschen.

    Dies ist dann bereits das ende der Prüfung wo ein Write scheitert:
    // Make sure the overlapped structure isn't busy
    /_ASSERTE(!m_hevtOverlapped || HasOverlappedIoCompleted(lpOverlapped));

    Kennt jemand diese Probleme ?

    Liebe Grüße aus Preußen
    Karsten


  • Mod

    Bitte kontrolliere mal wie m_hevtOverlapped NULL sein kann.

    Open ohne Overlapped ausgeführt? Oder gar Close ausgeführt und danach den Wait...



  • Achromat schrieb:

    Wie kann das Thema Serial endlich begraben werden ?

    Indem man sich eigenen, funktionierenden Code schreibt anstatt irgendwas aus dem Internetz zu verwenden.
    Alternativ kann man guten funktionierenden Code aus dem Internetz korrekt verwenden.



  • Hallo Martin,

    immer wenn ich nicht mehr weiter weis, schreibe ich Postings, am nächsten Tag jedoch ergründe ich die Probleme 🙂 Da stellt sich heraus das ein, Arduino
    komischerweise genau 2 Sekunden braucht bevor ich nach dem öffnen Daten senden lassen. Obschon alle Signale ok waren kommt, einfach nichts direkt nach Open an. Da muss ich bei diesem FTI Chip genau 2Sek warten, das Programm H-Term kennt das Problem scheinbar nicht.

    Alle meine anderen Serial -Clienten funktionieren ja einwandfrei.

    Aber so ganz Kurscher ist mir das nicht mit dem Master-Serial -Example.

    Da ist noch was nicht 100% IO.. zb bei Close , wenn ich da mit Infinite warten
    würde kommt es nie mehr zurück. Ein 100ms TakeOff wirkte da.

    Nun läuft es erstmal mit dieser 2Sek Pause, ich öffne nämlich ständig 3 unterschiedliche Quellen , und halte sie nicht gleichzeitig offen.. mal sehen.

    Danke für deine Antwort.

    Grüße aus Berlin
    Karsten.


  • Mod

    @hustbaer:

    Der Code ist "eigentlich" gut.
    https://www.codeproject.com/Articles/992/Serial-library-for-C

    Ich vertraue eigentlich mehr den CSerial Code von Naughter
    http://www.naughter.com/serialport.html

    Bei ihm (als MVP Kollege) weiß ich zu 100%, dass er seinen Code auch wirklich weiterpflegt und auch Verbesserungen einbaut...



  • Hallo HustiBätr,

    ja sicher kann man alles selber herleiten, aber man glaubt ja nicht was es bei Serial unter Windows für Spezialfälle gibt. Da kommen Geräte die ohne Signaleventverarbeitung dann doch nicht Funktionieren.

    Ganz Einfach ist das nicht mit dem Serial-gedünst. Bin froh wenn das läuft, habe ja noch hunderte andere Komponenten, da ist man heilfroh wenn man sich auf die meisten verlassen kann, und am wesentlichen wirken darf.

    Da haben es die Leute von Net-Frames und QT bissel einfacher, aber in deren Haut möchte ich nicht stecken hihi..

    Außerdem kommt bald der Osterhase, dann muss alles fertig sein ^^

    Grüße von Fort Hahneberg.
    Karst,


Log in to reply