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