Präprozessor-Makro verschachteln

[__Son´s B. (bersison)]

Hallo - beisse mir immer noch die Zähne an folgendem Proible aus.

Ich würde gerne aus;
  #define AUSGANG_SET_HIGH(port,mask) ((port) |= (1<<mask))
  #define BATT_ON (AUSGANG_SET_HIGH(PORTA,PA4))
(Funktioniert einwandfrei!)

solch eine Parametrierung machen;
  #define AUSGANG_SET_HIGH(port,mask) ((port) |= (1<<mask))
  #define PORT_BATT_OUT(PORTA,PA4)
  #define BATT_ON (AUSGANG_SET_HIGH(PORT_BATT_OUT))
Compiler meckert!

Obwohl nach meine Verständnis folgender Ersatz raus kommen sollte;
  #define BATT_ON (AUSGANG_SET_HIGH((PORTA,PA4)))

Auch ohne Leerzeichen zw. BATT_ON(AUSG...) klappts nicht.
Syntaxfehler?

[Georg G. (df2au)]

__Son´s B. schrieb:
> #define PORT_BATT_OUT(PORTA,PA4)

Da fehlt ein Leerzeichen.
#define PORT_BATT_OUT (PORTA,PA4)

[DerDan (Gast)]

Hallo

und obwohl bei deinem Verständnis was anders rauskommt als bei deiner 1. 
Lösung ist der Compiler schuldig ???

__Son´s B. schrieb:
> Obwohl nach meine Verständnis folgender Ersatz raus kommen sollte;
#define BATT_ON (AUSGANG_SET_HIGH((PORTA,PA4)))

__Son´s B. schrieb:
> #define BATT_ON (AUSGANG_SET_HIGH(PORTA,PA4))

zähl doch einfach mal die Anzahl der Klammern nach ...

mfg

DerDan

[__Son´s B. (bersison)]

DerDan schrieb:
> zähl doch einfach mal die Anzahl der Klammern nach ...
???
Wie sieht dein Lösungsansatz aus?

[__Son´s B. (bersison)]

Georg G. schrieb:
> Da fehlt ein Leerzeichen.
> #define PORT_BATT_OUT (PORTA,PA4)

Ob mit oder ohne Leerzeichen verändert nichts!

[Tom (Gast)]

Was man nicht alles tun muss, um die bösen performance-mordenden 
Funktionen zu vermeiden...

[__Son´s B. (bersison)]

Tom schrieb:
> Was man nicht alles tun muss, um die bösen performance-mordenden
> Funktionen zu vermeiden...
Deine Bemerkung kann ich gut nachvollziehen.

Versuche aktuell alle Grundparameter, Ports und Pins in einem 
Makro-Block zu hinterlegen. Die PORT/PIN-Zuweisung ist der letzte 
Schritt.

[Peter D. (peda)]

Tom schrieb:
> Was man nicht alles tun muss, um die bösen performance-mordenden
> Funktionen zu vermeiden...

Niemand muß sowas, es gibt bessere Möglichkeiten, z.B.:
1. Portpins als Bitvariablen definieren
2. Inline-Funktionen

__Son´s B. schrieb:
> Compiler meckert!

Gehts bitte noch ungenauer?
Copy&Paste den genauen Fehlertext!
Hänge den Quelltext als Anhang an, dann kann man sogar die Zeilennummer 
in der Meldung zuordnen.

[__Son´s B. (bersison)]

Peter D. schrieb:
> Copy&Paste den genauen Fehlertext!
> Hänge den Quelltext als Anhang an, dann kann man sogar die Zeilennummer
> in der Meldung zuordnen.
siehe Anhang.

[Walter S. (avatar)]

nicht der Fehler aber damit wirst Du dir ins Knie schießen:

#define LED_OFF (AUSGANG_SET_LOW(PORTA,PA5)); 
(AUSGANG_SET_LOW(PORTA,PA6)); (AUSGANG_SET_LOW(PORTA,PA7))  // alle LEDs 
werden gelöscht

was kommt da raus wenn du

if ( quark )
 LED_OFF;

schreibst?

[__Son´s B. (bersison)]

Walter S. schrieb:
> nicht der Fehler aber damit wirst Du dir ins Knie schießen:
Warum?

Alle 3 LEDs liegen auf low.
Funktioniert tatsächlich einwandfrei!

[Walter S. (avatar)]

__Son´s B. schrieb:
> Alle 3 LEDs liegen auf low.
> Funktioniert tatsächlich einwandfrei!

nee,
die erste geht auf LOW wenn quark true ist
die beiden anderen gehen IMMER auf LOW

[Jörg W. (dl8dtl) (Moderator)]

