Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[PIC] MPLAB Data storing in Varibles

Status
Not open for further replies.

M.Rehan

Full Member level 2
Joined
Feb 10, 2016
Messages
129
Helped
2
Reputation
66
Reaction score
33
Trophy points
28
Activity points
972
Can some one expalin the temp1 value?
dsPIC30Fxxxxxx
MPLAB XC16
Image for reference is attached and mentioned in comments


Code C - [expand]
1
2
3
4
5
6
7
8
#define Speed   Q15(0.51)                                               // Fixed Point Math Library
                                                                                  // 16 Bit Fraction --> "First Image"
int temp1;
int distance = 30601
 
temp1 = ((__builtin_mulss((int) speed,distance))>>15);   // Multiplication of both variables
                                                                                // Accepts both signed integers and returns double
                                                                                // 2nd Image attached



MPLAB stores double in little-endian method (3rd image attached)

My Confusions are:
1st --> "builtin_mulss" accepts integers so converting "speed" to int, How this will happen? I mean in what way MPLAB converts it(Remember its Q15 Fraction format)

2nd --> How double will be shifted 15 bits to store value in an int (Because there are 17 Bits remaining) and data loss?

3rd --> Can some one expalin the temp1 value?

I am new to MPLAB



Capture.JPG
Capture1.JPG
Capture2.JPG
 

First off, the compiler (XC16) is the thing that does all of the interpretations. MPLAB is only the IDE.
Second, you say at the start that you are using XC16 but the 3rd image is from the C18 compiler guide - a different compiler all together. However the 'endianness' is actually set by the dsPIC30F hardware.
As for your questions:
1) Probably no conversion is done at all. As you show in for first image, Q15 format is just an interpretation of what the 16 bits actually mean. Therefore the compiler will simply pass the bit pattern to the function. If you want to do a conversion to 'integer' then you will need to perform your own conversions, remembering that Q15 has a range of [-1.0, +0.999969482] so you will need to apply a scaling factor.
2) I don't understand this question. There are no 'double' values. The 15-bit shift that I can see applies tot he Q15 value which is 16 bits long and so you will end up with the MSB begin shifted to the LSB.
3) Again I don't really understand what you are asking as this is your code and therefore you should understand what you expect the function to do. The documentation will tell you what the function itself is doing.
Susan
 

1) Probably no conversion is done at all. As you show in for first image, Q15 format is just an interpretation of what the 16 bits actually mean. Therefore the compiler will simply pass the bit pattern to the function. If you want to do a conversion to 'integer' then you will need to perform your own conversions, remembering that Q15 has a range of [-1.0, +0.999969482] so you will need to apply a scaling factor.
Susan
This code is from a reference code by MicroChip
My question is this fraction will be converted to int

How long (datatype) will be shifted 15 bits to store value in an int?
 

Unfortunately, just because it comes from Microchip, does not mean that it is correct or that it can be taken (possibly) out of context.
As I have said, the Q15 format simply defined how the 16 bits in the variable can be interpreted to represent a value. The same bit pattern can equally be interpreted as 1 16-bit Unicode character or 2 8-bit ASCII characters or an integer or as anything else you want it to be. That is simply how YOU are interpreting the bits.
As far as the compiler is concerned it sees the Q15 value as a 16 bit value that corresponds to a fundamental data type (that the compiler does know about) of integer. Therefore, unless you code something in, then no conversion will be done for you in passing that value to the function.
Also I'm sorry but I misinterpreted the brackets in the code and I see now that it applies to the long int return value from the function. The bit-wise 'right shift' operator ('>>') will shift all of the bits in the value to the right and add in 0's to the MSB position(s).
A Long int is defined in XC16 as a signed 32 bit value (there is no real common definition of 'long int' other than it is no smaller than an 'int'; one of the strange things about the C programming language so you need to look at how each compiler defines these things). That means the MSB will be interpreted as the sign - 0 being positive and 1 begin negative.
However when you put the two items above together, you will see that shifting right a negative int will result in a positive value as the MSB (which is interpreted as a sign bit) will always be replaced by a 0. If you know the value will always be positive, then that is not a problem.
A 15 bit shift to the right is the same as dividing by 32768.
You have a further problem with your code in that the 'temp1' variable is defined as an int which is 16-bits and assumed to be signed. Even though you shift the 32-bit value right by 15 bits, it will be seen by the compiler as a 32-bit value which it will then try to store in a 16 bit variable. I'm surprised that you are not getting a warning message about the value being truncated.
Bottom line: when you start getting in to bit-fiddling like this, you really need to fully understand what the compiler is doing and be very sure you understand the range of the values you are dealing with.
Susan
 
  • Like
Reactions: M.Rehan

    M.Rehan

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top