"while" Bedingung hält nicht was es verspricht

Also wenn es an sowas hapert, hilft es häufig obskure "Konstrukte" 
aufzulösen...
Erstmal wir i nicht initialisiert, als nächstes wird Buffer etwas 
zugewiesen bevor die Schleife verlassen wird, und als nächstes wird 
falls kein Komma kommt (warum auch immer) fröhlich der Speicher 
vollgeschrieben in alle möglichen anderen Datenstrukturen hin nein...

1

void uartstr (char* buffer, int len)

2

{  

3

  int i = 0;

4

  for(; i < len; i++) {

5

    char c = receive();

6

    if (c == ',') {

7

     break;

8

    }

9

    buffer[i] = c;

10

  }

11

  buffer[i] = '\0';

12

}

Attila schrieb:
> Mein C Buch sagt dass in einer nicht initialsierten variablen eben
> irgendein Wert drin steht. Aber das ist doch nicht schlimm wenn man
> unmittelbar was hineinschreibt?

Ja, aber in deiner ersten Version wird nicht unmittelbar was 
hineingeschrieben. Vorher findet schon der erste "i!=','"-Test statt.

> Wenn das Komma zu unsicher ist ( habe ich das richtig verstanden?) um
> eine Schleife zu beenden, was wäre dann der bessere Weg?

Besser wäre es zusätzlich eine Längenbegrenzung mit in die Schleife 
aufzunehmen.

Attila schrieb:
> Wenn das Komma zu unsicher ist ( habe ich das richtig verstanden?) um
> eine Schleife zu beenden, was wäre dann der bessere Weg?
Nein das Komma an sich ist nicht unsicher!

Unsicher ist es einen Pointer gnadenlos ohne wissen der Länge des 
reservierten Speichers vollzuschreiben.

Attila schrieb:
> Warum sollte denn das NMEA Protokol kein Komma ausspucken?
Wer garantiert dir das du einen gültigen NEMA String empfängst? Zumal 
dieser nicht mit einem Komma Endet! (Ein Zeilenumbruch sollte also am 
besten auch noch die Schleife abbrechen..., und das anfängliche $ könnte 
man auch noch unterdrücken...)
Und spätestens hier kommt man an einen Punkt, wo alles in eine While 
Bedingung zu packen die Sache nicht übersichtlicher macht.

Und das ist am Anfang das aller wichtigste!

Und was machst du wenn der Aufrufer (sei es auch Speichernot sei es aus 
Unachtsamkeit) nur einen Buffer der Länge 3 angelegt hat... deshalb 
sollte man immer die Länge des buffers zusätzlich übergeben und auch 
prüfen!

Peter schrieb:
> Mit dem ,-Operator kannst du mehrere Anweisungen nacheinander ausführen,

Bitte!
Theatere den Fragesteller nicht in den Komma-Operator hinein, zumal er 
an dieser Stelle unnötig ist, weil ein && hier ganeusogut das gewünschte 
erledigt. Ganz im Gegenteil, wenn der scanf schief geht, kannst du dir 
mit dem Komma Operator hier ganz schönen Ärger einhandeln, weil kein 
Mensch dir garantiert, dass i dann 0 wird.

Der Komma-Operator ist ein konstanter Quell des Ärgernisses, 
insbesondere für Neulinge.

Läubi .. schrieb:

>> Warum sollte denn das NMEA Protokol kein Komma ausspucken?
> Wer garantiert dir das du einen gültigen NEMA String empfängst?

@Attila
Das ist überhaupt ein wichtiger Punkt bei (fast) jeglicher 
Eingabeverarbeitung.
Nachdem du deine Eingabebehandlung fertig hast, setz dich hin und 
überleg dir, was alles noch passieren kann. Dazu stellst du dir einfach 
vor, deine Engabe kommt nicht einfach voin irgendwo her, sondern von 
einer Tastatur und auf diese legst du einen Stein drauf. Übersteht das 
deine Eingaberoutine?
Oder noch schlimmer, du fährst mit der Hand ein paar mal wahllos von 
links nach rechts und wieder zurück über die Tastatur (Gewiefte setzen 
ein Kleinkind an die Tastatur und lassen es einfach drauflosklimpern). 
Eine gute Eingaberoutine übersteht so etwas, ohne das etwas Schlimmes 
passiert. Klar das Programm wird (und soll) einen Fehler registrieren 
und vielleicht sogar auch melden, aber es wird unter keinen Umständen 
etwas Schlimmes passieren, wie zb Speicher niederbügeln, der gar nicht 
mehr zum Eingabearray gehört oder Auswertungen mit falschen Daten 
machen.

