STM32F103C8, einfacher LED Blinkerei

GG Gast 13.02.2017 15:52 #4900384

Lesenswert?

•

Hallo zusammen! Bislang habe ich eigentlich nur uCs á la 328p 
programmiert... und taste mich gerade vorsichtig an einen ARM M3 heran. 
Ich habe mir ein Board und einen Programmer zugelegt (siehe Anhang). 
Nachdem ich mit CooCox diverse Probleme hatte und noch immer habe, bin 
ich auf EmBitz umgestiegen. Hier funktioniert soweit scheinbar alles 
einwandfrei. Zum flashen nutze ich CoFlash von ST (funktioniert wohl 
auch einwandfrei). Nun wollte ich einfach mal eine LED zum blinken 
bringen... doch nun verhält sich der Code recht seltsam und ich weiß 
nicht wieso?!

#include "stm32f10x.h"

int main(void)
{
  unsigned long c = 0;

  SystemInit();

  GPIO_InitTypeDef  GPIO_InitStructure;

  RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);

  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_13;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
  GPIO_Init(GPIOC, &GPIO_InitStructure);

    while(1)
    {
      GPIO_WriteBit(GPIOC, GPIO_Pin_13, Bit_SET);
      for(c=0;c<100000;c++);

      GPIO_WriteBit(GPIOC, GPIO_Pin_13, Bit_RESET);
      for(c=0;c<100000;c++);
    }
}

Wenn man die for-Schleifen wie oben gezeigt bis 100000 zählen läßt, ist 
die LED aus! Zählen sie nur bis 1000, leuchtet die LED minimal. Bei 100 
mit etwa 50% Intensität. Bei 10 und 1 hell!

Wieso? Sollte sie nicht immer langsamer blinken, desto größer die Grenze 
gewählt wird? Und noch mal... es blinkt NICHTS! Es verhält sich ehr wir 
ein DAC... ???

Angehängte Dateien:

stm32f103c8.jpg (60 KB)

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Lothar M. (lkmiller) Moderator (Firma: Titel) 13.02.2017 15:58 #4900390

Lesenswert?

•

▲
▼

Welche Optimierungsstufe hast du eingestellt?
Ein halbwegs schlauer Compiler optimiert dir die Schleifen einfach raus, 
weil sie am Programmverlauf an sich nichts, sondern nur die 
Programmdauer ändern. Und das primäre Ziel ist eine möglichst kurze 
Programmausführungszeit bei geringem Speicherbedarf.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

GG Gast 13.02.2017 16:09 #4900404

Lesenswert?

•

▲
▼

Bullseye!!! :D

Die Optimierung Stand auf Stufe 2. Bei -O0 läuft alles wie gewünscht! 
Perfekt! ... DANKE!

Antwort Zitieren Bearbeiten Löschen Beitrag melden

PascalFan Gast 13.02.2017 16:10 #4900406

Lesenswert?

•

▲
▼

ordne es anders an:

    while(1)
    {

      for(c=0;c<100000;c++) GPIO_WriteBit(GPIOC, GPIO_Pin_13, Bit_SET);

      for(c=0;c<100000;c++) GPIO_WriteBit(GPIOC, GPIO_Pin_13, 
Bit_RESET);

    }

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Lothar M. (lkmiller) Moderator (Firma: Titel) 13.02.2017 16:13 #4900410

Lesenswert?

•

▲
▼

GG schrieb:
> Bullseye!!! :D
Naja, blind geworfen... ;-)

> Die Optimierung Stand auf Stufe 2. Bei -O0 läuft alles wie gewünscht!
Es ist übrigens eine gute Idee, hin- und wieder mal die 
Optimierungsstrategie umzuschalten und zu schauen, ob das Design noch 
"läuft". Sonst erlebt man evtl. beim nächsten Update mit einer neuen 
Compilerversion eine unliebsame Überraschung.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

GG Gast 13.02.2017 16:20 #4900420

Lesenswert?

•

▲
▼

Ok, wird gemacht. Dennoch verstehe ich nicht, was da "optimiert" wurde. 
Selbst wenn dem Compiler die for-Schleifen unsinnig erscheinen und er 
diese einfach entfernt hat, hätte die LED unabhängig vom eingestellten 
Wert immer gleich "leuchten" müssen... ???

Antwort Zitieren Bearbeiten Löschen Beitrag melden

2cents Gast 13.02.2017 16:28 #4900433

Lesenswert?

•

▲
▼

ersetze
unsigned long c = 0;
durch
volatile unsigned long c = 0;

dann sollte es mit voller Optimierung auch wieder laufen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Lothar M. (lkmiller) Moderator (Firma: Titel) 13.02.2017 16:34 #4900445

Lesenswert?

•

▲
▼

