"struct" wird auf einem ESP8266 anders behandelt wie auf einem Arduino

[ardu_arne]

Hallo,
ich habe auf einem ESP8266 und einem Arduino MEGA2560 folgendes angelegt:

Code:

struct
{
  byte     val1 = 0x01;
  uint32_t val2 = 0x22334455;
  uint16_t  crc = 0x7788;
} testStruct;

mit:

Code:

template <typename T> unsigned int serialPrintAnything (const T& value)
{
  const byte * p = (const byte*) &value;
  unsigned int i;
  Serial.print("Size: "); Serial.print(sizeof value); Serial.print(" Byte - Data = ");
  for (i = 0; i < sizeof value; i++) {
    Serial.print("0x");
    if (*p <= 15) Serial.print("0");
    Serial.print(*p++, HEX);
    Serial.print(" ");
  }
  Serial.println();
  return i;
}

gebe ich den Inhalt von "testStruct" seriell aus.

der ESP8266 liefert:

Code:

Size: 12 Byte - Data = 0x01 0x00 0x00 0x00 0x55 0x44 0x33 0x22 0x88 0x77 0x00 0x00

der MEGA2560 liefert:

Code:

Size: 7 Byte - Data = 0x01 0x55 0x44 0x33 0x22 0x88 0x77

Beim ESP wird also scheinbar immer auf die Länge des größten Elementes mit "0" aufgefüllt.

Solange man mit den Daten auf einem System bleibt ist das kein Problem.
Aber wenn man die Daten seriell (I2C, SPI, UDP, ect.) am Stück zum jeweils anderen System überträgt passen die nicht mehr in die dort angelegte struct(ur).

Hat jemand eine Idee wie man das Problem (einfach) lösen könnte?

Gruß
Arne

[MicroBahner]

Hallo Arne,

(22.10.2017 21:48)ardu_arne schrieb:  Beim ESP wird also scheinbar immer auf die Länge des größten Elementes mit "0" aufgefüllt.

nicht generell, und eigentlich wird auch nicht aufgefüllt, sondern es entstehen Lücken durch das Alignment des Compilers auf Speichergrenzen. Das ist ein 'Problem' aller 32-Bit Rechner. Wenn Du eine 32-Bit-Variable definierst, muss die auch auf einer 32-Bit-Grenze liegen. Hast Du vorher kürzere Variablen definiert, entstehen gegebenfalls Lücken, damit die 32-Bit Variable wieder richtig an der Speichergrenze ausgerichtet ist.
Du hättest am Anfang des Structs bis zu 4 byte-Variable definieren können, ohne dass da was zusätzlich 'aufgefüllt' worden wäre.

z.B. bei dieser Struktur:

Code:

struct
{
  byte     val1 = 0x01;
  byte     val12 = 0x02;
  byte     val13 = 0x03;
  byte     val14 = 0x04;
  uint32_t val2 = 0x22334455;
  uint16_t  crc = 0x7788;
  uint16_t  crc1 = 0x99aa;
} testStruct;

gibt es gar keine Auffüllungen mit '0', da alles genau in die 32-Bit Speicherorganisation hineinpasst.
Auch so:

Code:

struct
{
  byte     val1 = 0x01;
  byte     val12 = 0x02;
  uint16_t  crc = 0x7788;
  uint32_t val2 = 0x22334455;
} testStruct;

geht es ohne Lücken und ist dann bei ESP und Mega identisch.
Datenaustausch zwischen 32-Bit und 8-Bit Rechnern hat also durchaus seine Tücken, wobei man gegebenenfalls auch noch zwischen 'little endian' and 'big endian' unterscheiden muss

Edit: Auch bei 16-Bit Variablen ist zu beachten, dass die auf einer geraden Adresse liegen müssen, sonst entstehen ebenfalls Lücken durch das Alignment des Compilers. Also so:

Code:

struct
{
  byte     val1 = 0x01;
  uint16_t  crc = 0x7788;
  byte     val12 = 0x02;
  uint32_t val2 = 0x22334455;
} testStruct;

