www.mikrocontroller.net

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


Autor: Owen Senmeis (senmeis)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RX Complete Interrupt ?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Owen Senmeis (senmeis)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast einen Fehler in deinem Programm.
Zeile 42.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: A. F. (artur-f) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stichwort ist Präambel und Startbyte.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt: AVRs unterstützen den MPCM mit 9 Datenbits.

Autor: Owen Senmeis (senmeis)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.