You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using a freescale ARM micro controller with:
char, signed char, and unsigned char are 8 bits;
The plain char type is unsigned by default;
short and unsigned short are 16 bits;
int and unsigned int are 32 bits;
long and unsigned long are 32 bits;
pointers are 32 bits;
long long and unsigned long long are 64 bits;
float is 32 bits;
double is 64 bits;
long double is 64 bits.
Anyway, the kBInt16 test fails because the receive method is still expecting 4 bytes. The 'i' format spec in the python struct documentation is to unpack 4 bytes. I'm confused how this test worked for anyone. With a '16' in the type name you'd think it would only be 2 bytes. The rest of the tests (except the multivalue) pass when I comment out the kBInt16 test.
The text was updated successfully, but these errors were encountered:
I'm using a freescale ARM micro controller with:
char, signed char, and unsigned char are 8 bits;
The plain char type is unsigned by default;
short and unsigned short are 16 bits;
int and unsigned int are 32 bits;
long and unsigned long are 32 bits;
pointers are 32 bits;
long long and unsigned long long are 64 bits;
float is 32 bits;
double is 64 bits;
long double is 64 bits.
Anyway, the kBInt16 test fails because the receive method is still expecting 4 bytes. The 'i' format spec in the python struct documentation is to unpack 4 bytes. I'm confused how this test worked for anyone. With a '16' in the type name you'd think it would only be 2 bytes. The rest of the tests (except the multivalue) pass when I comment out the kBInt16 test.
The text was updated successfully, but these errors were encountered: