C++ falscher Funktions-Rückgabewert

[Ste R. (ste_r)]

Hallo zusammen,

ich stehe vor einem Problem, das mich an die Grenze meiner praktischen 
Erfahrung bringt.

Grundsätzliche Aufgabenstellung: Eingabe eines Zeichens am PC -> USART 
zum ATmega328. Einlesen des Zeichens -> nutzen, um andere Funktionen zu 
triggern.

Das Problem: Alles funktioniert erstmal gut, doch plötzlich (immer nach 
derselben Eingabefolge), liefert mir die untenstehende Funktion einen 
falschen Rückgabewert.

Info: Ich verzichte hier erstmal auf viel drum-herum, um nur die aus 
meiner Sicht Fehlerstelle aufzuzeigen.

//******************************
//uart_debugging.hpp

// ist "true", wenn ein Zeichen über USART empfangen wurde und gibt es über ret_val zurück
extern bool received_single_char(unsigned char* ret_val);

//******************************
// Hauptprogramm.cpp

unsigned char received_char = 0;

// Hier wird innerhalb der Funktion das empfagene Zeichen richtig ausgegeben (über UART zurück gesendet)
if(uart_debugging::received_single_char(&received_char))
{
   //wenn ich hierher komme, ist teilweise ein falsches Zeichen gesetzt (wird über UART raus gesendet)
   uart_debugging::write_char(received_char);
}

Also wenn ich mir den Rückgabewert (&received_char) innerhalb der 
Funktion ausgeben lasse, passt es. Außerhalb der Funktion aber nicht.

Interessant: Egal was ich dann eingebe, es bleibt immer derselbe falsche 
Wert gesetzt.

Was ebenfalls auftrat: obwohl ich innerhalb der Funktion bei nicht 
empfangenen Zeichen "false" zurückgegeben habe, hat die if() Abfrage 
teilweise permanent "true" gelesen.

Hat jemand eine Erklärung, bei welchen Situationen ein solches Verhalten 
auftreten kann?
Kann irgendwie der Pointer verbogen werden? Wenn ja, wie?
Stack-Overflow habe ich mit der mem-check-Funktion eigentlich schon 
ausgeschlossen. Waren noch >1000Bytes frei.

Danke schon mal.
Beste Grüße

[Oliver S. (oliverso)]

Wie immer: Fehler in Zeile 42.

Oliver

[rµ (Gast)]

Der Fehler ist im geheimen Teil der Quellen.

[Tim T. (tim_taylor)]

1. Warum unsigned char?
2. Wo ist der Source von received_single_char?

[Axel S. (a-za-z0-9)]

Ste R. schrieb:
> Info: Ich verzichte hier erstmal auf viel drum-herum, um nur die aus
> meiner Sicht Fehlerstelle aufzuzeigen.

Dummerweise verzichtest du auch auf alles, was Licht auf das Problem 
werfen könnte.

> Also wenn ich mir den Rückgabewert (&received_char) innerhalb der
> Funktion ausgeben lasse, passt es. Außerhalb der Funktion aber nicht.

Das kann man deinen Codefragmenten nicht entnehmen. Genau genommen gibst 
du nirgenwo irgendetwas aus.

Ist es denn so schwer, den Code zu zeigen der nicht funktioniert und dem 
den Code gegenüber zu stellen, der funktioniert? Und zwar 
sinnvollerweise Code, der auch bei einem anderen compiliert? Und weil 
das dann mehr Code als Text sein wird, in Form eines Anhangs?

[rµ (Gast)]

Ste R. schrieb:
> Interessant: Egal was ich dann eingebe, es bleibt immer derselbe falsche
> Wert gesetzt.
>
> Was ebenfalls auftrat: obwohl ich innerhalb der Funktion bei nicht
> empfangenen Zeichen "false" zurückgegeben habe, hat die if() Abfrage
> teilweise permanent "true" gelesen.

das täuscht auch, unter garantie. klingt eher danach als würde die 
funktion in dem fall gar nicht aufgerufen.

[Ste R. (ste_r)]

Vorteil im Forum: Schnelligkeit und Expertise,
Nachteil: Fehlende Sachlichkeit.... (gilt nicht für alle ;-) )

Wie ich schrieb, ich habe bewusst andere Teile vom Code weggelassen, 
damit der geneigte Antwortende nicht gleich ein halbes Buch lesen muss..

