Return Anweisung mit Rückgabe vom Zustand des Ports

[Tommy (Gast)]

Hi,

bastel gerade ein wenig an einem neuen Projekt und hab ne Funktion die 
mir einfach nur den Zustand eines Pins zurückgibt....

int get_rx_pin_status(void)
{
  if (RX_PORT & (1 << RX))
  {
    return FALSE;
  }

  else
  {
    return TRUE;
  }
}

Funktioniert, aber irgendwie hab ich das Gefühl es geht auch einfacher 
bzw. kürzer. Hat einer ne Idee? Nur so aus reiner Neugier.....


Gruß

[Klaus W. (mfgkw)]

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

int get_rx_pin_status(void)
{
  return (RX_PORT & (1 << RX))!=0;
}

[Hans (Gast)]

Kürzer wäre es, den Pin direkt im Programm abzufragen.

[Klaus W. (mfgkw)]

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

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

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

[Antwort (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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

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

  if (get_rx_pin_status) {
    ...
  }

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

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

  if (!get_rx_pin_status) {
    ...
  }

[Klaus W. (mfgkw)]

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

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

[Andreas L. (anlo73)]

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

[Klaus W. (mfgkw)]

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

[mh (Gast)]

Als normale Funktion ist es schon okay. Der Compiler sollte eigentlich 
sehr klug entscheiden, ob er die Funktion von allein inlined (schneller 
in der Ausführung) oder nicht (weniger Code wenn die Funktion oft 
gebraucht wird), je nach Optimierungs-Parameter.

[Klaus W. (mfgkw)]

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.

[mh (Gast)]

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. 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.)

[Tommy (Gast)]

Wow,

vielen Dank für die schnellen und vielen Antworten!

Werd wohl bei der Variante von Klaus bleiben, einfach der 
Übersichtlichkeit halber. Nur warum gibts bei

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

folgende Fehlermeldung?

"..error: expected expression before '=' token"

[Klaus W. (mfgkw)]

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

[Klaus W. (mfgkw)]

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.

[Tommy (Gast)]

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

Nein, beide == sind da......

[Klaus W. (mfgkw)]

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

[Tommy (Gast)]

Jetzt gehts, hatte noch nen Fehler in den Defines....

Danke!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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