Gast
#4898802
Hallo, hierbei
1 | |
bekommen ich vom compiler avr/gcc (Atmel Studio 7) diese Fehlermeldung: 'expected expression before 'ZoomSettings_t'. Sehe nicht warum? Kann vllt bitte einer weiterhelfen?
Fehler in Zeile 42. Bitte den vollständigen Code als Anhang posten. Die Fehlermeldung bezieht sich offensichtlich nicht (nur) auf die gepostete Zeile.
Lass mich mal Detektiv spielen: Du hast die Zeile falsch abgeschrieben, und sie lautet in Wirklichkeit
1 | |
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.
Gast
#4898836
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 | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
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.
Gast
#4898869
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.
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.
Gast
#4898903
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.
Gast
#4898911
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 | |
2 | |
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Die Pointer sind alle 64 Bit gross auf meinem PC, weil der Datentyp nichts mit der breite des Pointers zu tun hat!
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.
Gast
#4898960
Marco H. schrieb: > ZoomSettings_t test; > > uint16_t *bufferPtr = (uint16_t *)&test; Danke! Hast recht hab es jetzt so abgeändert
1 | |
2 | |
3 | |
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....
Gast
#4898975
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?
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.
Gast
#4899091
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 | |
2 | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.