Hier die aufgerufene Funktion (im Wesentlichen aus dem 
uart-std-Beispiel) - sicherlich hätte ich die auch gleich mit angeben 
können:

#include "uart.h"

bool received_single_char(unsigned char* ret_val)
{
   bool b_retVal = false;
   uint16_t c = uart_getc();

   if ( c & UART_NO_DATA )
   {
      /* 
       * no data available from UART 
       */

        *ret_val = 0u;
        b_retVal = false;
   }
   else
   {
       /* 
        * send received character back
        */
        uart_putc( (unsigned char)c );

        /* return via function */
        *ret_val = (unsigned char)c;
        b_retVal = true;
   }
   return b_retVal;
}


void write_char(unsigned char data)
{
   uart_putc(data);
}

[Oliver S. (oliverso)]

Da fehlt Zeile 42.

Oliver

[rµ (Gast)]

Ein paar zusätzliche Salami-Scheiben brauchts noch.

[rµ (Gast)]

Ich hol schon mal die Kartoffelchips...

[Ste R. (ste_r)]

Tim T. schrieb:
> 1. Warum unsigned char?

Weil die "Standard" Funktionen der uart-Lib mit unsigned char arbeiten

Axel S. schrieb:
> Ist es denn so schwer, den Code zu zeigen der nicht funktioniert und dem
> den Code gegenüber zu stellen, der funktioniert? Und zwar
> sinnvollerweise Code, der auch bei einem anderen compiliert? Und weil
> das dann mehr Code als Text sein wird, in Form eines Anhangs?

Witzigerweise ist es derselbe Code. Ich mache ein paar Eingaben -> 
funktioniert. Paar Eingaben später -> funktioniert nicht mehr.

Sicher kann ich auch das ganze Projekt hochladen (bzw privat schicken). 
Aber erstmal möchte ich abklopfen, obs nicht etwas offensichtliches ist, 
ehe sich jemand die Mühe macht. Sind halt schon ein paar Zeilen..

rµ schrieb:
> das täuscht auch, unter garantie. klingt eher danach als würde die
> funktion in dem fall gar nicht aufgerufen.

Das glaube ich nicht, weil innerhalb der Funktion gibt's ja auch ne 
Ausgabe, die richtig funktioniert. Siehe Funktionscode in meinem letzten 
Post.
nach dem Motto:
>innen: 1 > außen: 1
>innen: 3 > außen: 3
>innen: 5 > außen: 5
>innen: 3 > außen: Y
>innen: 5 > außen: Y

VG

[rµ (Gast)]

Ste R. schrieb:
> rµ schrieb:
>> das täuscht auch, unter garantie. klingt eher danach als würde die
>> funktion in dem fall gar nicht aufgerufen.
>
> Das glaube ich nicht, weil innerhalb der Funktion gibt's ja auch ne
> Ausgabe, die richtig funktioniert. Siehe Funktionscode in meinem letzten
> Post.
> nach dem Motto:
>>innen: 1 > außen: 1
>>innen: 3 > außen: 3
>>innen: 5 > außen: 5
>>innen: 3 > außen: Y
>>innen: 5 > außen: Y

Das Problem liegt jedenfalls nicht (offensichtlich) im code der bis 
jetzt gezeigt wurde. Es fehlt auch noch die Hauptschleife und die uart_ 
Funktionen, die scheinen aus einer Library zu stammen, und ich gehe mal 
davon aus dass die lib funktioniert.

[Ste R. (ste_r)]

Und nochmal, weshalb ich nicht mehr Code gepostet habe:

Aus meiner Sicht ist es:

char Variable;
f(&Variable); //<-- ändern Variablenwert und gibt Ergebnis aus
read(Variable); //<-- nicht der erwartete (gleiche) Wert

Bitte erleuchtet mich, was der restliche Code dazu beitragen kann?!
Btw. ich hab auch schon ein cli() und sei() ringsrum gebaut: keine 
Besserung.

rµ schrieb:
> Das Problem liegt jedenfalls nicht (offensichtlich) im code der bis
> jetzt gezeigt wurde.

Gibt es übliche Fehler, die ich selbst überprüfen kann?

rµ schrieb:
> die uart_
> Funktionen, die scheinen aus einer Library zu stammen, und ich gehe mal
> davon aus dass die lib funktioniert.

Ja, davon gehe ich auch aus

[rµ (Gast)]

Ste R. schrieb:
> Bitte erleuchtet mich, was der restliche Code dazu beitragen kann?!
> Btw. ich hab auch schon ein cli() und sei() ringsrum gebaut: keine
> Besserung.

