STM32F4: µs-Delay

[Daniel V. (voda)]

Guten Abend liebes Forum.

Ich sitze hier mal wieder an einem Problem. Für eine SPI-Kommunikation 
benötige ich einen µs-Timer. Folgendes habe ich bisher auf meinem 
STM32F446 implementiert:

delay.c

#include <delay.h>

extern volatile uint32_t ticker;
volatile uint32_t us;

void SysTick_Init(void)
{
 if (SysTick_Config (SystemCoreClock / 1000)) //1ms per interrupt
  while (1);
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);
  NVIC_SetPriority(SysTick_IRQn,0);
  ticker = 0;
}

uint32_t generated_ms(void)
{
  return ticker;
}

uint32_t generated_us(void)
{
   /* us = ticker*1000+(SystemCoreClock/1000-SysTick->VAL)/80; */
   us = ticker * 1000 + 1000 - SysTick->VAL/80;
   return us;
}

void delay_ms(uint32_t nTime)
{
 uint32_t curTime = ticker;
  while((nTime-(ticker-curTime)) > 0);
}

void delay_us(uint32_t nTime)
{
 uint32_t curTime = us;
 while((nTime-(us-curTime)) > 0);
}

delay.h

#ifndef DELAY_H
  #define DELAY_H
  
#include <stm32f4xx.h>
#include <misc.h>

extern void SysTick_Init(void);
extern void delay_ms(uint32_t nTime);
extern void delay_us(uint32_t nTime);
#endif

Zudem habe ich in einer Funktion die SysTick_Handler:

void SysTick_Handler(void)
{
  ticker++;
}

Die Variable ticker++ ist natürlich als volatile uint32_t deklariert. 
Die ms-Funktion funktioniert ohne Probleme aber rufe ich in der main die 
us-Funktion auf, naja da passiert gar nichts...

Wo kann hier der Fehler liegen? Wie bekomme ich eine anständige 
us-Delay-Funktion hin?

Danke euch und Gruß
Daniel

[holger (Gast)]

>Wie bekomme ich eine anständige us-Delay-Funktion hin?

Nimm einen anderen Timer und nicht den Systick.

[Codeleser (Gast)]

Daniel V. schrieb:
> while (1);

wait forever?

[posti (Gast)]

Hi

C ist nicht meine Sprache :/

Vll. hilft Dir das Beispiel in dem AVR-Assembler-Makros:
https://www.mikrocontroller.net/articles/AVR_Assembler_Makros
... zumindest auf nem AVR (bisher ATtiny45) macht die Routine, was dran 
steht ;)

