STM32F103 GPIO

Sieh Dir die Beispiele an, die bei der SPL oder HAL dabei sind.
Du findest einiges beim Hersteller:
http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF189782#

Moin,

ich würde dir empfehlen, dir mal das Programm CubeMx von STM 
anzuschauen. Damit kannst du dir für deinen Controller/dein Board die 
Initialisierung erzeugen lassen. Das wirft auch gleich eine Projektdatei 
für Keil (und andere IDE's raus) Meiner Meinung nach ganz gut, um zu 
verstehen, wie das funktioniert.

Ansonsten steht auch alles, was du brauchst in der Dokumentation der HAL 
(in deinem Fall natürlich zur HAL F1).

Gruß

Zu praktisch allen Controllern gibt es das "C"-Äquivalent zu Hello 
World.

Dabei wird fast immer ein Port (mit LED) ein- bzw. ausgeschaltet.

Neben einigem an Initialisierung gehört auch dazu, dass (mindestens) ein 
Port vom Reset-Zustand (Input) in den Ausgabezustand gebracht wird. In 
einer späteren Hauptschleife wird dann abwechselnd der Port gesetzt und 
wieder zurückgesetzt.

Also einfach mal gucken.

Moby schrieb:
> W.S. schrieb:
> Kraft hast, es verstehend zu lesen, dann befasse dich mit irgend etwas
> anderem.
>
> Richtig. Zum Beispiel mit einfachen AVRs, um damit viel schneller ans
> Ziel zu kommen. ARM-Konfiguritis muß ja nicht jedermans Leidenschaft
> sein ;-)

Ist bei den gängigen arm kein bisschen anders oder komplizierter als bei 
avr. Teilweise sogar massiv einfacher und logischer.

Moby schrieb:
> Schon mal Ports und eine LED unter AVR gesetzt?

Ja. Funktioniert auch nicht anders als bei nem ARM.

Bernd K. schrieb:
> Ist bei den gängigen arm kein bisschen anders oder komplizierter als bei
> avr. Teilweise sogar massiv einfacher und logischer.

Erklärst Du mir dann mal wo ich beim AVR den Port einschalte, die 
Frequenz setze oder entscheiden muß, ob ich PullUp oder PullDown 
einschalte.

Es ist nicht schwieriger, aber doch anders und deutlich komplexer.

Oliver R. schrieb:
> Erklärst Du mir dann mal wo ich beim AVR den Port einschalte,

Beim AVR darf man sämtliche Peripherie die man nicht nutzt jedesmal erst 
ausschalten, also genau das selbe Prinzip nur mit schwachsinnigen 
Defaults.

> die Frequenz setze oder entscheiden muß, ob ich PullUp oder PullDown
einschalte.

Was willst Du? Die stehen alle auf brauchbaren Default-Werten, die 
Pullups sind selbstverständlich ausgeschaltet solange bis Du sie 
brauchst. Welche Frequenz willst Du wählen? Die Slew-Rate? Die ist ab 
Reset auch auf vernünftigen Default-Werten bei den Controllern die das 
überhaupt unterstützen.

Der AVR hat übrigens auch Pullups, die sind aber dort 
schwachsinnigerweise im PORT-Register, also eine verwirrende 
Mehrfachbelegung der selben Bits, als ob der auch nur einen Cent 
billiger geworden wäre durch das Einsparen eines weiteren Registers.

Einfacher oder irgendwie anders als jeweils ein Bit im PDDR und eins in 
PDOR zu setzen um eine LED einzuschalten wirds dadurch aber trotzdem 
nicht.

Typischer C Aufwand, um ne ARM-LED einzuschalten bzw. einschalten zu 
können:


/* GPIOD Takt einschalten  */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);

/* Konfiguriere GPIO Port D15 */
GPIO_InitTypeDef  GPIO_InitStructure;
GPIO_StructInit (&GPIO_InitStructure);
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);

GPIO_SetBits(GPIOD,GPIO_Pin_15);


Unter AVR z.B. :

sbi DDRA,0
sbi PORTA,0

um gleich mal die Vorteile einer einfachen Systemarchitektur (AVR) mit 
den  wenigen nötigen Zeichen einer kurzen Sprache (ASM) kombiniert zu 
demonstrieren.

Alles Reiner Masochismus, zumindest wenns die Anwendung (oder der Boss) 
nicht erfordert ;-)

