UART Übertragungsfehler bei bestimmten Zahlenwerten

[Thomas F. (thomas_f923)]

Hallo!

Ich benötige eine UART Datenübertragung zwischen uC (STM32G031K6T6) und 
meinem Windows Rechner. Dazu habe ich ein cpp Programm geschrieben 
welches einen 16 Bit Wert aufteilt in ein höherwertiges und ein 
niederwertiges Byte. Diese werden beide über UART an den PC gesendet. Um 
am PC eine Struktur zu erkennen, werden zwischendurch bestimmte Zeichen 
übertragen.
Nur leider werden manche Zahlen nicht korrekt übermittelt, sondern an 
stelle dieser einfach der Wert 63 (sechs aufeinanderfolgende 1-Bits).

STM32 MDK Arm Code:
char input,output;
bool test = 0;
bool change = 0;
uint32_t run = 0;
uint16_t tx_value = 12340;

void Task1(uint32_t T_ms){
  
  output = NULL;
  if (run==1) tx_value=0b0000010100000101;
  //else if(run==2)tx_value='a';
  /*else if(run<=26)
  {
    if(change==0){
    tx_value = ((run << 8) | (run+1));
    }
    else tx_value = 'n';
    run++;
  } */
  else if(run==2) {
    tx_value = 'a';
  }
  else if(run==3) {
    tx_value = (1872);
    }
  else if(run==4) {
    tx_value = 'n';
    }
  else if(run==5) {
    tx_value = (1234);
    }
  else if(run==6) {
    tx_value = 'n';
    }
  else if(run==7) {
    tx_value = (50);
  }  
  else if(run==8) {
    tx_value = 'n';
    }
  else if(run==9) {
    tx_value = (255);
  }  
  else {
    tx_value = 'z';
    run=0;
  }
  
  send16Bit(tx_value);
  run++;
  
}
uint8_t lower_byte;
uint8_t upper_byte;

  void send16Bit(uint16_t data) {
  lower_byte = data & 0xFF;
  upper_byte =  data >> 8;//(data >> 8) & 0xFF;
  sendByte(lower_byte);
  sendByte(upper_byte);
}
  
void sendByte(uint8_t data) {
  while (!(USART1->ISR & (1<<7)));  // warten, bis Übertragungsbuffers bereit ist
  USART1->TDR = data;  // Daten in Übertragungsbuffer schreiben
}

C# Consolen Anwendung zum Auswerten der Daten:

 SerialPort port = new SerialPort("COM8", 115200, Parity.Odd, 8, StopBits.One);
            port.Open();
            UInt16 value = '0';
            string output = "", output_csv="";
            UInt16 lowByte = 0;
            UInt16 highByte = 0;
            UInt16 rx_value = 0;
            string state = "waiting";
            Int32 run_csv = 0;

            while (run_csv < 1)
            {

                rx_value = Convert.ToByte(port.ReadChar());
                if (rx_value == 0b101)
                {
                    Console.WriteLine("Init Byte received");
                    output = "";
                    state = "lowByte";
                }
                else if (state == "lowByte")
                {
                    lowByte = rx_value;
                    state = "highByte";
                }
                else if (state == "highByte")
                {
                    highByte = rx_value;
                    value = (UInt16)((highByte << 8) | lowByte); //zusammensetzen von low und highByte

                    Console.WriteLine("highByte: {0} \tlowByte: {1}\tvalue: {2}",highByte,lowByte,value);

                    if (value == 'a')
                    {
                        output += "New: ";
                        Console.WriteLine("a erkannt");
                    }
                    else if (value != 'z')
                    {
                        Console.WriteLine("kein z erkannt");
                        if (value == 'n')
                        {
                            Console.WriteLine("n erkannt");
                            output += " Next:";
                            output_csv += ";";
                        }

                        else
                        {
                            Console.WriteLine("neue Zahl erkannt erkannt");
                            output += value + ";";
                            output_csv += value;
                        }
                    }
                    else if (value == 'z')
                    {
                        Console.WriteLine("\n z erkannt");
                        output += " Done!";
                        Console.WriteLine(output);
                        output_csv += "\n";
                        run_csv++;
                    }
                    state = "lowByte";
                    lowByte = 0;
                    highByte = 0;
                }                
            }
            port.Close();
            Console.WriteLine("output_csv:");
            Console.WriteLine(output_csv);

            
            Console.ReadKey();

        }

