cancel
Showing results for 
Search instead for 
Did you mean: 

What is reason behind multiplying the val[1] by 256 in the following function?

omkardixi
Associate II

I was working ISM330DLC sensor which I have interfaced with the my dev board nucleo 144 STM32F446. I'm using SPI protocol to get the raw data and also I'm able to read who am I register using following example codes "ism330dlc_read_data_polling.c". After reading getting raw data I was using MOTION GC library to get the calibrated data but I observed that "gyro_bias" parameter which will give the calibrated value of the accelerator as well as variable "bias update" was always zero

void MotionGC_Update  ( MGC_input_t *  data_in,  
  MGC_output_t *  gyro_bias,  
  int *  bias_update  
 )

So while debugging this issue, I came across the following function where I found the following function

int32_t ism330dlc_mag_calibrated_raw_get(stmdev_ctx_t *ctx,
                                         int16_t *val)
{
  uint8_t buff[6];
  int32_t ret;
  ret = ism330dlc_read_reg(ctx, ISM330DLC_OUT_MAG_RAW_X_L, buff, 6);
  val[0] = (int16_t)buff[1];
  val[0] = (val[0] * 256) + (int16_t)buff[0];
  val[1] = (int16_t)buff[3];
  val[1] = (val[1] * 256) + (int16_t)buff[2];
  val[2] = (int16_t)buff[5];
  val[2] = (val[2] * 256) + (int16_t)buff[4];
 
  return ret;
}

As we can able to see that in the above function input value is multiplied by 256 so my doubt is what will be reason of multiplying by the 256??

This discussion is locked. Please start a new topic to ask your question.
1 ACCEPTED SOLUTION

Accepted Solutions
KnarfB
Principal III

buff contains bytes but val are 16-bit entities. So it takes two consecutive buff elements to build up one val. * 256 and add will do that, other ways would be using a shift <<8 or a type cast.

hth

KnarfB

View solution in original post

3 REPLIES 3
KnarfB
Principal III

buff contains bytes but val are 16-bit entities. So it takes two consecutive buff elements to build up one val. * 256 and add will do that, other ways would be using a shift <<8 or a type cast.

hth

KnarfB

gbm
Principal

The whole routine above may be reduced to one line of code:

return ism330dlc_read_reg(ctx, ISM330DLC_OUT_MAG_RAW_X_L, (uint8_t *)val, 6);

No need to use buff[] and all these strange expressions.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

Thanks for your reply.

Can you please help me to understand the reason behind always getting "gyro_bias" buffer zero instead of getting the caliberated data?. Initially I thought may be an library integration issue but i tried to use other library functions like "uint8_t MotionGC_GetLibVersion(char *version)" where I was able to read the library version so that i concluded that library integration is okay.

Actually I'am stuck here for more than 4 weeks now so, any help will be really appreiciated!