Funktion mit je 2 rückgabewerten?

[x5 (Gast)]

Guten Morgen zusammen,


ich habe eine kleine Frage und zwar habe ich mir eine Funktion gebaut
die kurz überprüft ob und welche meiner 2 Tasten gedrückt worden ist.
Wenn Taste_Links(4) gedrückt ist soll eine 1 zurück gegeben werden wenn 
Taste_Rechts(8) gedrückt worden ist soll eine 0 zurückgegeben werden.

nur wo bzw wie kann ich das ergebnis dieser funktion im weiteren 
programm ablauf abrufen?

hier die kleine funktion

test_funktion()
{
while(auswahl_getroffen == 0)
    {
    if(Schalter == 4)
      {auswahl_getroffen = 1; return 1;}
    if(Schalter == 8)
      {auswahl_getroffen = 1; return 0;}
  
    Schalter = 0;
    }
}

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

x5 schrieb:
> hier die kleine funktion
Diese kleine Funktion ist noch nicht ganz fertig, denn es fehlt
1. die Definition eines Rückgabetyps:

int test_funktion() {...

Und
2. kannst du dir die while-Abfrage sparen, denn die Funktion wird 
soweiso bei einem return verlassen:

{
while(1)
    {
    if(Schalter == 4) return 1;
    if(Schalter == 8) return 0;
    Schalter = 0;
    }
}

Eine Frage bleibt: woher kommt jetzt der Wert für den Schalter?
So wie die Funktion derzeit aussieht, ist das eine Endlosschleife... :-o

[x5 (Gast)]

Ach sorry vergessen - Ich frage im Timer1 Interrupt alle 100 ms die 
schalter zustände ab die an PING angeschlossen sind und setze dann die 
jeweiligen bits in "Schalter"

[Läubi .. (laeubi)]

Du testest aber weder die Bits noch prüft deine Funktion ob eine Taste 
gedrückt wurde vielmehr wartet die Funktion bis genau die eine 
oder andere Taste gedrückt wurde (grusel) und das "Ergebnis der 
Funktion" ruft man njicht ab sondern die Funktion auf und wertet 
dann den Rückgabewert aus...

[x5 (Gast)]

Ja das ich nur auf diese beiden Tasten warte ist wichtig - Später soll 
da noch eine kurze zeitschleife rein das man nur ca 5 sekunden in der 
funktion hängt und danach wird die abfrage abgebrochen. Die endscheidung 
ist sehr wichtig welche taste da gedrückt wird.

aber wie werte ich denn dann den rückgabe wert aus ?

[Justus S. (jussa)]

x5 schrieb:
> aber wie werte ich denn dann den rückgabe wert aus ?

das sollte wohl in jedem C-Buch oder Tutorial, egal wie schlecht, 
erklärt werden...

[Klaus W. (mfgkw)]

z.B. in der Art:

#define SCHALTER1 (0b00000100)
#define SCHALTER2 (0b00001000)
...
    while(1)
    {
        if( Schalter & SCHALTER1 )
        {
           Schalter  &= ~SCHALTER1; // dieses Bit wieder löschen
           return 1;
        }
        else if( Schalter & SCHALTER2 )
        {
           Schalter  &= ~SCHALTER2; // dieses Bit wieder löschen
           return 1;
        }
    }

Das passt zum Stil der meisten Beispiele hier.

[Artur R. (artur2000)]

in C können Funktionen nur einen Rückgabewert zurückgeben. Möchtest du 
trotzdem mehrer Rückgabewerte haben, macht man das mit Zeigern, indem 
die Adressen der rückgegbenen Variablen der Funktion übergeben wird und 
in der Funktion mit den Adressen gearbeitet wird. Für nähere 
Erläuterungen und Beispiele bitte googeln bzw. in einem C Buch 
nachgucken.

Wenn du mit Tastern arbeitest, wirst du Probleme mit Prellungen haben. 
Das heißt, du drückst einmal auf einen Taster, aber die Kontakte 
schließen und öffnen sich mehrmals. Deshalb empfehle ich dir die fertige 
Funktion "debounce" zu verwenden, die findest du hier irgendwo.

[Klaus W. (mfgkw)]

Oder eher meine Art:

typedef struct
{
   unsigned  schalter1:1;
   unsigned  schalter2:1;
   // ... weitere ...
} schalter_t;

schalter_t  derSchalter;

...

    while( 1 )
    {
        if( derSchalter.schalter1 )
        {
            derSchalter.schalter1 = 0;
            return 1;
        }
        else if( derSchalter.schalter2 )
        {
            derSchalter.schalter2 = 0;
            return 0;
        }
    }

[Klaus W. (mfgkw)]

Artur R. schrieb:
> in C können Funktionen nur einen Rückgabewert zurückgeben.

ich glaube, er will einen von 2 Werten zurückgeben, nicht beide 
gleichzeitig.

[M3 (Gast)]

Artur R. schrieb:
> in C können Funktionen nur einen Rückgabewert zurückgeben.

Und? Das will er ja machen; er will GENAU EINEN Wert zurückgeben, dieser 
soll je nach Situation unterschiedlich sein. Er will NICHT auf einmal 2 
Returnwerte zurückgeben das würde so gehen wie Du beschrieben hast.
So werden ja auch z.B. Fehlermeldungen realisiert.
Wenn gut: return 0; Wenn schlecht: return 1; ...

>Wenn du mit Tastern arbeitest, wirst du Probleme mit Prellungen haben.
Is hier auch nicht Thema...

2 Themaverfehlungen ;)

