Verständnisfrage STM32 GPIO maximale Frequenz

[Peter H. (peter_hilleb)]

Hallo, ich mal wieder.

Ich habe die Clock so wie im Bild ersichtlich konfiguriert.

Nun verwende ich folgenden Code:

while(1)
{
  HAL_GPIO_TogglePin(SpiClk_GPIO_Port, SpiClk_Pin); 
  HAL_GPIO_TogglePin(SpiClk_GPIO_Port, SpiClk_Pin);
}

Wenn ich nun entsprechenden Ausgang am Oszi messe toggelt der mit ca 660 
kHz.
Ich hätte mir da eigentlich deutlich mehr erwartet, oder ist das normal?

Danke für jeden Hinweis!

Hier noch der generierte Code von CubeMx:

void SystemClock_Config(void)
{

  RCC_OscInitTypeDef RCC_OscInitStruct;
  RCC_ClkInitTypeDef RCC_ClkInitStruct;

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = 16;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI_DIV2;
  RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL16;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Initializes the CPU, AHB and APB busses clocks 
    */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Configure the Systick interrupt time 
    */
  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

    /**Configure the Systick 
    */
  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* SysTick_IRQn interrupt configuration */
  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
}

[Mike R. (thesealion)]

Theoretisch sollte das schneller gehen, aber je nachdem mit welchen 
Einstellungen du deinen Code kompiliert hast und wie die Funktion 
"HAL_GPIO_TogglePin()" aussieht kann das schon hinkommen.

Den Luxus einer einfachen Schnittstelle / eines HAL erkauft man sich 
immer auf kosten von Codegröße und Laufzeit!

[Ingo L. (corrtexx)]

Peter H. schrieb:
> Ich hätte mir da eigentlich deutlich mehr erwartet, oder ist das normal?
Schau dir mal an, was die Funktion

HAL_GPIO_TogglePin(SpiClk_GPIO_Port, SpiClk_Pin);

macht. Wirste dich wundern. Ein direkter Registerzugriff is deutlich 
schneller.

[Peter H. (peter_hilleb)]

void HAL_GPIO_TogglePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)
{
  /* Check the parameters */
  assert_param(IS_GPIO_PIN(GPIO_Pin));

  GPIOx->ODR ^= GPIO_Pin;
}

Kam mir auf den ersten Blick nicht so verdächtig vor.
Das IS_GPIO_PIN macht schon ein paar Sachen... Dachte aber nicht dass es 
so viel ausmacht.

Denn noch danke, ich kann zum testen ja mal nur den unteren teil selbst 
ausführen.

[Mike R. (thesealion)]

Auch der Befehl

GPIOx->ODR ^= GPIO_Pin;

ist nicht ganz billig. Außerdem hast du (je nach Optimierung) zwei 
Funktionsaufrufe mit allem was dazu gehört alleine um die Unterfunktion 
zu erreichen.

[Torsten (Gast)]

Ein ARM Mcu hat heute mehrere Busse, die CPU läuft von den Peripherie 
Clocks unabhängig. Am schnellsten geht das toggeln, wenn man nur das 
Outputregister genau mit dem wert beschreibt, der benötigt wird.
Lesen kostet extra.

Deine Schleife und HAL kosten natürlich auch - werden aber mit der Core 
clock abgearbeitet, die schneller ist, als die Peripherie clock.

Speicher und Flash Zugriffe Können je nach Controller auch noch Mal 
extra kosten. Z.b. das Peripherie Basis Register, kann im Rom/Flash 
liegen und wenn der Mcu  keinen Cache hat oder den Flash nicht schnell 
genug lesen kann, dauert das auch.

Last but not least habe ich im Raspberry Pi beobachtet, dass die Arm und 
VPU die gpio gleich schnell toggeln können. Nur nach einigen cyclen war 
die Arm CPU langsamer. Das lag daran, dass der soc ein Feature hat, das 
sie bei zu schnellen Arm Zugriffen auf den Bus den ARM Core warten lässt

[Olaf (Gast)]

> Ein ARM Mcu hat heute mehrere Busse, die CPU läuft von den Peripherie
> Clocks unabhängig.

Und die Zugriffe dazwischen muessen syncronisiert werden. Das kostet 
auch nochmal Zeit!

Olaf

[Schwanzus Longus (Gast)]

Gibt doch genug Infos dazu im Netz, einfach mal eine dieser Seiten 
durchlesen.
Z.B.
https://vjordan.info/log/fpga/stm32-bare-metal-start-up-and-real-bit-banging-speed.html

[Daniel B. (dbuergin)]

Pack das mal in deine main(), damit solltest du das Maximum bekommen,
was Du mit den Clocks eingestellt hast.

