MOD54415 2s Compliment question

[nicobari]

Hi,
This is more of a noob and C coding question. I am reading data from a sensor via SPI3, the sensor data is in 16 bit 2s compliment form. I am assuming that MOD54415 works with 2s Compliment. The problem is I am able to read the positive data correctly but I cannot get the same value in negative. For example I am measuring acceleration due to gravity using accelerometer using a single axis accelerometer. I am able to read 1g but not -1g. The code is below.

accel_raw=(unsigned int)accel_read_spi3;
float zaccel=(float)accel_raw*0.0008;(0.0008 is the scale)

What am I doing incorrectly?

Thanks,
Tanmay

[dciliske]

Um... you realize that you're using an unsigned integer, right? Unsigned = always positive. You're never going to get a negative value. Also, I have to ask, is this a .c or .cpp file; you said it was a C question, but i think the behavior for your (float) cast my vary depending on which compiler is used. In either case, I can't see how it would ever give you a negative value, as the two possibilities are: a) the unsigned integer is type cast to a float (and therefore used to construct one) yielding a positive value or b) it is interpretted as a float (meaning the binary data is examined as if it were already a float). In the second case, I don't see how that would work either since floats are 32 bits (on this device) and unsigned ints are only 16 bits.

I believe you will need to store your raw value as a signed int, but without the datasheet or bus spec I have no idea what you need to do.

-Dan

[nicobari]

Sorry it was my mistake, its a .cpp code and I used unsigned to save the actual byte data. So now I have changed the code to look like

accel_raw=(int)sim1.dspi3.popr;
printf("%d",accel_raw);

Since now I am not using "unsigned int' and the "float" conversion, I expected to see the negative integer values but this time also I couldn't view any negative values even after the whole range of movement of the sensor. The sensor datasheet can be found at http://www.analog.com/static/imported-f ... S16488.pdf . Also it seems like "int" is 32 bit in .cpp.

Thanks in advance,
Tanmay

[nicobari]

I guess I figured out the problem. Since int is 32 bit and the sensor data is only 16 bit the negative number is still in the positive range of the int. So I used short int and now I can view negative numbers. Thanks.

Regards,
TM

[dciliske]

You found your fix while I was typing this; I'll post it anyways cause you might find it useful

Hmm... I was under the impression tha 'int' was 16; ahh, well I don't use it for storing anything the comes remotely close to 64K, just >255. Looking at the data sheet, it appears that the IMUs accel registers are 16bit. If an int is 32 bit like you say, then it'll never be negative since the data will be something like this: 0x0000_nnnn. In two's compliment, a integer is only negative if the most significant bit is a 1, like this: 0x1nnn_nnnn. I think this should work for you if you use

accel_raw=(int16_t)sim1.dspi3.popr;
printf("%d",accel_raw);

int16_t is a standard type for signed 16 bit integer. The form is:

(u)intx_t: u = unsigned, x = bit size

-Dan

[nicobari]

Thank you, that was definitely helpful.

Regards,
TM

[tod]

Just wanted to offer a clarification

int is not 32 bit in C++, nor is it 16 bit. Short is also not guaranteed to be 16 bit. All of these things are defined by the compiler and typically the same in C++ and C for a given compiler. Compilers can conceivably change the size of the fundamental type based on the module (or the target language). In general when you're on a 32 bit platform an int is 32 bits, but it's not always so. (On win64 with my C++ compiler ints are still 32 bits not 64). If you want to find out for sure one of your first programs can do something like:

Code: Select all

int x =1;
std::cout << "size of int is" << sizeof(x) <<'\n';

and the compiler will tell you what it is using.

You might also want to do this for short, long, long long, float, double.

ON all the NB modules I have used int has always been 32 bits and short has always been 16 bits.

In embedded programming when I'm dealing with hardware that has a dependency on bit size I tend to favor using stdint.h which makes your code more portable and very explicit

Code: Select all

uint16_t x;
uint32_t y;
int16_t z;

I suspect you can tell how many bits x, y and z are. Plus its a good hint to readers of your code that there is a specific size dependency in play. Also looking at stdint.h will show you waht int, short etc are since the above types are simply typedefs of the fundamental types.

BTW, "complement".

[dciliske]

Yea, I'm not sure why I was thinking 'int' should be 16 bit. I think I forgot about shorts for a while, as I almost exclusively use (u)intx_t due to it's explicit nature.

As for complement/compliment, maybe this thread found a couple of really nice bits?

[nicobari]

Thank you, always learning new things.

Regards,
TM