Die Ausgabe auf der Konsole sieht wie folgt aus (Bild im Anhang):
Der zweite Zahlenwert sollte wie aus dem cpp Programm zu entnehmen 1234 
(highByte 4, lowByte 210) sein, jedoch ist dieser 1087 ((highByte 4, 
lowByte 63).
Ähnliches beim letzten Wert 255.

Bitte um Hilfe und herzlichen Dank im Voraus!

[Purzel H. (hacky)]

Etwas wie ein Protokoll duerft's schon sein. Auf einem Tisch, dh 
zwischen Board und PC sollte man ja schon keine Uebertragungsfehler 
auflesen. Kann aber dank EMV trotzdem geschehen. Und wie unterscheidest 
du dann low byte und high byte ?

[mitlesa (Gast)]

Thomas F. schrieb:
> Nur leider werden manche Zahlen nicht korrekt übermittelt

Da frage ich mich sofort ob denn die Baudrate ausreichend genau
stimmt. Wenn man im Controller einen internen Oszillator als
Zeitbasis verwendet kann das schon mal schiefgehen.

[PittyJ (Gast)]

Ich schliesse dann immer ein Scope an, und schaue, was wirklich auf der 
Leitung versendet wird.
Dann braucht man nur im Sender oder nur im Empfänger schauen.

Odd parity soll so sein? Ich lass die immer weg.

[mitlesa (Gast)]

Thomas F. schrieb:
> C# Consolen Anwendung zum Auswerten der Daten:

Bitte Anhang lesen, verstehen, verinnerlichen und danach handeln.
"Längerer Sourcecode" ist es wenn man dauernd scrollen muss um
alles zu sehen.

[Thomas F. (thomas_f923)]

Purzel H. schrieb:
> Etwas wie ein Protokoll duerft's schon sein. Auf einem Tisch, dh
> zwischen Board und PC sollte man ja schon keine Uebertragungsfehler
> auflesen. Kann aber dank EMV trotzdem geschehen. Und wie unterscheidest
> du dann low byte und high byte ?

Übertragungsfehler habe ich bereits ausgeschlossen, der Fehler passiert 
nur bei manchen bestimmten Zahlenwerten. Ich habe schon >1000 
Übertragungen ohne Fehler hintereinander, wenn ich eben nicht die paar 
besonderen Werte übertrage.

[mitlesa (Gast)]

Thomas F. schrieb:
> Übertragungsfehler habe ich bereits ausgeschlossen

Na und? Sicherlich sind bei grösseren Baudraten-Abweichungen nicht
alle Bytes gleichmässig von Übertragungsfehlern betroffen.

[Thomas F. (thomas_f923)]

PittyJ schrieb:
> Ich schliesse dann immer ein Scope an, und schaue, was wirklich auf der
> Leitung versendet wird.
> Dann braucht man nur im Sender oder nur im Empfänger schauen.
>
> Odd parity soll so sein? Ich lass die immer weg.

Odd parity hab ich dann aus Verzweiflung probiert, normal mach ichs auch 
ohne.
Zugang zu einem Osci habe ich aktuell leider nicht.

[mitlesa (Gast)]

Thomas F. schrieb:
> tx_value = 'z';

Was erwartest du denn beim Empfänger wenn du einen Character
über eine Funktion sendest die 16 Bit überträgt?

Thomas F. schrieb:
> void send16Bit(uint16_t data) {

[S. Landolt (Gast)]

Wäre nett bzw. zuvorkommend gewesen, Soll- und Istwerte direkt 
gegenüberzustellen, damit die Angesprochenen sich das nicht erst 
zusammensuchen müssen.

Kann es sein, dass Werte größer 127 schiefgehen - irgendwas mit 
7-bit-Übertragung?

[Thomas F. (thomas_f923)]

S. Landolt schrieb:
> Kann es sein, dass Werte größer 127 schiefgehen - irgendwas mit
> 7-bit-Übertragung?

Hab es grad getestet und scheint so korrekt zu sein, die 8 Bit Werte 
125, 126 und 127 werden korrekt übertragen. Ab 128 ist es lediglich 63.
Weiß jemand woran das liegen könnte?
Im Bild im Anhang ist meine uC UART Konfiguration zu sehen.
So sieht die Empfängerseite Port Config aus:

SerialPort port = new SerialPort("COM8", 115200, Parity.Odd, 8, StopBits.One);

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas F. schrieb:
> Zugang zu einem Osci habe ich aktuell leider nicht.
Irgendwo hatte ich schon wiederholt mal was zur Inbetriebnahme von 
seriellen Schnittstellen geschrieben.

Habs wieder gefunden, dort war es:
* Beitrag "Re: Atmega Uart - Falsche Byte Übertragung"
* Beitrag "Re: WS2812b flackern / 3600 LED Matrix"

Fazit: kauf dir wenigstens einen 10€ Logic-Analyzer, dann bist du 
wenigstens nicht mehr völlig blind.

Thomas F. schrieb:
> Nur leider werden manche Zahlen nicht korrekt übermittelt, sondern an
> stelle dieser einfach der Wert 63 (sechs aufeinanderfolgende 1-Bits).
Da wird wohl fälschlicherweise ein Startbit erkannt.

mitlesa schrieb:
> Was erwartest du denn beim Empfänger wenn du einen Character
> über eine Funktion sendest die 16 Bit überträgt?
Hast du den Code dieser Funktion mit ihren beiden *sendByte()* auch 
schon angeschaut?

Thomas F. schrieb:
> Bild_2023-02-08_125144747.png
Text bitte **nicht** als Bild posten.

Wenn die Formatierung wichtig ist, dann gibt es (wie in den Zeilen über 
jeder Textbox hier beschrieben) die [pre] Tags:
https://www.mikrocontroller.net/articles/Formatierung_im_Forum

[S. Landolt (Gast)]

Da das 8. Bit als letztes übertragen wird: vielleicht doch abweichende 
Geschwindigkeiten, wie von mitlesa in seiner ersten Antwort vermutet.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas F. schrieb:
> Ab 128 ist es lediglich 63.
> Weiß jemand woran das liegen könnte?
Da gibt es mehrere Ansätze: du kannst mangels eines Oszis/LA nur den 
einen probieren und kontrollieren, was der Compiler da tatsächlich ins 
TX-Register schreibt. Nicht, dass das ein trivialer 
singed/unsigned-Effekt ist.

Nimm mal für den Test einfache Bitmuster wie 0x55aa und 0xaa55 und 
0xcc33 oder so...

[Frank M. (ukw) (Moderator)]

Thomas F. schrieb:
> [Low Byte & High-Byte]...
> Diese werden beide über UART an den PC gesendet.

Sobald ein kleiner Übertragungsfehler passiert, wird der PC das 
nachfolgende High-Byte als Low-Byte (und umgekehrt) interpretieren. Du 
hast keine Chance, dass die beiden überhaupt noch einmal zueinander 
finden - außer durch einen weiteren Übertragungsfehler.

Von daher ist Dein Konzept unbrauchbar. Ich empfehle, die beiden zu 
übertragenen Bytes in einen gesicherten, eindeutigen Frame zu betten, 
z.B. durch ETX, STX und Checksum, wobei ETX und STX selbst innerhalb des 
Frames "escaped" werden.

Andere (einfachere) Möglichkeit: Du verteilst die 16 Bit auf 3 oder 4 
Bytes (24 bit oder 32 bit), wobei Du die höherwertigen Bits als Index 
benutzt z.B. so:

01XXXXXX
100XXXXX
110XXXXX

Durch Plausibilitätsprüfungen lassen sich Übertragungsfehler zumindest 
erkennen, aber nicht ausmerzen.

[Peter D. (peda)]

Du brauchst ein richtiges Protokoll und nicht was selber ausgedachtes 
und ungeprüftes.
Daten müssen sich eindeutig von Steuercodes unterscheiden lassen, auch 
bei Synchronisationsverlust. Eine CRC zur Fehlererkennung ist heutzutage 
auch Standard.

[Frank M. (ukw) (Moderator)]

Lothar M. schrieb:
> Nimm mal für den Test einfache Bitmuster wie 0x55aa und 0xaa55 und
> 0xcc33 oder so...

Eventuell ist es auch sinnvoll, auf der Senderseite die Anzahl der 
Stoppbits auf 1.5 oder 2 zu erhöhen. Dann werden bei andauernder 
Befeuerung ohne irgendeine Pause die einzelnen Bytes auf Empfängerseite 
eher als solche erkannt.

[Thomas F. (thomas_f923)]

Peter D. schrieb:
> Du brauchst ein richtiges Protokoll und nicht was selber ausgedachtes
> und ungeprüftes.
> Daten müssen sich eindeutig von Steuercodes unterscheiden lassen, auch
> bei Synchronisationsverlust. Eine CRC zur Fehlererkennung ist heutzutage
> auch Standard.

Bevor ich ein vernünftiges Protokoll implementiere, benötige ich erstmal 
eine funktionierende Schnittstelle.

Lothar M. schrieb:
> Nicht, dass das ein trivialer
> singed/unsigned-Effekt ist.

Scheint tatsächlich so zu sein.
Da ich kein Osci zur verfügung habe, habe ich einen Arduino Nano 
parallel an de Schnittstelle gehängt und mitprotokolliert.
Hier sind die Daten korrekt (siehe Bild im Anhang).
Hier hatte ich anfangs auch eigenartige Werte, teils mit minus. Durch 
Verwendung von unsigned jedoch nicht mehr.

Arduino Code:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(2, 3); // RX, TX

void setup() {
  Serial.begin(115200);
  mySerial.begin(115200);
}

void loop() {
  if (mySerial.available()) {
    unsigned int i = mySerial.read();
    if (i == 'a' || i == 'n' || i == 'z') {
      Serial.println((char)i);
    } else {
      Serial.println(i);
    }
  }
}

Also liegt das Problem an der Empfängerseite, jedoch finde ich nicht an 
welcher Stelle sich der Fehler verbergen könnte.

[Max M. (Gast)]

Thomas F. schrieb:
> Bevor ich ein vernünftiges Protokoll implementiere, benötige ich erstmal
> eine funktionierende Schnittstelle.
Mit der Schnittstelle ist alles in Ordnung.

Der Takt + max Fehler bei 115Kbps beim STM32 ist unklar.
Da kein Protokoll vorhanden ist sondern nur ein undurchdachter Wust der 
fullspeed Daten raushaut, fliegt es Dir eben auseinander.

Funktioniert es bei 9600bps?

[Thomas F. (thomas_f923)]

So danke für die Hilfe an alle.
Es lag nicht an falschen werten die übermittelt wurden, der einzige 
Fehler war die Verwendung der Funktion

rx_value = Convert.ToByte(port.ReadChar())

in meinem C# Programm.
Wenn ich

Convert.ToByte(ReadChar())

 durch

Convert.ToByte(ReadByte())

 ersetze funktionert es einwandfrei.

Anscheinend macht die Funktion Convert.ToByte etwas seltsames mit allen 
Char werten über 127.
Convert.ToByte ist trotz der verwendung von ReadByte noch notwendig, 
aber dann funktionierts.

Danke für eure mithilfe!

[S. Landolt (Gast)]

> Problem an der Empfängerseite

Yô - was für ein Programm liefert denn die eingangs gezeigte Ausgabe? 
Oder habe ich etwas überlesen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas F. schrieb:
> etwas seltsames mit allen Char werten über 127.
Es kommt drauf an, wie char definiert ist. Es ist nicht völlig abwegig, 
dass das ein signed 8-Bit-Wert ist:

https://www.google.com/search?q=char+signed+unsigned

BTW: Mein Tipp mit dem 10€ Logicanalyzer gilt weiterhin  ;-)

[S. Landolt (Gast)]

Wäre in diesem Fall also ein simples Terminalprogramm ein geeigneter 
Logik-Analysator gewesen.

Übrigens - fand ich lustig (s. 3. Bedeutung):

> Nicht, dass das ein trivialer singed/unsigned-Effekt ist.

[Steve van de Grens (roehrmond)]

Convert.ToByte(char)

Unterstützt Unicode Zeichen als Eingabe, kann aber nur 8 Bit breite 
Zeichen konvertieren. Siehe 
https://learn.microsoft.com/de-de/dotnet/api/system.convert.tobyte?view=net-7.0#system-convert-tobyte(system-char)

Außerdem überträgst du 16 Bit Zahlen die sicher nicht alle einem 16 Bit 
Unicode Zeichen entsprechen. Siehe
https://learn.microsoft.com/de-de/dotnet/api/system.io.binaryreader.readchar?view=net-7.0
https://learn.microsoft.com/de-de/dotnet/api/system.char?view=net-7.0

Deswegen bringt ReadByte() anstelle von ReadChar() die Lösung.