Zu viele Pointer - brauche Hilfe.

Auch

1

typedef struct navstruct_xy

2

{

3

  int newdata;

4

  double time;

5

} navstruct;

oder

1

typedef struct

2

{

3

  int newdata;

4

  double time;

5

} navstruct;

ändert leider nichts an der Sache.
Mit nem volatile struct hatte ich auch keinen Erfolg. Ich hab ein 
bisschen den Verdacht dass ich mich da mit dem referenzieren und 
dereferenzieren irgendwo vertan hab, aber ich find keinen Fehler...

Nein, das passt schon so, die Funktion ParseField muss den Pointer 
pMessage ändern können, deswegen char **. Problem ist dass die Daten, 
die ich in ParseMessage in den struct reinschreibe in der main Funktion 
nicht ankommen.

1

typedef struct navstruct_xy

2

{

3

  int newdata;

4

  double time;

5

} navstruct;

6

...

7

int main(void)

8

{

9

  navstruct_xy NavState;

10

...

??

>Nein, das passt schon so, die Funktion ParseField muss den Pointer
>pMessage ändern können, deswegen char **. Problem ist dass die Daten,
>die ich in ParseMessage in den struct reinschreibe in der main Funktion
>nicht ankommen.
ist zwar nicht der Fehler, naber warum muss sie pMessage ändern können 
wenn die Änderung nirgends beachtet wird?

ups, dort natürlich dann auch:

1

void ParseMessage(char * Message, int NMEA, navstruct_xy * pNavState) {

oder besser gleich

1

typedef struct navstruct

2

{

3

  int newdata;

4

  double time;

5

} ;

6

...

7

int main(void)

8

{

9

  navstruct NavState;

10

...

11

}

12

...

13

void ParseMessage(char * Message, int NMEA, navstruct * pNavState) {

14

...

oder so

mfg

Müll geschrieben, steht ja schon "typedef" davor, sorry

Ich mach heut abend mal ein kompilierbares Beispiel. Ich hab mir den 
Assembler-Code angeschaut, bin aber daraus auch nicht recht schlau 
geworden. Es scheint als ob er das gleiche Register (Z) sowohl für 
TempBuff als auch den Struct verwendet. Das wundert mich zwar etwas, 
aber grundsätzlich sollte da ja auch nichts dagegensprechen das mit 
unterschiedlichen Offsets zu machen.


Walter:
> ... ist zwar nicht der Fehler, naber warum muss sie pMessage ändern
> können wenn die Änderung nirgends beachtet wird?
Weil mein Code-Ausschnitt nur fürs Problem relevante Teile enthält, im 
vollständigen Programm hat das schon so seine Richtigkeit :-)

Johann:
> Bist du sicher daß der RAM nicht ausgeht? Und bei einem der
> Funktionsaufrufe mit dem Riesenstring oder bei atof/sprintf ein Teil des
> RAMs/Stacks überschrieben wird?
Eigentlich schon, der Code läuft auf nem Mega328. Aber ich probiers 
später mal mit nem kürzeren String.

Stefan:
> Und aus was besteht "..."? Wird da vielleicht auch nach dispbuff
> geschrieben?
Nein.

So, hab ein Progrämmchen zum kompilieren aufm PC draus gemacht. Ganz 
toll ist natürlich, dass die Sache auf dem PC einwandfrei funktioniert.

Daraufhin hab ich ein bisschen weiterprobiert:
Wenn ich ParseMessage verändere:

1

void ParseMessage(char * Message, int NMEA, navstruct * pNavState) {

2

  char * pMessage;

3

  char TempBuff[10]; 

4

5

  pMessage = Message;

6

  ParseField(&pMessage, TempBuff);

7

  pNavState->time = atof(TempBuff);

8

  pNavState->newdata = 1;

9

10

 dtostrf(pNavState->time, 6, 3,outbuff); 

11

 uart_puts_P("ParseMessage() ");

12

 uart_puts(outbuff);

13

}

dann kommt auch tatsächlich in der Main der gewünschte Wert an. Wenn ich 
die Zeile weglasse scheint es dass der Struct wegoptimiert wird. Ein 
deklarieren von NavStruct als volatile ändert leider auch nichts an der 
Sache. Hat noch jemand Ideen?

Hier ist mal ein lauffähiger Code für den Mega 328. So wie gepostet 
funktionierts, Zeile 83 bis 85 auskommentiert gehts nicht mehr. Der Uart 
Treiber is von Peter Fleury. Leider kann ich es nicht auf dem PC 
demonstrieren, da sich da der Fehler einfach weigert aufzutreten.

Tatsache, das Feld ist zu kurz... Jetzt gehts. Danke!
Der Tipp mit strtok ist gut, die kannte ich noch nicht. Aber jetzt gehts 
ja, d.h. die Funktion wird mal gespeichert und beim nächsten 
gleichartigen Problem wieder rausgekramt :-)