Da mir C (oder # oder + oder ++ oder was es noch gibt) nicht viel sagt, 
erscheint mir das Assembler-Listing auch irgendwie logischer - und 
erzeugt erfrischend kurzen Code bei takt-genauer Verzögerung.

Oder wird oben im Code 'nur' abgefragt, ob die Wartezeit bereits um ist?
(der Return-Wert 'return us' lässt mich Das fragen)

MfG

[Daniel V. (voda)]

holger schrieb:
> Nimm einen anderen Timer und nicht den Systick.

Du meinst die TIMs welche hier im diesem Projekt verwendet wird:

Beitrag "STM32F4Discovery mit CooCox :: GPIO,SDIO,Timer,SoftTimer,USART,printf"

Das habe ich irgendwie schon befürchtet.

Codeleser schrieb:
>> while (1);

Hmmm, verstehe ich jetzt nicht so ganz wo der Fehler sein sollte, da ja 
die delay_ms-Funktion funktioniert.

posti schrieb:
> Oder wird oben im Code 'nur' abgefragt, ob die Wartezeit bereits um ist?
> (der Return-Wert 'return us' lässt mich Das fragen)

Die Funktion

uint32_t generated_us(void)
{
   /* us = ticker*1000+(SystemCoreClock/1000-SysTick->VAL)/80; */
   us = ticker * 1000 + 1000 - SysTick->VAL/80;
   return us;
}

soll die µs anhängig vom SystemCoreClock sowie dem Zähler ticker 
generieren, daher auch die Berechnung. Die Variable us ist der 
berechnete Wert () und wird mit return übergeben. Gleichzeitig wird die 
Funktion mit diesem Schlüsselwort beendet.

Danke und Gruß
Daniel

[Nico W. (nico_w)]

Codeleser schrieb:
> Daniel V. schrieb:
> while (1);
>
> wait forever?

Ja, das ist da ja auch richtig. Kannst ja mal gucken wann die 
if-Bedingung wahr wird.

[Nop (Gast)]

Dann gibt es bei STM32F4 ja auch noch den DWT-Counter. Der zählt 
CPU-Takte. Wenn man weiß, was für einen Takt man eingestellt hat, kann 
man damit ohne weiteres recht genaue Warteschleifen machen.

[Johannes S. (Gast)]

Wo wird denn generated_us aufgerufen? Zumindest in dem gezeigten 
Ausschnitt wird us doch nicht verändert?

[greg (Gast)]

Für us-Delays kann man doch einfaches Busy Waiting verwenden, oder? Mach 
eine kleine Schleife mit Assembler und zähl die Takte. Die Anzahl der 
Durchläufe ergibt sich dann aus der Zeit für einen Schleifendurchlauf 
und der Taktfrequenz. Ansonsten der besagte DWT-Counter.

[Daniel V. (voda)]

greg schrieb:
> Für us-Delays kann man doch einfaches Busy Waiting verwenden, oder? Mach
> eine kleine Schleife mit Assembler und zähl die Takte. Die Anzahl der
> Durchläufe ergibt sich dann aus der Zeit für einen Schleifendurchlauf
> und der Taktfrequenz. Ansonsten der besagte DWT-Counter.

Kannst Du das mal an einem Beispiel zeigen? Was ist der DWT-Counter? 
Gibt es dazu auch Beispiele?

Danke euch und Gruß
Daniel

[STM-Macker (Gast)]

Daniel V. schrieb:
> Was ist der DWT-Counter?
> Gibt es dazu auch Beispiele?

- Kennst du gugel?
- kannst du das eventuel bedienen?
- meinst du dass du eventuell mit diesem Werkzeug
auch ein Beispiel finden kannst?

[aSma>> (Gast)]

Daniel V. schrieb:
> void delay_us(uint32_t nTime)
> {
>  uint32_t curTime = us;                 //us=generated_us
>  while((nTime-(us-curTime)) > 0);       //us=generated_us
> }

Man hat dir doch schon einmal einen Tipp gegeben, dass die Funktion 
generated_us() nicht aufgerufen wird.

[Nop (Gast)]

Daniel V. schrieb:

> Was ist der DWT-Counter?

Ein Register, welches synchron zum CPU-Takt hochzählt. Ist im Reference 
Manual leider nur schwammig erwähnt. Praxisbeispiel siehe hier:

http://www.carminenoviello.com/2015/09/04/precisely-measure-microseconds-stm32/ 
(etwas runterscrollen)

Daß dessen Version bei 1µs nicht so präzise ist, wundert mich nicht. 
Kommt sicherlich daher, daß er die Division in der Warteroutine macht, 
anstatt den Ausdruck "SystemCoreClock/1000000L" außerhalb nach dem 
Einstellen der Taktfrequenz einmal zu berechnen und in einer globalen 
Variablen (naja, file-static) zu speichern, und außerdem ist das auch 
noch in der falschen Reihenfolge (start müßte vor cycles gefüllt 
werden).

[Daniel V. (voda)]

aSma>> schrieb:
> Man hat dir doch schon einmal einen Tipp gegeben, dass die Funktion
> generated_us() nicht aufgerufen wird.

Stimmt, irgenwie untergegangen

Nop schrieb:
> Ein Register, welches synchron zum CPU-Takt hochzählt. Ist im Reference
> Manual leider nur schwammig erwähnt. Praxisbeispiel siehe hier:

Danke Euch. Muss ich jetzt mal prüfen.

[Daniel V. (voda)]

So, diese µs-Funktion habe ich aus diesem amerikanischen Blog 
abgeleitet:

http://micromouseusa.com/?p=296

Da könnt ihr mal sehen, was für eine Scheiße im Netz gepostet wird. Nach 
eingehender Untersuchung (und das hätte mir auch bei der Implementierung 
auffallen sollen) wird nie die Funktion generated_us(void) aufgerufen.

Meine Anfängerfrage an euch: Wie repariere ich das jetzt? Oder ist der 
Weg mit dem TIMs oder DWT vielversprechender? Ist das wirklich so 
aufwendig, einen us-Delay zu erzeugen ?

Danke und euch schönen Sonntag
Daniel

[Codechaos (Gast)]

Daniel V. schrieb:
> Ist das wirklich so aufwendig,
> einen us-Delay zu erzeugen ?

Was ist so schwer zu erkennen dass du mit

SysTick_Config (SystemCoreClock / xxxx));

