Hello all.
Reading data from an EEPROM involves an I2C transaction that uses a combined i2c-write and i2c-read data transfer: Following the write of the memory address, data can be read. The transaction looks like this:
This transaction involves a repeated Start condition.
To realize a repeated Start condition using the now obsolete LPCOpen API a single call to Chip_I2C_MasterTransfer() was sufficient as this function comprised a write with a following read.
However, the current SDK provides I2C_MasterTransferNonBlocking()which (to my understanding) provides either an i2c-read or an i2c-write transfer. It is more low level (and unwieldier) than the LPCOpen API. To generate the above transadtion, one has to call I2C_MasterTransferNonBlocking()twice and set the flags correctly to create the repeated Start condition.
With that said, let's look at the relevant function I2C_RTOS_Transfer() in fsl_i2c_freertos.c:
/*!
* brief Performs I2C transfer.
*
* This function performs an I2C transfer according to data given in the transfer structure.
*
* param handle The RTOS I2C handle.
* param transfer Structure specifying the transfer parameters.
* return status of the operation.
*/
status_t I2C_RTOS_Transfer(i2c_rtos_handle_t *handle, i2c_master_transfer_t *transfer)
{
status_t status;
/* Lock resource mutex */
if (xSemaphoreTake(handle->mutex, portMAX_DELAY) != pdTRUE)
{
return kStatus_I2C_Busy;
}
status = I2C_MasterTransferNonBlocking(handle->base, &handle->drv_handle, transfer);
if (status != kStatus_Success)
{
(void)xSemaphoreGive(handle->mutex);
return status;
}
/* Wait for transfer to finish */
(void)xSemaphoreTake(handle->semaphore, portMAX_DELAY);
/* Unlock resource mutex */
(void)xSemaphoreGive(handle->mutex);
/* Return status captured by callback function */
return handle->async_status;
}
As you can see, the call to I2C_MasterTransferNonBlocking() is guarded by a mutex.
With regard to the above transaction, the following situation can occur: After a first task has finished the first part of above transaction, a second task calls I2C_RTOS_Transfer() and 2C_MasterTransferNonBlocking().
I don't know if it is valid to interrupt an I2C transaction with a first target, start a second I2C transaction with a second target and later continue the transaction with the first target. I could not find an explicit hint in the I2C specification. It is my understanding that an ongoing I2C transaction should be finished before a next one is started.
To avoid this situation of interrupted I2C transactions (however unlikely it may be), one would need to add another guard to prevent I2C transactions to "intermingle".
Could anyone please comment on these issue?
Dear @xiangjun_rong ,
Thank you for your response.
When you have a realtime OS at hand, I don't recommend to use polling or disabling interrupts while polling.
Rather, I ditched the FreeRTOS driver fsl_i2c_freertos in favor of the CMSIS based driver fsl_i2c_cmsis. That is the API which Peripheral Tool generates code for. Further, I added resource locks and task notifications via FreeRTOS primitives. That worked for me.
Best regards,
Daniel
PS: Pro Tipp - If you want to add code samples to your posting, readability is greatly improved when you use the "Insert/Edit code sample" function, see screenshot below.
PPS: I think that it is not helpful to add a code sample if you just want to point to a certain function in a certain file and do not discuss the code you are presenting.
