mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 läuft mit Debugger schneller als er soll


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die LED an PC13 blitzt wie erwartet im Sekundentakt.

Aber wenn ich das Programm mit dem Debugger ausführe, blitzt sie 
schneller (0,75 Sekunden). Woran kann das liegen?

Das Programm wurde mit der Option -O0 compiliert.

Hardware:
Dieses minimale STM32F303CCT6 Board
https://robotdyn.com/stm32f303cct6-256-kb-flash-stm32-arm-cortexr-m4-mini-system-dev-board-3326a9dd-3c19-11e9-910a-901b0ebb3621.html
Als Debugger nutze ich die SW4STM32 in Kombination mit einem originalen 
ST-Link v2.1

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das ITM_Print schneller wenn der Debugger dran ist? Nimm das mal 
raus.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist das ITM_Print schneller wenn der Debugger dran ist?
> Nimm das mal raus.

Habe ich probiert, das macht keinen Unterschied.

Wenn ich als Taktquelle HSI 8 MHz oder HSE 8Mhz anstelle der PLL nutze, 
tritt der Effekt nicht auf.

Ich habe inzwischen diverse PLL Multiplier durchprobiert. Der einzige, 
bei dem der Effekt nicht auftritt ist 9x (=72 MHz).

: Bearbeitet durch User
Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Effekt tritt in einem von CubeMX generiertem Projekt (bei 48Mhz) 
nicht auf. Irgendwas muss in meinen wenigen in SystemInit() falsch sein. 
Kann mir jemand helfen, diese Funktion zu überprüfen?

Autor: Rätsel Rater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Irgendwas muss in meinen wenigen in SystemInit() falsch sein.

Muss doch nicht.

Vielleicht fummelt dein Debugger (also der Teil der im PC
läuft) in den Controller-Registern rum und keiner weiss es?

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rätsel Rater schrieb:
> Vielleicht fummelt dein Debugger (also der Teil der im PC
> läuft) in den Controller-Registern rum und keiner weiss es?

Aber müsste der Fehler dann nicht ebenso in dem Cube-HAL Projekt 
auftreten?

Ich habe gerade mal den HSI Oszillator anstelle von HSE mit PLL x6 
verwendet. Das tritt das Problem auch auf. Ein Problem mit dem Quart 
kann ich damit wohl auch ausschließen.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Weil ich den China-Produkten nicht traue, habe ich das Ganze jetzt mit 
einem anderen Board (Nucleo64 STM32F303RET6) wiederholt.

Das Problem tritt auch dort auf. Die LED blinkt wieder alle 0,75 
Sekunden anstatt jede Sekunde, wenn ich den Debugger benutze.

Es ist also definitiv kein Hardwarefehler.

Ich habe den Vollständigkeit halber den Quelltext für den STM32F303RE 
angehängt. Ist im Prinzip identisch, nur die Trace Meldungen habe ich 
dieses mal weg gelassen.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Irgendwas muss in meinen wenigen in SystemInit() falsch sein

Fehlt da nicht am Ende das Warten auf das Umschalten des Takts auf die 
PLL? Vielleicht ein paar DSB einstreuen?

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Fehlt da nicht am Ende das Warten auf das Umschalten des Takts auf die
> PLL? Vielleicht ein paar DSB einstreuen?

Meinst du das?:
> // Wait until PLL is ready
> while(!READ_BIT(RCC->CR, RCC_CR_PLLRDY)) {}

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Meinst du das?:

Nein, das Umschalten danach braucht IIRC auch noch eine Warteschleife.

Hier ein funktionierender Code für F103:
https://github.com/Erlkoenig90/f1usb/blob/master/sys/clockconf.c

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Hier ein funktionierender Code für F103

Vielen Dank, das habe ich direkt ausprobiert. Leider bleibt mein Problem 
bestehen. Um es noch weiter einzugrenzen, habe die Verwendung des 
Systemtimers raus geschmissen und stattdessen Warteschleifen 
programmiert.

Die funktionieren auch wie gewünscht ohne Debugger, aber mit Debugger 
läuft er wieder deutlich zu schnell.


Mein Quelltext sieht inzwischen so aus:
#include <stdint.h>
#include "stm32f3xx.h"

// delay loop without using a timer
// for 48MHz, Latency 1, gcc optimizer enabled
void delay_ms(uint32_t msec)
{
    for (uint32_t j=0; j<6000UL*msec; j++)
    {
        __NOP();
    }
}

