www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Return Anweisung mit Rückgabe vom Zustand des Ports


Autor: Tommy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
}

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kürzer wäre es, den Pin direkt im Programm abzufragen.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;

Autor: Antwort (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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) {
    ...
  }

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;

Autor: Andreas L. (anlo73)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Tommy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hast du nur ein = statt der nötigen zwei == geschrieben?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tommy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>hast du nur ein = statt der nötigen zwei == geschrieben?

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

Autor: Klaus Wachtler (mfgkw)
Datum:

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

Autor: Tommy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt gehts, hatte noch nen Fehler in den Defines....

Danke!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.