Moby A. schrieb:
> Typischer C Aufwand, um ne ARM-LED einzuschalten bzw. einschalten
> zu
> können:
> [bla]

Du verzerrst wieder mal die Wahrheit. Du vergleichst einen Schnipsel 
C-Code der ohne Not die stdperipheral-Lib von ST verwendet mit zwei aus 
dem Zusammenhang gerissenen ASM-Instruktionen wobei Du komplett das 
notwendige Brimborium drumherum verschweigst das ein Anwender braucht 
bis er AVR-ASM gelernt, deinen ASM-Schnipsel assembliert, mit der 
Vektortabelle und den Startup gelinkt und geflasht bekommt.

Der Anfänger fängt in der Regel mit C und hinter der ersten geschweiften 
Klammer von main() an und den Rest davor bekommt er frei Haus vom 
Hersteller oder von Beispielprojekten geliefert.

Hier ein Blinky auf einem STM32F401RE, dieses Device ist verglichen zu 
Deinem ATTiny so ziemlich das Über-Monster, trotzdem läuft das Blinky 
kein bisschen anders ab als das vergleichbare C-Blinky auf nem Tiny.

Die graue Schrift sind übrigens Kommentare, die kannst Du rauslöschen. 
Ebenso die Leerzeilen, die dienen nur der Auflockerung, nicht daß Du 
noch unterstellst die wären bei ARM erforderlich oder würden den Code 
aufblasen.

1

#include <stm32f401xe.h>

2

3

4

/*

5

 * The green LED is connected to port A5,

6

 * see schematic of NUCLEO-F401RE board

7

 */

8

#define LED_GPIO        GPIOA

9

#define LED_PIN         5

10

11

12

/**

13

 * Quick 'n' dirty delay

14

 *

15

 * @param time the larger it is the longer it will block

16

 */

17

static void delay(unsigned time) {

18

    for (unsigned i=0; i<time; i++)

19

        for (volatile unsigned j=0; j<20000; j++);

20

}

21

22

23

/**

24

 * Hello world blinky program

25

 *

26

 * @return never

27

 */

28

int main(void) {

29

30

    /*

31

     * Turn on the GPIOA unit,

32

     * see section 6.3.9 in the manual

33

     */

34

    RCC->AHB1ENR  |= RCC_AHB1ENR_GPIOAEN;

35

36

37

    /*

38

     * Set LED-Pin as output

39

     * see section 8.4.1 in the manual

40

     */

41

    LED_GPIO->MODER |= (0b01 << (LED_PIN << 1));

42

43

44

    while(1) {

45

46

        /*

47

         * LED on (see section 8.4.7 in the manual)

48

         */

49

        LED_GPIO->BSRRL = (1 << LED_PIN);

50

51

        delay(200);

52

53

        /*

54

         *  LED off

55

         */

56

        LED_GPIO->BSRRH = (1 << LED_PIN);

57

58

        delay(200);

59

    }

60

}

ucc schrieb:
> Kann vielleicht jemand in Worten schreiben was alles gemacht werden muss
> um GPIO auf Output zu aktivieren?

Zwei Registerzugriffe:
* gpio-einheit aktivieren (Takt dafür einschalten)
* entsprechende pins als Ausgang konfigurieren. Fertig.

Zeig doch mal was du bisher hast damit man sehen kann wie du das 
überhaupt angehen willst, mit HAL oder auf dem blanken Silizium.

Hast Du das Reference Manual schon gefunden? Konkrete Frage zu einem 
konkreten Kapitel?

http://www.stm32duino.com/viewtopic.php?t=58

Bernd K. schrieb:
> Beim AVR darf man sämtliche Peripherie die man nicht nutzt jedesmal erst
> ausschalten, also genau das selbe Prinzip nur mit schwachsinnigen
> Defaults.

Ach was. Beim ARM darfst Du jedesmal einschalten, beim AVR schaltest 
Du nur dann was aus wenn der ohnehin karge Stromverbrauch wirklich mal 
ne Rolle spielt...

> Der AVR hat übrigens auch Pullups, die sind aber dort
> schwachsinnigerweise im PORT-Register, also eine verwirrende
> Mehrfachbelegung der selben Bits

