delay(ms) funktioniert nicht

[ratloser_stm_user (Gast)]

Da ich noch ein ziemlicher Anfänger mit dem STM32F4 Discovery bin, 
probiere ich im Moment eine Delay Funktion aus, die solange in einer 
Schleife nichts tut, bis ein counter unter 0 ist. Dieser wird im 
SysTickHandler() runtergezählt.
folgendes Problem: Diese Schleife wird irgendwie endlos ausgefürt, 
jedenfalls gehen die LED's nich wieder an.
Hier der Quellcode:

#include "stm32f4xx_conf.h"
#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include "stm32f4xx.h"

signed int counter = 100;

//delay funktion abhängig von SysTick_Config
void delay(signed int ms){
  counter = ms;  
  while(counter > 0){
    
  }
  counter = ms;
}

void initApplication()
{
  SysTick_Config(SystemCoreClock/1000);
  // GPIOD Periph clock enable
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
  GPIO_InitTypeDef  GPIO_InitStructure;
  // Konfigurire PD12,13,14,15 als Ausgang
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12|GPIO_Pin_13|GPIO_Pin_14|GPIO_Pin_15;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOD, &GPIO_InitStructure);
}
 
int main(void) {
  SystemInit();
  initApplication();
  while(1) {
      GPIO_ResetBits(GPIOD,GPIO_Pin_15);
      GPIO_ResetBits(GPIOD,GPIO_Pin_14);
      GPIO_ResetBits(GPIOD,GPIO_Pin_13);
      GPIO_ResetBits(GPIOD,GPIO_Pin_12);
      delay(100);
      GPIO_SetBits(GPIOD,GPIO_Pin_15);
      GPIO_SetBits(GPIOD,GPIO_Pin_14);
      GPIO_SetBits(GPIOD,GPIO_Pin_13);
      GPIO_SetBits(GPIOD,GPIO_Pin_12);
      delay(100);
  }
  return 0;
}
void SysTick_Handler(void) {
  --counter;
}

Ich wäre euch sehr dankbar, wenn ihr eine Lösung für dieses Problem 
hättet.

PS: OS ist Ubuntu 13.10 mit arm-none-eabi und st-link
    Beide Programme sind in der Kommandozeile zuhause, also sthet mir 
keine IDE zur Verfügung.

[Peter II (Gast)]

machen mal die Variabel volatile, sonst wird sie wegoptimiert.

volatile signed int counter = 100;

[Mike (Gast)]

Volatile ?

[holger (Gast)]

>Ich wäre euch sehr dankbar, wenn ihr eine Lösung für dieses Problem
>hättet.

Ein Counter der negativ wird ist Quatsch. Es reicht ihn auf
Null zu zählen.

volatile uint32_t counter;

//delay funktion abhängig von SysTick_Config
void delay(uint32_t ms)
{
  counter = ms;  
  while(counter);
}

void SysTick_Handler(void)
{
  if(counter) counter--;
}

Und schon ist der Drops gelutscht;)

[holger (Gast)]

Einen Nachteil hat die Geschichte allerdings.
Wenn der Systick Interrupt kurz bevor steht
und man ein delay(1); macht wird das delay
keine ganze Millisekunde dauern. Das Teil kann auch sofort
zurückkommen;)

[ratloser_stm_user (Gast)]

Vielen Dank. Jetzt funktioniert das ganze prima.

holger schrieb:
> Einen Nachteil hat die Geschichte allerdings.
> Wenn der Systick Interrupt kurz bevor steht
> und man ein delay(1); macht wird das delay
> keine ganze Millisekunde dauern. Das Teil kann auch sofort
> zurückkommen;)

Das dürfte doch kein Problem mehr sein, wenn ich die SysTickClock auf

 SysTick_Config(SystemCoreClock/1000 - 1);

 seze, oder?

(nicht mehr) ratloser_stm_user

PS: was macht volatile eigentlich genau?? Ich weiß nur, dass auf die 
Varablen anders zugegriffen wird, um sie aktuell zu halten.
Und vor allem warum und was optimieren die Funktionen?

[Ingo (Gast)]

Ich würde in deiner Delay Funktion einfach nochmal ne ms drauf 
addieren...

[Dr. Sommer (Gast)]

Besser so

//delay funktion abhängig von SysTick_Config
void delay(uint32_t ms) {
   counter = ms;
   while(counter) __WFI ();
}

Zum Heizleistung einzusparen.

[ratloser_stm_user (Gast)]

Dr. Sommer schrieb:
> __WFI ();

Was ist das denn??

[ratloser_stm_user (Gast)]

