stm32 harte nuß !

[Reiner D. (dollreiner)]

Hallo,

ich beginne mit dem stm32f4 discovery. em::blocks als ide, mit dem 
avr-gcc compiler ("bare metal").

folgendes progrämmchen läuft prima :

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

volatile u8 sysTickCounter=0;

void initApplication()
{
  SysTick_Config(SystemCoreClock/100);

  // GPIOD Periph clock enable
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

  GPIO_InitTypeDef  GPIO_InitStructure;

  // Konfigurire PD15 als Ausgang
  GPIO_InitStructure.GPIO_Pin = 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);

  //  Konfiguriere PA0
  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_OD;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOA, &GPIO_InitStructure);

}

int main(void)
{
  SystemInit();
  initApplication();
  do
    {
        if (GPIOA->IDR & 0x0001)
        {
            GPIO_SetBits(GPIOD,GPIO_Pin_15);
            //GPIO_ResetBits(GPIOD,GPIO_Pin_15);
        }
        else
        {
            //GPIO_SetBits(GPIOD,GPIO_Pin_15);
            GPIO_ResetBits(GPIOD,GPIO_Pin_15);
        }
    }
  while (1);
  return 0;
}

aber jetzt kommts : wenn ich die leuchtlogik umdrehe (set <-> reset, wie 
in den kommentarzeilen) geht nichts !

auch wenn ich ne blinkschleife einbaue : nichts !!

ich werd wahnsinnig ...

[Frank M. (ukw) (Moderator)]

Und was passiert bei

  GPIO_WriteBit(GPIOD, GPIO_Pin_15, SET);

bzw.

  GPIO_WriteBit(GPIOD, GPIO_Pin_15, RESET);

?

[Dr. Sommer (Gast)]

Reiner Doll schrieb:
> RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
Vielleicht auch mal den Takt für GPIOA einschalten...

[Jay (Gast)]

Hi,

was bedeutet die Zeile:
if (GPIOA->IDR & 0x0001)
?

[Jay (Gast)]

... vergesst es. Ich hab den Quellcode nicht komplett gelesen.

[Dr. Sommer (Gast)]

Jay schrieb:
> if (GPIOA->IDR & 0x0001)
Abfragen ob der Pin PA0 auf '1' gesetzt ist.

[Reiner D. (dollreiner)]

hallo dr. sommer,

aber warum gehts dann so wie im text ??

egal. verzeih die dummy-frage : wie schalt ich den gpioa an den takt ?

[Frank M. (ukw) (Moderator)]

Reiner Doll schrieb:
> egal. verzeih die dummy-frage : wie schalt ich den gpioa an den takt ?

   RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE);

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

Reiner Doll schrieb:
> wie schalt ich den gpioa an den takt ?
Wie schaltest du denn den GPIO Port D an den Takt? Mein erster Versuch 
wäre, die Zeile zu kopieren und das D durch ein A zu ersetzen...

Oder eine kurze Google Umfrage zu starten:
https://www.google.de/search?q=RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIO

[Dr. Sommer (Gast)]

Reiner Doll schrieb:
> aber warum gehts dann so wie im text ??
Vielleicht ein Zufall. Wenn man Controller außerhalb der Spezifikation 
betreibt passieren komische Dinge. Außerdem hast du ja gar nicht gesagt, 
was "geht nichts" und "läuft prima" bedeutet.

Reiner Doll schrieb:
> egal. verzeih die dummy-frage : wie schalt ich den gpioa an den takt ?
Genauso wie bei GPIOD, und da hast du es ja schon erfolgreich gemacht. 
Hier bitte Transferleistung erbringen.

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

Dr. Sommer schrieb:
> bitte Transferleistung erbringen
Es gibt 2 Arten von Menschen:
1. solche, die aus unvollständigen Daten extrapolieren können.

[Reiner D. (dollreiner)]

;-)

  // GPIOD, GPIOA Periph clock enable
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE);

bringt nix, geht genausowenig ...

[Dr. Sommer (Gast)]

Reiner Doll schrieb:
> bringt nix, geht genausowenig ...
Erlätuere doch mal genau, was das heißt. Und auch, was in der 1. 
Variante funktioniert. Zwischen den Tests mal das Board komplett vom 
Strom trennen, um einen "echten" Neustart des Controllers zu 
garantieren.

[Frank M. (ukw) (Moderator)]

Reiner Doll schrieb:
> bringt nix, geht genausowenig ...

Ohne zu wissen, was Dein (...->IDR &0x0001) überhaupt macht, prüfst Du 
doch, ob der User-Button benutzt wurde, oder?

Prbiere mal folgenden Code:

#define BUTTON_PERIPH   RCC_AHB1Periph_GPIOA
#define BUTTON_PORT     GPIOA
#define BUTTON_PIN      GPIO_Pin_0

void button_init (void)
{
    GPIO_InitTypeDef gpio;

    RCC_AHB1PeriphClockCmd(BUTTON_PERIPH, ENABLE);

    // Config als Digital-Eingang
    gpio.GPIO_Mode = GPIO_Mode_IN;
    gpio.GPIO_PuPd = GPIO_PuPd_NOPULL;
    gpio.GPIO_Pin = BUTTON_PIN;
    GPIO_Init(BUTTON_PORT, &gpio);
}

int button_pressed (void)
{
    if (GPIO_ReadInputDataBit(BUTTON_PORT, BUTTON_PIN) == Bit_RESET)
    {
        return 0;
    }
    return 1;
}

und ersetze Deine Abfrage durch:

   if (button_pressed ())
   ....

P.S.
Auch für die LED kann man solche schönen Funktionen schreiben, z.B. so:

#define LED_PORT    GPIOD
#define LED_PERIPH  RCC_AHB1Periph_GPIOD

#define LED_GREEN   GPIO_Pin_12
#define LED_ORANGE  GPIO_Pin_13
#define LED_RED     GPIO_Pin_14
#define LED_BLUE    GPIO_Pin_15

void
led_init (void)
{
    GPIO_InitTypeDef gpio;

    RCC_AHB1PeriphClockCmd(LED_PERIPH, ENABLE);     // enable clock for PortD

    gpio.GPIO_Pin   = (LED_BLUE|LED_RED|LED_ORANGE|LED_GREEN);
    gpio.GPIO_Mode  = GPIO_Mode_OUT;
    gpio.GPIO_OType = GPIO_OType_PP;
    gpio.GPIO_PuPd  = GPIO_PuPd_NOPULL;
    gpio.GPIO_Speed = GPIO_Speed_50MHz;

    GPIO_Init(LED_PORT, &gpio);
}

void
led_on (uint16_t led)
{
    GPIO_WriteBit(LED_PORT, led, SET);
}

void
led_off (uint16_t led)
{
    GPIO_WriteBit(LED_PORT, led, RESET);
}

Dann reduziert sich Deine main() auf:

    button_init();
    led_init();

    while (1)
    {
        if (button_pressed())
           led_on (LED_BLUE);
        else
           led_off (LED_BLUE);
    }
}

Ist doch wesentlich lesbarer, oder?

[Reiner D. (dollreiner)]

habs ausprobiert.

der code von frank macht das gleiche wie meiner : auf knopfdruck wird 
die blaue led geschalten. in der "frank-variante" :

        if (button_pressed ())
        {
            GPIO_ResetBits(GPIOD,GPIO_Pin_15);
            //GPIO_SetBits(GPIOD,GPIO_Pin_15);
        }
        else
        {
            GPIO_SetBits(GPIOD,GPIO_Pin_15);
            //GPIO_ResetBits(GPIOD,GPIO_Pin_15);
        }


so gehts. druck auf den schwarzen taster -> blaue led aus.

aber so :


        if (button_pressed ())
        {
            //GPIO_ResetBits(GPIOD,GPIO_Pin_15);
            GPIO_SetBits(GPIOD,GPIO_Pin_15);
        }
        else
        {
            //GPIO_SetBits(GPIOD,GPIO_Pin_15);
            GPIO_ResetBits(GPIOD,GPIO_Pin_15);
        }

gehts eben nicht. es passiert gar nix. (ob : RCC_AHB1Periph_GPIOA, 
ENABLE gesetzt ist, ändert auch nix. hab ich jetzt natürlich, danke 
dafür nochmal)

[(prx) A. K. (prx)]

Reiner Doll schrieb:
> so gehts. druck auf den schwarzen taster -> blaue led aus.

Und auch wieder retour, wenn Taster losgelassen?

[Frank M. (ukw) (Moderator)]

Reiner Doll schrieb:
> so gehts. druck auf den schwarzen taster -> blaue led aus.

Auf den SCHWARZEN Taster?!?!?!?

Das ist der RESET-Button! :-))))))))))))

