STM32 Main loop zu langsam?

1

while (1)

2

{

3

  HAL_GPIO_TogglePin(LI_CH1_GPIO_Port,LI_CH1_Pin);

4

}

Wenn man zum schnöden ändern von einem Pin sich den Luxus eines Aufrufs 
einer aufgeblasenen Funktion gönnt darf man sich über nichts wundern.

Irgendwer schrieb:
> Wenn man zum schnöden ändern von einem Pin sich den Luxus eines Aufrufs
> einer aufgeblasenen Funktion gönnt darf man sich über nichts wundern.

HAL oder die LL Lib sind ja nicht total kacke ...
Es gibt genug grunde das zeug einzusetzen

Aber nur um den PIN so schnell wie möglich wackeln zu lassen ... ist das 
auch der der falsche ansatz
selbst der Weg mit leerer Main loop ist der total falsche !!

wenn man zB eine PWM nutzt oder andere HW features ... ist der einsatz 
der HAL oder LL Lib sicher undramatisch

der vorteil wäre:
man klickt sich das im Cube zusammen und hat 10 sek später den Ausgang 
am wackeln...

oder man liest sich durchs manual und sucht sich entsprechende Register 
und bits raus

Der peripheral Bus muss langsamer laufen als 180 MHz. Zudem noch der 
erwähnte mögliche overhead.

6MHz, also 12 Mio Durchläufe, also 15 Quarz-takte für
 Zustand abfragen,
togglen,
schreiben
Sprung.

Das ist ok. Verbesserungsmöglichkeiten: togglen ausrollen, also High, 
Low.
Noch besser: direkt, ohne hal

Ich kenn mich nich aus, aber:
>GPIO_InitStruct.Speed = GPIO_SPEED_LOW;
"LOW" impliziert "laangsaam". Wird aber mit dem Problem hier nichts zu 
tun haben, oder?

StromTuner

Irgendwer schrieb:
> while (1)
> {
>   HAL_GPIO_TogglePin(LI_CH1_GPIO_Port,LI_CH1_Pin);
> }
>
> Wenn man zum schnöden ändern von einem Pin sich den Luxus eines Aufrufs
> einer aufgeblasenen Funktion gönnt darf man sich über nichts wundern.

Hast du schon mal in diese achso aufgeblasene Funktion reingeschaut? 
Wenn nicht hier bitteschön:

1

void HAL_GPIO_TogglePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)

2

{

3

  /* Check the parameters */

4

  assert_param(IS_GPIO_PIN(GPIO_Pin));

5

6

  GPIOx->ODR ^= GPIO_Pin;

7

}

Irgendein anderer schrieb:
> /* Check the parameters */
>   assert_param(IS_GPIO_PIN(GPIO_Pin));

Und da hast du dir schon gleich die nächsten Funktionsaufrufe 
eingefangen:-)

Irgendwer schrieb:
> Und da hast du dir schon gleich die nächsten Funktionsaufrufe
> eingefangen:-)

was ist falsch daran ein generisches Argument auf Gültigkeit zu prüfen? 
Wenn man alles dem Performancegott opfern möchte und lieber lange Fehler 
sucht kann man solche Abfangjäger ja weglassen.
Das assert wird auch nur wirksam wenn man es möchte und das Symbol 
USE_FULL_ASSERT setzt, sonst wird das wegoptimiert.

Interessantes Thema.

Hier die Assembly im Compiler Explorer:
https://godbolt.org/g/3yhzYd

Bei -O3 sieht das so aus:

1

.L3:

2

