STM32 - relativ praezises Delay ohne Timer

[Rene K. (xdraconix)]

Ich würde gerne ein "relativ" präzises Delay, ohne Timer, für meine 
Biblio bauen.

Da ich für das Delay ein Rückgabewert für eventuelle Abbruchbedingungen 
benötige stellen sich für mich einige Fragen. Ich habe mir da so einige 
Überlegungen gemacht - kleines Beispiel für ein einfaches Delay ohne 
Rückgabe:

uint32_t delay_multiplier;

void InitDelay(void)
{
  /* Get SysClock */
  RCC_ClocksTypeDef RCC_Clocks;
  RCC_GetClocksFreq(&RCC_Clocks);
    
  /* While Schleife braucht 4 cycles */
  /* Für 1 ms delay, müssen wir durch 4K teilen, */
  /* da die while Schleife 4 Cycles benötigt. */
  delay_multiplier = RCC_Clocks.HCLK_Frequency / 4000;

}


void delay(uint32_t wait)
{
  /* wait * multi, und dann -10 für diese Berechnung */
  wait = (wait * delay_multiplier) - 10;

  while(delay--);
}

Für einen Rückgabewert benötige ich ja natürlich eine Abfrage in meinem 
delay - die Frage ist nun - wie viele Cycles benötige ich da nun genau 
für solch eine Abfrage eine volatilen Variable? Ist die von der 
Optimierungsstufe des Compilers abhängig? Ware es besser dies mit Inline 
ASM zu bewerkstelligen um den Compiler "festzunageln"? Mein 
Gedankengang:

volatile uint8_t delay_interrupt = 0;

uint8_t delay(uint32_t wait)
{
  /* wait * multi, und dann -10 für diese Berechnung */
  wait = (wait * delay_multiplier) - 10;

  while(delay--)
  {
    if(delay_interrupt) return 1;
  }
}

Wo finde ich Assembly in SW4STM (Eclipse) - damit ich mir die Cycles 
berechnen kann? Wie würde ein Inline ASM dafür aussehen?

Jemand eine Idee?

[RP6conrad (Gast)]

Diese ARM processoren haben dafur eine eingebaute "Sys_tick". Das ist 
ein timer die dafur ideal ist : nach einstellung haben sie auf feste 
intervallen einen interrupt, wo dan ihre delay gezahlt wird :
Beispiel fur F407 an 168 MHz :
/* SysTick end of count event each 1ms */
SysTick_Config(168000);
Dan die ISR :
void SysTick_Handler(void)
{
if (Delay != 0x00) Delay--;
milli_seconds++;cal_timer++;speed_timer++;watchdog_gps++;
MPU_print++;timer_0++;mpu_timer++;Tx_timer++;
}
Wie sie sehen verwende ich das dan für alle gewunschte 1ms timers.

[Rene K. (xdraconix)]

RP6conrad schrieb:
> Diese ARM processoren haben dafur eine eingebaute "Sys_tick". Das
> ist
> ein timer die dafur ideal ist : nach einstellung haben sie auf feste
> intervallen einen interrupt, wo dan ihre delay gezahlt wird :
> Beispiel fur F407 an 168 MHz :
> /* SysTick end of count event each 1ms */
> SysTick_Config(168000);
> Dan die ISR :
> void SysTick_Handler(void)
> {
> if (Delay != 0x00) Delay--;
> milli_seconds++;cal_timer++;speed_timer++;watchdog_gps++;
> MPU_print++;timer_0++;mpu_timer++;Tx_timer++;
> }
> Wie sie sehen verwende ich das dan für alle gewunschte 1ms timers.

Ja den Systick habe ich auch in Verwendung, das Problem beim Systick 
Interrupt ist ja folgender:

void SysTick_Handler(void)
{
  if (Delay != 0x00) Delay--;  //      10 cycles
  milli_seconds++;             // RMS:  3 cycles
  cal_timer++;                 // RMS:  3 cycles
  speed_timer++;               // RMS:  3 cycles
  watchdog_gps++;              // RMS:  3 cycles
  MPU_print++;                 // RMS:  3 cycles
  timer_0++;                   // RMS:  3 cycles
  mpu_timer++;                 // RMS:  3 cycles
  Tx_timer++;                  // RMS:  3 cycles
                               //     ---------- 
                               // SUM  34 cycles
                               //     ==========
}

Das sind dann in der Summe 34 Cycles welche in einer Atomaren ISR 
(Systick ist ja non-blockable) stehen - der Systick wird auch erst 
wieder gestartet wenn die ISR abgearbeitet ist. Das dezimiert den 
gesamten Busclock um genau diese Cycles. 34 Cycles hört sich ja im 
ersten Moment nicht "viel" an, macht aber in der Summe mehrere Mhz am 
gesamten Takt aus.

DAS ist ja genau das Problem welches ich umgehen will, da ich momentan 
ebenfalls den Systick als Taktquelle nutze :-/