funktioniert es nicht!

[ardu_arne]

Hallo Franz-Peter,
herzlichen Dank für die Erläuterungen.

Ich habe es jetzt so verstanden dass man das eigentliche Problem nicht beheben kann weil es ein zum jeweiligen Prozessortyp gehörendes "Naturgesetz" ist.

Einzig die negativen Auswirkungen kann man beseitigen wenn man die Struktur so anlegt dass die (kleinen) Variablen immer auf einer zum Prozessortyp passenden 8, 16, 32 oder 64-Bit-Grenze liegen. Um das zu erreichen füllt man die Struktur an den betroffenen Stellen mit entsprechenden Nutz- oder Dummybytes auf.
Durch passende Umsortierung der Nutzbytes kann man also Platz sparen weil man weniger Dummybytes braucht.

Jetzt kann man nur noch froh sein dass in diesen Fall beide Prozessoren mit Big-Endian arbeiten. Sonst wäre das Chaos komplett.

Gruß
Arne

[MicroBahner]

Genau so ist es

[Tommy56]

Man kann das Problem aber auch ohne Füllbytes lösen, indem man dem Compiler sagt, dass er das alles packen soll.
align.ino:

Code:

#include "align.h"

struct testStruct{
  byte     val1 = 0x01;
  uint32_t val2 = 0x22334455;
  uint16_t  crc = 0x7788;
}__attribute__ ((packed)) myTest;

void setup() {
  Serial.begin(115200);
  Serial.println("\nStart");
  serialPrintAnything(myTest);
}

void loop() {
}

Align.h (enthält die unveränderte Ausgabefunktion)

Code:

template <typename T> unsigned int serialPrintAnything (const T& value)
{
  const byte * p = (const byte*) &value;
  unsigned int i;
  Serial.print("Size: "); Serial.print(sizeof value); Serial.print(" Byte - Data = ");
  for (i = 0; i < sizeof value; i++) {
    Serial.print("0x");
    if (*p <= 15) Serial.print("0");
    Serial.print(*p++, HEX);
    Serial.print(" ");
  }
  Serial.println();
  return i;
}

Beide Prozessoren ergeben die gleiche Ausgabe:

Code:

Start
Size: 7 Byte - Data = 0x01 0x55 0x44 0x33 0x22 0x88 0x77

Auf diese Weise kann man Strukturen für den Datenaustausch zwischen den beiden Welten definieren.
Das sollte aber nur für derartige Übergabestrukturen angewandt werden, da der Zugriff für 32-Bit-Prozessoren auf die Variablen, die nicht auf 32-Bit-Grenzen liegen, langsamer ist.

Gruß Tommy

Edit: Das __attribute__ ist nicht ANSI-konform.

Edit2: Es gibt noch eine andere Schreibweise, die ebenfals auf beiden Architekturen die gleiche Ausgabe erzielt.
Der Wert in Klammkern gibt die Anzahl Bytes an, auf die gepackt wird. Hier also 1 Byte:

Code:

#pragma pack(1)
struct testStruct{
  byte     val1 = 0x01;
  uint32_t val2 = 0x22334455;
  uint16_t  crc = 0x7788;
} myTest;

[MicroBahner]

Hallo Tommy,
ja, da war doch noch was... das pack() ist mir nicht eingefallen

aber, wie Du schon sagst, ist das für einen 32-bitter recht ungünstig. Wenn möglich würde ich die Variante mit der optimalen Variablenanordnung vorziehen.

[ardu_arne]

Mit den Vorschlägen von Tommy eröffnen sich ja ganz neue Möglichkeiten. Danke dafür!
Aber mir wird es damit dann doch zu komplex und undurchsichtig.

Ich bleibe dann doch lieber dabei die Struktur händisch so zu sortieren dass möglichst wenige "Füllbytes" nötig sind.
Damit kann ich dann auch mögliche Inkompatibilitäten mit künftigen Compiler Versionen ausschließen die dann evtl. das Packen anders behandeln als derzeit aktuelle Compiler Versionen.

Gruß
Arne