STM32F7 UART - Parität Problem

[Fabian W. (fabian_w105)]

Hallo zusammen,

ich hab ein kleines Problem mit einem STM32F746BGT µC. Genutzt wird hier 
die CubeIDE mit dem V1.17.3 Firmware Package. Ein älteres Package hat 
das Problem nicht behoben.

Die Anforderung ist eine UART Kommunikation mit 8Bit Daten, Parität 
Gerade, 1 Stop Bit und einer Baudrate von 9600.

Beim STM ist es wohl so, dass man bei einem zusätzlichen Paritätsbit 
eine Datenbereite von 9 Bit einstellen muss. ....Hat leider nichts 
gebracht

Das Signal kommt am µC ordentlich an. Ich hab den Pegel mit dem 
Oszilloskop gemessen und der Logic Analyzer hat auch kein Problem das 
Signal an der Stelle zu dekodieren.

Die Daten die am µC ankommen lese ich per Interrupt ein. Wenn er nicht 
wegen einem Framing Error im HAL_UART_ErrorCallback landet, sondern im 
HAL_UART_RxCpltCallback dann wurde trotzdem nur Müll empfangen.

Hat jemand schonmal ein ähnliches Problem gehabt und hat einen Tipp für 
mich?

Ich hab mal ein paar Bilder aus der Konfiguration angehängt.

Gruß
Fabian

[Karlsson V. (karlsson_vom_dach)]

Fabian W. schrieb:
> und einer Baudrate von 9600.

Passt nicht zusammen mit:
huart7.Init.BaudRate = 19200; (aus Screenshot)

mfg KvD

[Bruno V. (bruno_v)]

Wenn Du ein oszi hast, dann immer probeweise senden (0xaa bzw 0x55).

Und ohne oszi auch, nur dann 0xe0 und am PC ohne parity mitlesen

[Fabian W. (fabian_w105)]

Moin,

>Passt nicht zusammen mit:
>huart7.Init.BaudRate = 19200; (aus Screenshot)


ja, da muss ich dir vollkommen recht geben.
Ist leider im Screenshot falsch.

Ich hatte kurz vorher im Initialisierungs Ablauf ein bisschen mit den 
UART Registern noch rum gespielt. Damit das aber wieder ordentlich ist, 
habe ich den Code Generator nochmal laufen lassen und da war mir wohl 
nicht aufgefallen, dass dort noch die Falsche Baudrate eingestellt war. 
Die hatte ich zuvor händisch angepasst.
Das Empfangen habe ich trotzdem mal mit 19.2k und 9600 probiert. Bei 
beiden Baudraten das selbe problem.

Gruß Fabian

[Harald K. (kirnbichler)]

Warum nur wird Quelltext als Screenshot gepostet? Was soll das?

[Peter D. (peda)]

Harald K. schrieb:
> Warum nur wird Quelltext als Screenshot gepostet?

Damit die Hilfsbereitschaft maximal gebremst wird, weil ihn niemand 
schnell mal eben selber in seiner IDE überprüfen kann.

Am besten solche Anhänge gleich in /dev/null ablegen.

[Georg S. (randy)]

Datenbreite auf 9 bit setzen und Parität selber berechnen?

[Harald K. (kirnbichler)]

Georg S. schrieb:
> Datenbreite auf 9 bit setzen und Parität selber berechnen?

Eine UART, die das braucht, ist Müll. Das konnten UARTs schon vor 50 
Jahren, siehe z.B. Motorola 6850 oder NSC 8250.

[Peter D. (peda)]

Georg S. schrieb:
> Datenbreite auf 9 bit setzen und Parität selber berechnen?

Erzähl mal noch einen vom Pferd.

[Bruno V. (bruno_v)]

Peter D. schrieb:
> Georg S. schrieb:
>> Datenbreite auf 9 bit setzen und Parität selber berechnen?
>
> Erzähl mal noch einen vom Pferd.

Bei Pics (16er, 18er) ist das z.B. so. Georg arbeitet vielleicht weniger 
mit STM.

[Cyblord -. (cyblord)]

Leider können die STM32 tatsächlich kein 9 Bit + Parity. AVRs können 
das.

Nervt mich auch, weil ich (hobbymäßig) JETI Sensoren für den Modellbau 
entwickle und das JETI Protokoll zwingend 9 Bit + Parity braucht. Somit 
kann ich partout nicht auf STM32 gehen.

[Axel R. (axlr)]

Cyblord -. schrieb:
> Leider können die STM32 tatsächlich kein 9 Bit + Parity. AVRs können
> das.

Das ist ja doof, aber brauch er ja hier nicht: 8Bit + Paritiy mit 9K6 
sind gefordert.
Würde ich dann auch auf 8E1 einstellen, nicht auf 9N. Wie, hat Peda ja 
angehangen.
Wenn CubeIDE da Mist baut (kann ja sein), kann man ja die UART-Register 
zur Not auch mal selbst beschrieben? Danach dann vergleichen.

Fabian W. schrieb:
> Die Anforderung ist eine UART Kommunikation mit 8Bit Daten, Parität
> Gerade, 1 Stop Bit und einer Baudrate von 9600.

[Frank K. (fchk)]

Cyblord -. schrieb:
> Leider können die STM32 tatsächlich kein 9 Bit + Parity. AVRs können
> das.
>
> Nervt mich auch, weil ich (hobbymäßig) JETI Sensoren für den Modellbau
> entwickle und das JETI Protokoll zwingend 9 Bit + Parity braucht. Somit
> kann ich partout nicht auf STM32 gehen.

Na und? Nimmste halt ATSAM bzw PIC32C. PIC32C ist ARM, quasi die 
Weiterentwicklung der ATSAM, PIC32M sind die MIPS-basierten Typen.

fchk

[Cyblord -. (cyblord)]

Frank K. schrieb:
> Na und? Nimmste halt ATSAM bzw PIC32C. PIC32C ist ARM, quasi die
> Weiterentwicklung der ATSAM, PIC32M sind die MIPS-basierten Typen.

Ja danke ich weiß was ich nehmen kann, weil ich bereits passende 
Bausteine nehme. Ich würde aber gerne eine einheitliche Sensor Plattform 
auf STM32 machen was nicht geht.
Aber daher weiß ich dass kein STM32 in der von benötigten Klasse 9 Bit + 
Parity bietet.

[Rick (rick)]

Fabian W. schrieb:
> und hat einen Tipp für mich?
Stell doch mal bitte einen Oszi-Screenshot hier ein.
Im Anhang ein Beispiel, wie ich mir das ungefähr vorstelle (ja, hier 
sind die Parameter 8N1 mit 115200 bit/s).

[Fabian W. (fabian_w105)]

Ich hab am Wochenende mal ein paar Sachen durchprobiert und ich denke 
ich habe für mich eine passende Lösung gefunden.

Axel schrieb ja schon
>Wenn CubeIDE da Mist baut (kann ja sein), kann man ja die UART-Register
>zur Not auch mal selbst beschrieben? Danach dann vergleichen.

Ich habe die UART Schnittstelle nun ohne die CubeIDE initialisiert und 
die Kommunikation auch ohne das Framework sondern dann direkt über die 
Register.