[Karl H. (kbuchegg)]

Klaus Wachtler schrieb:
> Artur R. schrieb:
>> in C können Funktionen nur einen Rückgabewert zurückgeben.
>
> ich glaube, er will einen von 2 Werten zurückgeben, nicht beide
> gleichzeitig.

Das glaub ich ehrlich gesagt nicht.
Sein Denken wird um die Fragestellung kreisen: Was, wenn beide Tasten 
gedrückt sind?
Dafür wurden ja auch schon Lösungen gennant, die alle nach dem Muster 
laufen: Man überlegt sich ein Schema, mit dem man auch beide Tasten 
kodieren kann und so wieder nur einen Returnwert braucht.

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

Artur R. schrieb:
> Wenn du mit Tastern arbeitest, wirst du Probleme mit Prellungen haben.
Da wäre es dann gut, wenn eine Kühlpackung in der Nähe wäre, damit es 
keine blauen Flecken gibt... ;-)

[x5 (Gast)]

Ja genau ich möchte nur einen wert der funktion übergeben. und zwar soll 
damit eine EnTscheidung getroffen werden. Ob der Zustand eines Ventils 
geändert werden soll und zwar wollte ich das in eine Funktion packen 
weil das auch noch mit 10 anderen Ventilen passieren sollte und ich 
nicht diese Auswertung 10 mal schreiben wollte


das sollte dann ungefähr im code so aussehn

......
test_funktion();

if("Funktionrückgabewert == 1")
{PORT_OUT |= (1<<V1);}
else
{"mache noch nichts"}
......

so in der art.

nur wie ich dann nach der funktion elegant deie Entscheidung abfragen 
kann. Klar ich könnte irgendne globale Variable auf 1 setzen in der 
Funktion - aber das müsste doch eleganter gehen oder ?

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

x5 schrieb:
> Ach sorry vergessen - Ich frage im Timer1 Interrupt alle 100 ms die
> schalter zustände ab die an PING angeschlossen sind und setze dann die
> jeweiligen bits in "Schalter"
Dann ist diese Denkweise hier falsch:

test_funktion()
{
while(auswahl_getroffen == 0)
    {
    if(Schalter == 4)
      {auswahl_getroffen = 1; return 1;}
    if(Schalter == 8)                       // **1**
      {auswahl_getroffen = 1; return 0;}
  
    Schalter = 0;                           // **2**
    } 
}

Denn was würde hier passieren, wenn genau hier (**1**) ein Interrupt 
käme und Schalter auf 4 setzen würde?
Richtig: gleich danach wird bei (**2**) der Schalter wieder auf 0 
zurückgesetzt...  :-o

Sogar das kann schiefgehen:

        if( Schalter & SCHALTER1 )
        {
           Schalter  &= ~SCHALTER1; // dieses Bit wieder löschen
           return 1;
        }

Wenn der Read-Modify-Write unterbrochen wird... :-o

Merke:
Interrupts kommen immer dann, wenn du sie am wenigsten vermutest!

x5 schrieb:
> - aber das müsste doch eleganter gehen oder ?
Ja, wenn du eine richtige Sofwarestruktur aufbauen würdest:
alle diese Tastenabfragen usw. usf. gehören in die Hauptschleife.
Und Tasten/Eingänge werden nicht über Interrupts, sondern in dieser 
Hauptschleife abgefragt.

Zeig doch mal deine komplette C-Datei (als Anhang mit Endung .c).

[H.Joachim S. (crazyhorse)]

Du kannst doch dem Rückgabewert verschiedene Werte geben, gerade bei 
Tastern oder Errorwerten nehme ich gerne eine direkte Bitkodierung.

#define TASTER1 1   //Bit 0
#define TASTER2 2   //Bit 1
#define TASTER3 4   //Bit 2
.
.



unsigned char Taster_lesen ()
{unsigned char temp=0;
if (xx) temp=temp | TASTER1;
if (xx) temp=temp | TASTER2;
if (xx) temp=temp | TASTER3;
return (temp);
}

So kannst du dann feststellen, ob überhaupt was passiert ist (return>0)
und wenn ja, welche, auch mehrere und beleibige Kombinationen.

[x5 (Gast)]

das sind rund 2k zeilen code wo es später eingesetzt werden soll. das 
ist momentan nur ein kleines test programm. Aber ich denke mal ich hab 
den rest schon nicht so toll programmiert. bei mir haperts an mangelnder 
erfahrung und zeitdruck. ich muss mir C# so schnell wie möglcih selbst 
beibringen und halt lernen

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

