AnsweredAssumed Answered

Clarification of I2C_DRV_MasterReceiveDataBlocking() parameters

Question asked by David Pfaltzgraff on Mar 9, 2015
Latest reply on Mar 9, 2015 by Chris Brown

I'm trying to use the I2C_DRV_MasterXXXDataBlocking parameters and need some clarification. The following is my interpretation and I would like comments for clarification. (My environment is Windows7, KDS, KSDK, PE, and MQX on FRDM-K22F.)


The documentation states (simplified with my annotation):


I2C_DRV_MasterReceiveDataBlocking (

  instance,    // Which I2C Bus

  device,      // Address on I2C bus (7-bit width)

   cmdBuff,     // If not NULL, commands to be sent

  cmdSize,     // If not zero, number of bytes sent as command IF cmdBuff is not NULL

               // If command was sent, a restart applied

               // and I2C Address sent with a READ cycle

  rxBuff,      // Memory location for data read

  rxSize,      // Number of bytes to read , unless terminated by device

  timeout_ms );// Time out in milliseconds (API states microseconds!)


My question is: If cmdBuff is NULL, does the driver issue a read to the device without sending out the command first? In other words, the restart cycle is never performed.


I have the same question on the I2C_DRV_MasterReadDataBlocking() function as well.


In these cases I would expect to see the I2C bus go immediately into the appropriate transfer. Am I correct in this interpretation?