AM6412: I2C Multi-Master mode

Hello Gunter,

Commenting from the SW slave side: Eventually we want to work towards being able to point customers to the AM64x SW Build sheet here:
https://www.ti.com/product/AM6442#design-development##software-development

However, the document that is up right now has some mistakes. I hope it gets updated with the release of Linux SDK 8.0, but I do not have an exact timeline. One of the mistakes in the document available for download right now ("AM64xx_SW_Build_Sheet_V5", revision Initial Release) is that Linux I2C driver does NOT support slave / secondary mode.

In general, we suggest using real-time operating systems if the processor needs to act as a protocol slave. The R5 FreeRTOS I2C driver supports slave mode (but NOT the bare metal driver). See here for more:
https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_00_00_21/exports/docs/api_guide_am64x/DRIVERS_I2C_PAGE.html

Regards,

Nick

Thanks, Nick and Paul.

So we are good from the HW side.

From the SW standpoint:

Linux: We are not supporting I2C slave. 

https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/07_03_01_006/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/I2C.html

Are there any plans to support I2C slave with a Linux driver?

In the AM64xx Software Build Sheet, what does the term "Primary" vs "Secondary" mean? Does this mean Master/Slave?

Is there a limitation in Linux to support I2C Slave, e.g. latency? Prompting your comment about Real-time OS and FreeRTOS.

Thanks,

--Gunter

Hello Gunter,

Primary = master and secondary = slave.

I'm on vacation today, if I haven't responded by wednesday to the rest of your questions please ping the thread and I'll talk about I2C slave, response times for RTOS vs Linux, etc.

Regards,

Nick

On latency times between operating systems:

Linux is a pretty complex OS with a lot of things going on. If an application needs a specific latency for a task to complete, we cannot typically guarantee timing in Linux. Real Time Linux (RT Linux) adds features that make it easier to meet timing requirements (thread priority, etc). NOTE: this next sentence might not be totally correct - I can reassign to our RT Linux owner to comment if you want more details. My understanding is that even RT Linux has trouble 100% guaranteeing specific cycle times, so users typically must test their software over long stretches of time to see if any edge cases pop up - and even then there might be a random edge case in the field that did not come up during testing.

That is where RTOS comes in. When we say "Real Time OS", we don't mean everything happens so fast that it feels like it's happening in real time. Instead, we mean everything can happen within a specific latency. So if you define that something needs to occur within 500us, you can design your RTOS driver in such a way that your task will happen in less than 500us every single time.

Ok, so what does that mean for I2C slave?

TI does not currently have plans to implement I2C slave in Linux. In general, protocol slaves are expected to respond to the master within a specific timeframe. So while it may be possible to meet slave timing every single time on RT Linux, it is easier for our software team to guarantee that the drivers meet the slave protocol specs in RTOS. Protocol masters do not typically have to respond to an outside signal within a specific timeframe, so you will more frequently see master mode supported in Linux drivers.

Regards,

Nick