Ja meine Güte, im Input-Modus hat das Port-Register halt die Funktion 
des Pullup-Schalters, im Output Modus werden damit die Pins selber 
gesetzt. Das ist weder schwachsinnig noch verwirrend sondern einfach 
clever und spart zusätzliche Konfigurationsregister ein. Ist natürlich 
nix für den konfigurationsregisterfreudigen ARM Fan- der braucht 
möglichst viele Register. Je komplexer umso besser...

Bernd K. schrieb:
> Du verzerrst wieder mal die Wahrheit. Du vergleichst einen Schnipsel
> C-Code der ohne Not die stdperipheral-Lib von ST verwendet mit zwei aus
> dem Zusammenhang gerissenen ASM-Instruktionen wobei Du komplett das
> notwendige Brimborium drumherum verschweigst das ein Anwender braucht
> bis er AVR-ASM gelernt, deinen ASM-Schnipsel assembliert, mit der
> Vektortabelle und den Startup gelinkt und geflasht bekommt.

Was für Brimborium? Notfalls stehen die beiden Asm-Instruktionen auch 
alleine im Flash und die LED geht an... An diese Einfachheit ist bei ARM 
nicht mal im Traum zu denken. Die paar Asm-Instruktionen sind samt AVR 
Datenblatt schnell gelernt- gar kein Vergleich mit ARM- wo schon aus 
Komplexitätsgründen Asm gar nicht mehr in Frage kommt.

Dr. Sommer schrieb:
> equ GPIOD, 0x40020C00
>
> // Initialisiere Pin PD15
> ldr r0, = GPIOD
> mov r1, (1 << 30)
> str r1, [r0, #0]
>
> // Setze Pin PD15
> mov r1, (1 << 15)
> str r1, [r0, #18]

Hier gings erstens um die Vorinitialisierung, um überhaupt auf den Pin 
so zugreifen zu können! Und zweitens ist sbi DDRA,0 + sbi PORTA,0 nach 
wie vor um Größenordnungen einfacher, um gerade mal einen Pin zu setzen.

> ganz ohne Bank-Umschaltung (wie bei AVR's mit > 64 KiB
> Speicher),

Wer braucht schon soviel bei typischen 8-Bit Programmen... Und ja, bei 
größerem Speicherbedarf ist 32Bit ARM im Vorteil und anzuraten, hat ja 
gar keiner bestritten.

> Spezial-Instruktionen je nach Speicher (wie LPM vs LD). Ist
> so im Endeffekt sogar einfacher.

Da geb ich Dir Recht. Was aber ist dieses Tröpfchen Einfachheit schon im 
komplexen ARM-Meer ;-)

> Achja, von wegen Einfachheit: Programmiere mal diese C-Funktion in
> AVR-Assembler:uint32_t shift (uint32_t x, uint32_t y) {
>   return x << y;
> }
>
> Im ARMv7M-Assembler sieht's so aus:shift:
>   lsl r0, r1
>   bx lr
> Na, ists auf dem AVR auch so einfach? Und auch so schnell (1 Takt)?

Nö. Ist halt ein 32-Bit Vorteil. Anwendungen die das brauchen dürfen 
gern mit ARM vorlieb nehmen.

Moby A. schrieb
> Alles Reiner Masochismus, zumindest wenns die Anwendung (oder der Boss)
> nicht erfordert ;-)

Dabei bleibts, auf jeden Fall mal für Portinitialisierungen und MSR ohne 
große Datenmengen und Berechnungen, die von 32-Bit Power abhängig wären.

Dr. Sommer schrieb:
> Das ist die Vortinitialisierung. Deswegen steht das auch im Kommentar.

Schön. Kann ich jetzt nicht nachprüfen. Trotzdem sieht jeder Blinder um 
wieviel einfacher die AVR-Formulierung ist.

> Beim AVR funktioniert das
> aber so auch nur mit den unteren Peripherie-Registern.

Das langt öfter als man glaubt ;-) Der Mehraufwand mit IN/OUT bzw. 
LDS/STS hält sich in allen anderen Fällen auch in Grenzen.

> Offenbar genug, dass es sich lohnt so etwas zu produzieren.

Stellt niemand in Frage. AVRs lohnen sich auch genug, um aktuell ca. 600 
Derivate davon zu produzieren ;-)

> Dies ist sogar ein großer Vorteil! Ein paar mehr Register initialisieren
> zu müssen stört mich nicht, aber von jeder Funktion eine *_P Variante
> schreiben zu müssen, damit man auf "progmem"-Variablen zugreifen kann
> (printf_P usw.), ist doch ein großer Aufwand.

