cubemx Erfahrungen mit Bugs

[Entwickler (Gast)]

Hallo,

der Code sollte für nucleo-l432kc sein und ich habe mich
beim RX Pin vertan und hab auf PA3 gelegt. Nach Blick in Schematic
sollte es aber PA15 sein. Dabei fiel mir auf, dass der vorherige
Code beide RX und TX als pushpull konfiguriert.

Ich hatte bisher keine Bugs in cubemx gehabt und bei Fehlersuche
mehr auf meine Fehler konzentriert. Wie oft stoplert ihr über Bugs da?
Eher beim HAL oder LL oder beidem? Wo soll man aufpassen?

BUG

  /**USART2 GPIO Configuration
  PA2   ------> USART2_TX
  PA3   ------> USART2_RX
  */
  GPIO_InitStruct.Pin = LL_GPIO_PIN_2|LL_GPIO_PIN_3;
  GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
  GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_VERY_HIGH;
  GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
  GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
  GPIO_InitStruct.Alternate = LL_GPIO_AF_7;
  LL_GPIO_Init(GPIOA, &GPIO_InitStruct);


RICHTIG

  /**USART2 GPIO Configuration
  PA2   ------> USART2_TX
  PA15 (JTDI)   ------> USART2_RX
  */
  GPIO_InitStruct.Pin = LL_GPIO_PIN_2;
  GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
  GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_VERY_HIGH;
  GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
  GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
  GPIO_InitStruct.Alternate = LL_GPIO_AF_7;
  LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

  GPIO_InitStruct.Pin = LL_GPIO_PIN_15;
  GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
  GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_VERY_HIGH;
  GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
  GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
  GPIO_InitStruct.Alternate = LL_GPIO_AF_3;
  LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Gruß,
Entwickler

[Entwickler (Gast)]

ziehe meine Aussage zurück.
Auch hier ist der RX aus pushpull konfiguriert.

Es sind 2 Blöcke wegen
GPIO_InitStruct.Alternate = LL_GPIO_AF_7;
bzw.
GPIO_InitStruct.Alternate = LL_GPIO_AF_3;
angelegt.

habe wieder mehr Vertraunen in cubemx :)

[Ben S. (bensch123)]

Entwickler schrieb:
> habe wieder mehr Vertraunen in cubemx :)

Ich gar keins. Darum programmiere ich auch nur mit CMSIS.

[Frank (Gast)]

Ben S. schrieb:
> Darum programmiere ich auch nur mit CMSIS.

Gibts das noch? ;-)

[Stefan F. (Gast)]

Entwickler schrieb:
> Wie oft stoplert ihr über Bugs da?

Von meinen ersten 4 kleinen Test-Projekten funktionierten drei nicht 
wegen Bugs in dem generierten Code. Seit dem nutze ich die HAL nicht 
mehr. Sie hat mir eh kein gutes Gefühl gegeben, weil so schwer zu 
durchschauen war, wie sie funktioniert. Die Doku dazu ist ja auch sehr 
mager.

Die Application Notes von ST waren mir hingegen eine große Hilfe. 
Besonders bei der fehlerbehafteten I²C Schnittstelle des STM32F1103.

(Die 3 Bugs waren wirklich Bugs, dabei wurde mir hier im Forum zugig 
geholfen).

[Entwickler (Gast)]

Ben S. schrieb:
> Entwickler schrieb:
>> habe wieder mehr Vertraunen in cubemx :)
>
> Ich gar keins. Darum programmiere ich auch nur mit CMSIS.

naja, das ist auch mein Ziel.
Seit PeripheralLib nicht mehr aktualisiert wird, ist LL ein Zwischenweg.
Scheint ein sehr dünner Wrapper über CMSIS zu sein.
Online findet man zu LL und CMSIS wenig Beispiele.
Das war mit ein Grund warum ich beim I2C beim Ansprechen von bme680
mit bsec Library auf HAL gegangen bin.

Wenn man LL nutzt, fällt es auch auf, dass ähnliche Peripherie
zum Teil seltsame Unterschiede aufweist ... z.B. zwischen F3 und L4
wobei beide cortex m4 sind.

Gruß,
Entwickler

