Forum: Mikrocontroller und Digitale Elektronik avr/gcc 'expected expression before 'ZoomSettings_t'


von Jup (Gast)


Lesenswert?

Hallo,

hierbei
1
uint8_t *bufferPtr = (uint8_t *)&ZoomSettings;
 bekommen ich vom compiler avr/gcc (Atmel Studio 7) diese Fehlermeldung:

'expected expression before 'ZoomSettings_t'.


Sehe nicht warum?

Kann vllt bitte einer weiterhelfen?

von Jim M. (turboj)


Lesenswert?

Fehler in Zeile 42.

Bitte den vollständigen Code als Anhang posten. Die Fehlermeldung 
bezieht sich offensichtlich nicht (nur) auf die gepostete Zeile.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Lass mich mal Detektiv spielen:

Du hast die Zeile falsch abgeschrieben, und sie lautet in Wirklichkeit

1
uint8_t *bufferPtr = (uint8_t *)&ZoomSettings_t;

Dabei ist ZoomSettings_t ein mit typedef definierter Typ. Da es dem
Compiler schwer fällt, von einem Typ die Adresse zu bestimmen, bringt er
die genannte Fehlermeldung.

von Jup (Gast)


Lesenswert?

Yalu X. schrieb:
> uint8_t *bufferPtr = (uint8_t *)&ZoomSettings_t;

sorry is wohl beim copy&paste passiert die Funktion lautet eigentlich 
so, bekomme aber immer noch diesen Fehler in der Zeile
1
 uint8_t *bufferPtr = (uint8_t *)&ZoomSettings_t;
1
 
2
void copyPayload(uint8_t *in, uint8_t payloadNum)
3
{
4
  uint8_t *bufferPtr = (uint8_t *)&ZoomSettings_t; 
5
  uint8_t a,base;
6
  
7
  base = payloadNum * PAYLOADSIZE;
8
  for(a = 0; a < PAYLOADSIZE; a++)
9
  {
10
    bufferPtr[base + a] = in[a];
11
        }
12
}

von Marco H. (damarco)


Lesenswert?

Das was du da veranstaltest ist dummer Quark !

ZoomSettings_t kommt mir aus einer anderen Thread bekannt vor?


uint8_t *bufferPtr = (uint8_t *)&ZoomSettings_t;  ? woher soll aus dem 
Type ein Zeiger kommen ?

ZoomSettings_t test;

 uint16_t *bufferPtr = (uint16_t *)&test;


Die Adresse passt auch gar nicht in eine uin8_t, das wäre das nächste 
...

Ist aber total blöd da du nicht weist wie test im Speicher angelegt 
wurde. Greifst du undefiniert irrend wo in den Speicher hinein.

Deine Funktion ist alles andere als save.

: Bearbeitet durch User
von Kaj (Gast)


Lesenswert?

Marco H. schrieb:
> Die Adresse passt auch gar nicht in eine uin8_t, das wäre das nächste
Der Datentyp hat nichts mit der groesse des Pointers zu tun.
Der Datentyp sagt nur, als was die Daten, auf die der Pointer zeigt, 
interpretiert werden.

von Marco H. (damarco)


Lesenswert?

Nunja es kommt drauf an der AVR(8bit) teilt die Adressen auf je ein byte 
auf MSB-LSB.  Wenn du diese Adresse in 1byte quetscht sollte beim AVR 
nur das LSB übrigbleiben.  So lange die Adresse nicht über den 
Wertebereich liegt mag das sogar funktionieren.


Ebene und die schleife springt immer eine Adresse nach oben.  Ist der 
Datentype größer wie 1Byte  gibt es Probleme, bei einen 16bit Datentype 
müsste er 2 byte springen. Auch wenn die Daten nicht mit aufsteigenden 
Adressen im Speicher liegen. Mit einen ARM landet er mit dem Code im 
dummy Handler.

Solch einen Käse sollte man sich gar nicht erst aneignen! Sondern sich 
ausgiebig mit Pointern und der Architektur beschäftigen.

: Bearbeitet durch User
von Ups (Gast)


Lesenswert?

Marco H. schrieb:
> Die Adresse passt auch gar nicht in eine uin8_t, das wäre das nächste

Da steht aber, dass er gerne einen Zeiger auf einen uint8_t haben möchte 
und nicht, dass in uint8_t ein Zeiger gespeichert wird.

von Kaj (Gast)


Lesenswert?

Marco H. schrieb:
> Wenn du diese Adresse in 1byte quetscht
Das passiert ja nicht...

Marco H. schrieb:
> Solch einen Käse sollte man sich gar nicht erst aneignen! Sondern sich
> ausgiebig mit Pointern und der Architektur beschäftigen.
Solltest du auch mal...

