Pb when transmitting int fields with Arduino ProMini board

I have created a Lora network using 2 types of boards :

  1. LilyGo (ESP32 + Lora bundle by LilyGo)
  2. "Arduino ProMini" similar board (from AZDelivery) + seperated SX1278 Lora board.

I'm sending date from 1 board to the other.
Sometimes data are sent from LilyGo to LilyGo.
Sometimes data are sent from Arduino Promini to LilyGo.
Sometimes data are sent from LilyGo to Arduino Promini.

I'm using a structure I have created. As follows :

struct __attribute__((packed)) MessageLora {
  byte header1;  // pour reconnaitre trame
  byte header2;  // pour reconnaitre trame
  byte version;  // pour évolutions future
  byte emetteur; 
  byte destinataire;
  byte relais; // enregistre les relais potentiels
  int numero_du_message;
  int test;
  byte type_du_message;
  float donnee1; // Poid
  float donnee2; // pour évolution future
  boolean donnee3; // pour évolution future
  boolean donnee4; // pour évolution
  float checksum; // pour évolution future
  char text[30]; // pour évolution future
};

And I'm facing a "strange" pb on the transmission of the "int" fields.

From LilyGo to LiLygo :

  • When I send from LilyGo to LilyGo, everything works fine. Data are sent and received correctly.

From LilyGo to Arduno Pro Mini :

  • With the same code than LilyGo - excepted some specific commands to Arduino Promini - when I send from LilyGo to Arduino ProMini, the first fields that are "byte fields" are received correctly, but from the "int field", data are received with errors.
  • I have tested with the same fields, but changing the type "int" to "byte"... and it works fine. All date are received correctly. Even the float fields !
  • I changed the first Byte field from Byte to Int... and I have also the pb on this first int field...
  • Conclusion : the pb is ONLY when transmitting int values....

From Arduino ProMini to LilyGo : I have the same pb !

Did somebody already face such a pb when tranmiting "int" values on Arduino Promini ?

Pb = Lead, or Peanut butter?

The issue is probably is native int size is different..
Instead of int use int16_t or int32_t..
This would show itself when using sizeof on your structure..
If you see sizes are different, then I am correct..

on esp32 int is 32 bits, on 8 bit mcu it's 16 bits..

good luck.. ~q

1 Like

The values need to be on a "natural" boundary for the data type. On a 32 bit processor this is 4 bytes for 32 bit data and 2 bytes for 16 bit data. On an 8 bit processor it is 1 byte for anything.

If data in a structure is not aligned on a 32 bit processor the compiler will silently add fillers to get to the boundary. On an 8 bit processor no fillers are added, so the structures might not align between processors.

I define structures so that data is aligned for the most restrictive case. Either rearranging the fields to get proper alignment or specifically adding fillers.

Some people advocate the use of attribute((packed)) to force alignment with out fillers. This can end badly - depending on the processor one of the following may happen.

  1. Extra code is generated to handle the unaligned data
  2. An alignment exception is raised
  3. The alignment is ignored and the fetch is done using the "natural" boundary resulting in the wrong data

More information here Structure Member Alignment, Padding and Data Packing - GeeksforGeeks

1 Like

could you provide links to the actual boards you are using?

try running the following program on both boards - the results may give you some idea of the problem

struct __attribute__((packed)) MessageLora {
  byte header1;  // pour reconnaitre trame
  byte header2;  // pour reconnaitre trame
  byte version;  // pour évolutions future
  byte emetteur;
  byte destinataire;
  byte relais;  // enregistre les relais potentiels
  int numero_du_message;
  int test;
  byte type_du_message;
  float donnee1;    // Poid
  float donnee2;    // pour évolution future
  boolean donnee3;  // pour évolution future
  boolean donnee4;  // pour évolution
  float checksum;   // pour évolution future
  char text[30];    // pour évolution future
} message;

void setup() {
  Serial.begin(115200);
  delay(3000);
  Serial.println("pro mini sizeof()");
  Serial.print("int ");
  Serial.println(sizeof(int));
  Serial.print("long int ");
  Serial.println(sizeof(long int));
  Serial.print("float ");
  Serial.println(sizeof(float));
  Serial.print("double ");
  Serial.println(sizeof(double));
  Serial.print("structure ");
  Serial.println(sizeof(message));
}

void loop() {
  // put your main code here, to run repeatedly:
}

results of tests on an ESP32 and Pro Mini

ESP32 sizeof()
int 4
long int 4
float 4
double 8
structure 59

pro mini sizeof()
int 2
long int 4
float 4
double 4
structure 55

to overcome the problem use int16_t or int32_t (depending on required numeric range) as recommended by @qubits-us

Hi.
Thanks to all of you. I will try and give you the results.

Hi. 1000 x thanks ! Pb is solved "forcing" the size of the int. :blush:

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.