STM32G431: LPUART1 Baudrate?

Lies mal LPUART1->BRR aus. Stimmt der Wert? Gebe den 170 MHz noch den Postfix U, damit auch wirklich als unsigned gerechnet wird. GDB zumindest macht da einen Unterschied: $8 = 0x452c5 (gdb) p /x ((170000000U/16 << 8)) / 9600 $9 = 0x452c5 (gdb) p /x ((170000000/16 << 8)) / 9600 $10 = 0xfffd7f25

Uwe B. schrieb:

Lies mal LPUART1->BRR aus. Stimmt der Wert?

Ich lese aus dem BRR 283333 zurück. Das sollte doch richtig sein?

Ein HAL Code ist in wenigen Minuten erstellt und den kann man sich als Referenz ansehen. Darin werden die Limits geprüft, die CR richtig gesetzt was man evtl. aus mehreren Stellen des DB zusammensuchen muss. Es wird auch die tatsächliche Tatkquelle für die Berechnung benutzt, nicht einfach angenommen des es die 170 MHz sind. Wenn man auf das alles verzichten möchte, dann ist halt Fehlersuchen angesagt.

J. S. schrieb:

Ein HAL Code ist in wenigen Minuten erstellt und den kann man sich als Referenz ansehen. Darin werden die Limits geprüft, die CR richtig gesetzt was man evtl. aus mehreren Stellen des DB zusammensuchen muss. Es wird auch die tatsächliche Tatkquelle für die Berechnung benutzt, nicht einfach angenommen des es die 170 MHz sind. Wenn man auf das alles verzichten möchte, dann ist halt Fehlersuchen angesagt.

Super nutzlose Antwort!

vielleicht ist deine Ansicht einfach nur superignorant? Wenn du alles besser weißt, warum fragst du dann hier?

J. S. schrieb:

vielleicht ist deine Ansicht einfach nur superignorant? Wenn du alles besser weißt, warum fragst du dann hier?

Lies den Eingangspost: da steht eine sehr konkrete Frage mit tatsächlichem Code. Wenn Du darauf keine Antwort weißt, dann bleib einfach ruhig und spare Dir solche Hinweise, die explizit nicht gefragt waren!

Die Auflösung:

1

  LPUART1->PRESC = 0x0111; // presc: 16

muss natürlich

1

  LPUART1->PRESC = 0b0111; // presc: 16

heißen.

Randy B. schrieb:

Die Auflösung:

[...]

Solche Tippfehler sind extrem fies. Da liest man leider sehr schnell drüber.

Allerdings: spätestens, wenn man den Code im Debugger durchsteppt und nach jedem Schreibvorgang in ein SFIOR kontrolliert, ob da das erwartete drinsteht, sollte sich das Problem offenbaren.

Nunja, hat es ja wohl letztlich auch.

Randy B. schrieb:

uint32_t clock = 170'000'000;

Welcher Compiler übersetzt das eigentlich?

Harald K. schrieb:

Randy B. schrieb:

uint32_t clock = 170'000'000;

Welcher Compiler übersetzt das eigentlich?

GCC

Ach ja?

1

main.c: In function ‘main’:

2

main.c:15:26: warning: multi-character character constant [-Wmultichar]

3

   15 |     uint32_t  clock = 170'000'000;

4

      |                          ^~~~~

5

main.c:15:26: error: expected ‘,’ or ‘;’ before '\x303030'

Harald K. schrieb:

Ach ja?

1

> main.c: In function ‘main’:

2

> main.c:15:26: warning: multi-character character constant [-Wmultichar]

3

>    15 |     uint32_t  clock = 170'000'000;

4

>       |                          ^~~~~

5

> main.c:15:26: error: expected ‘,’ or ‘;’ before '\x303030'

6

>

@Harald gebs auf! Mit ignoranten Klugscheissern, die ihren Ansatz für den einzig Wahren halten, diskutiert man nicht! Die läßt man vor die Wand laufen.

Harald K. schrieb:

Ach ja?

Ja.

Als C muss Du auf C2x schalten, in C++ geht das ab C++14.

Harry L. schrieb:

Mit ignoranten Klugscheissern, die ihren Ansatz für den einzig Wahren halten, diskutiert man nicht!

Habe ich behauptet, das mein Ansatz der einzig wahre ist?

Blödsinn, es war eine simple Frage zu einem recht simplen Problem, und es hat sich ja auch herausgestellt, dass die Lösung dafür simpel war.

Aber leider hast Du das gar nicht bemerkt! Und leider hast Du auch gar nicht bemerkt, dass er obige Code C++ war.