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 ?
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..
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.
Extra code is generated to handle the unaligned data
An alignment exception is raised
The alignment is ignored and the fetch is done using the "natural" boundary resulting in the wrong data