[Ben S. (bensch123)]

Entwickler schrieb:
> Online findet man zu LL und CMSIS wenig Beispiele.

Es gibt da von ST mehrere tausend Seiten dicke Handbücher. Das ist für 
mich Dokumentation genug.

[Entwickler (Gast)]

Ben S. schrieb:
> Es gibt dav on ST mehrere tausend Seiten dicke Handbücher. Das ist für
> mich Dokumentation genug.

keine Frage, das Datenblatt und ReferenceManual sind immer im PDF Viewer
offen und liefern wichtige Infos. Was fehlt sind Abläufe, was in welcher
Reihenfolge muss ablaufen. Was ist beim Modewechsel erlaubt und was 
nicht.
Eine Sammlung der Minimalbeispiele wäre auch gut.

[Entwickler (Gast)]

Ben S. schrieb:
> Es gibt da von ST mehrere tausend Seiten dicke Handbücher. Das ist für
> mich Dokumentation genug.

steht in den 1000 Seiten irgendwo warum RX Pin als pushpull konfiguriert 
wird?

[Ben S. (bensch123)]

Entwickler schrieb:
> steht in den 1000 Seiten irgendwo warum RX Pin als pushpull konfiguriert
> wird?

Wer konfiguriert RX als pushpull, die HAL? Wenn ich CMSIS mache 
konfiguriere ich den RX pin so wie ich will - übrigens hat bei einem 
Eingang die Opendrain/pushpull Konfiguration keine Relevanz. Entweder 
schreibe ich mir da eine Funktion oder ein Makro - also eine Zeile und 
das Beinchen ist konfiguriert.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Entwickler schrieb:
> Wenn man LL nutzt, fällt es auch auf, dass ähnliche Peripherie
> zum Teil seltsame Unterschiede aufweist ... z.B. zwischen F3 und L4
> wobei beide cortex m4 sind.

Cortex-M4 ist der CPU kern, als Periph kann man da dann alles mögliche 
ranhämmern.
Der L4 hat eine komplett andere I2C Periph als der F3.
(Vom I2C schreib ich jetzt wegen dem bme680.)
Der I2C im L4 zählt zB autimatisch die gesendeten Bytes für ein 
automatisches stop.
Das ist für DMA durchaus praktisch.

Der LL ist ansonsten nur eine Funktion welche einen Registerzugriff 
"abstrahiert".
Kannst ja mal in die Dateien gucken, da kannste wirklich gleich den 
CMSIS nehmen.
Wobei der CMSIS aus mehreren Layern besteht von Register- und 
Bitdefinitionen bis hoch zu DSP und RTOS.
(Man muss ja nich jede Schicht nutzen)

Entwickler schrieb:
> Was fehlt sind Abläufe, was in welcher
> Reihenfolge muss ablaufen. Was ist beim Modewechsel erlaubt und was
> nicht.

Im Refman gibts doch vor den Registerbeschreibungen ellenlange 
Erklärungen mit Zustandsdiagrammen und Ablaufdiagrammen.
Was fehlt dir denn da genau?


Zum PP beim RX:
Mach doch mal das Refman auf und suche die "Port bit configuration 
table".
Wie du siehst gibts dort kein Alternate Function Input.
Nur "AF PP" und "AF OD" (die Pullupdowns ignorieren wir jetzma)
Der HAL Config struct ist da nur mal wieder missverständlich ausgelegt.

Aus:
GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
ergibt sich dann:
"AF PP"

Ein "AF OD" brauchste dann zB bei I2C.

Steht alles im Refman ;)
Aber ja, das kann einem am Anfang erstmal etwas erschlagen.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Stefan ⛄ F. schrieb im Beitrag #6550575:
> Macht der STM32F3xx auch.

Danke für die Info, dann hatte ich mir da was falsch gemerkt.

[Stefan F. (Gast)]

Mw E. schrieb:
> Danke für die Info, dann hatte ich mir da was falsch gemerkt.

Ich hab's wieder gelöscht weil ich doch nicht ganz sicher bin. Er zählt 
zwar mit aber zumindest in meiner Anwendung setze ich das STOP Flag 
trotzdem "zu Fuß".