[Stefan F. (Gast)]

> Ist die von der Optimierungsstufe des Compilers abhängig?

Ja ist es. Und je nach Taktfrequenz musst du Wait States für den Flash 
Speicher nutzen, daher geht es nicht ganz so einfach (die Taktfrequenz 
durch x teilen).

> Wo finde ich Assembly in SW4STM (Eclipse) - damit ich mir die
> Cycles berechnen kann?

Ich bin unsicher, was du mit der Frage meinst. Wenn du sehen willst, 
welchen Assembler-Code der Compiler erzeugt, dann trage in in das 
Textfeld unter Properties/C/C++ Build/Settings/Tool Settings/MCU GCC 
Linker/Miscellaneous/Linker Flags das ein:

-Wa,-adhlns="$(@:%.o=%.lst)"

Du findest dann für jede Quelll-Datei eine *.lst Datei im Verzeichnis 
Debug oder Release.

> 34 Cycles hört sich ja im ersten Moment nicht "viel" an, macht aber
> in der Summe mehrere Mhz am gesamten Takt aus.

Ich gehe davon aus, dass nicht alle Counter so schnell hochzählen 
müssen. Dann bietet sich folgendes Konstrukt an:

void SysTick_Handler(void)
{
  static uint8_t teiler=0;

  if (Delay != 0x00) Delay--;
  milli_seconds++; 

  if (++teiler == 100)
  {
    teiler=0;
    cal_timer++;
    speed_timer++;
    watchdog_gps++;
    MPU_print++;
    timer_0++;
    mpu_timer++; 
    Tx_timer++; 
  }
}

Das würde die CPU Last deutlich senken.

Eine andere Möglichkeit ist, nicht viele Variablen hochzuzählen, sondern 
nur eine einzige. Vermutlich setzt dein Programm die vielen Zähler auf 0 
und macht dann irgend etwas bis (oder wenn) sie einen gewissen Wert 
erreicht haben. Das kann man auch anders machen:

uint32_t milli_seconds;

void SysTick_Handler(void)
{
  milli_seconds++; 
}

void delay_ms(uint32_t time)
{
  uint32_t start=milli_seconds;
  while (milli_seconds-start <= time);
}

void measure_time()
{
  uint32_t start=milli_seconds;
  // tu irgendwas hier
  uint32_t elapsed=milli_seconds-start;
}

Der Trick hierbei liegt in der Subtraktion. Sie liefert sogar das 
korrekte Ergebnis, wenn milli_seconds zwischendurch einmal übergelaufen 
ist. Das Zurücksetzen auf 0 entfällt, und das wiederum ermöglicht es 
Dir, den EINEN milli_seconds Counter in mehreren Threads parallel und 
überlappend zu verwenden.

Du kannst damit Intervalle messen, die maximal 2x so lang sind, wie ein 
kompletter Durchlauf. Also in diesem Fall maximal 98 Tage.

Von Delays halte ich übrigens nicht viel. In sehr einfachen Programmen 
sind sie noch praktisch, doch für so einfache Programme würde keinen 
"fetten" 32bit Controller verwenden. Früher oder später soll dein 
Programm mehrere Threads parallel abarbeiten (lerne: Endlicher Automat) 
und dann sind Delays praktisch verboten (außer im µS Bereich).

[eagle user (Gast)]

Rene K. schrieb:

> /* wait * multi, und dann -10 für diese Berechnung */
>   wait = (wait * delay_multiplier) - 10;
und
> Das sind dann in der Summe 34 Cycles welche in einer Atomaren
> ISR (Systick ist ja non-blockable) stehen

Wenn man sooo genau werden will, muss man mindestens noch die 
Flash-Wait-Zyklen berücksichtigen, oder nicht, wenn die Schleife im RAM 
läuft. Dazu kommt, ob prefetch eingeschaltet ist und die Wirkung von 
Cache/ART. Das Alignment der delay-Routine macht auch 1 Zyklus hin oder 
her oder evt. auch nicht. Selbst wenn man die Routine selbst in 
Assembler schreibt oder die Optimierung festnagelt, spielt immer noch 
die Optimierung des Aufrufs eine Rolle.

Wenn du sooo genau werden willst und die Bibliothek sogar auf 
verschiedenen Chips nutzen willst: nimm einen Timer.

Man könnte den systick-_Counter_ abfragen, aber der ist nur 24 Bit breit 
und kann mit HCLK oder HCLK/8 laufen. Man sollte den DWT Cycle Counter 
abfragen. Der läuft immer mit HCLK und ist 32 Bit breit, macht also 
weniger (keine) Probleme beim Überlauf.

[eagle user (Gast)]