Das Interessante daran. Es ist gar nicht mal so schwer eine Eingabe 
gegen derartige Dinge abzusichern und oft sind die Modifikationen gar 
nicht schwer und gar nicht mal so groß. Mit ein paar kleinen 
Umstellungen und Abfragen ist das alles erledigt und berücksichtigt.

Attila schrieb:
> So richtig?
>
> void uartstr (char* buffer)

nein.
Wenn du eine Funktion schreibst, die in einem Array etwas ablegen soll, 
dann ist es PFLICHT, dass der Aufrufer die Größe des Arrays mitgeben 
muss.

Alles andere ist 'Ask for trouble'

> {
>   int i=0,check=0;
>
>   i=receive();
>   while(i!=','&&check<=10)

:-)
Woher weißt du die 10?
Genau davon hat der erste Absatz gehandelt. Diese 10 muss der Aufrufer 
der Funktion der Funktion mitgeben. Denn nur er kann das wissen.

1

void uartstr (char* buffer)

2

{

3

  int i=0,check=0;

4

5

  i=receive();

int i? Wieso int? Hier ist von Zeichen aus der UART die Rede. Konkret 
ASCII Zeichen. Also char

Attila schrieb:
> @Karl Heinz:
>
> Genau: Wieso eigentlich int? Ärgerlicher Fehler!
>
> Zu der 10: Ich lese ja ein NMEA Protokol aus. Zumindest in dem Protokol
> (RMC) was ich auslese ist das länsgte string 10 Zeichen lang. Nämlich
> der Längengrad. Ist aber falsch gedacht wie ich jetzt begriffen habe.

Yep.
Frag dich einfach:

Ist diese Funktion in irgendeiner Art und Weise NMEA spezifisch?
Eigentlich doch nicht. Denn diese Funktion soll einen String empfangen. 
Ob den ein Benutzer eingibt, oder ob der von einer Fräsmaschine kommt 
oder eben wie bei dir von einem GPS Empfänger ist doch erst mal für die 
Funktion selber uninteressant.

Und da du nicht bei jedem Projekt das Rad immer wieder neu erfinden 
willst, schreibst du dir am liebsten immer Funktionen, die eben dieses 
Wissen nicht in ihrem Code enthalten haben, sondern allgemein verwendbar 
sind.

In deinem Code gibt es keinerlei Sicherung gegen diesen Fall

  char buffer[4];
  uartstr (buffer);

Ooops. Das Feld hier ist nur 4 Zeichen lang. Trotzdem behandelt es deine 
Funktion als ob es 10 Zeichen lang wäre. Komplette Rechenzentren wurden 
wegen solcher blödsinniger Annahmen in Funktionen schon lahmgelegt.

Hier, beim Aufruf weiß ich, wei lang mein Array ist, in welches ich den 
String reinhaben möchte. Also

  char buffer[4];
  uartstr( buffer, sizeof(buffer) );

uartstr muss jetzt nur noch mit dieser Zahl arbeiten. Das kostet uartstr 
nichts und das kostet mir hier beim Aufruf nichts. Nur hab ich plötzlich 
eine Funktion, die ich allgemeiner benutzen kann.

Welche Annahmen hast du in uartstr noch getroffen?
Du hast noch die Annahme getroffen, dass der String mit einem ',' 
aufhört. Muss das so sein? (Denk jetzt an den allgemeinen Fall). Könnte 
man diese Annahme in der Funktion leicht loswerden?

Ja, könnte man
Dann sieht halt der Aufruf so aus

  char buffer[4];
  uartstr( buffer, sizeof(buffer), ',' );

und die Funktion bekommt das Ende Zeichen mit.

> Allerdings wirft das eine neue Frage auf:
>
> Wie mache ich das denn bei einem String bei dem das Protokol selber
> entscheided wieviele zeichen es hat?

Das geht in C auf deinem µC nicht vernünftig. Dazu müsste man dynamisch 
Speicher allokieren und das möchte man auf so einem kleinen µC 
eigentlich nicht tun. Leb damit, dass du den Buffer beim Aufrufer 
großzügig genug dimensionierst, so dass alles reinpasst.

http://www.mikrocontroller.net/articles/FAQ#wie_schreibt_man_eine_Funktion.2C_die_einen_String_liefert.3F

Attila schrieb:

> Wobei im main dies steht:
>
> char rein[11]
>
> Und als Aufruf dies z.b.:
>
> uartstr(rein,1);  //Wenn es um das Zeichen "N" oder "S" oder ähnliches
> geht

Nein, das machst du so nicht.
Du hast das ',' von der Eingabe, welches den String beendet.

Hier geht es nicht darum, wie lang der String ist, den du erwartest, 
sondern darum wie groß der Buffer ist, den du uartstr zur Vefügung 
stellst um dort den String abzulegen.


Denn ob von der SChnittstelle tatsächlich der String kommt, den du 
erwartest, kannst du sowieso nicht sicher stellen.

> uartstr(rein,10) //Wenn es um den Längengrad geht

  char rein[11]
  uartstr(rein,11);

weil rein 11 char groß ist.
Oder eben

  char rein[11]
  uartstr( rein, sizeof(rein) );

dann brauchst du das nicht selber abzählen sondern der Compiler macht 
das für dich.

Attila schrieb:
> Ich glaube so soll es sein:
>
> void uartstr (char* buffer,int size,char zeichen)
> {
>   char i=0;
>   int zaehler=0;
>
>   i=receive();
>   while(i!=zeichen&&zaehler<=size)
>   {
>     zaehler++;
>     *buffer++=i;
>     i=receive();
>   }
>   *buffer='\0';
> }
>
> Aufruf geht so:
>
> uartstr(rein,sizeof(rein),',');
>
> Funktioniert, sieht besser aus,

Ist so schon eine gute Lösung.

> löst aber mein Problem nicht:

Das ist jetzt aber auch eine komplett andere Baustelle

> Kann es sein das der Atmega 8 schlichtweg überfordert ist?

Überfordert wäre er jetzt höchstens, wenn er mit der Rechenzeit nicht 
mehr mitkommt. Aber davon war ja jetzt erst mal noch überhaupt nicht die 
Rede

Zum anderen musst du bedenken, dass dein Mega mit wesentlich weniger 
Kommastellen arbeitet als dein PC. Rechenungenauigkeiten werden so im 
Lauf der Zeit immer größer, wenn man es ungeschickt anfängt.

Deine Beschreibung klingt aber eher nach einem Programmfehler.

Ohne Programm kann man da aber wenig dazu sagen.
Was mich stutzig macht ist, das du anscheinend beim UART Empfang schon 
weißt, was du empfangen wirst. Das kann gut gehen, muss es aber nicht, 
je nachdem wie es programmiert ist. Daher würde ich NMEA auch niemals so 
empfangen, dass ich der Empfangsroutine sage: lies mal alles bis zum 
','. Sondern immer so, dass ich erst mal eine komplette NMEA Zeile 
empfange. Und nur dann, wenn ich die komplett habe, fange ich an sie zu 
zerlegen und weiterzuverarbeiten. Denn eines ist auch klar. Während der 
Mega am Rechnen ist, beginnt das GPS schon die nächste Übertragung. Das 
wartet nicht auf dich.

Aber wie gesagt: Ohne Programm kann man da überhaupt nichts sagen.

Karl heinz Buchegger schrieb:
> Ist so schon eine gute Lösung.

Na, na, na, Karl Heinz, also ich sehe da einen Out-Of-Bound-Zugriff. ;-)