__Son´s B. schrieb:
> Warum?

Du solltest dir hin und wieder mal ansehen, was aus dem Präprozessor
so hinten „herausfällt“.  (avr-gcc ... -E)  Dann würde dir vielleicht
auffallen, dass der Präprozessor von C keine Ahnung hat sondern stur
Texte ersetzt, und vielleicht entdeckst du dann auch mal das unsinnige
Semikolon im Zeichenstrom. ;)

Ansonsten funktioniert das, was du machen willst, zweistufig.

Ich hatte meine Lösung schon mal gepostet, auch wenn sie „W.S.“ nicht
gefiel. ;-)

#define GLUE(a, b)     a##b

/* single-bit macros, used for control bits */
#define SET_(what, p, m) GLUE(what, p) |= (1 << (m))
#define CLR_(what, p, m) GLUE(what, p) &= ~(1 << (m))
#define GET_(/* PIN, */ p, m) GLUE(PIN, p) & (1 << (m))
#define SET(what, x) SET_(what, x)
#define CLR(what, x) CLR_(what, x)
#define GET(/* PIN, */ x) GET_(x)

#define ASSIGN_(what, p, m, v) GLUE(what, p) = (GLUE(what, p) & \
                                                ~((1 << (m)) | (1 << ((m) + 1)) | \
                                                  (1 << ((m) + 2)) | (1 << ((m) + 3)))) | \
                                                ((v) << (m))
#define READ_(what, p, m) (GLUE(what, p) & ((1 << (m)) | (1 << ((m) + 1)) | \
                                            (1 << ((m) + 2)) | (1 << ((m) + 3)))) >> (m)
#define ASSIGN(what, x, v) ASSIGN_(what, x, v)
#define READ(what, x) READ_(what, x)

...
  SET(PORT, HD44780_E);
    x = READ(PIN, HD44780_D4);
  CLR(PORT, HD44780_E);
...
  CLR(PORT, HD44780_RW);
  if (rs)
    SET(PORT, HD44780_RS);
  else
    CLR(PORT, HD44780_RS);
  ASSIGN(PORT, HD44780_D4, n);

Die HD44780_x-Makros sind dabe projektabhängig definiert:

#define HD44780_RS A, 6
#define HD44780_RW A, 5
#define HD44780_E  A, 4
/* The data bits have to be not only in ascending order but also consecutive. */
#define HD44780_D4 A, 0

Wenn du obiges mal auf besagte Weise durch den Präprozessor schickst,
siehst du, was er da draus zimmert.

[__Son´s B. (bersison)]

Walter S. schrieb:
> die beiden anderen gehen IMMER auf LOW
Schau dir die beiden darüber liegenden Makros an - da geht nichts nach 
der ersten Anweisung IMMER auf LOW!

Da diese Anweisung einwandfrei funktioniert, konzentriere ich mich 
lieber auf das was nicht klappt;

__Son´s B. schrieb:
> solch eine Parametrierung machen;
>   #define AUSGANG_SET_HIGH(port,mask) ((port) |= (1<<mask))
>   #define PORT_BATT_OUT(PORTA,PA4)
>   #define BATT_ON (AUSGANG_SET_HIGH(PORT_BATT_OUT))
> Compiler meckert!

[Frank M. (ukw) (Moderator)]

__Son´s B. schrieb:
> Schau dir die beiden darüber liegenden Makros an - da geht nichts nach
> der ersten Anweisung IMMER auf LOW!

Doch. Dicker Fehler, den Du nur noch nicht verstanden hast.

Ich vereinfache mal, dann wird es klarer:

#define A()       a();b();c();
...
if (x)
   A()

Was macht der Preprocessor draus?

if (x)
   a();b();c();

Das kann man ohne Code-Änderung umschreiben in:

if (x)
   a();
b();
c();

Da ohne geschweiften Klammern nur a() im if-Block steckt, werden b() und 
c() IMMER ausgeführt, egal, ob man es nebeneinander oder untereinander 
schreibt.

Merke: Wenn Du sagst: "Es funktioniert aber", dann heisst das lediglich, 
dass Du es nur im falschen Kontext getestet/überdacht hast - hier 
nämlich für x != 0.

[Georg G. (df2au)]

__Son´s B. schrieb:
> Ob mit oder ohne Leerzeichen verändert nichts!

Aber die Bedeutung der Zeile ist mit und ohne Leerzeichen drastisch 
anders. Du hast eben mehr als nur einen Fehler drin.

[__Son´s B. (bersison)]

Frank M. schrieb:
> Da ohne geschweiften Klammern nur a() im if-Block steckt, werden b() und
> c() IMMER ausgeführt,
Klar, passt doch!
Aber nicht, wie Walter S schrieb; "IMMER auf LOW".

