Forum: Mikrocontroller und Digitale Elektronik das erste Byte von UART-Paketen mit Hardware erkennen


von Owen S. (senmeis)


Lesenswert?

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

von ich (Gast)


Lesenswert?

RX Complete Interrupt ?

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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.

von Jörg S. (joerg-s)


Lesenswert?

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

von Detlev T. (detlevt)


Lesenswert?

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.

von Owen S. (senmeis)


Lesenswert?

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

von H.Joachim S. (crazyhorse)


Lesenswert?

Du hast einen Fehler in deinem Programm.
Zeile 42.

von Ralf (Gast)


Lesenswert?

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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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

von Jörg S. (joerg-s)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Detlev T. (detlevt)


Lesenswert?

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.

von A. F. (artur-f) Benutzerseite


Lesenswert?

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

von gast (Gast)


Lesenswert?

Stichwort ist Präambel und Startbyte.

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

Wie gesagt: AVRs unterstützen den MPCM mit 9 Datenbits.

von Owen S. (senmeis)


Lesenswert?

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

von Tubie (Gast)


Lesenswert?

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

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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

von Tubie (Gast)


Lesenswert?

@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
Noch kein Account? Hier anmelden.