Stefan Ernst schrieb:
> Karl heinz Buchegger schrieb:
>> Ist so schon eine gute Lösung.
>
> Na, na, na, Karl Heinz, also ich sehe da einen Out-Of-Bound-Zugriff. ;-)

Hast recht.
Zwischendurch hab ich ihn mal gesehen, aber dann wieder verschwizt.

Attila schrieb:
> @Stefan: Ein "Raus aus Schranke" Zugriff? ;-) Und was ist das?

Wenn du 6 Zeichen in ein Array der Länge 5 quetschen willst


  while(i!=zeichen&&zaehler<=size)

Hier: das <= fängt diesen potentiellen Fehler nicht ab.

Attila schrieb:
> Muss es < heissen damit noch Platz für das "/0" ist?
nein, weil die Zählung bei 0 beginnt...
Warum beist du dich eigentlich mit aller Kraft an deiner while Schleife 
fest? Ich hatte oben doch shcon ein Beispiel gepostet was dieses 
"Problem" umgeht, und welches die "normale" Notation für Array zugriffe 
nutzt...
Ebenso das problem mit int/char war dort auch schon gelöst man darf auch 
gerne sich Beispiele mal angucken, es besteht keine Pflicht zu 
iterative-trial-and-error-programming...

Attila schrieb:

