Analyse NMEA Datensatz klappt nicht so richtig - Rechnenleistung schuld

Hallo
Danke für Deine Antwort.

Ich weiß, dass einige Strings leer sein können.
Aus diesem Grund haben ich auch die strsep Funktion genommen und nicht 
die strtok Funktion, die nämlich mit leeren Token nichts anfangen kann.

Reale Strings aus meinem Gerät sind uim Quelltext ganz oben.

Hast Du noch eine andere Idee ?

Gibt es Links zu Seiten, wo andere das Problem mit diesen Strings schon 
gelöst haben ?

danke und Gruß
Torsten

Du reservierst Speicher mit
  running = strdup(uart_string[j]);
und gibst ihn mit
  free(running);
frei. Das ist im Prinzip ok, aber dazwischen wendest du mit
  ptr = strsep(&running,delimiter);
eine Funktion an, die running modifiziert. Das ist nicht ok, weil dann 
beim free() eine Adresse übergeben wird, die nichts mehr mit dem zu tun 
hat, was du von strdup() erhalten hast. Das bringt die 
Speicherverwaltung durcheinander, die Folgen sind nicht absehbar.

@Konrad:
Bin auch noch neu auf diesem Gebiet, aber diese vorgehensweise ist in 
vielen Beispielen zu der Funktion strsep so zu sehen.
Wie würdest Du es machen ?
Ich habe schon versucht ohne strdup auszukommen, aber dann geht gar 
nichts.

grüße
Torsten

Eine Möglichkeit:
  char *merken;
  merken = running = strdup(uart_string[j]);
  ... //unverändert
  free(merken); //statt free(running);
Hier wird die richtige Adresse an free() übergeben.

Andere Möglichkeit:
  running = uart_string[j]; //kein strdup(), kein free()
Hier wird zwar das String-Array manipuliert (',' mit '\0' überschrieben, 
aber wenn du damit leben kannst, sparst du dir die gesamte dynamische 
Speicherverwaltung und damit auch Speicher.
"Spare in der Zeit, dann hast du in der Not", haben die Alten uns immer 
gesagt. Passt hier ganz gut, finde ich. ;-)

Mal davon abgesehen ist der NMEA Parser Schrott. Sowas macht man eher 
per State-Machine und hangelt sich an den Kommata durch, da die Anzahl 
der Zeichen innerhalb eines NMEA Datensatzes nicht festgelegt ist (wie 
oben schon angemerkt).

Danke
Werde ich gleich zu hause mal ausprobieren.
Wenn ich mich richtig entsinne, habe ich aber schon ausprobiert, den 
running pointer direkt auf den Ur-String zeigen zu lassen. Ich meine, 
dass strsep dann nicht funktioniert hat. Aber ich werde testen und 
berichten :-)
Versuch macht kluch ...

Was ich allerdings noch nicht verstanden habe ist, warum sich die Start 
Adresse der String-Kopie unter strdup verändert. Es wird doch nur ein 
1Byte Komma durch ein 1Byte "0" ersetzt. Bleibt die Länge  und damit der 
belegte Speicherbereich dabei nicht gleich?

grüße
Torsten

@Simon:
Bin mir wegen der Anzahl der Komma in einem Satz-Typ nicht sicher, aber 
vorstellen kann ich mir nicht, dass die Anzahl nicht festgelegt ist.
Ob das Feld beschrieben ist, oder nicht ist nicht festgelgt, aber woher 
sollte ein Parser (egal welcher Bauart) wissen, in welchem Feld er 
gerade ist, wenn die Anzahl der Felder nicht vorgegeben wäre ?

Werde es aber auch mal mit einer State-Machine probieren.

Grüße
Torsten

@Rolf:
Ich prüfe in der Hauptschleife die Checksumme des Satzes. Hier wird 
festgestellt, ob alles drin ist. Wenn das der Fall ist, gehe ich davon 
aus, dass das $ an der ersten Stelle im String steht.
Ist das Flasch ?

Grüße
Torsten

@Rolf:

Rolf Magnus schrieb:
> Was denkst du, woher strsep beim zweiten Aufruf weiß, daß das erste
> Token schon gelesen wurde? Oder warum du nicht den Zeiger, sondern
> dessen Adresse übergeben mußt? Antwort: In diesem Zeiger speichert
> strdup die Position des ersten Zeichens nach dem Komma, so daß es beim
> nächsten Aufruf da weitermachen kann.

OK, jetzt hab ich es kapiert .... (mechanisches Hirn halt) :-)

Torsten B. schrieb:
> Was ich allerdings noch nicht verstanden habe ist, warum sich die Start
> Adresse der String-Kopie unter strdup verändert. Es wird doch nur ein

