Return Anweisung mit Rückgabe vom Zustand des Ports

Falls dieses komische TRUE 1 ist und FALSE 0 (diese Thema hatten
wir doch eben erst?):

1

int get_rx_pin_status(void)

2

{

3

  return (RX_PORT & (1 << RX))!=0;

4

}

Klaus Wachtler schrieb:
> return (RX_PORT & (1 << RX))!=0;

sorry, damit es deinem Beispiel entspricht (falls das richtig ist),
muß es heißen:

1

  return (RX_PORT & (1 << RX))==0;

Tommy schrieb:
> Hat einer ne Idee?
Definier dir ein Makro.

1

#define get_rx_pin_status (RX_PORT&(1 << RX)?0:1)

2

3

  if (get_rx_pin_status) {

4

    ...

5

  }

BTW: deine Rückgabewerte sind ungünstig gewählt.
Invertiert ginge es noch kürzer:

1

#define get_rx_pin_status (RX_PORT&(1 << RX))

2

3

  if (!get_rx_pin_status) {

4

    ...

5

  }

Falls du TRUE und FALSE irgendwie anders definiert haben
solltest, geht auf jeden Fall diese Version (auch wenn es
Unfug ist):

1

  return ( (RX_PORT & (1 << RX))==0 ) ? TRUE : FALSE;

Antwort schrieb:
> würde ich diese Abfrage in ein Makro packen

hmm... da sträuben sich mir immer ein bisschen die Haare :) ist ein 
Verstoß gegen MISRA-C Regel 19.7

Lothar Miller schrieb:
>> Hat einer ne Idee?
> Definier dir ein Makro.

Der gcc kennt auch inline bei C.
Dann geht es ohne tatsächlichen Funktionsaufruf, und man hat
die Makro-Nachteile nicht.

http://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline

Antwort schrieb:
> Wenn du dein Programm übersichtlich haben willst, aber trotzdem sehr
> Code-Effizient würde ich diese Abfrage in ein Makro packen. Wenn du den
> Pin natürlich sehr häufig an verschiedenen Stellen abfrägst ist das
> natürlich nicht so gut.

Daß ein Makro (oder das inline) ungünstiger wäre bei häufigem
Aufruf, glaube ich hier noch nicht einmal.
Ein Funktionsaufruf ist auch nicht kostenlos und kaum billiger
als das Testen eines Bits.

hast du nur ein = statt der nötigen zwei == geschrieben?

mh schrieb:
> Klaus Wachtler schrieb:
>> Daß ein Makro (oder das inline) ungünstiger wäre bei häufigem
>> Aufruf, glaube ich hier noch nicht einmal.
>> Ein Funktionsaufruf ist auch nicht kostenlos und kaum billiger
>> als das Testen eines Bits.
>
> Hmm? Das Bit muss so oder so getestet werden. Und wenn ich durch ein
> Makro oder ein "inline" einen Funktionsaufruf und einen Rücksprung
> spare, so ist die Ausführungszeit schneller. Eine ge-inline-te Funktion
> wird immer mindestens 2 Befehle schneller ausgeführt als eine normale
> Funktion, würde ich sagen.

Ich habe auch nicht von Rechenzeit gesprochen. Da ist die
inline-Version eh schneller.

Es ging mit bei dem obigen Zitat um die Anmerkung mit dem
häufigen Aufruf; der Nachteil hierbei kann bei Makro/inline sein,
daß der Code größer werden kann.
Dem habe ich für diesen Fall widersprochen, weil der Funktionsrumpf
eben nicht größer ist als der Aufruf (gemessen in Code im ROM).

> Zudem kann der Compiler die Funktion mit dem
> umgebenden Code optimieren, also noch ein bisschen Zeitgewinn. Auf
> Kosten der Codegröße. Der gcc entscheidet das bei entsprechenden
> Optionen sogar selbst.
>
> (Andere Optimierungen wie const-Funktionen könnten u.U. noch besser
> sein. [const passt nicht zu unserem konkreten Beispiel.] Deshalb sollte
> man die Funktionen immer ausreichend markieren.)

static ist hier das Mittel der Wahl, weil der Compiler dann
weiß, daß es außerhalb der Datei nicht benötigt wird.

tja, meine Version funktioniert (behaupte ich dreist),
deine ist dann wohl irgendwie anders.
Vermutlich in Zeile 42?

Tommy schrieb:
> hatte noch nen Fehler in den Defines....
Lass raten: ein Strichpunkt?