> Meine LCD Routine machte nur Cursor return und NICHT clear display.

Sie soll auch nicht 'Clear Display' machen.

Das führt zu Flackern auf dem LCD.

Ist doch nicht so schwer. Wenn du die Zeichen dahinter weghaben willst, 
dann schreib halt einfach Leerzeichen drüber.
Oder formatiere die Zahl immer so, dass sie immer in einem String mit 3 
Zeichen rechtsbündig dargestellt wird. Aussuchen kannst du dir ob du 
führende 0-en haben willst oder ob führende 0-en durch Leerzeichen 
ersetzt werden sollen.

Clear Display willst du sparsam einsetzen, aber auf keinen Fall um dein 
Display in Ordnung zu halten, wenn sich Werte ändern.

@Karl Heinz:

Ich finde das nicht einfach.Echt nicht.
Ich finde deinen Hinweis aber sehr nützlich und werde versuchen ihn 
umzusetzen.

Gibt es Beispiele zu , am liebsten, beide Versionen?

Ach so: Wieso will man clear display nicht einsetzen um das Display in 
Ordnung zu halten. Nur wegen des Flackerns oder gibt es noch andere 
Gründe?

Attila Ciftci schrieb:
> Ach so: Wieso will man clear display nicht einsetzen um das Display in
> Ordnung zu halten. Nur wegen des Flackerns

Genau.
Ausserdem musst du dann andere Dinge auf dem LCD wieder neu schreiben. 
Ist ja alles ebenfalls weg.

Nach Möglichkeit willst du am LCD immer nur die Dinge verändern, die 
auch verändert werden müssen. Und das so, dass du nichts anderes dabei 
beschädigst.  Clear ist so ziemlich die schlimmste Form von 
'Beschädigung', die du deiner Anzeige antun kannst.


Wie gesagt, die Technik dazu ist nicht weiter schwierig (*). Du musst 
nur darauf achten, dass auch immer alles alte überschrieben wird. Am 
einfachsten geht das, wenn man für jede Ausgabe auf dem LCD ein 'Feld' 
mit einer bestimmten Stellenanzahl vorsieht und dort Zahlen 
reinschreibt. Wenn alle Stricke reissen, kann man vorher immer noch 
genau dieses Feld vorher mit einer entsprechenden Anzahl Leerzeichen 
'löschen' und dann die neue Zahl dort hinschreiben. Macht man diesen 
Update nur dann, wenn er auch tatsächlich notwendig ist (nur dann wenn 
sich die Zahl auch geändert hat), dann merkt das noch nicht einmal wer. 
Aber es ist auch nicht weiter schwer, die Zahlen so zu formatieren, dass 
sie immer alles überschreiben.

Zahlen auch am besten rechtsbündig ausgeben. Nichts ist so lästig, wie 
eine Zahl zu beobachten, die am Display ständig hin und her springt. Die 
Einerstelle der Zahl sollte immer an der gleichen Position am LCD sein.

(*) Entweder schreibt man sich selber was, oder aber wenn man es sich 
leisten kann benutzt man einfach sprintf. Das hat ein paar nette 
Formatieroptionen mit, die man hier sinnvoll einsetzen kann.

@Karl Heinz:

Diese Tipps sind natürlich GOLD!  Klasse! Vielen Dank!