Der Trick, die Division für den Takt in eine Init auszulagern, ist 
allerdings sehr gut. Der Div-Befehl kann je nach Daten unterschiedlich 
lange dauern. Beim Mul-Befehl muss man nur wissen, ob ST den großen oder 
nur den kleinen Multiplizierer eingebaut hat (1 bzw. ca. 32 Zyklen).

[eagle user (Gast)]

Noch was (aber dann gebe ich Ruhe). Ein normaler Timer TIMx ist im 
I/O-Adressbereich angesiedelt während systick und DWT am Private 
Peripheral Bus hängen. Ein Thread mit CONTROL_TPL = 1 hat da evt. keine 
Zugriffsrechte.

[m.n. (Gast)]

Das exakte Zählen von Zyklen in einer Warteschleife ist sinnlos, sofern 
Interrupts im Programm auftreten können.

[einfügen (Gast)]

>der Systick wird auch erst wieder gestartet wenn die ISR abgearbeitet ist.

Wo hast Du denn das gelesen?

[eagle user (Gast)]

m.n. schrieb:
> Das exakte Zählen von Zyklen in einer Warteschleife ist sinnlos,
> sofern Interrupts im Programm auftreten können.

Ohne Hardware-Zähler ist es auf größeren Chips sowieso sinnlos, mit wird 
die Unterbrechung ja in gewissen Grenzen kompensiert. Eine ISR sollte ja 
nicht so lange dauern. Und oft braucht man nur eine minimale 
Verzögerung. Und notfalls kann der Aufrufende die Priorität anpassen.

einfügen schrieb:
>>der Systick wird auch erst wieder gestartet wenn die ISR
> abgearbeitet ist.
>
> Wo hast Du denn das gelesen?

Naja, die systick ISR wird sich nicht selbst unterbrechen. Auf cortex-m 
geht das nichtmal mit Gewalt, glaube ich.

[Niklas G. (erlkoenig)]

Ich hatte mal aus Spaß ein taktgenaues Delay ganz ohne Timer (in 
Assembler) geschrieben:
https://github.com/Erlkoenig90/stm32delay
Das wird im RAM ausgeführt, damit keine Waitstates berücksichtigt 
werden. Die Funktion rechnet den Overhead raus, um somit immer exakt die 
richtige Anzahl an Takten zu warten (ab einer bestimmten Mindestanzahl). 
Die Berechnung muss man je nach Controller ggf. anpassen.
Nur als Beispiel, die Sinnhaftigkeit von Delays ohne Timer/Interrupt 
wurde ja oben schon besprochen.

[Nico W. (nico_w)]

Was ist mit DWT?

[go for gold (Gast)]

> uint32_t delay_multiplier;
Hier fehlt das volatile.

In BS gibt es einen Zähler, der mit konstantem Takt inkrmentiert wird. 
Der  Zählerwert kann von jedem gelesen werden und es lassen sich 
beliebig viele Referenzen ableiten, ohne (fast!) die Genauigkeit zu 
beeinflussen.

D. h. in der ISR wird nur ein Inkrement ausgeführt.

[Thomas (kosmos)]

kannst du deine Delay Anforderungen genauer beschreiben? Also kürzestes, 
längstes benötigtes Delay und die benötigte Abstufung.

Man könnte z.B. die Netzfrequenz hinter einem Trafo mit AC Opokoppler 
oder nach dem Gleichrichter mit einem normalen Optokoppler abgreifen und 
in einer ISR mitzählen.

[Thomas E. (picalic)]

Rene K. schrieb:
> void SysTick_Handler(void)
> {
>   if (Delay != 0x00) Delay--;  //      10 cycles
>   milli_seconds++;             // RMS:  3 cycles
>   cal_timer++;                 // RMS:  3 cycles
>   speed_timer++;               // RMS:  3 cycles
>   watchdog_gps++;              // RMS:  3 cycles
>   MPU_print++;                 // RMS:  3 cycles
>   timer_0++;                   // RMS:  3 cycles
>   mpu_timer++;                 // RMS:  3 cycles
>   Tx_timer++;                  // RMS:  3 cycles
>                                //     ----------
>                                // SUM  34 cycles
>                                //     ==========
> }

Warum machst Du das so? Normalerweise kenne ich das so, daß im 
Systick-Interrupt nur genau ein einziger Zähler hochgezählt wird, und 
zwar in der Regel "milli_seconds" - für alle Delays im 
Millisekundenbereich oder länger wird nur diese Variable genutzt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas E. schrieb:
> Warum machst Du das so? Normalerweise kenne ich das so, daß im
> Systick-Interrupt nur genau ein einziger Zähler hochgezählt wird, und
> zwar in der Regel "milli_seconds" - für alle Delays im
> Millisekundenbereich oder länger wird nur diese Variable genutzt.
Und beim Arduino gibt's dafür sogar eine hübsche Anleitung, die ganz 
ohne Überlaufproblem mit Zeitdifferenzen arbeitet:
http://playground.arduino.cc/Learning/BlinkWithoutDelayDe