Juckt mich im von mir favorisierten Asm samt verwendeter AVRs weniger.

> Es bleibt dabei, dass ARM mächtiger

Ja.

> und einfacher ist

Nein.

> und die Frickelei
> mit den winzigen AVR-8-Dingern reine Quälerei

Bei größeren Datenmengen und Berechnungen.

> wo jeder Speicherzugriff, jede Pointer-Arithmetik

Ach woher denn. Mir reichen die Adressierungsarten.

> und jedes "x << y" potentiell
> kompliziert ist.

Na ja, Shiftoperationen hat auch der AVR auf Lager, was ist daran 
kompliziert?

Dr. Sommer schrieb:
> das
> Vorhandensein der SBI/CBI Instruktionen als so gigantischen Vorteil
> betrachtest, was wohl alle mächtigen ARM-Instruktionen aufwiegen soll.

Hier wiegt das eine nicht das andere auf. Es ist nur so, daß die 
Kehrseite der ARM-Mächtigkeit ARM-Komplexität heißt. Deshalb kannst Du 
zwar auch mit

> Durch Verwendung der Bit-Banding Regionen
> kann man sich sogar sbi/cbi Makros definieren

die Einfachheit des AVRs nachbilden, ich nehm dafür aber lieber gleich 
das Original und erspare mir solche intellektuellen Kopfstände.

> Wie schreibst du denn da Funktionen, die z.B. einen string in einem
> anderen string suchen? Da brauchst du auch 4 Varianten

In aller Regel sucht man einen String im RAM in einer Flash-Stringliste.
Ansonsten wird RAM beim AVR gespart, bzw. er schränkt den Einsatzbereich 
der AVRs ein. Aber keine Sorge, er ist immer noch groß genug ;-)

> Wenn das "y" variabel ist. Dann brauchst du eine Schleife, da der AVR
> vor lauter Einfachheit keinen Barrel-Shifter hat.

Nett. Aber man kann nicht alles haben. Für die paar Rechenoperationen 
gehts auch mit den AVR-Shiftbefehlen.

> Ist ja schön dass deine Blinki-Programme damit auskommen

Damit kommen Millionen AVR-Anwendungen z.T. recht komplexer Natur aus.

> Sehr viele Programme verwenden komplexere
> Datenstrukturen (wie in meinem Beispiel, ein uint16_t -Array) oder gar
> structs, da hilft die Offset-Addressierung und die einfache
> Pointer-Arithmetik doch gewaltig.

Absolut. Dann handeln sie aber meist auch größere Datenmengen- dafür ist 
Sinn und Zweck eines ARM natürlich unstrittig.

Schlaumeier schrieb:
> btw, wolltest Du nicht aufhören, in ARM-threads das Hohelied des
> AVR-Assemblers zu singen,

Hier gehts gerade um die viel einfachere AVR GPIO-Konfiguration im 
Vergleich zum ARM. An der viel einfacheren AVR-Konfiguration gibts nix 
zu deuteln. Genausowenig daran, daß diese Dinge mit Asm schneller/kürzer 
zu Papier gebracht sind. Zumindest beim AVR ;-)

Schlaumeier schrieb:
> Nö, um AVR gehts hier nicht ...

Den Fokus scharf aufs ursprüngliche Thema zu halten gelingt in den 
wenigsten Threads. Warum auch? Zuweilen öffnen erst die Randaspekte neue 
Horizonte ;-)

Moby A. schrieb:
> GPIO-Konfiguration im
> Vergleich zum ARM.

Moby, es gibt bei ARM gar keine GPIO-Konfiguration, hast Du das gewusst? 
Einfacher gehts nimmer! GPIO ist nämlich nicht Teil des ARM-Cores.

Es gibt nur die GPIO-Einheiten die die unterschiedlichen Hersteller in 
die unterschiedlichen Controller einbauen und da gibt es bei den 
kleineren ARMs auch welche die genauso simpel funktionieren wie bei AVR. 
Man muss nicht immer die überkomplexe Peripherie die STMicroelectronics 
gerne in ihre Controller einbaut stellvertretend für alle ARM-Controller 
heranziehen, man kann auch genausogut klein anfangen, zum Beispiel mit 
nem Freescale MKE04Z8, da ist zum Beispiel die GPIO-Einheit per Default 
ab Reset schon eingeschaltet, man muss nur noch Datenrichtung auf 
Ausgang setzen (ein Register, ein Bit pro Pin, genau wie AVR) und schon 
kann man anfangen zu blinken.