// Change system clock to 48 MHz using 8 MHz crystal
// Called by Assembler startup code
void SystemInit(void)
{
    // Flash latency 1 wait state
    MODIFY_REG(FLASH->ACR, FLASH_ACR_LATENCY, FLASH_ACR_LATENCY_0);

    // Enable HSE oscillator
    SET_BIT(RCC->CR, RCC_CR_HSEON);

    // Wait until HSE oscillator is ready
    while(!READ_BIT(RCC->CR, RCC_CR_HSERDY)) {}

    // 48 MHz using the 8 MHz HSE oscillator with 6x PLL, lowspeed I/O runs at 24 MHz
    WRITE_REG(RCC->CFGR, RCC_CFGR_SWS_HSE + RCC_CFGR_PLLSRC_HSE_PREDIV + RCC_CFGR_PLLMUL6 + RCC_CFGR_PPRE1_DIV2);

    // Enable PLL
    SET_BIT(RCC->CR, RCC_CR_PLLON);

    // Wait until PLL is ready
    while(!READ_BIT(RCC->CR, RCC_CR_PLLRDY)) {}

    // Select PLL as clock source
    MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_CFGR_SW_PLL);

    // Wait until PLL is active
    while ((RCC->CFGR & RCC_CFGR_SWS_Msk) != RCC_CFGR_SWS_1) __NOP ();
}


int main(void)
{
    // Enable Port A
    SET_BIT(RCC->AHBENR, RCC_AHBENR_GPIOAEN);

    // PA5 = Output
    MODIFY_REG(GPIOA->MODER, GPIO_MODER_MODER5, GPIO_MODER_MODER5_0);

    while (1)
    {
        // LED On (High)
        WRITE_REG(GPIOA->BSRR, GPIO_BSRR_BS_5);
        delay_ms(100);

        // LED Off (Low)
        WRITE_REG(GPIOA->BSRR, GPIO_BSRR_BR_5);
        delay_ms(900);
    }
}

Ich habe inzwischen den gcc Optimizer eingeschaltet. Das beeinflusst 
natürlich die Geschwindigkeit der Warteschleife, aber ändert nichts an 
meinem Problem.

