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

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
Lead III

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!