ein nahezu beliebiges Zeitraster erzeugen kannst? Der bereitzustellende

void SysTick_Handler(void)
{
  ticker++;
}

zählt dein Zeitraster immer weiter, der Rest ist eine selbst-
geschriebene delay_xxx(...) Funktion die dein Zeitraster abzählt
und eine Differenzabfrage ausführt.

[Daniel V. (voda)]

Das ist richtig aber wenn ich den Nenner erhöhe, ist der Controller nur 
noch damit beschäftigt, den Interrupt auszulösen und die entsprechende 
Variable zu inkrementieren, oder verstehe ich das jetzt falsch?

[grundschüler (Gast)]

Es gab irgendwo mal code von pd für eine arm-delay-funktion.

ich hab den systick auf einem f103 mal durchprobiert. Ging runter bis 
10us aber dann ist die mcu doch sehr mit dem systick beschäftigt. 
Sinnvoll scheint mir systick mit 1ms.

für us-delays ist der systick damit nicht geeignet. Einfach und 
ausreichend genau geht es -wie bereits mehrfach ausgeführt- mit einer 
einfachen Schleife:

void _delay_ms(long ms){
  //genau auf 100sec
  //bei 72Mhz F_CPU=6536
  //bei 100Mhz F_CPU=9078
uint32_t i,j=xF_DELAY*ms;
  for(i=0;i<j;i++);
}
void _delay_us(long us){
uint32_t i,j=xF_DELAY*us/1000;
  for(i=0;i<j;i++);
}

[Thomas E. (picalic)]

grundschüler schrieb:
> void _delay_ms(long ms){
>   //genau auf 100sec
>   //bei 72Mhz F_CPU=6536
>   //bei 100Mhz F_CPU=9078
> uint32_t i,j=xF_DELAY*ms;
>   for(i=0;i<j;i++);
> }
> void _delay_us(long us){
> uint32_t i,j=xF_DELAY*us/1000;
>   for(i=0;i<j;i++);
> }

Wenn ich der Compiler wäre, würde ich diesen Unsinn einfach aus dem 
Programm 'rausschmeissen, weil er nichts sinnvolles macht.

[Codechaos (Gast)]

Daniel V. schrieb:
> Das ist richtig aber wenn ich den Nenner erhöhe,

Ja, wenn du schon so genau Bescheid weisst dürfte es dir doch
nicht schwer fallen einen Timer deines Controllers auf
1us Intervall (ohne Interrupt) zu programmieren und diesen
bei Bedarf zyklich abzufragen bis dein gewünschtes Zeitintervall
erreicht ist.

[aSma>> (Gast)]

Daniel V. schrieb:
> Meine Anfängerfrage an euch: Wie repariere ich das jetzt? Oder ist der
> Weg mit dem TIMs oder DWT vielversprechender? Ist das wirklich so
> aufwendig, einen us-Delay zu erzeugen ?

Lösche die Variable:
>volatile uint32_t us;

Rufe stattdessen us_generated():

uint32_t generated_us(void)
{
   return ticker * 1000 + 1000 - SysTick->VAL/80;
}

void delay_us(uint32_t nTime)
{
 uint32_t curTime = generated_us();
 while((nTime-(generated_us()-curTime)) > 0);
}

Das sind nur ein paar Zeilen Code aber verdammt nochmal sehr elegant 
gelösst. Mit Inlinen und Optimierung kommt man noch bei 24Mhz auf die 
1µs Auflösung.

[Thomas E. (picalic)]

aSma>> schrieb:
> Das sind nur ein paar Zeilen Code aber verdammt nochmal sehr elegant
> gelösst.

Mag elegant aussehen, ist aber meiner Meinung nach nicht zuverlässig.
Wenn nämlich der Systick-Interrupt mal genau innerhalb der Berechnung 
dieser Zeile:

return ticker * 1000 + 1000 - SysTick->VAL/80;

auftritt, kann u.U. ein Wert um 1000 zuwenig zurückgeliefert werden.
Wenn dieser falsche Wert dann curTime zugewiesen wird, hat man 1000µs zu 
kurzes Delay bzw. gar keins.
Es könnte auch ein Wert um 1000 zuviel zurückgeliefert werden, je 
nachdem, ob zuerst ticker oder SysTick->VAL geholt wird.

[Daniel V. (voda)]

@ aSma,

ich glaube das ist der Durchbruch. Ich habe Deine Lösung implementiert 
und ja, es scheint zu gehen.

