Why uint16_t assignment does not work

cancel
Showing results for 
Search instead for 
Did you mean: 

Why uint16_t assignment does not work

937 Views
xuedongyang
Contributor II

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.....

0 Kudos
7 Replies

911 Views
diego_charles
NXP TechSupport
NXP TechSupport

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. 

diego_charles_0-1634658394456.png

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.

 

 

0 Kudos

901 Views
xuedongyang
Contributor II

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.

0 Kudos

890 Views
diego_charles
NXP TechSupport
NXP TechSupport

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?  

diego_charles_1-1634788378764.png

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. 

 

0 Kudos

861 Views
xuedongyang
Contributor II

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?

0 Kudos

853 Views
diego_charles
NXP TechSupport
NXP TechSupport

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 . 

0 Kudos

848 Views
xuedongyang
Contributor II

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.

0 Kudos

385 Views
diego_charles
NXP TechSupport
NXP TechSupport

 

@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.

diego_charles_0-1636437334718.png

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.

0 Kudos