W.G. schrieb:
> Der ARM hat halt ganz andere Möglichkeiten (mehrere Clock
> Domains, Slew Rate, Pullup, Pulldown, ...) die konfiguiert werden
> müssen.

... und die das Ganze komplexer machen. Dazu hatte ich ja schon 
festgestellt: Bitte nur, wenns die Anwendung (oder der Boss) verlangt.

> Das ist ein Vergleich Äpfel mit Birnen. Dass sich die
> Steuerung/Bedienung von einem Fahrraddynamo erheblich von der eines
> Kernkraftwerkes unterscheidet ist doch klar. Trotzdem kommt bei beiden
> Strom raus. Das willst du doch auch nicht vergleichen.

Nein. Doch siehe sinngemäß oben: Die Dinge für ihren Zweck so einfach 
wie möglich halten sollte der Anspruch sein. Und einen konkreten Zweck 
gab der TO nicht vor.

> Versteh mich nicht falsch, ich habe früher
> viel mit Assembler gemacht und auch komplexe Programme wie Morsedecoder
> auf VGA Monitor mit Touch und integrierter Funkgerätfernbedienung über
> RS-232. Aber es lohnt sich eben leider nicht.

Finde ich prima. Allerdings fällt unser Resümee da unterschiedlich aus 
;-)

Bernd K. schrieb:
> man kann auch genausogut klein anfangen, zum Beispiel mit
> nem Freescale MKE04Z8, da ist zum Beispiel die GPIO-Einheit per Default
> ab Reset schon eingeschaltet, man muss nur noch Datenrichtung auf
> Ausgang setzen (ein Register, ein Bit pro Pin, genau wie AVR) und schon
> kann man anfangen zu blinken.

Interessant. Hab ich noch nicht gewusst.
Mir langt aber schon ein kurzer Blick aufs >600 seitige "KE04 Sub-Family 
Reference Manual" um zu erkennen, daß man im Zweifelsfall besser bei AVR 
bleiben sollte ;-)

>Hier gings erstens um die Vorinitialisierung, um überhaupt auf den Pin
>so zugreifen zu können!

Der TE hat mit Sicherheit mehr vor, als einen Pin zu initialisieren. 
Wenn das das Ziel ist, hättest du ihm auch einen Schalter vorschlagen 
können. Der ist NOCH einfacher als AVR.

Jasson J. schrieb:
> hättest du ihm auch einen Schalter vorschlagen
> können. Der ist NOCH einfacher als AVR.

Nun, man kann es mit E wie einfach auch E wie extrem übertreiben.
Das wär sicher nicht mehr hilfreich ;-)

Schlaumeier schrieb:
> Dass Du als viel gesehener Forumschreiber mit vollem Wissen einem Troll
> auf den Leim gehst, weißt Du aber?

Mach Dir keine unnötigen Sorgen lieber Schlaumeier.
Hab gerade eingesehen, daß ich meinen Nachmittag jetzt besser sinnvoller 
verbringe. Meine ernsthaften ernstgemeinten Bedenken hab ich schließlich 
zum Ausdruck gebracht ;-)

Schlaumeier schrieb:
> Deine Trollerei

Der Troll bist Du, weil Du nicht das Thema sondern nur den 
(zugegebenermaßen unbequemen) Moby im Fokus hast ;-)

Naja als Übersetzer bist Du zwar grottenschlecht, aber  Deinem Nicknamen 
machst Du alle Ehre, inklusive einem gewissen Unterhaltungswert ;-)
Schönen Sonntag noch.

Moby schrieb:
> W.S. schrieb:
>> Kraft hast, es verstehend zu lesen, dann befasse dich mit irgend etwas
>> anderem.
>
> Richtig. Zum Beispiel mit einfachen AVRs, um damit viel schneller ans
> Ziel zu kommen. ARM-Konfiguritis muß ja nicht jedermans Leidenschaft
> sein ;-)

W.S. schrieb:
> Auf der letzten Embedded wurden doch Schachteln mit ATtiny drin
> verteilt, gelle?

Sag ich doch, DIE Alternative zu

W.S. schrieb:
> absolute
> Krätze.