Als Kontrolle toggle ich eine Debug-LED:

void test_timer(void)
{
  delay_us(75);
   DEBUG_LED_ON;
  delay_ms(100);
   DEBUG_LED_OFF;
}

Die entsprechende Pinansteuerung habe ich in den Header gepackt.

#define DEBUG_LED_ON  GPIOA->BSSRL |= (1<<12)
#define DEBUG_LED_ON  GPIOA->BSSRH |= (1<<12)

Nun habe ich das Oszi angeschmissen und bei den geforderten 75 µs messe 
ich 77,03 µs.

aSma>> schrieb:
> Das sind nur ein paar Zeilen Code aber verdammt nochmal sehr elegant
> gelösst.

Dann ist der Blogeintrag doch nicht so schlecht.

aSma>> schrieb:
>Mit Inlinen und Optimierung kommt man noch bei 24Mhz auf die
> 1µs Auflösung.

Mit Inlinern kenne ich mich leider noch nicht aus.

[Thomas E. (picalic)]

aSma>> schrieb:
> return ticker * 1000 + 1000 - SysTick->VAL/80;

Warum überhaupt "SysTick->VAL/80"? Das wäre doch wohl nur bei einer 
Clockfrequenz des Systick-Timers von 80 MHz korrekt, oder sehe ich das 
falsch?

[Daniel V. (voda)]

Thomas E. schrieb:
> Warum überhaupt "SysTick->VAL/80"? Das wäre doch wohl nur bei einer
> Clockfrequenz des Systick-Timers von 80 MHz korrekt, oder sehe ich das
> falsch?

Richtig, der Controller läuft auch auf 80 MHz.

[Thomas E. (picalic)]

Ok,

return ticker * 1000 + 1000 - SysTick->VAL/(SystemCoreClock/1000000UL);

wäre etwas universeller.

Nachtrag zu der "eleganten" Lösung aus dem Blog:
Dieser Poster (http://micromouseusa.com/?p=296#comment-532728) hat ja 
auch schon auf das Problem hingewiesen. Ich würde mal behaupten, 
insgesamt ist diese relativ komplizierte Funktion, dann auch noch mit 
der Notwendigkeit, die Interrupts zu sperren, weniger elegant, als 
einfach einen freilaufenden Timer zu benutzen (µs oder CPU-Zyklen).

[Codechaos (Gast)]

Codechaos schrieb:
> einen Timer deines Controllers auf
> 1us Intervall (ohne Interrupt) zu programmieren und diesen
> bei Bedarf zyklich abzufragen bis dein gewünschtes Zeitintervall
> erreicht ist.

Es scheint sich niemand Gedanken darüber zu machen dass bei solchen
Rechnereien

Thomas E. schrieb:
> return ticker * 1000 + 1000 - SysTick->VAL/(SystemCoreClock/1000000UL);

eine Menge Overhead anfällt. Wozu die Mikrosekunden berechnen wenn
es allein schon durch die Rechnung falsch wird? Dann kann man ja
gleich leerlaufende kalibrierte Schleifen zählen lassen.

[Daniel V. (voda)]

Thomas E. schrieb:
> Ok,return ticker * 1000 + 1000 -
> SysTick->VAL/(SystemCoreClock/1000000UL);
> wäre etwas universeller.

Jetzt sind es ca. 75 µs.

Damit kann man arbeiten. Leute, ich danke euch!

[EDIT]
Bei 100 µs sind es auch genau 100 µs.

Gruß
Daniel

[Thomas E. (picalic)]

Achte aber darauf, daß in Deinem System keine Interrupt Service Routinen 
mit Laufzeiten im Bereich 1µs und länger auftreten können, sonst werden 
u.U. aus den 100 µs auch mal > 1 Stunde!

[sajjad yaghoubi (Gast)]

some bug
change code to this solved problem:

.....................................................................
#include "Delay.h"

extern volatile uint32_t ticker;
volatile uint32_t us;

void SysTick_Init(void)
{
 if (SysTick_Config (SystemCoreClock / 1000)) //1ms per interrupt
  while (1);
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);
  NVIC_SetPriority(SysTick_IRQn,0);
  ticker = 0;
}

uint32_t generated_ms(void)
{
  return ticker;
}

uint32_t generated_us(void)
{
   us = (ticker * 1000) + 1000 - SysTick->VAL/72;
   return us;
}

void delay_ms(uint32_t nTime)
{
 uint32_t curTime = ticker;
  while(nTime + curTime > ticker);
}

