"A big Little Endian Problem" oder sowas in der Art

[Nils_Langner]

Das mit dem kleiner und größer ist nur mal aus reiner verzweiflung entstanden. Wenn du genau hinschaust, dann sind auch die Werte verdreht, also isses im Endeffekt wieder die gleiche Aussage.

[ten]

was ist dieses 'puiLength'?
falls das ungefähr sowas ist:

irgendeintyp irgendwelche_daten[irgendeine_anzahl];
uiLength *puiLength = (uiLength*)irgendwelche_daten;  // <<- sowas geht oft schief

dann könnt's schon sein, dass er zickt...

[Nils_Langner]

Also sieht schon verdammt danach aus:

BasicStruct_UInt* puiLength = (BasicStruct_UInt*) pstPar->pDest;

naja ich hab kein Array. Woran denkst du denn, dass es liegen könnte?

[CStoll]

Und was für einen Typ hat 'pstrPar->pDest'? (wenn das schon ein Zeiger auf ein 'BasicStruct_UInt' ist, erübrigt sich der Cast, andernfalls könnten dort die selben Probleme auftreten wie bei einem Array - irgendwelche (in anderem Zusammenhang gebrauchte) Daten werden als BasicStruct neu interpretiert)

[Nils_Langner]

also pstrPar ist so ein struct

typedef struct {
  CommBufferPointer pstSource;
  USInt* pDest;
  UInt uiBufferlength;
} Deser_ParStruct;

leider wurde der Code von einem Code Generator erstellt, deswegen sind manchmal vielleicht unschöne Sachen drin.

Und hier noch der vollständigkeit halber.

typedef struct {
  UInt value;
}  BasicStruct_UInt;

dass das ganze als struct sein muss, liegt irgendwie am alignment des contollers und der damit resultierenden GAPS bei der deserialisierung.

das beide vom typ UInt sind, war dann wohl glatt gelogen von mir vorhin, aber war mir irgendwie sicher. Naja "meinen" Fehler finde ich trotzdem nicht.

[CStoll]

Sehe ich das richtig, daß pDest ein USInt ist? (und wofür steht das 'S'? short?)

[Nils_Langner]

jop short sollte werte von 0...255 drin haben.

[CStoll]

Und da hast du auch schon das Problem - effektiv hast du ein short-Array als int-Array interpretiert, dadurch werden (short=16 Bit, int=32 Bit) jeweils zwei Array-Elemente zu einem int-Wert zusammengepackt. Die einzige Lösung, die ich dir empfehlen kann, ist: vermeide Typ-Umwandlungen, wo immer es geht (gerade bei Pointern läuft das schnell aus dem Ruder) - du kannst besser direkt auf deine Daten zugreifen, da weiß der Compiler höchstwahrscheinlich besser als du, wie er mit verschiedenen Typen umgehen muß.

(das sind zwar ein paar Indirektionen mehr, aber dafür ist es weniger fehleranfällig)

[ten]

erzähl mehr von dem, was du da bastelst.
- was ist das für ein controller/prozessor?
- woher komen die daten, auf die du da zugreifsen willst?
wahrschinlich sind doch noch irgendwo endian-dreher drin...

[Nils_Langner]

also es ist ein keil mcb2140 board mit usb anschluss und daher kommen auch die daten. controler. ist ein arm. kompiliert wird mit den optionen

-c -gdwarf-2 -MD -O0 -mapcs-frame -mcpu=arm7tdmi -w -mthumb-interwork -mlittle-endian

die usb seite war herstellerseitig (hitex) schon vorimplementiert. dann kamen unsere geräteseitigen funktionen dazu und alles ging auch wunderbar, bis auf diese eine stelle.

[ten]

du machst ja little endian auf dem arm, das sollre sich mit dem pc vertragen.
macht usb vielleicht irgendwelche dataframes die möglicherweise big-endian werte enthalten?
alignment könnte's auch sein. ein arm kann z.b. nicht 2-bytig auf ungerade adressen zugreifen (er springt dann in'n exception-handler, was bei dir offensichtlich nicht passiert) aber die structs müssen trotzdem aligned angelegt werden. wenn du jetzt 'nen type-cast von einer strukt in eine andere machst, dann geht das mit ziemlicher sicherheit voll daneben...
musste irgendwie debuggen.
z.b. hexdumps ausgeben usw.
haste 'nen jlink-adapter oder sowas?
dann nimm z.b. die testversion vom IAR (EWARM).
der debugger, der dabei ist, ist spitze...

[Nils_Langner]

ich hab eigentlich alles was dazugehört. jtag debugger von hitex (Tantino). die werte im speicher sehen auch alle richtig aus also eigentlich sollte alles stimmen. tuts aber leider nicht

[ten]

Nils_Langner schrieb:

ich hab eigentlich alles was dazugehört. jtag debugger von hitex (Tantino). die werte im speicher sehen auch alle richtig aus also eigentlich sollte alles stimmen. tuts aber leider nicht

na, damit solltestes aber finden.
laufen dabei noch irgendwelche interrupts? vielleicht zerbrutzelt dir irgendwas die daten?

[Nils_Langner]

hab da noch einige interrupts, aber der wert ist vor und nach der IF abfrage gleich, deswegen denke ich, dass es daran nicht liegen kann (aus der sicht eines anfängers:)
wenn ich dieses komische basicStruct weglasse, dann scheints zu gehen, also wenn ichs gleich in einen UInt packe.