STM32F7 UART - Parität Problem

Fabian W. schrieb:

und einer Baudrate von 9600.

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

mfg KvD

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

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

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

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.

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

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.

Georg S. schrieb:

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

Erzähl mal noch einen vom Pferd.

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.

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.

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.

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

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.

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

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.