Why uint16_t assignment does not work

[xuedongyang]

Hi, experts,

I am trying to assign a 16-bit hex value to a uint16_t variable (actually an element of uint16_t array), but it does not work. I see the value is alway 0x7FFF for real and 0 for imaginary parts in CodeWarrior..

Any idea why? Did I miss anything? If I do the assignment for a floating point data, it works well. The value I see from CodeWarrior is just as I expected. But this uint16_t does not work the same way.....

[diego_charles]

Hi @xuedongyang 

I hope that you are doing well!

From the below snapshot . In the green highlighted area ,   I think that everything is going ok. 

But ,  as I understand , the assignation uint16_t   real and  uint16_t imag  (members of your scratch_b0 structure )  is not as expected. Let me know if otherwise. 

Could you  let us see how the structures  are defined (red area )? This to   check and try to replicate the situation more effectively. 

Does the compiler give you any warning on this?

I would recommend , to check if you need any cast ,  during the real and imag assignments. 

Best regards, 

Diego.

[xuedongyang]

Thanks, Diego, for your help.

Please find the attached screen shot (capture1.png) for the structure definition. I think that the important thing is the definition of cfixed16_t. I am not sure which one (capture2.png and capture3.png) is the real definitions for cfixed16_t.

Maybe you can guide me if the definition is right and if the definition would cause the problem we observed.

BTW, I don't see any compiling warnings for this.

[diego_charles]

Hi @xuedongyang 

Thank you for your reply!

Interesting! What if you go back to here ,  define temp value arrays as fixed16_t  and test again?  

Maybe the problem is an actual  difference in the data type, as you mention with the fixed16_t .  and the compiler can not see this. But during in assembly, the data is written to img and real  in special way. 

  Diego. 

[xuedongyang]

Thanks for the advice.

I did an experiment for 4 types of data: float, uint16_t, uint32_t, and fixed16_t. All work as expected, except fixed16_t for assignment. See the attached screen shots.

Any idea why fixed16_t does not work?

[diego_charles]

Hi @xuedongyang 

Thank you for your reply  and interesting tests! 

Probably , we still need to cast that assignation of the hex value to the fixed16_t , which is intended for fixed point arithmetic.  I have a snippet code to test, where we check by code, and not by the IDE the assignation if the fixed16_t variable was successful.

/** cast asignation of data to the data type *//
fixed16_t a  =  (fixed16_t ) 0xFE ;

 /** check assignation   */ 
if ( a   =  ( (fixed16_t) (0xFE) )   )
{
  /** assignation was the expected  */ 
}

 By the way, which NXP processor are you using?

All the best 

Diego . 

[xuedongyang]

Thanks for helping.

By casting the number with fixed16_t type as you suggested, I still observed the same problem. Very strange....

BTW, we are using LA1224 with VSPA3 DSP.

[diego_charles]

@xuedongyang 

Thank you for your reply, 

According to what I have found on that fixed16_t: its highest bit is the sign bit, and the remaining 15 bits are data .The data values ​​from MSB to LSB are 2^(-1) to 2^(-15), for example, 0x4000 represents 2^(-1) and 0xC000 represents -2^(-1).

This seems to match the fractional q15_t data type on the ARM CMSIS DSP library. however with my project compiled on ARM GCC I have not found this problem during variable assignation.

I am in the  general purpose MCU area, unfortunately , I do not have the hardware and SW libraries to test on my own.  I would recommend check for any examples within your BSP drivers where this  fixed16_t  is implemented and test  the assignation using different values  than 0x1357, for example 0.5 and -0.5 . It could be that the 7FFF, you are seeing  represents an overflow to the data type. Check that the sign bit can be set.

Please accept my apologies for the delay and the inconvenience.

Diego.