UART receive data

[godlyblade (Gast)]

Hallo,

ich habe ein sehr komisches Problem bei der UART Übertragung zwischen 
einem Controller (Kinetis MK10DX128) und einem Regelventil.


Grundsätzlich:
- Es sollen Daten über das UART Modul (1 start  8 Datenbits  2 stop / 
Baudrate 9600baud) gesendet werden.

- Die Daten werden über einen RS485 Treiber auf das Regelventil 
umgesetzt

- Das Regelventil schickt seinerseits eine Antwort

- Die gesendete Antwort wird wieder durch den RS485 Wandler auf UART 
Pegel umgesetzt und im RX Interrupt interpretiert

Soweit so gut. Wenn ich mir die Kommunikation auf einem Logik Analyser 
anschaue passt alles! (siehe Bild)

Wie im Bild zu sehen erwarte ich als erstes Byte 0xF7 danach 0x03 usw...
leider bekomme ich als Ausgabe im Empfangsregisters meines UART 
interrupts immer die Bytes 0xBF, 0x40... Sieht jemand dort ein 
grundsätzliches Problem? Ich habe die Daten bereits mit 
unterschiedlichen UART Modulen ausprobiert und erhalöte immer diese 
Antwort.

Vielen Dank für eure Hilfe!

[Frank B. (f-baer)]

Deine Endianness stimmt nicht, würde ich mal sagen.

[godlyblade (Gast)]

Das habe ich auch schon vermutet. Leider bekomme ich nach dem Wechsel 
von LSB frist zu MSB first auch keine richtigen Ergebnisse!

[Frank B. (f-baer)]

Schicke versuchsweise mal 0x55 und überbrücke RX und TX. Funktioniert 
das?
Baudratenfehler wäre auch nicht völlig auszuschliessen.

[godlyblade (Gast)]

Okay werde ich sofort mal eben ausprobieren!

[godlyblade (Gast)]

Die direkte Verbindung zwischen RxD und TxD funktioniert! (siehe Bild)

[godlyblade (Gast)]

Jetzt habe ich alles wieder auf den Standard umgebaut unt erhalte 
Folgendes Bild! Die Bytes 0x6C und 0x3C passen ja zumindest schonmal... 
als wenn ich ein Startbit nicht detektieren würde...

[Karl H. (kbuchegg)]

Kann es sein, dass deine Baudrate ein kleines bischen daneben liegt?

Wenn ich UART in Betrieb nehme, dann mach ich das gewöhnlich so, dass 
ich erst mal mit einem Terminalprogramm auf einem PC arbeite. Dann lass 
ich den µC senden und im Terminalprogramm sehe ich, ob dort alles so 
ankommt wie es soll. Wenn nicht, dann stimmt was mit der Baudrate nicht.
Dann die Umkehrung: vom PC zum µC und dort auswerten. Ist der 
vorhergehende Schritt absolviert, dann ist diese Umkehrung normalerweise 
kein Problem mehr und dient eigentlich nur noch zu meiner 
Vertrauensbildung.
Dann häng ich das Gerät an den PC und versuch mal, es vom 
Terminalprogramm aus anzusteuern. HTerm mit seiner einfachen 
Möglichkeit, Bytes direkt einzugeben, ist da prädestiniert. Bei diesen 
Spielchen sehe ich auch gleich, ob und wie das Gerät auf Kommandos 
reagiert.
Und dann kommt der grosse Moment: der µC steuert das Gerät direkt an. 
Und im Regelfall klappt das dann nach den Vorversuchen auch auf Anhieb.

Das alles hört sich zwar jetzt nach einem Unweg an, der erst mal Zeit 
kostet. Aber über alles gesehen, hat sich diese Zeit noch immer gelohnt. 
Im Endeffekt war ich damit immer schneller als diejenigen, die sich 
direkt rumgemüht haben und bei Problemen im Nebel gestochert haben.

[godlyblade (Gast)]

Ich habe mir die Kommunikation auch schon über H-Term angeschaut. Das 
hat soweit funktioniert, bisauf das mir aufegafllen ist, dass nicht 
immer die gleiche Anzahl an Bits angekommen ist... das könnte natürlich 
auch an der baud rate liegen... komisch ist nur, dass die Zeichen an 
sich immer stimmen...

[godlyblade (Gast)]

Ich habe das genaz jetzt nochmal mit H-Term aufgenommen und dabei 
festgestellt, dass auch H-Term jedes 20 mal ca. ein 0xBF als erstes 
Zeichen erkennt. Ansonsten wird jedoch wie im Logik analyser ein 0xF7 
erkannt.

Bedeutet das, dass die BAUD rate des Reglers verstellt ist?

[Frank B. (f-baer)]

Der Decoder zeigt eigentlich, dass die Baudrate in Ordnung ist. Was 
passiert denn, wenn du das Ventil direkt mit HTerm ansprichst? Gibt es 
dann auch diese Fehlinterpretationen? Interessant wäre auch das Telegram 
im Decoder, bei dem auch HTerm komische Ergebnisse liefert.

[godlyblade (Gast)]

Problem gelöst!

Der UART RxD Pegel muss auf 3,3V angehoben werden ;)