Meeting MCP23016 Twait

[kaolpr]

According to MCP23016 datasheet minimal time between transmissions should be 12 us:

This requirement may not be met at all times, so it may be advisable to put some delays between calls to MCP functions.

These delays should be included in MCP functions, however those are called in two different contexts:

• during initialization they are called in "bare metal" context,
• in payload they are called in a context of FreeRTOS task.

We can use nop-based wait function, but it seems not the right way of doing things in FreeRTOS context. On the other hand, vTaskDelayUntil can't be used outside the scheduler.

I'm not very experienced in FreeRTOS, so maybe I'm missing some more obvious solution, but I'm thinking of two ways of solving this:

• give up putting delays in MCP functions and place them in the calling context what makes it possible to use different implementations in different places,
• move initialization to one-off FreeRTOS task (what requires some synchronization of other tasks start...)

[augustofg]

Isn't the MCP23016 supposed to hold the SCL line down until it can process the previous byte, so the microcontroller I2C peripheral has to wait for SCL to become high again?

[kaolpr]

Hmm... Then maybe just checking if I2C write succeeds (#112) would do the trick.

[augustofg]

Checking every I2C transaction should be the norm (this is one of our goals for future refactoring), but holding SCL low should not cause the transaction to fail from my understanding as the I2C master peripheral would wait for it to go back to high.

[augustofg]

We haven't experienced problems with MCP23016 anymore, as stated in my previous comment an explicit delay is not necessary. I'm hoping that the I2C refactoring will be finished in the next months. I'm closing this issue for now.