Generell ist jede Verwendung einer Pointer-Referenz (also die Adresse 
des Pointers, wie bei &running), bei welcher der Pointer mit strdup(), 
malloc() usw. belegt wurde, verdächtig (==Fehler), sofern nicht 
besondere Vorkehrungen getroffen wurden (Sicherungskopie).

Performanz:
1. Wenn du es eilig hast, dann solltest du nach "GPRMC" (oder "$GPRMC") 
nicht mit strstr() suchen, weil immer der gesamte String abgesucht 
werden muss, falls der gesuchte String nicht enthalten ist. Da du eine 
genaue Vorstellung davon hast (hast du doch, ja?), wo der String zu 
finden sein müsste, kannst du dort besser mit strncmp() nachschauen. Und 
evtl. ist es angebracht nach "$GPRMC," zu suchen, weil es auch ein 
"$GPRMCL" geben könnte (von ',' zum 'L' ist es nur ein Bit das umfallen 
muss und ein weiteres Bit an gleicher Position in einem anderen Byte, 
damit die NMEA_checksum() wieder stimmt).

2. Zwischen die
  if (strstr(uart_string[j],"PFLAU")) { ... }
  if (strstr(uart_string[j],"GPRMC")) { ... }
würde ich noch ein else setzen. Wenn es ein "PFLAU" ("$PFLAU,") war, 
kann es kein "GPRMC" sein. Und auf die häufiger vorkommenden Datensätze 
zuerst testen.

Konrad S. schrieb:
> Performanz:
> 1. Wenn du es eilig hast, dann solltest du nach "GPRMC" (oder "$GPRMC")
> nicht mit strstr() suchen, weil immer der gesamte String abgesucht
> werden muss, falls der gesuchte String nicht enthalten ist. Da du eine
> genaue Vorstellung davon hast (hast du doch, ja?), wo der String zu
> finden sein müsste, kannst du dort besser mit strncmp() nachschauen. Und
> evtl. ist es angebracht nach "$GPRMC," zu suchen, weil es auch ein
> "$GPRMCL" geben könnte (von ',' zum 'L' ist es nur ein Bit das umfallen
> muss und ein weiteres Bit an gleicher Position in einem anderen Byte,
> damit die NMEA_checksum() wieder stimmt).
>
> 2. Zwischen die
>   if (strstr(uart_string[j],"PFLAU")) { ... }
>   if (strstr(uart_string[j],"GPRMC")) { ... }
> würde ich noch ein else setzen. Wenn es ein "PFLAU" ("$PFLAU,") war,
> kann es kein "GPRMC" sein. Und auf die häufiger vorkommenden Datensätze
> zuerst testen.

Das leuchtet ein und wird heute Abend gleich mal angetestet.
Danke

HAllo Gruppe

Hab all Eure Tips mal ausprobiert,aber keinen Erfolg gehabt. Der Fehler 
liegt in einer anderen Ecke.

Habe ein kleines Programm geschrieben, dass den Datenstrom meines 
Gerätes simuliert und die Sätze vertauscht ausgeben kann.
Bisher kam $PFLAU zuerst und wurde als einziger Satz erkannt.

Wenn ich jetzt $GPRMC als ersten Satz übertrage, wird dieser als 
einziger erkannt.

Es hat also was mit der Reihenfolge der Sätze zu tun.
????

Vielleicht versuche ich doch mal eine klassische Statemashine zu bauen, 
wenn das alle so machen.

Hat sonst noch jemand eine Idee ?

Danke
Torsten

Poste doch noch mal den aktuelle Stand des Codes.

gerne

Die Variablen BlockOK und SatzNr müssten wohl noch volatile deklariert 
werden, da sie zur Kommunikation zwischen ISRs und dem Programm 
verwendet werden.

Hallo Gruppe
Hier nun eine im Grunde gut funktionierende Version.

ABER !!!

In Zeile 79 steht folgendes geschrieben:
"char uart_string_copy[UART_MAXSTRLEN + 1];"

Das ist eine Stringvariable, die ich zwischenzeitlich mal gebraucht 
habe, aber in dieser Version nur noch Speicher belegt, weil nicht mehr 
benötigt.

Wenn ich diese Zeile nun aber mit "//" stilllege, kommt zwar beim 
kompilieren keine Meldung (auch kein Warning), aber dafür erscheint auf 
meinem LCD Display nur noch Müll.

?!?!?!?

Wenn ich die "//" wieder lösche und ich den Compiler die Zeile wieder 
verarbeiten lasse, geht wieder alles super.

Kann mir das jemand erklären ?

Danke
Torsten

An welcher Stelle stellst Du sicher, dass du maximal MaxSatz Sätze 
empfängst?

1

for (unsigned char j = 0; j <= SatzNr; j++)

Bist Du sicher, dass Du da nicht vielleicht "<" meinst?

Viele Grüße,
        Simon