GPIO-Zugriff STM32 F103C über Register

[Mathias B. (mathias_b103)]

Ich versuche GPIO-Zugriffe über die Register zu bewerkstelligen.

Das Ein- und Ausschalten über BSRR und BRR funktioniert wie es soll.
Aber der Modus auf Output stellen funktioniert nicht, ausser über 
gpio_set_mode(...

Wie kann ich das lösen, das es auch über GPIOx->regs->??? geht ?

#include <Arduino.h>

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

#define LEDPin PC13

void setup() {
//    GPIOC->regs->CRL = 0xFFFF;
//    GPIOC->regs->ODR = 0xFFFF;
  gpio_set_mode(GPIOC, 13, GPIO_OUTPUT_PP);
  gpio_set_mode(GPIOA, 3, GPIO_OUTPUT_PP);
}

void loop() {
  GPIOC->regs->BSRR = 1 << 13;
  GPIOA->regs->BSRR = 0xFFFF;

  delay(500);

  GPIOA->regs->BRR = 0xFFFF;
  GPIOC->regs->BSRR = 1 << 13 << 16;

  delay(500);
}

[Beo Bachter (Gast)]

Mathias B. schrieb:
> Wie kann ich das lösen, das es auch über GPIOx->regs->??? geht ?

Du willst es auf die harte Tour?

Bitte sehr, auf / ab Seite 170 (also Abschnitt 9.2) des Reference
Manuals sind alle Register zum Steuern der Pins beschrieben.

Vorlesen tu ich dir nicht, ich bin kein Märchenonkel ;-)

[Mathias B. (mathias_b103)]

Super Antwort, damit komme ich richtig weiter. Grr!!

[Philipp K. (philipp_k59)]

Erster google eintrag?

https://gist.github.com/iwalpola/6c36c9573fd322a268ce890a118571ca

[Dr. Sommer (Gast)]

Mathias B. schrieb:
> GPIOC->regs->BSRR = 1 << 13 << 16;

Das ist bedenklich... ist das nun (1 << 13) << 16 oder 1 << (13 << 16)? 
Hast du im C Standard nachgeschaut ob das korrekt ist? Am Besten ist es 
einfach Klammern zu setzen.

[Nop (Gast)]

Dr. Sommer schrieb:
> ist das nun (1 << 13) << 16

Ist es, weil Compilerschreiber die "nimm den größten Bissen"-Regel 
haben. Übersichtlich ist trotzdem anders. Allein schon diese ganzen 
magic numbers, gerade als ob defines noch nicht erfunden wären.

[Dr. Sommer (Gast)]

Nop schrieb:
> Ist es, weil Compilerschreiber die "nimm den größten Bissen"-Regel
> haben.

Ahja, stimmt. Hier steht es:
http://en.cppreference.com/w/cpp/language/operator_precedence

"Operators that have the same precedence are bound to their arguments in 
the direction of their associativity. For example, the expression a = b 
= c is parsed as a = (b = c), and not as (a = b) = c because of 
right-to-left associativity of assignment, but a + b - c is parsed (a + 
b) - c and not a + (b - c) because of left-to-right associativity of 
addition and subtraction."

Und bei << steht "Left-to-right". Gut zu wissen. Den Leser verwirrt es 
trotzdem...

Nop schrieb:
> Allein schon diese ganzen
> magic numbers, gerade als ob defines noch nicht erfunden wären.
Defines sind auch blöde, besser Konstanten.

[Nop (Gast)]

Dr. Sommer schrieb:

> Ahja, stimmt.

Deswegen ist auch

int a, b=1, c=2;
a= b+++c;

durchaus definiert. Eine nette Frage für Bewerbungsgespräche. ;-)

> Defines sind auch blöde, besser Konstanten.

Ich nehm für Bitmasken usw. immer defines. Zumal man dann anhand der 
durchgehenden Großschreibung sieht, was das sein soll. Bei 
const-variablen wäre das verwirrend, die in Caps zu schreiben, und in 
normaler Variablen-Schreibung wäre das noch verwirrender.

Const-Variablen nehme ich für ernsthaftere Sachen wie z.B. 
Lookup-Tabellen.

Allerdings nehme ich bei den Bit-defines auf Cortex-M immer "UL" als 
Suffix, wodurch der Typ hinkommt wie gewünscht.

[Dr. Sommer (Gast)]

Nop schrieb:
> Eine nette Frage für Bewerbungsgespräche. ;-)

Naja, das "," da ist doch nicht der Komma-Operator?

Nop schrieb:
> Zumal man dann anhand der
> durchgehenden Großschreibung sieht, was das sein soll.
Kann trotzdem zu Kollisionen führen.

Nop schrieb:
> Bei
> const-variablen wäre das verwirrend, die in Caps zu schreiben, und in
> normaler Variablen-Schreibung wäre das noch verwirrender.
Konstanten darf man ja auch klein schreiben

Nop schrieb:
> Allerdings nehme ich bei den Bit-defines auf Cortex-M immer "UL" als
> Suffix, wodurch der Typ hinkommt wie gewünscht.
Ja, bis du es portierst... :)

Ein

static const uint32_t PinMask = 1 << 13;

hat nur Vorteile gegenüber einem

#define PinMask ((uint32_t) (1 << 13))

wenn man nicht gerade einzelne Bytes Quelltext sparen möchte. In C gibt 
es da ein paar Einschränkungen bzgl. Array-Größen-Definitionen, aber 
Arduino ist ja C++.

Um es mit Bjarne Stroustrup's Worten zu sagen:
"One of my least favorite activities is tracking down an error caused by 
a name being macro-substituted into something completely different by a 
macro defined in an indirectly #include'd header that I have never even 
heard of." [1]
Und
"Avoid macros excpt for include guards " [2]
Und
"Most people seriously overuse casts and macros" [2]

1: The C++ Programming Language 4th Ed., S. 425
2: www.stroustrup.com/bs_faq.htmla

[Dr. Sommer (Gast)]

Dr. Sommer schrieb:
> Naja, das "," da ist doch nicht der Komma-Operator?
Ach Quatsch, disregard that...