ARM-GCC: "pointers are not permitted as case values"

Warum übergibst du denn überhaupt einen Pointer, wenn du ihn nur zur 
Fall-Unterscheidung nutzen willst?

1

   switch(*gpio) ....

sollte das Problem lösen.

Grüsse,
R.

Rene H. schrieb:
> sollte das Problem lösen.

Das löst garnichts. Bei dem Controllertyp, den Walter gerade benutzt 
und dem Headerfile, was er dafür gerade in Händen hält, sind die 
Ports als struct's deklariert. Einen kompletten Struct kann man aber 
nicht als case-Value benutzen, das ist auch logischer Unsinn.

Abgesehen davon halte ich Walters Herangehensweise inzwischen auch für 
GRUNDFALSCH. Er versucht nämlich, die Ports per Namen zu 
vereinheitlichen, um Namensgleichheit zwischen ARM und AVR herzustellen. 
Wahrscheinlich will er gleiche Initialisierungs-Quelltexte für so 
unterschiedliche Architekturen schreiben. Sowas kann nicht funktionieren 
und es ist auch logischer Mumpitz. Ungleiche Hardwaren (Hardwares ?) 
kann man auf der alleruntersten Ebene NICHT über einen Kamm scheren, 
dazu schreibt man sich  lowest-level-Routinen, die höhere Funktionalität 
(also Lampe_ein, Motor_aus und so) auf die darunterliegende Hardware 
umsetzen.

W.S.

Walter Tarpan schrieb:
> Was bewirkt der Dereferenzierungsoperator bei einem struct?

Ah, ok, das wusste ich nicht, dass das ein typedef struct ist, ich 
dachte an einen enum. Dann geht das natürlich nicht.
In dem Fall würde ich eher auf if else gehen (nicht schön, braucht aber 
meines Wissens nicht mehr Taktzyklen).

Walter Tarpan schrieb:
> naja, viel Padding wird bei uint32_t
> ja nicht gemacht.


Da sollten bei einem ARM eigentlich kaum Padding Bytes eingesetzt 
werden.

Grüsse,
R.

>Ich habe mein Projekt
>jetzt zu 90% von AVR auf ARM migriert und die Source-Code-Qualität auf
>beiden Seiten hat deutlich zugenommen.

Und die Geschwindigkeit vermutlich deutlich abgenommen.

Protip: Die CMSIS/Standard Peripheral Library hat extrem schlechtes 
Design. Alles was man an Informationen benötigt um einen Port zu 
identifizieren und nutzen ist eine 3 (oder so) bit-Zahl die die 
Port-Nummer (0-4 = A-E o.ä.) angibt. Die Adresse der zugehörigen 
Port-Register und die RCC-Register-Bitnummer ("RCC_APB2Periph_GPIOx") 
lässt sich direkt daraus berechnen (einfach mal in die Definition von 
RCC_APB2Periph_GPIOx, und ins Manual über die RCC-Register schauen). 
D.h. es reicht dann

1

enum Port { GPIOA=0, GPIOB, GPIOC, GPIOD };

2

void init (Port p) {

3

  RCC_APB2PeriphClockCmd(4 << p,ENABLE);

4

  RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO,ENABLE);

5

}

6

int main () {

7

  init (GPIOB);

8

}

Und schon hast du den ganzen Aufwand gespart...

Walter Tarpan schrieb:
> In ein uint32_t casten?
Wenn schon casten, dann korrekterweise in ein intptr_t.

holger schrieb:
> Und die Geschwindigkeit vermutlich deutlich abgenommen.

Nicht genug, als daß die Funktion des Geräts dadurch beeinträchtigt 
worden wäre.

Vermutlich dauert die Initialisierung jetzt 100mal länger als zuvor - 
dummerweise ist sie aber immer noch so schnell, daß sie fertig ist, 
bevor ich den Finger vom Netzschalter zu den Bedienelementen bewegt 
habe.

Dr. Sommer schrieb:
> Protip: Die CMSIS/Standard Peripheral Library hat extrem schlechtes
> Design. Alles was man an Informationen benötigt um einen Port zu
> identifizieren und nutzen ist eine 3 (oder so) bit-Zahl die die
> Port-Nummer (0-4 = A-E o.ä.) angibt. Die Adresse der zugehörigen
> Port-Register und die RCC-Register-Bitnummer ("RCC_APB2Periph_GPIOx")
> lässt sich direkt daraus berechnen (einfach mal in die Definition von
> RCC_APB2Periph_GPIOx, und ins Manual über die RCC-Register schauen).
> D.h. es reicht dannenum Port { GPIOA=0, GPIOB, GPIOC, GPIOD };
> void init (Port p) {
>   RCC_APB2PeriphClockCmd(4 << p,ENABLE);
>   RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO,ENABLE);
> }
> int main () {
>   init (GPIOB);
> }Und schon hast du den ganzen Aufwand gespart...

Danke für den Tipp! Die GPIOx als enum neu zu definieren wiederstrebt 
mir zwar- aber das Ganze funktioniert ja auch mit den 
Original-Definitionen.

Walter Tarpan schrieb:
> Danke für den Tipp! Die GPIOx als enum neu zu definieren wiederstrebt
> mir zwar-
Immer noch viel besser als der "#define" Haufen aus der Std Peripheral 
Library... Von mir aus auch "static const uint8_t GPIOA = 0;".

Walter Tarpan schrieb:
> Und generell hat das bislang sehr gut geklappt.

..und hat dir bisher ca. 70000 Quellzeilen beschert, wie du in einem 
anderen Thread geschrieben hattest. Ich stell jetzt mal keine 
Vermutungen an, ob das bislang alles nur Quellzeilen waren, die aus dem 
Gleichmach-Wunsch zwischen AVR und ARM deinerseits herrühren. Ich sag 
nur eins: du stellst das Ganze verkehrt an, stolperst dabei über 
grundsätzliche Unmöglichkeiten, die dir nicht nur in C blühen, sondern 
dich auch in allen anderen Programmiersprachen angrinsen würden - und du 
bist erstaunlich beratungsresistent. Na dann mach mal.

W.S.