Verständnissfrage zu WinAPI (serial comm)
-
Ach so ja jetzt leuchtet es mir ein, super danke.
eine andere Frage:
Kann ich zuerst Senden und erst nachher die Funktion zum lesen aufrufen?
Weil soein Scenario kann ja auch vorkommen.Habe es mal getestet, aber wenn ich zuerst sende, und nachher mit WaitCommEvent() auf das erscheinen eines Bytes im RX Buffer der COMM Schn. warte, wartet er sich einen Wolf, obwohl ja sicherlich was drinne sein muss.
-
Kann ich zuerst Senden und erst nachher die Funktion zum lesen aufrufen?
Natürlich.
Wenn es sein muß kannst Du sogar beide Aktionen gleichzeitig ausführen, also gleichzeitig senden und empfangen. Das nennt man auch Vollduplex-Modus.
ergo -> Halbduplex ist somit nur senden oder nur empfangen zur gleichen Zeit.Das bedeutet allgemein, Du mußt mit Deiner Software (genauer Software-Struktur) dafür sorgen, daß die Reihenfolge Senden/Empfangen eingehalten wird.
Du kannst aber auch z.B. nur fürs Empfangen einen eigenen Thread, und fürs Senden einen anderen Thread erzeugen. Und die Threads kommunizieren miteinander.
Martin
P.S.: Wenn wir schon bei diesem Thema sind: Versuche Deine Software so zu schreiben, daß sie auch mit unerwünschten und unerwartet empfangenen Bytes klarkommt. Z.B. wenn Du das Kabel abziehst, könnte das Kontaktprellen dummerweise als "ein weiteres Byte angekommen" interpretiert werden!
Auch EMV ist mit verantwortlich dafür: Z.B. wenn nicht gerade gesendet wird, können die Treiber hochohmig werden, dann wirkt die Schnittstellenleitung als eine Antenne für alle möglichen Störungen
-
Hi,. theoretisch stimmt das mit dem EMV, die meisten erhältlichen treiber sind doch aber kapazitiv gegengekoppelt und haben nen EMV schutz wodurch ich nie fehlerhafte info's über die schnittstelle erhalten habe trotz rund +-3% offizieller fehlerquote,... falls die angst fehlerhafter daten z.b. ADC bestimmter sensoren doch zu groß ist sollte man selber ein protokoll schreiben bzw. die daten mit korrekturterm codieren,...(CRC mit error reply und folgender wiederholung der sendung währ vlt. am schnellsten zu machen),...
naja,. a bissl senf und ketchup
-
Wenn es sein muß kannst Du sogar beide Aktionen gleichzeitig ausführen, also gleichzeitig senden und empfangen. Das nennt man auch Vollduplex-Modus.
ergo -> Halbduplex ist somit nur senden oder nur empfangen zur gleichen Zeit.Also für mich wäre Vollduplex, wenn beide Threads gleichzeitig senden und empfangen können. Ob das über die RS232 möglich ist, ich weis nicht?
Aber wieso ist es bei mir so, dass wenn ich gesendet habe und der Leser erst nachher aufgerufen wird, wartet er als ob nichts im Buffer wäre. Bei mir muss zuerst der Leser aufgerufen werden, und er dann kann ihm etwas gesendet werden.
Du kannst aber auch z.B. nur fürs Empfangen einen eigenen Thread, und fürs Senden einen anderen Thread erzeugen. Und die Threads kommunizieren miteinander.
Und wie gebe ich den Thread meine zu sendenden Bytes mit?
Danke sehr
Übrigens habe ein CRC zu dem gesamten Datenstrom, von daher wird das schon irgendwie klappen.
-
JDHawk schrieb:
Also für mich wäre Vollduplex, wenn beide Threads gleichzeitig senden und empfangen können. Ob das über die RS232 möglich ist, ich weis nicht?
Klar, RS232 hat ja fürs Senden und fürs Empfangen je eine eigene Leitung (TxD und RxD).
Wichtig ist nur zu wissen, ob Deine Gegenstelle (sei es ein PC oder irgendein Gerät) auch Vollduplex unterstützt.
Damit keine Mißverständnisse auftreten, der Vollständigkeit halber: Für RS232 gibt es verschiedene Sonder-Übertragungslösungen, z.B. RS232-auf-RS485- oder RS232-auf-LWL-Umsetzer (LWL=Lichtwellenleiter), manche (meist billigere) können nur Halbduplex arbeiten! In diesem Fall bringt auch die Vollduplex-Fähigkeit Deiner Gegenstelle logischerweise nichts.JDHawk schrieb:
Aber wieso ist es bei mir so, dass wenn ich gesendet habe und der Leser erst nachher aufgerufen wird, wartet er als ob nichts im Buffer wäre. Bei mir muss zuerst der Leser aufgerufen werden, und er dann kann ihm etwas gesendet werden.
Das liegt (vermute ich zumindestens) wahrscheinlich nur an Deiner Software. Versuche mal im ersten Schritt nur den Empfänger zu programmieren und zu testen (so mehrere Byte-Pakete übertragen, kommen alle Bytes in Dein Buffer fehlerfrei an? usw.). Dann nur den Sender zu programmieren und testen. Und als Krönung dann beide Funktionen zu "verschmelzen".
JDHawk schrieb:
Und wie gebe ich den Thread meine zu sendenden Bytes mit?
Du kannst Threads über Nachrichten steuern und über Nachrichten auch (einzelne) Bytes übertragen. Bei mehreren Bytes bieten sich global deklarierte Buffer (idealerweise Sende- und Empfangsbuffer getrennt, bei Vollduplex sowieso!) an. (Es ist klar, daß z.B. das Hauptprogramm mit dem Senden weiterer Daten solange warten muß, bis der Sende-Thread mit den letzten Daten fertig ist
)Martin
P.S.: "Serial Communications in Win32" http://msdn2.microsoft.com/en-us/library/ms810467.aspx, der Artikel beschreibt multithreaded RS232-Kommunikation mit Synchronisation untereinander sehr gut. Hoffentlich ist er nicht eine zu hohe Hürde für Dich? Auch ich mußte damals selbst erst ein paarmal durchlesen und vor allem ausprobieren, ausprobieren
-
zeusosc schrieb:
Hi,. theoretisch stimmt das mit dem EMV, die meisten erhältlichen treiber sind doch aber kapazitiv gegengekoppelt und haben nen EMV schutz wodurch ich nie fehlerhafte info's über die schnittstelle erhalten habe trotz rund +-3% offizieller fehlerquote,... falls die angst fehlerhafter daten z.b. ADC bestimmter sensoren doch zu groß ist sollte man selber ein protokoll schreiben bzw. die daten mit korrekturterm codieren,...(CRC mit error reply und folgender wiederholung der sendung währ vlt. am schnellsten zu machen),...
Hallo zeusosc, ich kann Dein Posting nicht so unkommentiert lassen, da ich vermeiden möchte, daß andere Forenleser (die die Hardware-Schaltungstechnik vielleicht nicht im Blut haben) die Informationen falsch interpretieren könnten.
Ich habe das so interpretiert:
zeusosc schrieb:
die meisten erhältlichen treiber sind doch aber kapazitiv gegengekoppelt
Nein! (jedenfalls nicht die meisten handelsüblichen Pegelwandler a la MAX232 oder die Kombination MC1488/1498 sowie ihre unzähligen moderneren Nachfolger).
zeusosc schrieb:
...und haben nen EMV schutz wodurch ich nie fehlerhafte info's über die schnittstelle erhalten habe
Es freut mich, daß Du "nie fehlerhafte Infos erhältst", aber Du wiegelst Dich in falscher Sicherheit.
Die (etwas teureren) RS232-Treiber haben integrierten ESD-Schutz bis +/-16kV. Sie schützen aber nur den Baustein selbst vor elektrostatischer Beschädigung, i.d.R. durch transiente Suppressor-Dioden oder vergleichbare Techniken.
Das aber wiederum heißt nicht, daß sie fehlerhafte Infos auf den Datenleitungen verhindern! Beispiel: Eine ESD-Störung von, sagen wir mal, positive +10kV auf einer Leitung (oder Steckerleiste) wird vom Empfänger als +12V interpretiert (durch Begrenzung der Suppressor-Dioden), selbst wenn der Sender -12V auf die Leitung gelegt hat -> also Daten werden manipuliert, selbst wenn es nur ein einziges Bit ist!
Das gleiche Szenario passiert auch bei EMV-Einkopplungen, den sog. Bursts. Nur haben die Bursts i.d.R. niedrigere Störpotentiale und weniger eingekoppelte Energiebeträge als dies bei ESD der Fall ist.
Der Vollständigkeit halber: ESD ("Discharge") gibts als Luft- und als Kontakt-Entladungen (i.d.R durch Berührungen mit bloßen Händen), EMV ("Bursts") sind grundsätzlich leitungsgebundene Störeinkopplungen (Leitungen funktionieren also als Antenne für externe Störfrequenzen).zeusosc schrieb:
...trotz rund +-3% offizieller fehlerquote,...
Das hat nichts mit den elektrischen Spannungen auf den RS232-Leitungen zu tun.
Eine Fehlerquote (Abweichung) von +/-3% dürfen die Baudraten (und auch die Taktgeber, von der die Baudraten abgeleitet werden) zwischen Sender und Empfänger voneinander haben, damit eine Kommunikation gerade noch möglich ist.
Unsere praktische Erfahrungen zeigen daß die 3% unzuverlässig sind, wir selbst setzen mit 1% an, das einzuhalten ist mit Quarztechnik heutzutage überhaupt kein Problem. Lediglich bei µC (Mikrocontrollern) mit RC-Oszillatoren (aus Kostengründen) sind Streuungen im Bereich 2% bis 5% üblich, je nach Hersteller und Typ.zeusosc schrieb:
Hi,. theoretisch stimmt das mit dem EMV...
Glaub mir, die Berücksichtigung von EMV (und auch ESD) ist keine theoretische Floskel, sondern praktische Pflicht in meinem professionellen Arbeitsumfeld (embedded Systeme). Wir treiben einen nicht unerheblichen Aufwand um unsere Geräte (Hard- und Software) nach VDE- bzw. EN-Normen zu testen und qualifizieren.
zeusosc schrieb:
falls die angst fehlerhafter daten z.b. ADC bestimmter sensoren doch zu groß ist sollte man selber ein protokoll schreiben bzw. die daten mit korrekturterm codieren,...(CRC mit error reply und folgender wiederholung der sendung währ vlt. am schnellsten zu machen),...
Das ist absolut lobenswert!
So ein Ansatz sollte sich jeder zu Herzen nehmen, der was mit Datenübertragung zu tun hat (egal ob über RS232, Ethernet, Funk, ... )Martin
P.S.: Diese Infos sollen auf keinen Fall den Eindruck vermitteln, daß es auf den Leitungen nur so von Störungen und statischen Entladungen wimmeln. Diese kommen in Privathaushalten normalerweise nur sporadisch vor! Im industriellen Bereich (Büroarbeitsplätze sind nicht Industrie!) sieht es schon ein bisschen heftiger aus...
-
Hi mmacher,..
mal ne andere frage: welche schnittstelle verwendet ihr am häufigsten zur multi µC Communication??
Sei gegrüßt,..
-
Überwiegend RS485 und LON, im Wirkungsbereich Gebäudeautomation.
Ein wenig auch EIB.Bei uns ist somit automatisch "multi µC Communication" zwischen den einzelnen Komponenten gegeben
.RS232 und USB verwenden wir eigentlich nur zum Anschluß an PC's
Und selbst?
Auch nen schönen Gruß zurück :xmas1: ,
Martin
-
Naja,.. SPI, TWI (I2C) und ich bin gerade dabei mir mal Multimaster USART anzugucken,.. wir arbeiten hauptsächlich mit ATMEL avr's, ich habe hier aber auch noch n' arm und c51 rumliegen,...
Sag denn müsstest du ja auch www.mikrocontroller.net bzw. ulrich radig kennen??
sei gegrüßt
-
So langsam ists schon Off-topic...
Ja, externe Peripherie innerhalb einer Leiterplatte (embedded Systeme) mit I2C und SPI (z.B. EEPROM, A/D-Wandler, aber auch PIC als Co-Prozessoren) ist auch unser Standard-Arbeitsprogramm.Bei geräteübergreifender Kommunikation über RS485 verwenden wir die integrierten UARTs von 8051- und ARM7-µC.
Eigentlich müßte ich dem seriellen Wahn(-sinn) verfallen sein
Ulrich Radig und www.mikrocontroller.net habe ich schon paarmal gelesen, aber kennen tu ich ihn nicht so wirklich.
Martin