: Bearbeitet durch User
Autor: Dennis R. (dennis_r93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeig mal dein Debug initialisierungsscript.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dennis R. schrieb:
> Zeig mal dein Debug initialisierungsscript.

Gerne, siehe Anhang. Ich habe gleich noch ein paar andere Dateien 
angehängt, die vielleicht nützlich sein könnten.

Das ist für mich ein richtig schräges Rätsel. Mein Code stimmt ziemlich 
mit dem Beispiel auf 
https://github.com/cjheath/stm32f3-discovery-basic-template/blob/master/src/system_stm32f30x.c 
überein. Ich habe nur ein paar oder-Verknüpfungen mit Konstanten 
weggelassen, die den Wert 0 haben (RCC_CFGR_HPRE_DIV1 und 
RCC_CFGR_PPRE2_DIV1).

: Bearbeitet durch User
Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt Sachen, die gibt's gar nicht. Aber Dennis R. hat mich in die 
richtige Richtung geführt.

Und zwar habe ich jetzt die STM32 Cube IDE heruntergeladen und siehe da: 
Das Problem ist weg!

Zurück in die System Workbench: Problem ist wieder da.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du verwendest openocd?

schau mal in die targets/stm32f3x.cfg:
proc stm32f3x_default_reset_init {} {
        # Configure PLL to boost clock to HSI x 8 (64 MHz)
        mww 0x40021004 0x00380400   ;# RCC_CFGR = PLLMUL[3:1] | PPRE1[2]
        mmw 0x40021000 0x01000000 0 ;# RCC_CR |= PLLON
        mww 0x40022000 0x00000012   ;# FLASH_ACR = PRFTBE | LATENCY[1]
        sleep 10                    ;# Wait for PLL to lock
        mmw 0x40021004 0x00000002 0 ;# RCC_CFGR |= SW[1]

        # Boost JTAG frequency
        adapter_khz 8000
}

vielleicht tut das was ungutes.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die RCC-Register kann man sich ja ansehen, steht da das drin was 
drinstehen soll? Gibts Unterschiede zwischen dem 1s und 0.75s Blinker?

Autor: Dennis R. (dennis_r93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefanus,

Das ist sehr komisch. Mir selber ist so ein Verhalten noch nie 
vorgekommen.

Dein Script sieht unauffällig aus, aber ich kenne die Inlcudes nicht.
Ich selber kenne nur die Keil Scripte.

Ich gehe davon aus, dass der Inhalt vom Flash beides mal der gleiche 
ist.
Ist das Blinken nur dann schneller wenn der Debugger Aktiviert ist oder 
reicht es schon den Debugger einfach nur mit dem Board zu verbinden?

Hast du ein Osziloskop zur Hand? Dann könntest du mit an einem Pin den 
Systemtakt ausgeben und mit dem Osziloskop erkennen was los ist.

Der ITM hat i.d.r. einen Puffer. D.h. wenn du ein mal Pro sekunde
4 Buchstaben schreibst dann sollte das keine 
Geschwindigkeitsauswirkungen haben.

Kannst du den ITM Port Lesen ohne den Kern zu debuggen?
Dafür müsstest du die ITM Ausgabe in deinem Init Script aktivieren.

Edit:

Ok, ihr scheint das Problem gefunden zu haben :-)

: Bearbeitet durch User
Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennis R. schrieb:
> Ist das Blinken nur dann schneller wenn der Debugger Aktiviert ist
Ja

> Dann könntest du mit an einem Pin den Systemtakt ausgeben
> und mit dem Osziloskop erkennen was los ist.

Nicht nötig, denn ich habe ja schon anhand der delay() Schleife bemerkt, 
dass der Systemtakt genau um Faktor 1,5 zu schnell ist.

> Kannst du den ITM Port Lesen ohne den Kern zu debuggen?

Ich weiß nicht, wie man das macht.

rµ schrieb:
> schau mal in die targets/stm32f3x.cfg:
> # Configure PLL to boost clock to HSI x 8 (64 MHz)
> vielleicht tut das was ungutes.

Das passt exakt zur falschen Blink-Frequenz, die ich sehe.

> Die RCC-Register kann man sich ja ansehen

Nicht in der System Workbench, wo der Fehler auftritt. Aber du hast mich 
auf eine Idee gebracht. Da gibt es ein paar Bits in den RCC Registern, 
die man nur umstellen darf, wenn die PLL deaktiviert ist. Wenn jetzt der 
Debugger die PLL auf 64 MHz einstellt, ist mein Programm vielleicht 
genau deswegen nicht imstande, sie auf 48 Mhz umzustellen.

Die ST Cube IDE benutzt was anderes als openocd, das könnte erklären, 
warum das Problem mit der Cube IDE richtig läuft.

Ihr seid echt super, jetzt habe ich einen Ansatzpunkt, mit dem ich 
arbeiten kann. Vielen Dank!

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab's ausprobiert. Das war es wirklich. Ich musste zwei Zeilen 
einfügen, um zunächst die PLL zu deaktivieren, bevor ich sie 
umkonfigurieren. Da wäre ich ohne eure Hilfe never ever drauf gekommen.
// Change system clock to 48Mhz using 8Mhz crystal
// Called by Assembler startup code
void SystemInit(void)
{
    // First disable PLL just in case it was enabled by the debugger
    MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_CFGR_SW_HSI);
    while ((RCC->CFGR & RCC_CFGR_SWS_Msk) != RCC_CFGR_SWS_HSI) {}
    CLEAR_BIT(RCC->CR, RCC_CR_PLLON);

    // Flash latency 1 wait state
    MODIFY_REG(FLASH->ACR, FLASH_ACR_LATENCY, FLASH_ACR_LATENCY_0);

    // Enable HSE oscillator
    SET_BIT(RCC->CR, RCC_CR_HSEON);

    // Wait until HSE oscillator is ready
    while(!READ_BIT(RCC->CR, RCC_CR_HSERDY)) {}

    // 48Mhz using the 8Mhz HSE oscillator with 6x PLL, lowspeed I/O runs at 24Mhz
    WRITE_REG(RCC->CFGR, RCC_CFGR_SWS_HSI + RCC_CFGR_PLLSRC_HSE_PREDIV + RCC_CFGR_PLLMUL6 + RCC_CFGR_PPRE1_DIV2);

    // Enable PLL
    SET_BIT(RCC->CR, RCC_CR_PLLON);

    // Wait until PLL is ready
    while(!READ_BIT(RCC->CR, RCC_CR_PLLRDY)) {}

    // Select PLL as clock source
    MODIFY_REG(RCC->CFGR, RCC_CFGR_SW, RCC_CFGR_SW_PLL);

    // Set USB prescaler to 1, skip in case of 72 MHz
    MODIFY_REG(RCC->CFGR, RCC_CFGR_USBPRE, RCC_CFGR_USBPRE);

    // Update variable
    SystemCoreClock=48000000;
}