Du musst schon den blauen Taster nehmen.

Hahahahaaaa, der war echt gut!

[Frank M. (ukw) (Moderator)]

A. K. schrieb:
> Und auch wieder retour, wenn Taster losgelassen?

Klar doch, wenn er den Reset-Taster wieder loslässt ;-)

[Reiner D. (dollreiner)]

das ist der knaller ...

es geht aber mit der blauen taste überhaupt nicht, beide varianten 
nicht.
wenn der schwarze reset macht, erklärt das meinen testfehler : das 
schaut genauso aus, als würde die eine variante funktionieren  .. 
während des reset ist die led aus.

also : es geht keines von meinen programmen. ;-((

[Frank M. (ukw) (Moderator)]

Reiner Doll schrieb:
> also : es geht keines von meinen programmen. ;-((

Das wundert mich aber. Die oben von mir skizzierten Funktionen habe ich 
selbst so ausprobiert und im Einsatz. Das kann ich aber erst heute abend 
testen.

[Matthias L. (Gast)]

Du solltest hier anfangen:

http://www.diller-technologies.de/stm32.html#start

hat mir auch geholfen...

[(prx) A. K. (prx)]

Frank M. schrieb:
> Klar doch, wenn er den Reset-Taster wieder loslässt ;-)

Der war gut!

[Frank M. (ukw) (Moderator)]

Matthias Lipinsky schrieb:
> Du solltest hier anfangen:
>
> http://www.diller-technologies.de/stm32.html#start

Genau da ist er doch gerade, nämlich beim Schalten von LEDs. Leider 
kann man das Diller-Beispiel genau hier nicht verwenden, weil die 
Port-Definitionen von der Numerierung her für den STM32F1 komplett 
anders sind.

Reiner hat das schon richtig gemacht. Er sollte aber trotzdem mal die
GPIO_WriteBit() Funktion nehmen.

[Reiner D. (dollreiner)]

danke für den tipp mit diller. hatte ich schon probiert, wegen der nicht 
kompatilen libraries (f10) dann aber aufgegeben.

auch das habe ich schon probiert :

        if (button_pressed ())
        {
            //GPIO_ResetBits(GPIOD,GPIO_Pin_15);
            //GPIO_SetBits(GPIOD,GPIO_Pin_15);
            GPIO_WriteBit(GPIOD, GPIO_Pin_15, SET);
        }
        else
        {
            //GPIO_SetBits(GPIOD,GPIO_Pin_15);
            //GPIO_ResetBits(GPIOD,GPIO_Pin_15);
            GPIO_WriteBit(GPIOD, GPIO_Pin_15, RESET);
        }


... no go. (trotz gezieltem druck auf den BLAUEN taster ;-)

wahnsinn. ich habe vor nem jahr ungefähr mit dem atmega128 gespielt. da 
hat die einarbeitung genau einen nachmttag gedauert. das hier ist ne 
andere liga.

[Franz (Gast)]

Weißt du was AVR oder STM32 sind?

Reiner Doll schrieb:
> ich beginne mit dem stm32f4 discovery. em::blocks als ide, mit dem
> avr-gcc compiler ("bare metal").

[Uwe B. (derexponent)]

den gleichen Fehler hatten wir hier schonmal im Forum

diese Zeile ist schuld :

SysTick_Config(SystemCoreClock/100);


du schaltest den Timer ein, hast aber keine ISR dafuer
programmiert

ergo landet die CPU im HardFaultHandler und
macht eine while(1)

Gruss Uwe

[Frank M. (ukw) (Moderator)]

Reiner Doll schrieb:
> wahnsinn. ich habe vor nem jahr ungefähr mit dem atmega128 gespielt. da
> hat die einarbeitung genau einen nachmttag gedauert. das hier ist ne
> andere liga.

Ich spiele auch erst seit 2 Wochen mit dem STM32F4-Disco-Board herum. 
Wenn man einmal die (vermeintlichen) Einstiegshürden überwunden hat, 
dann fluppt es danach wesentlich einfacher als bei den AVRs. Hab etwas 
Geduld :-)

Schau Dir mal die einzelnen Projekte von

   http://mikrocontroller.bplaced.net/wordpress/?page_id=744

an... schön von oben nach unten. Das hat mir mehr als alles andere (div. 
Tutorials etc) gebracht. Eigentlich ist von allem, was das Disco-Board 
so bietet, etwas dabei.

[Frank M. (ukw) (Moderator)]

Uwe B. schrieb:
> diese Zeile ist schuld :
>
> SysTick_Config(SystemCoreClock/100);

Upps, Du hast recht. Die Zeile muss wech.

[npn (Gast)]

Reiner Doll schrieb:
> ich beginne mit dem stm32f4 discovery. em::blocks als ide, mit dem
> avr-gcc compiler ("bare metal").

Stimmt!
Franz hats gesehen... Wäre mir nicht gleich aufgefallen.
Stell mal statt dem AVR-GCC den STM32-Compiler ein (müßte "ARM-GCC" 
heißen).

[A. B. (funky)]

probier doch erstmal die LED überhaupt blinken zu lassen ohne jegliche 
Benutzerinteraktion...

ne Schleife, Pausen und On/Off


desweiteren Beitrag "STM32F4 Taster"

schmeiss also mal dein systick_config rasu und schau was dann passiert.

Würde auch zu deiner Beschreibugn passen. Der Code läuft einmal durch 
und setzt die LED ohne Tastendruck, danach hängt das Ding in der Systick 
Schleife.

Änderst du den Code dahingeghend das die LED nach Tastendruck gesetzt 
wird, siehst du nix, da dein Code nach 100us in der Schleife hängt

Halt doch mal den Taster gedrückt bei Variante 2 und starte den uC dann. 
Theoretisch müsste die LED dann ja leuchten


Hat em::Blocks keinen Debugger Support?

[A. B. (funky)]

Oh...Uwe B. war schneller. Hatte geschrieben und erst später abgeschickt

[Reiner D. (dollreiner)]

da wär ich nie draufgekommen. danke !!

jetzt geht alles einwandfrei ;-)



@franz : avr/arm verwechselt oben (arm gcc), sorry.



jetzt mal blinken, dann ein wenig uart, dann a/d-wandler, das wird 
sicher heiter mit dem ding.

[Grobi (Gast)]

Reiner ich kann dir das aktuellle emblocks und die aktuelle stm32cubef4 
von stm empfehlen sowie das cubemx. Nimmt einem doch schon was an Arbeit 
mit der ganzen initialisierung etc. und Ansteuerung der peripherie ab. 
Und wenn du ganz genau wissen möchtest wie das alles so funzt kannste 
dir auch immer noch den quellcode der libs anschauen, die Jungs von STM 
wissen doch schon eigentlich ganz gut was sie da tun... obwohl es immer 
noch ein paar "bugs" darin gibt, aber dazu findet sich genug in diversen 
foren etc.

[Dr. Sommer (Gast)]

Grobi schrieb:
> die Jungs von STM
> wissen doch schon eigentlich ganz gut was sie da tun...
Ahaha, der war gut. Sobald die ST-Leute irgendwas mit Software 
anfassen, gehts schief. Die "Cube" Libraries sind da noch schlimmer als 
die alten "Standard Peripheral Libraries" - Struktur noch vermurkster, 
noch (unnötig!) ineffizienter...


Problem: "Das API unserer Library ist so umständlich und kompliziert"
Normale Programmierer: "Wir verbessern das API"
ST-Programmierer: "Wir bauen einen Code-Generator (STM32CubeMX), um die 
Library-Aufrufe zu generieren"

[Chris D. (myfairtux) (Moderator)]

Dr. Sommer schrieb:
> Grobi schrieb:
>> die Jungs von STM
>> wissen doch schon eigentlich ganz gut was sie da tun...
> Ahaha, der war gut. Sobald die ST-Leute irgendwas mit Software
> anfassen, gehts schief. Die "Cube" Libraries sind da noch schlimmer als
> die alten "Standard Peripheral Libraries" - Struktur noch vermurkster,

Ja? Finde ich nicht. meinem Eindruck nach wurde da etwas entschlackt.

> noch (unnötig!) ineffizienter...

Ok, darüber kann man reden :-)

> ST-Programmierer: "Wir bauen einen Code-Generator (STM32CubeMX), um die
> Library-Aufrufe zu generieren"

Den Generator finde ich nicht schlecht - auch weil man da sich sehr 
schön den passenden Chip raussuchen kann ohne sich durch die 
gehäusetypen wühlen zu müssen und direkt sieht, wo Pinbelegungen sich 
gegenseitig ausschließen.

ST zwingt einen ja auch nicht dazu, die Bibliotheken zu nutzen :-)