Best practice for handling buffers

Question

I'm writing some evaluation code with a lot of rx/tx operations, using the same two buffers and I started to think about how this could easily go very wrong.

I can argue that it is nice to clear/reinitialize the buffers with 0's or any other val for that matter for safety purpose, and it's not like my MCU can't spare the extra X ms operations.

But at the same time I could also argue that flushing them is just bloat operations as the program behaves as it should.

What is the best practice / industry standard when it comes to handling buffers continuously overwritten? Is flushing the buffers after each operation, like wearing a life jacket on land ?

void IIS328DQ_Read_All(void)
{
  txbuf[0] = IIS328DQ_REG_OUT_X_H;
  txbuf[1] = IIS328DQ_REG_OUT_X_L;
  txbuf[2] = IIS328DQ_REG_OUT_Y_H;
  txbuf[3] = IIS328DQ_REG_OUT_Y_L;
  txbuf[4] = IIS328DQ_REG_OUT_Z_H;
  txbuf[5] = IIS328DQ_REG_OUT_Z_L;

  // Request X axis high and low bytes
  ret = HAL_I2C_Master_Transmit(&hi2c1, IIS328DQSADWR, &txbuf[0], 2, 
  HAL_MAX_DELAY);
  ret = HAL_I2C_Master_Receive(&hi2c1, IIS328DQSADRD, &rxbuf[0], 2, 
  HAL_MAX_DELAY);
  // Request Y axis high and low bytes
  ret = HAL_I2C_Master_Transmit(&hi2c1, IIS328DQSADWR, &txbuf[2], 2, 
  HAL_MAX_DELAY);
  ret = HAL_I2C_Master_Receive(&hi2c1, IIS328DQSADRD, &rxbuf[2], 2, 
  HAL_MAX_DELAY);
  // Request Z axis high and low bytes
  ret = HAL_I2C_Master_Transmit(&hi2c1, IIS328DQSADWR, &txbuf[4], 2, 
  HAL_MAX_DELAY);
  ret = HAL_I2C_Master_Receive(&hi2c1, IIS328DQSADRD, &rxbuf[4], 2, 
  HAL_MAX_DELAY);


 // Combine high and low bytes 0b00001111+00001111 (Endianness) to 16 bit int
 x_raw = ((int16_t)rxbuf[0]<<8) + rxbuf[1];
 // Shift the 16 bits to a 12-bit representation
 x_raw = x_raw >> 4;
 y_raw = ((int16_t)rxbuf[2]<<8) + rxbuf[3];
 y_raw = y_raw >> 4;
 z_raw = ((int16_t)rxbuf[4]<<8) + rxbuf[5];
 z_raw = z_raw >> 4;

 // FS bits set to 00 - min 0.9 | typ 0.98 | max 1.1
 // convert raw data using sensitivity (0.98mg/digit ~ normal mode)
 axisArr[0] = x_raw * Sensitivity;
 axisArr[1] = y_raw * Sensitivity;
 axisArr[2] = z_raw * Sensitivity;
 clearBuf();
 }

clearBuf() simply fills the rx/tx buffers with 0's up to sizeof()

Answer 1

In this specific example, yes I would continue to clear the buffers and call your clearBuf() function.

Why? Mainly because you aren't even handling that return status from your I2C tx and rx functions.

What happens if your device suddenly becomes unreachable via I2C and all your Receive calls are failing? I don't know what the HAL_I2C_Master_Receive does to the buffer when timeout duration is reached without looking in depth at their specific implementation but there's a decent chance they just leave the buffer untouched.

The result could be, if not caught via checking return status or other special handling, that you continue to process data as if it is not changing at all.

Real process data will typically be something non-zero so if you're reading a data stream that goes something like [1.56, 1.54, 1.58, 0, 0, 0, 0, 0, 0] a user may be alerted to your device being bad even if you didn't account for handling the specific error condition encountered (such as the one present in your code).

Evaluating this single failure mode of loss of I2C communication for two possible data stream scenarios either:

1. Your data stream is typically zero and simply doesn't respond to changes due to the failure
2. Your data stream is typically non-zero and has suddenly zero'd out due to the failure

Clearing your buffers makes the error condition visible in the second scenario even if it doesn't improve things for the first one.

So--you could (and should) fix your error handling to alleviate this particular issue, but what else are you missing? Sensors go bad, I2C operations fail, power can fluctuate, are you making sure you don't lie to your users?