x5 schrieb:
> das sind rund 2k zeilen code wo es später eingesetzt werden soll.
Ja und? Dann poste das eben (als Anhang mit Endung .c)...
"Rat" kommt nicht von "Raten".

[x5 (Gast)]

Also speziell jetzt in meinem Fall wird später auf dem Display stehen 
Soll das V xy wirklich geöffnen werden und dann als Auswahl Ja / Nein 
welche man mit den Besagten Tasten auswählen kann.


Meine Menustruktur ist auch schon leicht Marode sowie die 
Tastenenprellung sollte geändert werden nur bleibt mir dafür grade keine 
Zeit. Momentan ist alles einfach nur mehr oder weniger eingeprügelt bis 
es läuft - weil da so ein druck hinter steht

[Sebastian B. (sebastian86)]

Oki ich hänge das Hauptfile dran. Nur nicht erschlagen ;)


Zum groben Aufbau in der Mainschleife ist man im Hauptmenu in dem man 3 
Verschiedene Programmmodi auswählen kann "Programm Automatik" habe ich 
vor 3 tagen auf eine Statemachine geändert das war vorher eine Abfolge 
ind If und Ifelse ich kannte bis Dato noch keine Statemachine

Programm Manuell ist grade in meiner Bearbeitung

[Rufus Τ. F. (rufus)]

x5 schrieb:
> das sind rund 2k zeilen code wo es später eingesetzt werden soll.

Ich will Dir ja nicht zu nahe treten, aber meinst Du nicht, daß Du Dich 
da ein winzigkleines Bisschen übernommen haben könntest? Das "Auswerten" 
des Rückgabewertes einer Funktion ist kein obskures Wissen, das man in C 
(oder oder auch beliebigen anderen Programmiersprachen) nur alle paar 
Monate mal braucht, das ist absolutes Grundlagenwissen.

Der Ansatz "learning by doing" ist ja an und für sich nicht völliger 
Mumpitz, wenn aber das "doing" überbetont wird und auf das "learning" 
komplett verzichtet wird, dann wird das ganze vollkommen nutzlos.

Literaturhinweis: Brian Kernighan & Dennis Ritchie "Programmieren in C", 
Hanser-Verlag, 2. Auflage.

Durchlesen! Übungen darin nachprogrammieren, Aufgaben darin bearbeiten. 
Nochmal durchlesen! Programmcode von anderen Leuten ansehen, versuchen, 
die dort gemachten Dinge zu verstehen und im Buch die entsprechenden 
Stellen finden.

Dann kannst Du gerne auch "2k zeilen code" entwickeln wollen. Dann. 
Aber nicht so.

[Sebastian B. (sebastian86)]

joar ich weiss :/ am anfang wars auch ein winziges Projekt alá kannst du 
mal gucken ob du das und das hinbekommst. Dann kam immer mehr und mehr 
dazu und wurde extrem aufgebläht.... :(

[Rufus Τ. F. (rufus)]

Dann nimm Dir 'ne Auszeit und lerne die Grundlagen. Jetzt! Sonst 
fällst Du später immer wieder auf irgendwelche Banalitäten rein.

[Karl H. (kbuchegg)]

Sebastian B. schrieb:
> joar ich weiss :/ am anfang wars auch ein winziges Projekt alá kannst du
> mal gucken ob du das und das hinbekommst. Dann kam immer mehr und mehr
> dazu und wurde extrem aufgebläht.... :(

Der übliche Softwarezyklus.
"Ach, das ist doch ganz einfach. Da ist doch die universelle 
Standardlösung komplett überkandidelt. Das machen wir ganz einfach"

Wochen, Monate, Jahre später: "Hätte ich doch damals nur ...."

Merke: Jede, aber ausnahmslos jede voreilig angenommene Vereinfachung 
oder Jugendsünde rächt sich irgendwann!

Eine zeitlang kann man das alles kaschieren, aber irgendwann bricht das 
Kartenhaus zusammen.

Dann ist es meistens mit 1 oder 2 Zeilen ändern nicht getan. Software 
entwickeln bedeutet auch, dass man sich mit jeder Erweiterung immer der 
Frage stellt: Ist meine Architektur dem Problem noch angemessen oder 
sollte ich sie besser jetzt anpassen anstatt in ein paar Wochen, wenn 
alles kurz vor dem Kollaps steht.
In der Theorie ist das nicht notwendig. Denn in der Theorie nimmt man 
immer von vorne herein gleich den richtigen Ansatz. Aber in der Praxis, 
gerade bei unerfahrenen Programmierern, ist diese Theorie nichts wert.

Aus genau diesem Grund wird hier im Forum Wert darauf gelegt, auch bei 
kleinen Programmen mit Softwareansätzen zu arbeiten, die sich bewährt 
haben und von denen wir wissen, dass sie auch nach einiger Zeit noch 
tragfähig sind. Selbst wenn das am Anfang nach unnötiger Mehrarbeit 
aussieht.