Makros versus Funktionen

[Stefan (Gast)]

Ich habe mal den genialen Tip bekommen, für den schreibenden Zugriff auf 
einzelne I/O Pins bei AVR Makros zu verwenden:

#define writeBit(port,bit,value) { if ((value)>0) (port) |= (1<<bit); else (port) &= ~(1<<bit); }

Dieses Makros kann der Compiler wunderbar optimieren, wenn bit und value 
Konstanten sind. Aus "writeBit(PortA,3,1)" wird zum Beispiel "PortA|=1".

Aber Makros finde ich häßlich, vor allem wirken sie sich auf 
Fehlermeldungen störend aus. Wenn ich sie intensiv nutze, meldet mir der 
Compiler in Fehlermeldungen oft (aber komischerweise nicht immer) 
falsche Zeilen Nummern.

Deswegen erwäge ich, lieber Funktionen/Prozeduren zu verwenden. Aber 
dann klappt die Optimierung nicht mehr so gut, oder doch?

void writeBit(??? port, uint8_t bit, uint8_t value) {
  if (value>8)
    port |= (1<<bit);
  else
    port &= ~(1<<bit);
}

Wie kann ich das so verbessern, dass sowohl der Funktionsaufruf als auch 
der if-Ausdruck weg optimiert werden, sofern bit und value Konstanten 
sind?

Und was gehört an der Stelle ??? hin?

[Oliver (Gast)]

Stefan schrieb:
> Aus "writeBit(PortA,3,1)" wird zum Beispiel "PortA|=1".

Hoffentlich nicht, dann wäre der Conmpiler kaputt.

Aber was gefäät dir an

PortA |= 1<<3;

nicht?

Wenn man mehrere Bits gleichzeitig setzen will, was ja durchaus mal 
vorkommt, passt dein Makro eh nicht mehr.

Oliver

[Peter D. (peda)]

Ich finde extra Funktionen für Zuweisungen zu umständlich.
Ich belasse es daher bei Zuweisungen.
Eine Zuweisung an eine Bitvariable geht einfach über ein Macro:

#include "sbit.h"

#define LED0 PORT_D5
#define TASTE0 PIN_B6

if( TASTE0 == 0 )
  LED0 = 0; // LED0 aus
else
  LED0 = 1; // LED0 ein

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

Stefan schrieb:
> Wie kann ich das so verbessern, dass sowohl der Funktionsaufruf als auch
> der if-Ausdruck weg optimiert werden, sofern bit und value Konstanten
> sind?

Sollte circa so gehen:

static inline void writeBit(volatile uint8_t *port, uint8_t bit, uint8_t value) {
  if (value>8)
    *port |= (1<<bit);
  else
    *port &= ~(1<<bit);
}

und Aufruf mit

writeBit(&PORTA, 6, 1);

[Yalu X. (yalu) (Moderator)]

Die Zeile

  if (value>8)

sollte noch in

  if (value != 0)

oder einfach

  if (value)

geändert werden.

Dann erzeugt der Compiler (ab Version 4.3) wie erwartet SBI- bzw.
CBI-Instruktionen, wenn die Argumente bit und value konstant sind.

[Johann L. (gjlayde)]

Yalu X. schrieb:
> Dann erzeugt der Compiler (ab Version 4.3) wie erwartet SBI- bzw.
> CBI-Instruktionen, wenn die Argumente bit und value konstant sind.

Allerdings ohne Garantie :-P

[holger (Gast)]

>> Dann erzeugt der Compiler (ab Version 4.3) wie erwartet SBI- bzw.
>> CBI-Instruktionen, wenn die Argumente bit und value konstant sind.
>
>Allerdings ohne Garantie :-P

Und für PORTF hoffentlich nicht;)

[Johann L. (gjlayde)]

holger schrieb:
> Und für PORTF hoffentlich nicht;)

Der Compiler hat keine Vorstellung von PORTF — braucht er auch nicht. 
Alles was er wissen muß ist die Adresse, denn die legt fest, ob die 
Instruktionen SBI, CBI, IN, OUT, SBIS, SBIC verwendet werden dürfen oder 
nicht.

[Dr. Sommer (Gast)]

Stefan schrieb:
> Aber
> dann klappt die Optimierung nicht mehr so gut, oder doch?
Funktionen sind Makros grundsätzlich und immer vorzuziehen, falls 
irgendwie möglich. Makros haben keinen Typ, keinen Scope, bringen die 
Syntax durcheinander etc. Wenn man inline-Funktionen verwendet klappt 
die Optimierung genau so gut (wenn der GCC sich trotzdem weigert die 
Funktion zu inlinen, __attribute__((always_inline)) dranschreiben).

Headerfiles mit Tausenden #defines (siehe CMSIS...) sind wie ein Feld 
voller Tretminen, verwendet man einen "falschen" (per #define 
vorbelegten) Bezeichner gibt es obskure Fehlermeldungen. Versehentliche 
Doppel-Verwendung von Funktionsnamen funktioniert entweder (je nach Art 
der Verwendung & Scope) oder führen zu sinnvollen Fehlermeldungen.

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

Dr. Sommer schrieb:
> Makros haben keinen Typ, keinen Scope, bringen die Syntax durcheinander
> etc.

Naja, einen Scope haben sie.  File scope halt. :)

[Dr. Sommer (Gast)]

Jörg Wunsch schrieb:
> Naja, einen Scope haben sie.  File scope halt. :)
Nö:

#define foo1 7
const int foo2 = 7;

int main () {
  double foo1; // funktioniert nicht, gibt lustige Compilerfehler
  double foo2; // funktioniert; die globale foo2-Variable wird "unsichtbar"
}

Deklarationen in einem inneren Scope (hier der Funktionskörper von main) 
können Deklarationen im äußeren Scope (hier der globale Scope) 
überdecken; bei Macros geht das nicht.

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

Dr. Sommer schrieb:
> Deklarationen in einem inneren Scope (hier der Funktionskörper von main)
> können Deklarationen im äußeren Scope (hier der globale Scope)
> überdecken; bei Macros geht das nicht.

OK, überredet. ;-)