ldr     r3, [r2, #20]   | 3 Takte

3

eor     r3, r3, #1      | 1 Takt

4

str     r3, [r2, #20]   | 3 Takte

5

b       .L3             | 1 + P Takte

Die ARM ISA sagt zu P folgendes: /The number of cycles required for a 
pipeline refill. This ranges from 1 to 3 depending on the alignment and 
width of the target instruction, and whether the processor manages to 
speculate the address early./ 
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100166_0001_00_en/ric1417449098079.html). 
LDR und STR können unter günstigen Umständen (pipelining) auch schneller 
sein, das ist mir nicht so klar wann das ist.

b kann also 2-4 Takte brauchen, ich nehme mal den Worst-Case von b=3 an. 
In Summe sind das dann 11 Takte pro Toggle, x2 für eine komplette 
Periode. 180/22 = 8MHz. Du bist also nah an der Grenze des technisch 
machbaren.

Das doofe am Toggeln ist ja dass du den Pin lesen musst, obwohl in 
deiner Funktion das gar nicht nötig ist. Schneller sollte es gehen wenn 
du einfach hard-coded deine Schleife durchfährst, dann sind die stores 
gepipelined (https://www.arm.com/files/pdf/CortexM3_Uni_Intro.pdf, Seite 
31)
https://godbolt.org/g/UHEHHV

1

.L4:

2

str     r1, [r3, #24]   | 1 Takt (+2 Latenz)

3

str     r2, [r3, #24]   | 1 Takt

4

b       .L4             | 1 + P Takte

Damit dauert deine Periode nur noch 6 Takte (= 30MHz), auf Kosten eines 
asymmetrischen Rechtecks.

1

.L4:

2

str     r1, [r3, #24]   | 1 Takt

3

nop                     | 1 Takt

4

nop                     | 1 Takt

5

str     r2, [r3, #24]   | 1 Takt

6

b       .L4             | 1 + P Takte

Das ist ein symmetrisches Rechteck mit 22,5MHz (=180MHz/8). Wenn es noch 
schneller sein sollte, würde ich mir die Peripherie anschauen, 
vielleicht kann man irgendwelche Hochgeschwindigkeits-Peripherie mit 
180MHz Daten ausspucken lassen.

Ich hatte gerade die gleiche Frage wie OP. Allerdings sieht mein 
Hauptprogramm so aus:

1

uint32_t i = 0;

2

while (1) {

3

  if (i > 2000000L) {

4

    HAL_GPIO_TogglePin(LED2_GPIO_PORT, LED2_PIN);

5

    i = 0;

6

  }

7

  ++i;

8

}

Die LED blink im 1-Sekunden-Takt, d.h. die Schleife läuft mit 2 "MHz", 
entsprechend der Durchläufe. Der Takt ist allerdings 64 MHz, d.h. wo 
werden hier 32 Zyklen pro Schleife verbraten? (Die HAL o.ä. spielt hier 
keine Rolle.)

Wie kann ein STM32 so langsam sein? Ich wollte ihn eigentlich als 
Bus-Treiber (1-3 MHz) einsetzen. Sind die anderen Hersteller schneller 
(ich vermute nicht)? Gibt es schnellere Alternativen (außer FPGA)?

Ulf schrieb:
> Der Takt ist allerdings 64 MHz,

Dann ist das wohl kein STM32F4xx und du vergleichst
Äpfel mit Birnen ....?

Nein, das ist ein STM32F1, aber das Prinzip dürfe wohl gleich sein.

Markus M. schrieb:
> Schau mal ob das schneller geht:

Gut gemeint, aber ....

Für wen war dein Vorschlag?

Ja, bei mir wird die LED nur einmal pro 2 Mio. Durchläufen angesprochen, 
d.h. deren Performance ist vernachlässigbar.

Aber -Os werde ich mal ausprobieren.

Interessant ... -O3 und -Os haben einen Faktor 4x herausgeschlagen. Ob 
-O3 oder -Os besser ist, kann ich mit dem bloßen Auge nicht erkennen.

Ulf schrieb:
> Ob
> -O3 oder -Os besser ist, kann ich mit dem bloßen Auge nicht erkennen.

Kann ja auch zufällig das gleiche Optimierungs-Ergebnis herauskommen.