Why uint16_t assignment does not work

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why uint16_t assignment does not work

5,417 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
9 Replies

5 Views
Nikhil9313
Fresh Out Contributor

Facing issues with your assignment? Perhaps integrating a Student Result Management System could streamline the process, enhancing academic excellence while resolving such challenges. 

0 Kudos

3,831 Views
curransam471
Contributor I

Nursing Assignment Help | Best Writing Service By Experts
Being a nurse is difficult, and becoming one is even more difficult. Students frequently join nursing programs with the expectation of pursuing a rewarding career, only to fail the program due to the complexity of the scholastic work that they must complete. Students pursuing degree and diploma programs in nursing at Australian universities find writing nursing assignments difficult and seek Nursing assignment writers in Australia. Nursing is one of the noblest courses a person can pursue, but in order to complete your degree in the area, you must be familiar with all of the concepts and terminologies that may come in helpful while completing the task of nursing assignment writing.

0 Kudos

5,391 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

5,381 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

5,370 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

5,337 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

5,330 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

5,325 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

4,862 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