16bit Wert per RS232 senden

[Klaus Kaiser (Gast)]

Hallo,

ich moechte einen 16Bit Wert ueber eine serielle RS232 Verbindung
senden. Ich teile dazu den 16Bit Wert in LSB und MSB und versende die
so gewonnenen 8Bit Werte. Jetzt moechte ich aber auf der
Empfaengerseite gern erkennen, ob es sich bei einem empfangenen 8Bit
Wert um ein das MSB oder das LSB handelt. Wie macht man denn sows?
Irgendwo habe ich gelesen, dass einige UARTs 9 Datenbits senden
koennen, von denen man das eine dann zur Markierung von LSB/MSB nutzen
kann, aber die USARTs in meinem MSP430F1611 scheinen dieses "9N1"
nicht zu beherrschen. Wie also kann man sowas denn sonst noch machen?

Klaus

[Andreas Dörr (ADoerr) (Gast)]

Das einfachste wäre eine feste Reihenfolge, d.h. das erste Byte sind die
oberen 8Bit, das zweite die unteren. Dann kannst Du das in deinem
PC-Programm wieder zusammenbauen.
Eigentlich ist deine Frage arg trivial. Oder gibt's auf der PC-Seite
was besonderes zu beachten, was Du "vergessen" hast uns mitzuteilen?

[Klaus Kaiser (Gast)]

Es koennte beispielsweise sein, dass zwischen Sender und Empfaenger ein
Byte verloren geht. Ich moechte dann erkennen koennen, dass das der
Fall war, und dann feststellen koennen, ob es das MSB oder das LSB war.

[Anton W. (antonwert)]

Nunja ich kann mir schon vorstellen das es nicht trivial ist, denn im
Falle einer Desyncronisation währ's aus mit der 1 MSB - 2 LSB
"Markierung"

Ich selbst hatte in meinen Lösungen bisher ein kleines Protokoll
bestehend aus Startbyte, 1. Byte, 2. Byte, ..., Prüfsumme verwendet.
Kann ich nur empfehlen, wobei mir eben für diesen speziellen Fall noch
die Lösung einfallen würde drei Bytes zu verwenden. Die obersten 2
Bytes könnten dann die "Nummer" beinhalten....

[Ssss S. (sssssss)]

Sende doch einfach zb
0x0A 0x1B 0x2C 0x3D (wenn HI = 0xAB, LO = 0xCD)
Braucht zwar doppelt soviele bytes, wenns aber nicht drauf ankommt
ist es so ganz einfach zu erkennen welches nibble ankommt ;)

Bye, Simon

[mmerten (Gast)]

Alternativ in 3 Byte zerlegen. Gesetztes 8. Bit zeigt den Beginn eines
neuen Datenpaketes an.

[Klaus Kaiser (Gast)]

Die Idee mit 0x0* 0x1* 0x2* 0x3* gefaellt mir gut, das werd ich machen.
Die doppelte Anzahl Bytes ist kein Problem. Wichtig ist mir einzig,
dass ein "Broadcast" reicht, um Daten zu uebermitteln, und dass der
"PC" nicht aus dem "Takt" kommt. Fehlerhaft uebertragene 16Bit
Werte sollen einfach weggeworfen werden

[Anton W. (antonwert)]

wie gesagt, muss auch mit 3 Bytes gehen

[Andreas Dörr (ADoerr) (Gast)]

Euer Pseudoprotokoll birgt aber auch Probleme. Wenn jetzt ein Byte
verloren geht, kann er eventuell auch nicht mehr rückschließen, welches
Byte ihm fehlt (da ja seine Nutzdaten auch die gleiche Bitfolge wie die
Stempelbytes haben können). Bei mehreren Verlusten, verwurschelt dann
das Programm verschieden zugehörige High/Low-Kombinationen. Das würde
nur funktionieren, wenn er definierte Pausen zwischen den Übertragungen
seiner 16-Bit-Pakete hat, anhand er dann sieht, es fehlt was. Dann
reicht aber auch mein obengenannter Ansatz.

Nimm nicht ein ganzes Byte als Preampel, um zu sehen welches das High-
bzw. das Low-Byte ist, sondern nimm z.B. die obersten 4 Bit um zu
erkennen, wohin die unteren 4 Bit in deinem 16-Bit Wert gehören. Kannst
sogar noch 1-2 Paritybits einbauen (oder die 4x2 überschüssigen Bits für
eine Art CRC verwenden). Das ganze liese sich auch mit 3 Byte
realisieren (2 Bit als Preampel und 6 Bit für die Nutzdaten). Das ist
zwar aufwendiger (wenn auch nicht besonders), aber sicherer, als die
oben genannten Vorschläge.

Bis denne, Andreas

[Rahul (Gast)]

Nicht wirklich...
Wenn eins der letzten drei Bytes ausfällt, kann man anhand der
"Nummer" sehen, dass da eigentlich ein anderes hätte kommen müssen,
und dann entweder die Daten neu anfordern oder einfach nur verwerfen.

[Klaus Kaiser (Gast)]

Ich nehme jetzt erstmal den Ansatz mit 4 Bytes. Probleme haette ich da,
wenn 4 Bytes in Folge auf der Seriellen Verbindung verloren gingen
(oder vielfache davon), das ist zwar nich unmoeglich, aber sehr viel
unwahrscheinlicher als der Verlust von einem, zwei oder gar drei bytes
in Folge...

Keine 100%ig sichere Loesung, aber eine wo mir das "Preis
Leistungsverhaeltnis" fuer mein Bastelprojekt ausreicht ;).

[Andreas Dörr (ADoerr) (Gast)]

Naja, meine Lösung lässt sich auch mit sehr wenig Aufwand realisieren:

void sendData(unsigned int nutzdaten)
{
  unsigned char data[4];

  // oberstes Nibble in die unteren 4 Bit verschieben
  // anschließen natürlich Typecast
  data[0] = (unsigned char) (nutzdaten >> 12);
  // oberen 4 Bit als erstes Datenpaket markieren
  data[0] = data[0] | 0x80;

  // das nächste Nibble in die unteren 4 Bit verschieben
  // die obersten Bits müssen ausgeblendet werden
  data[1] = (unsigned char) ((nutzdaten & 0x0F00) >> 8);
  // oberen 4 Bit als erstes Datenpaket markieren
  data[1] = data[1] | 0x40;

  // drittes Nibble in die unteren 4 Bit verschieben
  // (nach dem Typecast)
  data[2] = ((unsigned char) nutzdaten) >> 4);
  // oberen 4 Bit als erstes Datenpaket markieren
  data[2] = data[2] | 0x20;

  // wir brauchen nur die untersten 4 Bit, der rest wird ausmaskiert
  data[3] = (unsigned char) (nutzdaten & 0x000F);
  // oberen 4 Bit als erstes Datenpaket markieren
  data[3] = data[3] | 0x10;

  // hier dann die 4 Bytes verschicken

  return;
}

Ich setz hier jeweils nur eins der 4 Bit im oberen Nibble um zu
erkennen, wohin die nachfolgenden Nutzbits hinmüssen. Hier wird von MSB
nach LSB aufgetrennt.

Vielleicht hilft's (ich hoff ich hab keine Fehler drin, ist nur
trocken gecodet worden, ohne nen Compiler anzuwerfen ;)).

Bis denne, Andreas