das erste Byte von UART-Paketen mit Hardware erkennen

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.

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

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

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