: Bearbeitet durch User
Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur so als Anmerkung zum Abschluss (das Problem ist ja gelöst)

Stefanus F. schrieb:
>> Die RCC-Register kann man sich ja ansehen
>
> Nicht in der System Workbench, wo der Fehler auftritt.

Ich meinte damit, dass sich das Register auslesen lässt, sogar gefahrlos 
und ohne Nebeneffekt. Das muss ja nicht der Debugger machen, das 
Programm kann selber nachschaun was da drin steht.

OpenOCD kann man auch per telnet kontaktieren und mit den 
Memory-Befehlen kann man auch Register auslesen (mrw oder so).

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein interessanter Nachtrag:
Beim STM32F103 tritt das Problem nicht auf. Ich füge die Zeile jetzt 
aber trotzdem in meine Mustervorlage ein. Ist sicherer.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
rµ schrieb:
> du verwendest openocd?
>
 proc stm32f3x_default_reset_init {} {
>         # Configure PLL to boost clock to HSI x 8 (64 MHz)
> }

Wie krank ist das denn? Sag' bitte, dass das optional ist. Wer denkt 
sich sowas aus? Ist der Herr Poettering jetzt auch im embedded Bereich 
unterwegs?
Mit irgendeinem zufälligen, unbekannten Takt funktioniert doch kaum ein 
Programm. Außer, man treibt einigen zusätzlichen Aufwand, z.B.

Stefanus F. schrieb:
> Ich hab's ausprobiert. Das war es wirklich. Ich musste zwei Zeilen
> einfügen, um zunächst die PLL zu deaktivieren, bevor ich sie
> umkonfigurieren.

> Ich füge die Zeile jetzt aber trotzdem in meine Mustervorlage ein.
> Ist sicherer.

Das ist natürlich richtig, zum *um*-konfigurieren braucht man das, aber 
doch nicht nach einem Reset. Konsequenterweise müsste man bei jedem init 
davon ausgehen, dass alle Register zufällige Werte enthalten. Es gibt 
aber einzelne Bits die man nur einmal schreiben kann...

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> rµ schrieb:
>> du verwendest openocd?
>> proc stm32f3x_default_reset_init {} {
>>         # Configure PLL to boost clock to HSI x 8 (64 MHz)
>> }
> Wie krank ist das denn? Sag' bitte, dass das optional ist. Wer denkt
> sich sowas aus? Ist der Herr Poettering jetzt auch im embedded Bereich
> unterwegs?
> Mit irgendeinem zufälligen, unbekannten Takt funktioniert doch kaum ein
> Programm. Außer, man treibt einigen zusätzlichen Aufwand, z.B.

Ich habs nicht ausprobiert oder genauer untersucht ob das immer 
zuschlägt oder nur manchmal. Dass so Debugger in den Registern 
herumfuhrwerken und alles mögliche konfigurieren, damit muss man rechnen 
IMHO. Kommt ja eh komplett mit Quellen.

Zufällig ist der Takt sicher nicht, der interne Oszillator der F3 ist 
immer 8MHz, mal 8 ergibt immmer 64MHz, und das vertragen die MCUs der F3 
Baureihe auch.

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ein interessanter Nachtrag:
> Beim STM32F103 tritt das Problem nicht auf. Ich füge die Zeile jetzt
> aber trotzdem in meine Mustervorlage ein. Ist sicherer.

Naja, openocd verwendet beim F103 ja auch ein anderes 
Initialisierungsskript.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
rµ schrieb:
> Zufällig ist der Takt sicher nicht, der interne Oszillator der F3 ist
> immer 8MHz, mal 8 ergibt immmer 64MHz

Für mein Programm ist der Takt zufällig. Vielleicht wird der Faktor 
morgen, oder für einen STM32F105, von 8 auf 4 geändert. Und was ist, 
wenn mein Programm mit dem HSI-Takt zufrieden ist und die PLL nicht 
braucht? Erwarten die wirklich, dass meine UART-Initialisierung die 
PLL-Konfiguration dekodiert und die Baudrate danach einstellt?

Und wie viele ähnliche Überraschungen sind da noch versteckt? Pfuscht 
der vielleicht nicht nur nach einem Reset dazwischen?

