This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Host driver portability issue due to char usage (macro STREAM_TO_UINT32_f )



Hi , 

This is just a sharing for community and a warning regarding char usage :

CC3000 host driver uses many char and perform lot of shift operation on these chars.

Developpers must take care of compilation options :

for example if you use Keil, by default  "Plain Char is signed", so this mean the driver will not work properly mainly due to *** on signed char that leads to uncorrect lengh of data for example

instead of lengh 0x39 you will get 0xFFFFF39 ... 

Example of macro leading to issue : 

unsigned long STREAM_TO_UINT32_f(char* p, unsigned short offset)
{
return (unsigned long)
((unsigned long) ((unsigned long)(*(p + offset + 3)) << 24) +
(unsigned long)((unsigned long)(*(p + offset + 2)) << 16) +
(unsigned long)((unsigned long)(*(p + offset + 1)) << 8) +
(unsigned long)(*(p + offset)));
}

i've upgraded all the driver with only "unsigned char", and accordingly upgraded corresponding macros in cc3000_common.c

unsigned long STREAM_TO_UINT32_f(unsigned char* p, unsigned short offset)
{
unsigned char * pbyte = p + offset;
return ((unsigned long)(pbyte[0])) +
(((unsigned long)(pbyte[1])) << 8) +
(((unsigned long)(pbyte[2])) << 16) +
(((unsigned long)(pbyte[3])) << 24);
}

Cheers

Lionel

  • Hello Lionel,

    I had to port all types to C99 exactly because of types used. Plain char is implementation defined, thus not portable.

    This lead me to believe the code was written at least by 2 engineers, one knows about the portability issue, the other one does not. Because for example one code file uses a plain char , another one a signed/unsigned char. Same "mess" applies to other types which are fortunately not implementation defined but directly defined by a standard :-)

    Regards,

    0xc0170

  • Hi Lionel.

    Interresting to see that I wasn't alone to have this problem. The compiler I use is Tasking for Arm and it also uses signed "plain" char. I'm sorry I didn't report this to the forum but I accually reported the problem to TI when we we're still on the 10.2 version.
    I also ended up writing my own STREAM_TO_UINT16_f and STREAM_TO_UINT32_f functions.

    TI: You really should fix this issue and also fix all the castings needed to avoid the tone of warnings some compilers give when compiling your code. Some of the castings probably could be avoided by streamlining the datatypes used.

    This really should be fixed, all these warnings makes the code seem unproffesional.

    Kind regards

    Jimmy