in der Funktion readData ist data noch korrekt. Heißt 128 Bytes lang und
richtige Werte.
zurück nach readData in file1.c sind die Daten aber nicht mehr da.
Zumindest kann ich diese im Debugger nicht sehen.
dataBuffer enthält zwar eine Adresse (ist also vorhanden), aber der
inhalt ist 0.
Wie bekomme ich die Daten richtig zurückgegeben?
Marcel schrieb:> zurück nach readData in file1.c sind die Daten aber nicht mehr da.> Zumindest kann ich diese im Debugger nicht sehen.> dataBuffer enthält zwar eine Adresse (ist also vorhanden), aber der> inhalt ist 0.>> Wie bekomme ich die Daten richtig zurückgegeben?
Du brauchst keine Poiner-Definition, sondern ein Array, das vorhanden
ist.
So müsste das laufen:
enthält a nachher immer noch 1, weil das 2 verschiedene Werte sind, und
der Wert von b einfach überschrieben wird. In deiner Code hast du die
gleiche Situation, nur halt mit Pointern statt mit Integern:
1
int*a=&(int){1};
2
int*b=a;// b zeigt auf das selbe compound literal, auf das auch a zeigt. Die Zeiger haben den selben Wert
3
*b=2;// der Wert, auf den a und b zeigen, der in dem compound literal oben, auf 2 gesetzt.
4
b=&(int){3};// Aber jetzt zeigt b auf dieses andere compound literal. a ist das egal, und zeigt weiterhin auf das Alte. a und b sind unabhängige Werte / Zeiger, und hier wird der Zeiger selbst überschrieben, nicht das, auf was er zeigt.
Ausserdem:
1) Man könnte direkt in dataBuffer schreiben, wieso legst du überhaupt
einen separaten womöglich zu kleinen Buffer auf dem Stack an, und was
soll der Offset dort bringen? Mit nem extra buffer müsste man das
ausserdem nochmal extra kopieren (z.B. mit memcpy). Ich würde den
einfach weg lassen.
2) Das startIndex argument kannst du dir eigentlich sparen. Übergib
einfach dataBuffer+startIndex, dann zeigt das gleich an den Anfang, von
wo an rein geschrieben werden soll.
Oder willst du einen neuen Buffer in der Funktion erstellen und zurück
geben? In dem Fall den nicht auf den stack packen, sondern auf dem heap
reservieren (malloc / calloc), sonst ist er nach der Funktion futsch. In
dem fall müsste man halt das Augument auf den Zeiger zeigen lassen, den
man überschreiben will, so das er auf den neuen Buffer zeigt.
STK500-Besitzer schrieb:> uint8 dataBuffer[128};> ...> readData( startIndex, &dataBuffer, size );
Das hätte ich auch so verstanden. Das Problem ist, dass ich
dataBuffer[128] nirgendwo finden kann.
nur die Initialisierung finde ich
1
uint8*dataBuffer;// Points to the data to write or to the array where data should be copied to.
? DPA ? schrieb:> 2) Das startIndex argument kannst du dir eigentlich sparen. Übergib> einfach dataBuffer+startIndex, dann zeigt das gleich an den Anfang, von> wo an rein geschrieben werden soll.
Das Problem ist, dass die Funktionen
readData( startIndex, dataBuffer, size ); (hier nur der Aufruf.)
und
getByte( byte );
schon vorhanden sind und ich nicht verändern darf.
Aber trotzdem kann ich den Array im Debugger (mit qtCreator) nicht
sehen.
Auch nach dataBuffer = dataArray sehe ich zwar den pointer, aber
inhaltlich sehe ich nichts. Auch da wo der pointer hinzeigt, stehen
nicht die Werte, die ich aus getByte bekomme.
Marcel schrieb:> uint8* dataBufferMarcel schrieb:> uint16 readData( uint32 startIndex, uint8* dataBuffer, uint32 size )
Ich würde mir deine Namensgebung vllt. nochmal überlegen.
Globale und Funktionsparameter gleich zu bennen, irgendwie verwirrend
auf den ersten Blick.
Hab es zwar grad mal getestet, aber ich wäre davon ausgegangen, dass es
auf
"Variable shadowing" hinausläuft.
Test:
COMPLETE_SIZE ist mit 384 definiert.
die FUnktion readData wird drei mal Aufgerufen
Aufruf 1
startIndex = 0
dataBuffer -> Speicheradresse von dataArray[0]
size = 128
dataArray[0] bis dataArray[127] sind mit den richtigen werten befüllt.
Aufruf 2
startIndex = 128
dataBuffer -> Speicheradresse von dataArray[128]
size = 128
im ersten durchlauf der For-Schleife ist byte = 128 und value kommt 129
heraus. Dies ist auch richtig.
Aber das Ergebnis wird nicht in dataBuffer[128] geschrieben, sondern in
dataBuffer[256] und ab dann immer weiter (also dataBuffer[257]...).
Wieso ist das so?
byte ist 128
und wieso wird dann dataBuffer[byte] woanders reingeschrieben? Es wird
ja auch die richtige Speiceradresse übergeben.
Marcel schrieb:> uint32 byte;> for(uint32 byte=startIndex; byte<(startIndex+size); byte++)
Was machst du da??? Warum definierst du "byte" zwei mal?
Marcel schrieb:> uint8 value;
Außerdem ist hier uint8 eher falsch, wenn du auch Werte über 255 haben
möchtest.
Marcel schrieb:> value = getByte( byte );
Wie sieht denn die Funktion getByte() aus?
Na wenn dataBuffer = dataArray+128, dann ist dataBuffer+128 =
dataArray+128+128 = dataArray+256. Also entweder ist dataBuffer falsch,
oder startIndex, oder startIndex ist in readData nicht zu dataBuffer
hinzuzuaddieren. Da müsste man halt wissen, wie die readData Funktion
tatsächlich gedacht war. Das ist die Art von Sachen, die im Code im
Idealfall irgendwo mit einem Kommentar Dokumentiert sein sollte.
? DPA ? (der übliche) schrieb:> Na wenn dataBuffer = dataArray+128, dann ist dataBuffer+128 => dataArray+128+128 = dataArray+256.
Ja dann ist der Aufruf aber evtl. falsch:
1
// Richtig
2
readData(0,dataArray,128);
3
readData(128,dataArray,128);
4
5
// Falsch
6
readData(0,&dataArray[0],128);
7
readData(128,&dataArray[128],128);
Also ich hab es nun mal so runtergeschrieben, und es tut was es soll:
(Hab mir den zweiten Pointer gesparrt, konnte bis jetzt den Sinn nicht
erkennen).