while(1)
{
   SpiClk_GPIO_Port->BSSRL = SpiClk_Pin; // Set the pin high
   SpiClk_GPIO_Port->BSSRH = SpiClk_Pin; // Set the pin low
}

[STM Apprentice (Gast)]

Da hammas wieda:

Entweder HAL oder schnell.

HAL ist ja sooooo schöööön bequem.

Da kann auch nix zu schnell werden. Könnt ja sein dass
man sich sonst "der-rennt", wie der Bayer so schön zu
sagen pflegt.

[Markus M. (adrock)]

BTW: Ich verstehe diesen Test aus assert_param() nicht:

#define   IS_GPIO_PIN(PIN)   ((((PIN) & (uint16_t)0x00) == 0x00) && 
((PIN) != (uint16_t)0x00))

Also der zweite Teil ist klar, PIN darf nicht 0 sein (fängt bei 1 an, 
wie sinnvoll (sic)). Aber wozu am Anfang das mit dem &?

[W.S. (Gast)]

Peter H. schrieb:
> GPIOx->ODR ^= GPIO_Pin;

Jaja, das kommt davon, wenn man partout NICHT das Manual zum Chip zu 
lesen bereit ist und deshalb seine Uralt-Ideen vom AVR oder sonstigem µC 
auch auf einen 32Bitter überträgt ohne weiter drüber nachzudenken.

Versuche mal lieber sowas:
 GPIO.BSRR = (1<<Pinnummer);
 GPIO.BSRR = (16<<Pinnummer);
in deiner Schleife.

W.S.

[dasrotemopped (Gast)]

CubeMX und schnell ohne CPU Last geht mit DMA auf GPIO Port

Einfach in CubeMX einen 16bit DMA konfigurieren, Memory to peripheral 
Modus, dann geht es so schnell wie der DMA Controller kann, meist zu 
schnell. Also den DMA von einem Timer triggern lassen, dann kann man 
sich die Geschwindigkeit einstellen. AN4031 hilft beim Einstieg.

[STM Apprentice (Gast)]

dasrotemopped schrieb:
> CubeMX und schnell ohne CPU Last geht mit DMA auf GPIO Port

Äusserst sinnvoll!

Einfach per DMA einen Port dauernd togglen lassen.
Bloss keinen unnötigen Hardware-Leerlauf erzeugen.

Das hilft auch beim Programmieren sehr viel weiter
wie es der TO vor hat.

[Markus M. (adrock)]

W.S. schrieb:
> Peter H. schrieb:
>> GPIOx->ODR ^= GPIO_Pin;
>
> Jaja, das kommt davon, wenn man partout NICHT das Manual zum Chip zu
> lesen bereit ist und deshalb seine Uralt-Ideen vom AVR oder sonstigem µC
> auch auf einen 32Bitter überträgt ohne weiter drüber nachzudenken.

Du hast aber schon gesehen, dass der Codeschnipsel offenbar aus der HAL 
Library von ST war?

[Stefan F. (Gast)]

Der Codeschnipsel aus der HAL ist ja nicht falsch, denn die Funktion 
soll den Pin 1x toggeln, egal in welchem Zustand er vorher war.

Wenn man aber weiß, dass man den Pin schneller setzen bzw. rücksetzen 
kann, dann macht man das, anstatt zu toggeln.

[Johannes S. (Gast)]

Mike R. schrieb:
> Auch der BefehlGPIOx->ODR ^= GPIO_Pin;
>
> ist nicht ganz billig. Außerdem hast du (je nach Optimierung) zwei
> Funktionsaufrufe mit allem was dazu gehört alleine um die Unterfunktion
> zu erreichen.

so ist das, das wird zu:

          HAL_GPIO_TogglePin:
08000260:   sub     sp, #8
08000262:   str     r0, [sp, #4]
08000264:   mov     r3, r1
08000266:   strh.w  r3, [sp, #2]
509         GPIOx->ODR ^= GPIO_Pin;
0800026a:   ldr     r3, [sp, #4]
0800026c:   ldr     r2, [r3, #12]
0800026e:   ldrh.w  r3, [sp, #2]
08000272:   eors    r2, r3
08000274:   ldr     r3, [sp, #4]
08000276:   str     r2, [r3, #12]
510       }

Peter H. schrieb:
> Kam mir auf den ersten Blick nicht so verdächtig vor.
> Das IS_GPIO_PIN macht schon ein paar Sachen... Dachte aber nicht dass es
> so viel ausmacht.

das steckt aber im assert_param(), und das verpufft zu Luft wenn das 
define USE_FULL_ASSERT nicht gesetzt ist. Da man bei den vielen 
Parametern viel falsch machen kann ist das gar nicht verkehrt das im 
debug build zu aktivieren.