2020-05-08 09:21 AM
Hi,
My setup:
I'm using "STMems_Standard_C_drivers/ism330dhcx_STdC" driver in order to manage communication between uC SPC570S50E1 and ISM330DHCX module.
https://github.com/STMicroelectronics/STMems_Standard_C_drivers/tree/master/ism330dhcx_STdC
"STMems_Standard_C_drivers/ism330dhcx_STdC" driver are not-written in a machine-indipendent manner.
In particular, "struct" (Structure) access in "ism330dhcx_STdCdriver" is consider little-endian, but SPC570S50E1 is a big-endian machine.
Example (row 46-55): Structure access is considered in litte-endian byte order
typedef struct{
uint8_t bit0 : 1;
uint8_t bit1 : 1;
uint8_t bit2 : 1;
uint8_t bit3 : 1;
uint8_t bit4 : 1;
uint8_t bit5 : 1;
uint8_t bit6 : 1;
uint8_t bit7 : 1;
} bitwise_t;
In order to properly use the ism330dhcx STdC driver on SPC570S50E1 uC, i have to modify all structures inverting the fields order.
Example:
typedef struct{
uint8_t bit7 : 1;
uint8_t bit6 : 1;
uint8_t bit5 : 1;
uint8_t bit4 : 1;
uint8_t bit3 : 1;
uint8_t bit2 : 1;
uint8_t bit1 : 1;
uint8_t bit0 : 1;
} bitwise_t;
Please, do you have the "big-endian" version of this library?
Or could you provide me a an endian-independent version of library?
Thanks,
Regards
Leo
2020-05-11 07:21 AM
Hi @LeoC , Endianness consists of the differences between the order of the bytes within a word, not the bits within the byte. Please consider below solution for managing multi-byte data using the driver.
uint8_t data[6];
uint16_t data_x, data_y, data_z;
ism330dhcx_acceleration_raw_get(&dev_ctx, data);
data_x = 256 * data[1] + data[0];
data_y = 256 * data[3] + data[2];
data_z = 256 * data[5] + data[4];
acceleration_mg[0] =
ism330dhcx_from_fs2g_to_mg(data_x);
acceleration_mg[1] =
ism330dhcx_from_fs2g_to_mg(data_y);
acceleration_mg[2] =
ism330dhcx_from_fs2g_to_mg(data_z);
Regards
2020-05-11 09:31 AM
Dear Eleon,
Thanks for reply, but your solution is not sufficient.
SPC5 uC manages struct bitfield in big-endian access.
Library doesn’t work correctly because library assumes struct bitfield in little-endian access.
Regards,
Leonardo
2020-05-13 05:49 AM
Ciao Leonardo, understood... so our experts suggestion is to add the
#pragma reverse_bitfields
command in the header file of the driver. The issue should be related primarily to the compiler and not to the hw architecture of the specific uC: in particular, you should check if your compiler support this function.
The endianness management is not yet supported and the bitfield inversion in the driver is internally scheduled but not yet implemented. For this reason, if this command doesn't work, I'm afraid that the endiannes has to be managed "by hand" re-ordering the bit structure.
Regards
2020-05-13 07:10 AM
Ciao Eleon,
Thanks for suggestion.
I will inform you if everything OK.
Many thanks!
Leonardo