> Damit will ich ausdrücken, daß das Thema "Wie programmiere ich die > serielle Schnittstelle unter Windows in C" in diesem Forum verdammt > oft diskutiert und ausreichend besprochen wurde. Die Forensuchfunktion > sollte helfen. ja eine echt tolle Antwort, nicht falsch, aber auch nicht hilfreich mit blackbird code kann ich ja schon senen und empfangen, aber XON XOFF ist mir total unklar und die Suche brachte nach 4-5 Fundstellen keine Klarheit ich kann zwar dcb.fOutX = 1; dcb.fInX = 1; dcb.XonChar = 17; dcb.XoffChar = 19; einsetzen nur wer kümmert sich darum ich in der Abfrage oder das OS ? muss ich seriell in solange lesen bis ich auf ein XOFF treffe ? und dann mit dem senden aufhören oder wie ? nur setzen reicht nicht, aber XOFF erhalte ich auch nicht zurück, oder liegt es an als Text öffnen das Steuerzeichen unterdrückt werden ? aber CR und LF kommen doch durch ? über Code mit XON XOFF würde ich mich freuen LG jar
hat keiner eine Idee ? bitte XON XOFF ist hier wirklich nicht oft beschrieben.
jar schrieb: > XON XOFF ist hier wirklich nicht oft beschrieben. weil 90% der Leute es nicht brauchen. Meist stellt der PC eine Anfrage und der µC antwortet. Dabei kann man davon ausgehen das der PC mit der Datenmenge die über UART reinkommen kein Problem hat und somit die Datenrate nicht drosseln muss. Wenn man etwas an den µC sendet, dann muss man früher oder später auf eine Bestätigung warten. Ich müsste keine Anwendung wo ich XON XOFF brauchen würde. Warum denkst du das du es brauchst?
Peter II schrieb: > Ich müsste keine Anwendung wo ich XON XOFF brauchen würde. Warum denkst > du das du es brauchst? weil das in der Anleitung vom KWS AMA210s steht und weil ich das Gerät hoffnungslos vom PC überfahre, nur Warteschleifen will ich auch nicht, ich brauche das volle Tempo aber sicher. Der PC gibt das Kommando, das Gerät soll so schnell antworten wie es kann, wann das Gerät die Verarbeitung beendet hat müsste ich ja raten......
jar schrieb: > nur wer kümmert sich darum ich in der Abfrage oder das OS ? Ich würde mal sagen das OS. Wenn man alles per Hand machen müsste, wüsste ich nicht wozu man die Einstellungen überhaupt machen sollte. > > muss ich seriell in solange lesen bis ich auf ein XOFF treffe ? und dann > mit dem senden aufhören oder wie ? Ich hätte angenommen, dass das OS das Senden dann selbst bis zum XON pausiert und Daten erstmal in einer Warteschlange aufsammelt oder WriteFile() mit NumberOfBytesWritten=0 zurückkehrt. > > nur setzen reicht nicht, aber XOFF erhalte ich auch nicht zurück, oder > liegt es an als Text öffnen das Steuerzeichen unterdrückt werden ? aber > CR und LF kommen doch durch ? Da die XON/XOFF Zeichen nicht in den Nutzdaten vorkommen dürfen, würde ich vermuten dass man die niemals lesen wird ;D (An Infos über den aktuellen xon/xoff Status kommt man via ClearCommError()) (Alles geraten, ich hab mit xon/xoff noch nie zu tun gehabt)
bluppdidupp schrieb: > Ich würde mal sagen das OS. Wenn man alles per Hand machen müsste, > wüsste ich nicht wozu man die Einstellungen überhaupt machen sollte. > Ich hätte angenommen, dass das OS das Senden dann selbst bis zum XON > pausiert und Daten erstmal in einer Warteschlange aufsammelt oder > WriteFile() mit NumberOfBytesWritten=0 zurückkehrt. aber dann wäre es doch nicht möglich mehr Zeichen zu senden als das Gerät verträgt, das Gerät würde nie "überfahren" werden, was es aber tut > Da die XON/XOFF Zeichen nicht in den Nutzdaten vorkommen dürfen, würde > ich vermuten dass man die niemals lesen wird ;D > (An Infos über den aktuellen xon/xoff Status kommt man via > ClearCommError()) > (Alles geraten, ich hab mit xon/xoff noch nie zu tun gehabt) kann ich versuchen, was ich bis jetzt weiss, alle Zeichen werden mit erweiterung zurückgegeben, vermutlich muss ich die Rückgabe auf Korrektheit prüfen und dann kann ich weitersenden, oder ich muss den Buffer out verkleinern damit eben nicht zuviel zu schnell gesendet wird ?
Joachim B. schrieb: > aber dann wäre es doch nicht möglich mehr Zeichen zu senden als das > Gerät verträgt, das Gerät würde nie "überfahren" werden, was es aber tut Ich habs gerade einfach mal ausprobiert, Aufbau war: a) COM3 und COM4 sind verbunden b) Software "A" hinter COM3 sendet einfach in Endlosschleife "HALLO" und gibt aus wie lange WriteFile() gedauert hat c) Software "B" hinter COM4 liest einfach alles was rein kommt weg und sendet alle 10s ein XOFF, macht 5s lang nichts und sendet dann ein XON. Ergebnis: Sobald durch "B" ein XOFF gesendet wurde, blockiert WriteFile() in "A" für etwa 5s bis wieder ein XON kommt. Wenn die Gegenstelle zu spät Xoff sendet kann es trotzdem passieren, dass sie "überfahren" wird: Der PC sendet alles was noch in irgendwelchen Puffern (Hardware-Puffer oder ggf. auch Software-Puffern in Treibern) ist raus bevor das XOFF berücksichtigt werden kann.
bluppdidupp schrieb: > Ich habs gerade einfach mal ausprobiert, Aufbau war: > a) COM3 und COM4 sind verbunden > b) Software "A" hinter COM3 sendet einfach in Endlosschleife "HALLO" und > gibt aus wie lange WriteFile() gedauert hat > c) Software "B" hinter COM4 liest einfach alles was rein kommt weg und > sendet alle 10s ein XOFF, macht 5s lang nichts und sendet dann ein XON. > > Ergebnis: > Sobald durch "B" ein XOFF gesendet wurde, blockiert WriteFile() in "A" > für etwa 5s bis wieder ein XON kommt. > > Wenn die Gegenstelle zu spät Xoff sendet kann es trotzdem passieren, > dass sie "überfahren" wird: Der PC sendet alles was noch in > irgendwelchen Puffern (Hardware-Puffer oder ggf. auch Software-Puffern > in Treibern) ist raus bevor das XOFF berücksichtigt werden kann. Klasse, danke das bedeutet aber man müsste nach jedem Zeichen den Status abfragen mehrfach sogar ...... auch nicht toll....
XON XOFF hin oder her das Gerät gibt praktisch den Befehl zurück (mit Zusatz) ich vergleiche den Befehl mit der Rückgabe und wenn das stimmt gehts weiter ist zwar lahm, aber funktioniert ohne weitere Wartezeit vielen Dank
bluppdidupp schrieb: > Der PC sendet alles was noch in > irgendwelchen Puffern (Hardware-Puffer oder ggf. auch Software-Puffern > in Treibern) ist raus bevor das XOFF berücksichtigt werden kann. Das darf nicht sein, wenn der Treiber korrekt arbeitet (im Zweifelsfall werden eben solche Puffer abgeschaltet). Allerdings muss der Empfänger, der ja das Xoff sendet, noch mit weiteren Zeichen rechnen - mit einem sowieso wegen der Zeichenübertragungszeit und ev. auch noch mit 1..2 mehr wegen der Verarbeitungszeit. Praktisch heisst das, der Empfänger sendet zwar nach X Zeichen im Buffer Xoff, bleibt aber weiter empfangsbereit (und X muss kleiner sein als der Buffer). Unterschreitet die Zeichenzahl im Buffer einen bestimmten Wert (weil die Zeichen abgearbeitet wurden), so wird Xon gesendet. Es ist auch recht praktisch, bei leerem Buffer in gewissen Abständen, z.B. 1 Sek, Xon zu senden, dann startet das Protokoll ohne Eingriff. Der Sender ist einfacher: er muss bloss so schnell wie möglich auf Xon und Xoff reagieren. Ich habe schon oft Xon/Xoff Protokolle programmiert für Industriesteuerungen, das funktioniert einfach und zuverlässig und benötigt keine Steuerleitungen. Mir ist auch nicht bekannt, dass das Windows-Protokoll fehlerhaft wäre, meine Geräte haben immer mit DOS und Windows sauber zusammengearbeitet. Gruss Reinhard
Reinhard Kern schrieb: > Ich habe schon oft Xon/Xoff Protokolle programmiert für > Industriesteuerungen, das funktioniert einfach und zuverlässig und > benötigt keine Steuerleitungen. Mir ist auch nicht bekannt, dass das > Windows-Protokoll fehlerhaft wäre, meine Geräte haben immer mit DOS und > Windows sauber zusammengearbeitet. glaub ich ja gerne, ohne Sniffer werde ich nie rausbekommen ob ich einen Fehler mache oder das Gerät.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.