ratloser_stm_user schrieb:
> PS: was macht volatile eigentlich genau?? Ich weiß nur, dass auf die
> Varablen anders zugegriffen wird, um sie aktuell zu halten.
> Und vor allem warum und was optimieren die Funktionen?
Kann mir hierauf jmd einen Link oder eine Antwort geben?

[N.G. (Gast)]

Schau ins FAQ hier
Der Abschnitt heißt: was hat es mit volatile auf sich?
Sry, dass ich den link grad net da hab

[Dr. Sommer (Gast)]

ratloser_stm_user schrieb:
> Dr. Sommer schrieb:
>> __WFI ();
>
> Was ist das denn??
Wait For Interrupt. Legt den Core schlafen bis ein Interrupt - wie der 
SysTick Interrupt - kommt. So muss er nicht mit 168 MHz nichts tun. 
Reduziert den Stromverbrauch um Größenordnungen...
Siehe S. 683 im ARM v7-M Architecture Reference Manual.

[ratloser_stm_user (Gast)]

N.G. schrieb:
> Schau ins FAQ hier

Jo vielen Dank, jetz hab ichs verstanden.

Dr. Sommer schrieb:
> Wait For Interrupt. Legt den Core schlafen bis ein Interrupt

also im rinzip nicts anderes als wenn ichs net hinschreibe, nur dass der 
Prozessor schläft(also nichts verbraucht).
1.)Aber wenn er den Prozessor nur zu irgendeinem Interrupt hochfährt, 
kann das doch irgendein X-beliebiger sein, oder?
2.)Wenn der Prozessor aus dem Interrupt rausgeht, wird im Ablauf normal 
fortgefahren?

[Dr. Sommer (Gast)]

ratloser_stm_user schrieb:
> also im rinzip nicts anderes als wenn ichs net hinschreibe, nur dass der
> Prozessor schläft(also nichts verbraucht).
Ja.
> 1.)Aber wenn er den Prozessor nur zu irgendeinem Interrupt hochfährt,
> kann das doch irgendein X-beliebiger sein, oder?
Ja, er wacht bei allen Interrupts auf. Wenn kein Interrupt-Handler 
definiert ist wird er wie ohne Verwendung von __WFI() auch abstürzen 
(einer der Error-Handler wird aufgerufen).
> 2.)Wenn der Prozessor aus dem Interrupt rausgeht, wird im Ablauf normal
> fortgefahren?
Wenn alle Interrupts abgehandelt sind kehrt __WFI() zurück; in diesem 
Fall wird es direkt wieder aufgerufen wegen der Schleife bzw.

[ratloser_stm_user (Gast)]

Dr. Sommer schrieb:
> ratloser_stm_user schrieb:
>> also im rinzip nicts anderes als wenn ichs net hinschreibe, nur dass der
>> Prozessor schläft(also nichts verbraucht).
> Ja.
>> 1.)Aber wenn er den Prozessor nur zu irgendeinem Interrupt hochfährt,
>> kann das doch irgendein X-beliebiger sein, oder?
> Ja, er wacht bei allen Interrupts auf. Wenn kein Interrupt-Handler
> definiert ist wird er wie ohne Verwendung von __WFI() auch abstürzen
> (einer der Error-Handler wird aufgerufen).
>> 2.)Wenn der Prozessor aus dem Interrupt rausgeht, wird im Ablauf normal
>> fortgefahren?
> Wenn alle Interrupts abgehandelt sind kehrt __WFI() zurück; in diesem
> Fall wird es direkt wieder aufgerufen wegen der Schleife bzw.

Das heißt, dass ich ihn lieber nicht benutze, nur um ein paar mA zu 
sparen...
Nicht dass ich dann beim nächsten Interrupt hier die nächste Frage 
stelle.

[Dr. Sommer (Gast)]

ratloser_stm_user schrieb:
>>> 2.)Wenn der Prozessor aus dem Interrupt rausgeht, wird im Ablauf normal
>>> fortgefahren?
>> Wenn alle Interrupts abgehandelt sind kehrt __WFI() zurück; in diesem
>> Fall wird es direkt wieder aufgerufen wegen der Schleife bzw.
>
> Das heißt, dass ich ihn lieber nicht benutze, nur um ein paar mA zu
> sparen...
Was warum nicht?! Es ist funktional kein Unterschied zu ohne Nutzung 
von __WFI() da, es braucht nur weniger Strom und vermeidet das sehr 
intensive Tun von nichts.
> Nicht dass ich dann beim nächsten Interrupt hier die nächste Frage
> stelle.
Wieso das? Du verwendest alle Interrupts einfach ganz normal wie immer.

[ratloser_stm_user (Gast)]

Dr. Sommer schrieb:
> Wieso das? Du verwendest alle Interrupts einfach ganz normal wie immer.

jaja, Denkfehler.

Vielen Dank für alle Antworten