void delay_us(uint32_t nTime)
{
  uint32_t curTime;
  ticker=0;
  curTime = generated_us();
        while(nTime + curTime > generated_us());
}
...............................................
#ifndef __Delay_H
#define __Delay_H
#include "stm32f10x.h"
#include "stm32f10x_it.h"

void SysTick_Init(void);
u32 micros(void);
u32 millis(void);
void delay_ms(u32 nTime);
void delay_us(u32 nTime);
#endif
.......................................................
volatile uint32_t ticker;
void SysTick_Handler(void)
{
  ticker++;
}

[aiCis (Gast)]

// I use some thing simple for millis like that!

int main(void)
{

  while (1)
  {
      // elapsedMillis 1 starts ---------------------
      static const uint32_t interval_1 = 1000;

      static uint32_t timeElapsed_1 = 0;

      if(HAL_GetTick() - timeElapsed_1 > interval_1)
      {
          HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_6);

    timeElapsed_1 = HAL_GetTick();
      }
      // elapsedMillis 1 ends -----------------------


      // elapsedMillis 2 starts ---------------------
      static const uint32_t interval_2 = 500;

      static uint32_t timeElapsed_2 = 0;

      if(HAL_GetTick() - timeElapsed_2 > interval_2)
      {

         HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_7);

         timeElapsed_2 = HAL_GetTick();
      }
      // elapsedMillis 2 ends -----------------------
  }

}

[The Wonderer (Gast)]

aiCis schrieb:
> // I use some thing simple for millis like that!

Oh how wonderful complicated, this is great news!

[aiCis (Gast)]

how can this code make more simplest?

[Ingo Less (Gast)]

Ich habe das so gelöst und bin damit zu frieden:

void MyDelayMS( uint32_t DelayInMS )
{
  MSDelayCounter = (DelayInMS * SYSTICK_IN_HZ) / 1000;
  while (MSDelayCounter);
}

void MyDelayUS( uint32_t DelayInUS )
{
  volatile uint32_t USDelayCounter = (DelayInUS * 168) / 10;
  while (USDelayCounter){USDelayCounter--;}
}

/* Timerinitialisierung */
void Init_SysTimer ( uint32_t Timerfrequenz )
{
  SysTick_Config( SystemCoreClock / Timerfrequenz );
}

void SysTick_Handler( void )
{
  
  // Userbutton
  if ( USER_BUTTON_PRESSED && !Debounce ){
    Debounce = DEBOUNCETIME;
    Flags.TorqueReversion = ON;
  }

  if ( MSDelayCounter ) MSDelayCounter--;
  if ( Debounce ) Debounce--;
}

Da siehst du auch, wie ich einen Taster entprelle ;)
Natürlich ist die MyDelayUS nicht so genau, als wenn sie mit einem Timer 
erzeugt worden wäre, aber das ist ganz oft nicht so schlimm. Die 
Magicnumber 168 ist zufällig die 168MHz, kann aber durch Probieren 
ermittelt werden

[aiCis (Gast)]

But this code stopped main while loop, from programme free flow is best 
use timer counter switching multiple pins.

void MyDelayMS( uint32_t DelayInMS )
{
  MSDelayCounter = (DelayInMS * SYSTICK_IN_HZ) / 1000;
  while (MSDelayCounter);  // <<<---- this while loop stopped main while loop
}

void MyDelayUS( uint32_t DelayInUS )
{
  volatile uint32_t USDelayCounter = (DelayInUS * 168) / 10;
  while (USDelayCounter)  // <<<---- this while loop stopped main while loop
  {
     USDelayCounter--;
  }
}

[Ingo Less (Gast)]

aiCis schrieb:
> But this code stopped main while loop
Of course it does. Thats what a delay does. Other option is using time 
slots....

If you use your version, you can not be sure, when you check your 
routine again. The jitter is massive

[aiCis (Gast)]

The jittering is coming from system clock?

[Aigars C. (aigars_c)]

//what you think about this solution?

static inline void waittick(uint32_t step)
{
static uint32_t tick0;
if (!step)
{
tick0 = SysTick->VAL;
return;
}
tick0 -= step;
while ((tick0 - SysTick->VAL) & ((SysTick_VAL_CURRENT_Msk+1)>>1));
}


// init SysTick:
SysTick->LOAD = SysTick_VAL_CURRENT_Msk;
SysTick->CTRL = SysTick_CTRL_ENABLE_Msk;
// init waittick
waittick(0);
// wait 1000 ticks
waittick(1000);