Gibt es irgendeine Erklärung, warum man sowas macht? ARM hat die 
SWD-Mimik ziemlich transparent gemacht, der Debugger könnte viel machen 
ohne das Programm zu beeinflussen. Und dann sowas?

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> rµ schrieb:
>> Zufällig ist der Takt sicher nicht, der interne Oszillator der F3 ist
>> immer 8MHz, mal 8 ergibt immmer 64MHz
>
> Für mein Programm ist der Takt zufällig. Vielleicht wird der Faktor
> morgen, oder für einen STM32F105, von 8 auf 4 geändert. Und was ist,
> wenn mein Programm mit dem HSI-Takt zufrieden ist und die PLL nicht
> braucht?

Dein Programm muss so oder so neu übersetzt werden wenns von F3 auf F1 
geht. Das openocd-script ist für die F3 gedacht und wird nur für diese 
verwendet.

> Erwarten die wirklich, dass meine UART-Initialisierung die
> PLL-Konfiguration dekodiert und die Baudrate danach einstellt?

Ja. Jeder vernünftige Baudraten-Kalkulator macht das auch so. Abgesehen 
davon gilt es nicht nur den CPU-Takt zu berücksichtigen, sondern 
vielmehr den Takt des jeweiligen Bus' an dem fraglicher UART hängt, das 
kann man bei dem STMs ja teilweise recht flexibel konfigurieren. Wer 
würde schon so eine engstirnige UART-Initialisierung schreiben, die nur 
mit genau einem Fall umgehen kann, und vielleicht den zweiten UART gar 
nicht bedienen kann, weil der am anderen nur halb so schnellen Bus 
hängt?

> Und wie viele ähnliche Überraschungen sind da noch versteckt? Pfuscht
> der vielleicht nicht nur nach einem Reset dazwischen?

Was im OpenOCD sonst noch versteckt ist weiss ich nicht, aber ich hab in 
meine Scripts schon Sachen eingebaut die z.B. die DBGMCU Register so 
ändern, dass die Timer während einem Break stehenbleiben (oder auch 
nicht, je nach dem).

> Gibt es irgendeine Erklärung, warum man sowas macht? ARM hat die
> SWD-Mimik ziemlich transparent gemacht, der Debugger könnte viel machen
> ohne das Programm zu beeinflussen. Und dann sowas?

Offenbar war es irgendwem mit 1MHz zu langsam, und laut Kommentar soll 
der JTAG-Takt maximal 1/6 des CPU-Takts sein.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Wer denkt sich sowas aus?

Einer, der die Chips mit OpenOCD flashen will.
Das dauert bei 1 MHz sehr lange, debuggen ebenfalls.

