Servus, ich möchte zwei Mikrocontroller über UART direkt verbinden lassen. In beiden Richtungen bestehen UART-Pakete jeweils aus zwei Bytes. Die Anforderung ist, die UART-Schnittstellen müssen das erste Byte irgendwie erkennen. Ich habe viele Artikel gelesen und bin der Meibung, dass die Hardware-Datenflusskontrolle lediglich Datenverluste vermeidet und das erste Byte nicht erkennen kann. Gibt's Methoden, die Mitteilung des ersten Byte per Hardware zu schaffen? Ciao Senmeis
Wenn Du AVRs verwendest, kannst Du das 9. Bit im Datenframe als Startmarkierung nutzen. Beim ersten Byte setzt Du das 9. Bit, bei allen anderen Bytes löschst Du es. Nennt sich auch Multiprozessor-Kommunikations-Modus (MPCM).
Ich kann mir nicht vorstellen, dass der Verlust des ersten Bytes jeder UART / RS232 Übertragung normal und allgemein akzeptierte Praxis ist. Verwechselst du das vielleicht mit dem Thema "Aufwecken des µCs, wenn die serielle Leitung aktiv wird und dann rasch auf UART-Empfang gehen"? DAS kann problematisch sein, weil das Startbit den µC wecken muss und die die Hardware UART so schnell hochgefahren werden muss, dass sie das gleiche Bit noch als Startbit für das erste zu empfangene Byte mitbekommt.
>Ich kann mir nicht vorstellen, dass der Verlust des ersten Bytes jeder >UART / RS232 Übertragung normal und allgemein akzeptierte Praxis ist. Glaub ich auch nicht. Alle meine bisherigen Projekte mit UART empfangen Problemlos das erste Byte. Auch im Low Power Mode (MSP430) ist das kein Problem. Kostet halt mehr Strom wenn der UART komplett läuft.
Welche Hardware-Datenflusskontrolle meinst du denn? Solche Sachen wie RTS/CTS wird AFAIK nicht durch die Hardware unterstützt. Das läuft über Software. Wie man die Signale dann dort interpretiert, kann man durch die Programmierung festlegen. Du solltest dir aber einmal überlegen, ob SPI (ggf I²C) da nicht eine bessere Alternative wäre.
Der Controller bzw. die UART-Schnittstelle ist immer aktiv. Ich moechte nur diesen folgenden Fehler vermeiden: Aus irgendwelchen Gruenden wird das erste Byte im Paket zerstoert und dies fuerht dazu, dass alle nachfolgende Bytes falsch intepretiert werden da der Empfaenger weiss nicht, welches Byte der Anfang des Pakets ist. Die Hardwareflusskontrolle mit RTS/CTS ist nicht dafuer gedacht. Noch Hinweise? Gruss Senmeis
Du hast einen Fehler in deinem Programm. Zeile 42.
Hi, > Ich moechte nur diesen folgenden Fehler vermeiden: Aus irgendwelchen > Gruenden wird das erste Byte im Paket zerstoert und dies fuerht dazu, dass > alle nachfolgende Bytes falsch intepretiert werden da der Empfaenger weiss > nicht, welches Byte der Anfang des Pakets ist. Die Hardwareflusskontrolle > mit RTS/CTS ist nicht dafuer gedacht. Dann musst du m.E. anhand des Protokolls dafür sorgen, dass solche Fehler erkannt werden. Typischerweise wird dann z.B. als erstes Byte die Gesamtsumme aller Bytes des Transfers gesendet. Zusätzlich wird am Schluss eine Checksumme des Kommandos mitgesendet. Auf diese Art kannst du erkennen, ob ein Byte fehlt bzw. die Transaktion fehlerhaft war, und du kannst neu synchronisieren, z.B. über ein Timeout, oder du startest jeden Transfer mit einem speziellen Byte. Ralf
>Aus irgendwelchen Gruenden wird >das erste Byte im Paket zerstoert und dies fuerht dazu, dass alle >nachfolgende >Bytes falsch intepretiert werden Schreit nach einem Programmfehler - poste doch mal Deinen Code.
>Ich moechte nur diesen folgenden Fehler vermeiden: Aus irgendwelchen >Gruenden wird das erste Byte im Paket zerstoert und dies fuerht dazu, >dass alle nachfolgende Bytes falsch intepretiert werden Und was machst du wenn nicht das Erste sondern das Zweite Byte falsch ankommt? Wie schon geschrieben wurde solltest du eine Checksumme o.ä. implementieren.
Owen Senmeis wrote: > Der Controller bzw. die UART-Schnittstelle ist immer aktiv. Ich moechte > nur diesen folgenden Fehler vermeiden: Aus irgendwelchen Gruenden wird > das erste Byte im Paket zerstoert Das erste Byte ist nicht anfälliger als alle anderen. Allerdings sollte man schon dafür sorgen, daß wenn jemand über die leitung stolpert und den Stecker zieht, die Kommunikation selbsttätig wieder aufgenommen werden kann. Das heißt, Du brauchst ein Protokoll, an dem der Empfänger eindeutig erkennen kann, wann ein neues Datenpaket beginnt. Und auch erkennen kann, wann ein Datenpaket unvollständig oder fehlerhaft ist, um es zu verwerfen und vielleicht den Fehler zurückmeldet. Peter
Wenn du keine Möglichkeit hast, dies über eine separate Datenleitung zu steuern, muss die Information im Datenstrom stecken. Entweder mit dem bereits erwähnten neunten Bit, was aber nicht jeder µC unterstützt. Oder durch Codes, die sonst nicht im Strom vorkommen können. Brauchst du alle 256 Werte? Wenn ja, wäre folgende Kodierung möglich: *0xFF kündigt das nachfolgende erste Byte an *0xFE bewirkt, dass das nachfolgende Byte um zwei erhöht wird. Die Werte 0xFF und 0xFE muss man dann, wenn sie auftreten, in zwei Bytes kodieren: 0xFE 0xFD beziehungsweise 0xFE 0xFC. Alternativ kann man die Daten generell auf drei Bytes aufteilen. z.B. jeweils 7Bit+Parity. Die Daten stecken dann in den untersten 6 Bits, das siebte ist nur beim ersten Byte gesetzt.
> Der Controller bzw. die UART-Schnittstelle ist immer aktiv. Ich moechte > nur diesen folgenden Fehler vermeiden: Aus irgendwelchen Gruenden wird > das erste Byte im Paket zerstoert Ist es etwa eine 0x03?
Ich habe Artikel über den MPCM gelesen. Es geht eigentlich um Master-Slave-Kommunikation. Die Frage ist, ob es asynchrone Kommunikation in beiden Richtungen lässt, wie in UART üblich ist? MfG Senmeis
Ich habe es in meinem Projekt so gelöst, das der Master das Senden immer mit $03 beginnnt. Anschließend wird der Datenstrom im HEX Format übermittelt: $03, "00","010203040FFF","FF", $04 Start,ID, Daten, ,Checksumme,Ende Die Anzahl der Bytes selbst steckt in ID(Paket Typ). Eine Sendung beginnt immer mit $03 und endet mit $04 werden dazwischen Zeichen außerhalb von 0-F empfangen, so wird das gesamte Paket verworfen. Stimmt die Checksumme nicht, wird das Paket verworfen. Kommt $04 nicht oder zu früh -> verwerfen. Kommt kein $04 wird nach Timeout verworfen. Beim verwerfen bekommt der Master keine Antwort und das Paket im nächsten Durchlauf erneut gesendet. Gruß, Tubie
>Ich habe Artikel über den MPCM gelesen. Es geht eigentlich um >Master-Slave-Kommunikation. Die Frage ist, ob es asynchrone >Kommunikation in beiden Richtungen lässt, wie in UART üblich ist? Ja natürlich. Es geht einzig darum, den Frame-Start zu erkennen, sprich in dem Fall die Adresse des Slaves. Wie Du nun Dein übergeordnetes Protokoll schreibst, ist Dir überlassen. Selbstverständlich kann man über Befehle auch Multimasterbetrieb erreichen, allerdings muß dann die Hardware etwas anders gestaltet werden -> alle an eine Leitung mit PullUp und RX -|<|- (Diode) TX zusammenschalten. @Tubie: über ASCII-HEX macht man die erreichbare Datenrate um mindestens den Faktor 2 kleiner.
@Travel Rec. Ist aber in meinem Fall absolut unwichtig, da die meiste Zeit eh durch das warten auf eine Antwort drauf geht. Ich fahre mit 9600 Baud und die Tatsächliche Datenrate liegt irgendwo zwischen 2500-3500. Ist halt ein Bussystem für eine Heizungssteuerung und das ist ja eh alles recht träge und Zeit unkritisch. Gruß, Tubie
Bitte 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.