2cents schrieb:
> dann sollte es mit voller Optimierung auch wieder laufen.
Dann sollte man zumindest das c vorher noch zur globalen Variablen 
machen. Denn c ist innerhalb der main-Routine definiert, deshalb 
kann es sich gar nicht (z.B. durch einen Interrupt) von ausserhalb 
ändern. Das weiß der Compiler auch.

GG schrieb:
> Ok, wird gemacht. Dennoch verstehe ich nicht, was da "optimiert" wurde.
Ich sehe mir da immmer das erzeugte Compilat an. Man lernst mit solchen 
Dreizeilern seinen Compiler ganz gut kennen...

Antwort Zitieren Bearbeiten Löschen Beitrag melden

GG Gast 13.02.2017 16:38 #4900451

Lesenswert?

•

▲
▼

2cents schrieb:
> ersetze
> unsigned long c = 0;
> durch
> volatile unsigned long c = 0;
>
> dann sollte es mit voller Optimierung auch wieder laufen.

ja, das funktioniert! :)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Quatschkopf Gast 13.02.2017 21:55 #4900850

Lesenswert?

•

▲
▼

Als Delay-Funktion empfehle ich:

void Delay(__IO uint32_t nCount)
  while(nCount--)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jim M. (turboj) 14.02.2017 11:43 #4901358

Lesenswert?

•

▲
▼

Quatschkopf schrieb:
> Als Delay-Funktion empfehle ich:

Leider hat die AFAIK je nach Compiler Optimierungsstufe 
unterschiedliches Delay.

Für konstantes Delay muss man Hardware Timer oder Assembler bemühen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Nop Gast 14.02.2017 11:59 #4901377

Lesenswert?

•

▲
▼

Delay über Dummy-Operationen war schon vor 30 Jahren Unsinn.

Damals(tm) hatten DOS-Rechner tatsächlich einen Turbo-Knopf, mit dem man 
von 8MHz auf höhere Taktung gehen konnte, für Anwendungen. Weil viele 
Spieleprogrammierer genau diese Methode für die Warteroutinen genutzt 
haben.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Ruediger A. (rac) (Firma: keine) 14.02.2017 12:15 #4901397

Lesenswert?

•

▲
▼

Nop schrieb:
> Delay über Dummy-Operationen war schon vor 30 Jahren Unsinn.
>
> Damals(tm) hatten DOS-Rechner tatsächlich einen Turbo-Knopf, mit dem man
> von 8MHz auf höhere Taktung gehen konnte, für Anwendungen. Weil viele
> Spieleprogrammierer genau diese Methode für die Warteroutinen genutzt
> haben.


Jim M. schrieb:
>
> Für konstantes Delay muss man Hardware Timer oder Assembler bemühen.

was genau meinst Du mit "Hardware Timern"? Externe RTCs? Jeder 
Prozessortimer leitet sich von der Taktfrequenz ab, also ist Alles, was 
im Controller passiert, bei Änderung der Taktung beeinträchtigt. Das 
passiert aber zumindestens bei Embedded relativ selten, und wenn, 
funktioniert so ziemlich nichts mehr wie erwartet.

WENN schon ein busy waiting, kann man das beim Cortex M über den DWT 
cycle counter machen, dessen Stand abhängig vom Takt immer einen 
verlässlichen Wert liefert. Da die Taktfrequenz i.d. Regel aus dem RCC 
ausgelesen werden kann, ist sogar die Mathematik relativ einfach, das 
erforderliche Delta an Taktzyklen zu einem Delay auch bei sich ändernden 
Taktfrequenzen für ein "absolutes delay" dynamisch zu berechnen, aber 
wie gesagt sind dynamisch variable Taktungen ein eher akademisches 
Problem.

Was Alles natürlich nichts daran ändert, dass busy waiting nur in 
seltenen Fällen eine Berechtigung hat.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Nico W. (nico_w) 14.02.2017 12:44 #4901434

Lesenswert?

•

▲
▼

Hat der Cortex M1 überhaupt nen DWT? Ist doch afaik erst in nem M3?!?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Ruediger A. (rac) (Firma: keine) 14.02.2017 13:01 #4901454

Lesenswert?

•

▲
▼

Nico W. schrieb:
> Hat der Cortex M1 überhaupt nen DWT? Ist doch afaik erst in nem M3?!?

guter Punkt, aber wie kommst Du darauf, dass der 32F103xx auf einem M1 
basiert? lt. ST Dokument RM0008 ist das ein M3?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Nico W. (nico_w) 14.02.2017 13:57 #4901521

Lesenswert?

•

▲
▼

Ruediger A. schrieb:
> lt. ST Dokument RM0008 ist das ein M3?

Ja, da hast du auch wieder recht :)

Ich nutze bei meinem Projekt Assembler für ein kurzes Delay.

Ich nutze den DWT gerne dazu mein Projekt genauer zu betrachten wie 
lange die Funktionen brauchen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

STM32F103C8, einfacher LED Blinkerei

Antwort schreiben