Bsp: Folgend sollen alle 3 Befehle nacheinander ausgeführt werden;
...
#define LED_LOW (AUSGANG_SET_LOW(PORTA,PA5)); 
(AUSGANG_SET_LOW(PORTA,PA6)); (AUSGANG_SET_HIGH(PORTA,PA7))
...
LED_LOW;
...
Somit LED_high aus, LED_mid aus, LED_low ein.
Funktioniert auch Live nach dem 1000-sten mal.

Oder meinst du, dass es eine "unsaubere" Syntax ist?

[Jörg W. (dl8dtl) (Moderator)]

__Son´s B. schrieb:
> Oder meinst du, dass es eine "unsaubere" Syntax ist?

Ja, ist es. Er schrieb ja auch, warum.  Wenn du schreibst:

  if (some_event)
    LED_LOW();

… dann erwartest du vermutlich, dass die LEDs nur dann alle geschaltet
werden, wenn „some_event“ eintrifft, und nicht nur der Ausgang auf PA5
von der Bedingung abhängt.

[__Son´s B. (bersison)]

Jörg W. schrieb:
> if (some_event)
>     LED_LOW();
Verstehe - habe die Makros bis jetzt in if{}, Abläufen oder case 
eingebunden.

[Walter S. (avatar)]

__Son´s B. schrieb:
> Klar, passt doch!
> Aber nicht, wie Walter S schrieb; "IMMER auf LOW".

dann lies das noch Mal:

Walter S. schrieb:
> nicht der Fehler aber damit wirst Du dir ins Knie schießen:
>
> #define LED_OFF (AUSGANG_SET_LOW(PORTA,PA5));
> (AUSGANG_SET_LOW(PORTA,PA6)); (AUSGANG_SET_LOW(PORTA,PA7))  // alle LEDs
> werden gelöscht
>
> was kommt da raus wenn du
>
> if ( quark )
>  LED_OFF;
>
> schreibst?


das wird zu:
if ( quark )
 LED1 low;

LED2 low;
LED3 low;

2 und 3 werden also IMMER low

[__Son´s B. (bersison)]

Walter S. schrieb:
> 2 und 3 werden also IMMER low
in dem Fall soll das auch so sein!
Da bei mir if-Anweisungen in {} stehen, ist die Problematik noch nicht 
aufgefallen.

Lösungsvorschlag von Jörg Wunsch liest sich (als Anfänger) äusserst 
aufwendig.

[Walter S. (avatar)]

__Son´s B. schrieb:
> Lösungsvorschlag von Jörg Wunsch liest sich (als Anfänger) äusserst
> aufwendig.

ja, ist aber leider so
Aber warum nimmst du nicht inline-Funktionen, du ersparst dir vieles und 
die Laufzeit wirst du normalerweise nicht merken

[__Son´s B. (bersison)]

Walter S. schrieb:
> Aber warum nimmst du nicht inline-Funktionen
Mag blöd klingen, aber ich finde blockartige Makros im Header einfacher, 
transparenter und schneller zu erfassen...

[Kirsch (Gast)]

Ob es schön ist, ist eine andere Sache, aber so kann man diese Aufrufe 
kapseln

#define A()       do{a();b();c();}while(0)

[nicht"Gast" (Gast)]

__Son´s B. schrieb:
> Mag blöd klingen, aber ich finde blockartige Makros im Header einfacher,
> transparenter und schneller zu erfassen...

Geil,

du bist selbt der beste Gegenbeweis, dass dem nicht so ist. Du siehst 
bei deinem relativ einfachen Code selber nicht schon durch und auch kein 
anderer kann die wirklich helfen, finden aber Fehler, die du nicht 
siehst.

Vieeeeeeel transparenter.

[nicht"Gast" (Gast)]

Oo

die vielen Fehler und Wortdreher einfach weg denken.

[Jörg W. (dl8dtl) (Moderator)]

__Son´s B. schrieb:
> Lösungsvorschlag von Jörg Wunsch liest sich (als Anfänger) äusserst
> aufwendig.

Den Aufwand hatte aber nur ich damit, mir das auszudenken. ;-)

Du kannst den Kram einfach in einen Header packen und benutzen.

Der wesentliche Trick ist die doppelte Verschachtelung, also ein
FOO(), welches dann ein FOO_() aufruft.  Der weitere Aufwand, den
ich getrieben habe, dient dann nur dazu, die AVR-Eigenheit der
heiligen Registerdreifaltigkeit (PORTx, PINx, DDRx) so abzubilden,
dass man das „x“ nur an genau einer Stelle im Headerfile schreiben
muss.