Autor: Bauform B. (bauformb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rµ schrieb:
>> Erwarten die wirklich, dass meine UART-Initialisierung die
>> PLL-Konfiguration dekodiert und die Baudrate danach einstellt?
>
> Ja. Jeder vernünftige Baudraten-Kalkulator macht das auch so. Abgesehen
> davon gilt es nicht nur den CPU-Takt zu berücksichtigen, sondern
> vielmehr den Takt des jeweiligen Bus' an dem fraglicher UART hängt, das
> kann man bei dem STMs ja teilweise recht flexibel konfigurieren. Wer
> würde schon so eine engstirnige UART-Initialisierung schreiben, die nur
> mit genau einem Fall umgehen kann, und vielleicht den zweiten UART gar
> nicht bedienen kann, weil der am anderen nur halb so schnellen Bus
> hängt?

na gut, die UARTs auf dem aktuellen Chip wird man wohl alle 
berücksichtigen. Eine Taktumschaltung zwecks Strom sparen natürlich 
auch. Aber schon dabei gibt's viele Möglichkeiten und ein Programm wird 
nur sehr wenige davon benutzen. Eine wirklich flexible 
UART-Initialisierung würde also viel nie benutzten Code enthalten. Wie 
weit treibt man das im wirklichen Leben? Jedenfalls möchte ich dabei 
nicht noch auf Debugger oder IDE aufpassen müssen.

Immerhin geht's mir dank deiner Geduld schon wieder viel besser ;)

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich immer wieder auffällig finde: Wenn man von AVR oder MC51 in die 
Welt der STM32 Controller vordringt, stößt man immer wieder auf 
unerwartete Effekte. Die langen Errata bin ich auch nicht gewohnt.

Ist das bei anderen ARM Controllern auch so, oder ist "lass dich 
überraschen" nur bei ST an der Tagesordnung?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bauform B. schrieb:
> Eine wirklich flexible
> UART-Initialisierung würde also viel nie benutzten Code enthalten. Wie
> weit treibt man das im wirklichen Leben?

Der STM32HAL macht sonen schmarrn.
Wenn du da die Baudrate einstellst ließt der erstmal sämtliche RCC 
Register im CLK Pfad zum UART und rechnet den APB Takt aus.

Dabei gibts dann noch ein Bug im CubeMX Autocode für den L431.
Da wird ein PLL Init struct member nicht gefüllt, dann steht zwar 
korrekterweise 1 im Register, aber der Gammel HAL verrehcnet sich um den 
Faktor 2.
-> HAL+Autocode nicht nutzen, nur Bugs, Bugs, Bugs!
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
//RCC_OscInitStruct.PLL.PLLM = 1;                    << wird von CubeMX nicht inited und steht daher auf 0 (bss) -> HAL nimmt defaultwert von 2, aber die PLL bekommt 1 im Reg
RCC_OscInitStruct.PLL.PLLN = 10;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;
RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;

Dadurch passiert folgendes im UARt Init Code des Gammel HALs:
uint32_t clk = HAL_RCC_GetPCLK2Freq(); // CLK = 31750000 statt 80000000
usartdiv = (uint16_t)(UART_DIV_SAMPLING16(clk, huart->Init.BaudRate));

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Was ich immer wieder auffällig finde: Wenn man von AVR oder MC51 in die
> Welt der STM32 Controller vordringt, stößt man immer wieder auf
> unerwartete Effekte. Die langen Errata bin ich auch nicht gewohnt.
>
> Ist das bei anderen ARM Controllern auch so, oder ist "lass dich
> überraschen" nur bei ST an der Tagesordnung?

Also ich bin am Anfang bei den AVRs auch auf genug unerwartete Effekte 
gestossen, vor allem in Verbindung mit den Fuses, dem EEPROM und ein 
paar anderen Kleinigkeiten die ich nach Jahren erfolgreich aus dem 
Gedächtnis verdrängt habe.

Von der Komplexität her ist so ein ARM ja nicht vergleichbar mit den 
AVRs, "mehr" (eingebaute Peripherie) erzeugt halt "mehr" (potentiell 
unerwartetes Verhalten).

Autor: rµ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Bauform B. schrieb:
>> Eine wirklich flexible
>> UART-Initialisierung würde also viel nie benutzten Code enthalten. Wie
>> weit treibt man das im wirklichen Leben?
>
> Der STM32HAL macht sonen schmarrn.
> Wenn du da die Baudrate einstellst ließt der erstmal sämtliche RCC
> Register im CLK Pfad zum UART und rechnet den APB Takt aus.

Mit der STM HAL handelt man sich so oder so viel Code ein der großteils 
unbenutzt ist. Von der Code-Ästhetik (die grenzwertig grausam ist) ganz 
abgesehen, aber #define DAS_IST_SOWIESO_EIN_CMSIS_PROBLEM. Die 
Bug-Dichte finde ich auch bedenklich, aber so als Inspirationsquelle wie 
gewisse Abläufe prinzipiell denkbar wären ist es ganz brauchbar.

Bei mir bleibt auch der Eindruck zurück, dass man Flash verbrauchen 
will. Bei den großen Controllern isses ja wurscht ob man 15kB 
generierten Code nur zur Initialisierung der Pins mitlinkt, hat man nur 
32kB isses aber nicht mehr so egal...

In dem Fall der Baudraten-Berechnung kann die lib aber nicht wirklich 
anders, irgendwoher muss die ja wissen, wie schnell der UART getaktet 
ist, und soo kompliziert ist das ClockTree-auslesen ja auch wieder 
nicht.

Ansonsten, wenn man alles zur Compile-Zeit wüsste und sich nichts zur 
Laufzeit ändert könnte man das ja auch direkt als Konstante im Code 
ablegen.

Autor: Stefanus F. (Firma: der mit dem Helfersyndrom) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit eurer Hilfe konnte ich letztendlich die USB-Serial Implementierung 
von W.S. auf den Nachfolger des Blue-Pill Boardes (mit STM32F303CC) 
portieren.

Board: http://stefanfrings.de/stm32/stm32f3.html#stm32f3mini
USB Code: http://stefanfrings.de/stm32/stm32f3.html#vcpnohal

Besten Dank nochmal.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.