Einfacher als aufzuzählen was man in C++ auf einem µC alles falsch 
machen kann wäre es den Code anzusehen. Whatever. Viel Spass noch. Gn8.

[Tim T. (tim_taylor)]

Welche Baudrate benutzt du und welchen Quarz? Lib ist von Peter Fleury?

[g457 (Gast)]

> Gibt es übliche Fehler, die ich selbst überprüfen kann?

<salamitaktik>Ja.</>

HTH und nix für ungut

[Ste R. (ste_r)]

rµ schrieb:
> Einfacher als aufzuzählen was man in C++ auf einem µC alles falsch
> machen kann wäre es den Code anzusehen.

Ja, da hast du wohl recht. Fehler gefunden: ein char-Array an ganz 
anderer Stelle im Programm war ein Feld zu klein.. Asche auf mein Haupt.

Danke trotzdem..

[Tim T. (tim_taylor)]

Ste R. schrieb:
> rµ schrieb:
>> Einfacher als aufzuzählen was man in C++ auf einem µC alles falsch
>> machen kann wäre es den Code anzusehen.
>
> Ja, da hast du wohl recht. Fehler gefunden: ein char-Array an ganz
> anderer Stelle im Programm war ein Feld zu klein.. Asche auf mein Haupt.
>
> Danke trotzdem..

Mit komplettem Quelltext wäre das eventuell auch jemandem aufgefallen...

[mh (Gast)]

Tim T. schrieb:
> Ste R. schrieb:
>> rµ schrieb:
>>> Einfacher als aufzuzählen was man in C++ auf einem µC alles falsch
>>> machen kann wäre es den Code anzusehen.
>> Ja, da hast du wohl recht. Fehler gefunden: ein char-Array an ganz
>> anderer Stelle im Programm war ein Feld zu klein.. Asche auf mein Haupt.
>> Danke trotzdem..
>
> Mit komplettem Quelltext wäre das eventuell auch jemandem aufgefallen...
Ja, der vollständige Quelltext hätte vielleicht geholfen (falls sich 
jemand die Mühe gemacht hätte ihn zu lesen). Was sicher geholfen hätte, 
wäre ein minimales compilierbares Beispiel, das den Fehler reproduziert. 
Dann hätte er den Fehler ziemlich wahrscheinlich selbst gefunden, bevor 
er das erste Wort seiner Frage hier im Forum geschrieben hat.

[Axel S. (a-za-z0-9)]

mh schrieb:
> Was sicher geholfen hätte, wäre ein minimales compilierbares
> Beispiel, das den Fehler reproduziert.
> Dann hätte er den Fehler ziemlich wahrscheinlich selbst gefunden

Genau das war der Grund, weswegen ich danach gefragt hatte.

[Forist (Gast)]

Oliver S. schrieb:
> Wie immer: Fehler in Zeile 42.

Aber wie soll man ohne mühseliges Abzählen herausfinden, welches die 
Zeile 42 ist, wenn keine C Code-Tags verwendet werden?

[Tim T. (tim_taylor)]

Forist schrieb:
> Oliver S. schrieb:
>> Wie immer: Fehler in Zeile 42.
>
> Aber wie soll man ohne mühseliges Abzählen herausfinden, welches die
> Zeile 42 ist, wenn keine C Code-Tags verwendet werden?

Und da sagt man es gibt keine dummen Fragen...

[Oliver S. (oliverso)]

Forist schrieb:
> Aber wie soll man ohne mühseliges Abzählen herausfinden, welches die
> Zeile 42 ist, wenn keine C Code-Tags verwendet werden?

Ist doch einfach: Zeile 42 ist die mit dem Fehler.

Oliver

[Ford (Gast)]

Tim T. schrieb:
> Forist schrieb:
>> Oliver S. schrieb:
>>> Wie immer: Fehler in Zeile 42.
>>
>> Aber wie soll man ohne mühseliges Abzählen herausfinden, welches die
>> Zeile 42 ist, wenn keine C Code-Tags verwendet werden?
>
> Und da sagt man es gibt keine dummen Fragen...

Bis Du das, Deep Thought?

[Carsten P. (r2pi)]

Ford schrieb:
> Bis Du das, Deep Thought?

Wenn du Ford bist, weißt du, dass Deep Thought nur Antworten weiß, nicht 
die passenden Fragen dazu =p