I2C design

[qermit]

First of all I fixed badly designed mutex handling in commit: qermit/afcipm@49c5959
It was to prevent other tasks changing this shared structure.
I've also introduced a initial i2c multiplexer handling.

In this case memory copy is just waist of resources and limits usage of I2C bus function in a master mode. Just pointer to rx/tx data shall be assigned while only one task may take ownership over I2C bus.

[qermit]

A separate data buffers for slave and master mode shall be used.
250uS between
Followed scenario is possible:

• MMC wants to send IPMI event, it writes data to data buffer/structures.
• MCH sends request to MMC
• i2ccfg.msg structure is changed partially inside ISR routine
• MMC sends corrupted data to MCH

Another problem I found is not checking if I2C interface is free before sending and not validating against arbitration lost.
All non obvious cases are handled in i2c_x17xx_40xx.c.

[qermit]

1. Average time between stop transmission (slave receive) and data copied from msg structure to rx_data: 12us
2. Average time between stop transmission (slave receive) and semaphore is is asked to be taken: 8us
3. Average time between stop transmission (slave receive) and data saved to input queue: 36us
4. Time spent to save message into input queue: 7us
5. Time between semaphore is taken in xI2CWrite and i2c flags are changed: 6us
6. Time between i2c flags are changed in xI2CWrite and transmission is started (MMC wins a bus partially) 2us.
7. Time between i2c flags are changed in xI2CWrite and MMC wins a bus: 61us.

The 8us (until semaphore is taken in xI2CSlaveTransfer) is most critical one. A received data is not protected against transmission started by MMC (event???) or next start from MCH (request after event response).

[henrique-silva]

Maybe a solution to lower the delays between semaphores being released/taken is to change them to Task Notifications, which, according to FreeRTOS spec, are way faster than the Semaphore API.
This should work as long as we register which task will get notified when an event finishes in the I2CBus using the i2c_cfgstruct

[henrique-silva]

Actually, that's how it is implemented in the custom I2C ISR functions, so the semaphore that's taking so long to be taken/released is the Mutex?

[henrique-silva]

Now using LPCOpen I2C driver functions, just masked as xI2C*** so other target uC can implement their own if they need.

[henrique-silva]

Timing should be tested again with the new implementation

[qermit]

I guess it may miss some transfer made by MCH after master transfers because slave mode is enabled again not in interrupt routing but in user context. Tests I made in Juli confirmed this.

That's why I made modifications to handleMasterXferState and added Chip_I2C_MasterTransferXfer (https://github.com/qermit/AFC-Loader/blob/master/src/chip/src/i2c_17xx_40xx.c)