I2C FreeRTOS, big time gap between sub commands

[p_mamatis]

Dear Community,

I have a really strange problem and i don't know what i am missing.
I am trying to use an I2C communication to read a sensor. So every transfer command , if read or write,  starts with a start command which contains also the slave address, followed by a write command in case there is a certain register which should be read and so on.
My Problem is:
When i am trying to use the I2C Interface in my own project, there is always a huge time gap between this sub-commands.
I made i picture to show my problem. Green is SCL(Clock) yellow the SDA(Data).

(I2C timing in own project)

The point is, when i am using the examples given by the SDK the I2C communication looks normal like this. All sub commands stick together as one can see at the small gaps between the Clock (green)

(I2C timing with example code)

There must be a configuration or something else i am missing.
I am using the LPCXpresso54S018 evaluation board and trying to implement my software on top of FreeRTOS.
I already merged the example FreeRTOSConfig.h in my own project, but changed nothing with the I2C timing.

Thanks for any help.

 

[frank_m]

> My Problem is:
> When i am trying to use the I2C Interface in my own project, there is always a huge time gap between this sub-commands.

As already mentioned, the answer to your question is already in the title.
You would have to check what other tasks are running in your application.

However, I would not be worried, unless you really need a high throughput.
A realtime OS allows you to do several tasks quasi-simultaneously, and to react to events in a given time.
This surely comes at the expense of runtime available to individual tasks, and complexity.

My company for example uses a similiar RTOS for our ECU, initializing devices on multiple CAN busses, and processing CAN messages at runtime at a certain time tick (10ms).

[p_mamatis]

@frank_m
Thank you for your reply,
I used a plain template project without any tasks than the i2c tasks, within a I2C_RTOS_Transfer. Also checked, if the normal I2C_Transfer and the I2C_DMA_Transfer are having the time gaps. All the same.

I must missing some clock config or maybe messing up with the task priority.

But yeah you are absolutely right, if I would use a couple of tasks with higher priority there is a high possibility for such time gaps.

In my application it is really important to match the baud rate, because it comes with a measurement which should meet a certain frequency. So if I am not reading the registers of the device every X ms, i am loosing a lot of information.

But Thank you for your help

[frank_m]

> I used a plain template project without any tasks than the i2c tasks, within a I2C_RTOS_Transfer. Also checked, if the normal I2C_Transfer and the I2C_DMA_Transfer are having the time gaps. All the same.

Most probably it is the scheduler alone creating this gaps - and perhaps FreeRTOS interrupt handlers. If I remember correctly, FreeRTOS grabs control over most interrupt handlers.

> In my application it is really important to match the baud rate, because it comes with a measurement which should meet a certain frequency.

I am not sure what you mean here with baudrate.
The I2C peripheral is mostly independant, and each transfer is automatically done with the set clock frequency. Most I2C slave are static designs, i.e. you could theoretically stop a byte transfer at any point for an arbitrary time, and it would still succeed once finished.

> So if I am not reading the registers of the device every X ms, i am loosing a lot of information.

I suppose you need to get in the weeds with FreeRTOS.
I don't know this RTOS in much detail, and if implementing your I2C via its task system is the best approach. Consider using interrupts callbacks instead.

[p_mamatis]

>Most probably it is the scheduler alone creating this gaps - and perhaps FreeRTOS interrupt handlers. If I remember correctly, FreeRTOS grabs control over most interrupt handlers

This is a good advise! Thank you.
I will dive more into the interrupts and scheduling.

>I am not sure what you mean here with baudrate
Inside the MCUXpresso IDE, while the peripheral initialization they call the I2C Clock frequency "Desired Baud rate"

>you could theoretically stop a byte transfer at any point for an arbitrary time, and it would still succeed once finished.
Good to know. So if an other task with higher priority interrupts my i2c transfer, it should be possible to continue the i2c task without errors and data loss?
This is a really helpful information!

>I suppose you need to get in the weeds with FreeRTOS.
yeah absolutely
I am trying my best.

>I don't know this RTOS in much detail, and if implementing your I2C via its task system is the best approach. Consider using interrupts callbacks instead.
The advantage of FreeRTOS is, that it provides a lot of network overhead like the lwip and MQTT. But if don't get the i2c connection work properly i need to switch to baremetal or go with interrupts.
When i get it right, there is a configuration to decide which interrupts prioritys are handled by FreeRTOS and which are still managed by the microcontroller itself.

Thank you so much for your solution approaches!

[frank_m]

> Good to know. So if an other task with higher priority interrupts my i2c transfer, it should be possible to continue the i2c task without errors and data loss?

Unless you have a "software implementation" (a.k.a. bit-banging), this is not really relevant four your case. Basically all modern MCUs have I2C peripherals that operate on transaction granularity. Which means, you trigger a transaction (at least byt transfer), and the rest happens without core interference. Actually, you can't even stop it.

The point becomes relevant when a slave somewhat picks up a "wrong" clock pulse, and gets out of sync.
In this case, you most probably need to perform "special tricks" to reset or re-synchronize it, bypassing the I2C peripheral.

But as mentioned - unless you have real-time constraints, you usually can have arbitrary long "idle times" even in multibyte transfers, as long as the signal sequences is correct.
I.e. an access stretching over multiple invocations of the same thread.

Though I would read the slave datasheet carefully...

[xiangjun_rong]

Hi,

When you use FreeRtos to transfer data, there are semaphore or event mechanism to synchronize, so you will take a long time.

For example, this is the code, the line /* Wait for transfer to finish */
(void)xSemaphoreTake(handle->semaphore, portMAX_DELAY);

you need a longer time to transfer than that of without FreeRtos.

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)
{
xSemaphoreGive(handle->mutex);
return status;
}

/* Wait for transfer to finish */
(void)xSemaphoreTake(handle->semaphore, portMAX_DELAY);

/* Unlock resource mutex */
xSemaphoreGive(handle->mutex);

/* Return status captured by callback function */
return handle->async_status;
}

Hope it can help you

BR

XiangJun Rong

[p_mamatis]

Thank you for your reply
You are totally right, but the big time gap is not existent in the freertos_i2c sdk example.

I figured out that i cant reach the total 2.9 MHz I2C baud rate in the example, probably because of the FreeRTOS overhead (semaphore etc.), but i am not certain about that.
My solution now, is to build my project on top of the freertos_i2c example. It is a way around the problem but extremely unsatisfying

Thank you for your help,

Paul