Auf meinem PC (64 Bit) kann ich auch sowas machen:
1
uint64_t x = 349587987;
2
uint8_t *p = (uint8_t *)&x;
Oh, wunder, das funktioniert ganz wunderbar.

Nochmal:
Der Datentyp des Pointers hat nichts mit der breite des Pointers zu 
tun.
In meinem Beispiel hat p eine groesse von 64 Bit und nicht 8 Bit, so wie 
du es bescheinigst.
Der Datentyp des Pointer sagt nur wie die Daten interpretiert werden, 
und nichts anderes.
1
uint8_t* a;
2
uint16_t* b;
3
uint32_t* c;
4
uint64_t* d;
5
float* e;
6
double* f;
7
char* g;
Die Pointer sind alle 64 Bit gross auf meinem PC, weil der Datentyp 
nichts mit der breite des Pointers zu tun hat!

von Marco H. (damarco)


Lesenswert?

Das Stimmt du hast recht die Adresse ist trotzdem 64bit groß. Es besagt 
nur das der Pointer auf ein 8bit breiten Datentype zeigt.

Das Problem besteht aber weiterhin wenn in dem Type 16bit Datentypen 
enthalten sind wird mit 8bit darauf zugegriffen.

von Jup (Gast)


Lesenswert?

Marco H. schrieb:
> ZoomSettings_t test;
>
>  uint16_t *bufferPtr = (uint16_t *)&test;

Danke! Hast recht hab es jetzt so abgeändert
1
ZoomSettings_t RAMZoomSettings;
2
3
uint8_t *bufferPtr = (uint8_t *)&RAMZoomSettings;

Der Hintergrund ist: Ich bekomme Daten Byte für Byte bis 5 Bytes 
empfangen wurden. Ich schreibe diese in der reihenfolge wie ich sie 
empfangen habe in ein struct hintereinander weg und schreibe dann wenn 
das struct (112 Byte groß) voll ist ins EEPROM weg...

Danach lese ich die Variable aus dem EEPROM aus und verarbeite sie 
weiter....

von Brummbär (Gast)


Lesenswert?

Jup schrieb:
> Ich schreibe diese in der reihenfolge wie ich sie
> empfangen habe in ein struct hintereinander weg

Meinst Du wirklich ein Struct oder eher ein Array?

von Marco H. (damarco)


Lesenswert?

Aha also doch das selbe  Thema !


Er meinte ein Struct in dem sich ein Array befindet.

Das was du machst ist sehr ineffektiv was die Anordnung im EEROM 
betrifft. So wirst du nie den Speicher gut ausnutzen und nutzt nur einen 
Teil dessen als wenn man die Daten Sinnvoll anordnet das sie auf einer 
Page passen.

Das mit dem dauernden Schreiben in den EEROM würde ich mir gut 
überlegen! Das sollte man lieber über ein externen RAM etc. machen.

Aber auch dieser ist Blockweise organisiert.

Sein Problem wird sein das er nicht weiß wie man darauf zugreift.
Man kann sich ja auch die Adresse des Array aus dem struct ziehen.

uint8_t *buffer=&RAMZoomSettings.array[0];

oder uint8_t *buffer=&RAMZoomSettings.array[index_schon_geschieben];

Arrays hängen immer zusammenhängt im Speicher damit wäre sichergestellt 
das er auch wirklich darauf zugreift.

: Bearbeitet durch User
von Jup (Gast)


Lesenswert?

Hallo habe es jetzt so implementiert und es funktioniert soweit für ein 
Datenpaket empfange ich das zweite wird es überschrieben... wie gehe ich 
weiter vor wenn jetzt mehrere Datenpakete ankommen die ich nacheinander 
im EEPROM ablegen möchte... stehe gerade auf dem Schlauch

An sowas hab ich gedacht i soll nach jedem empfangen Datenpaket 
inkrementiert werden, sodass die Daten immer weiter rücken

dafür muss ich wissen wann ucRxBuffer vollständig empfangen wurde dann 
i++
usw.

Jemand ne Idee?
1
//hab an sowas gedacht
2
copyPayload(&ucRxBuffer[3], i);
1
//dieses funktioniert
2
3
ZoomSettings_t EEMEM EEPROMZoomSettings;
4
ZoomSettings_t RAMZoomSettings;
5
6
void copyPayload(uint8_t *in, uint8_t payloadNum)
7
{
8
  uint8_t *bufferPtr = (uint8_t *)&RAMZoomSettings; 
9
  uint8_t a,base;
10
  
11
  base = payloadNum * PAYLOADSIZE;
12
  for(a = 0; a < PAYLOADSIZE; a++)
13
  {
14
    bufferPtr[base + a] = in[a];
15
  }
16
}
17
18
copyPayload(&ucRxBuffer[3], 0);
19
eeprom_update_block( &RAMZoomSettings, &EEPROMZoomSettings, sizeof(ZoomSettings_t) );

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.