MSPM0C1104: Is it possible to use I2C communication and LIN communication at the same time?

Hi Donguk,

Please set LIN interrupt as the highest priority. And try to enable I2C FIFO to reduce the I2C's CPU occupied resource.

Regards,

Zoey

Hi zoey,

For now, as a temporary measure, I have set up I2C communication for the period from when LIN communication is completely terminated to the next LIN communication.
However, since the length of data to be sent and received through I2C communication is expected to increase, this method will not be possible if the length of I2C communication becomes longer than the period between LIN communications.
Therefore, it must be possible to communicate simultaneously.

Now, if  I communicate at the same time, it gets disconnected in the middle.

From what you said, I only use ADC0, LIN, and I2C interrupts in the project, so LIN has a higher priority than I2C.

I did not understand FIFO well. I would like to request additional explanation.

Regards,

Donguk

What is it that doesn't work? From what you've described, this appears to be a matter of strategy/coding. Looking at the scope trace, it appears that each operation (I2C/LIN) is run to completion before the other device is allowed to run, which isn't (generally) required.

The I2C FIFOs are always enabled. You can store up to 4x bytes (each direction), with e.g. DL_I2C_fillControllerTXFIFO(). For many I2C devices (usages) this is an entire transaction, in which case CPU intervention is only required at the beginning and at the end, and the transaction can run in the background while you're working with the LIN. With a 100kHz I2C, the FIFO provides (4*9*10usec)=360usec of I2C activity between interactions. 

Moreover, the I2C unit has flow-control, so if the FIFO goes empty (Tx) or full (Rx) the bus will be paused (clock stretched) until the CPU gets around to servicing it.

I'm less familiar with LIN, but I understand it has tighter real-time requirements. Even so, I think these are at a byte (1msec at 9600bps) level, not a bit level. With proper interrupt priority, this should allow the CPU interactions with the I2C to fit in between by just allowing the interrupts to "schedule" for you.

Hi bruce,
Thanks for your answer.
Unfortunately, I am not very good at communication strategies.

In my example, I used I2C in C:\ti\mspm0_sdk_2_04_00_06\examples\nortos\LP_MSPM0C1104\driverlib\i2c_controller_rw_multibyte_fifo_interrupts and LIN in C:\ti\mspm0_sdk_2_03_00_07\examples\nortos\LP_MSPM0G3507\lin\lin_commander.
The paths are a bit different because I changed the MCU during development.

I have a question about the content of your answer.

I2C: It is communicating at a speed of 400kbit/s and the size of 1 packet is 8 bytes for TX (including the slave address in the first byte) and 8 bytes for RX (excluding the first byte).
I am using MCF8329 as the slave board for I2C communication and follow the I2C rules of the data sheet.

LIN: It is communicating at a speed of 19200bps and communicates 8 bytes of data (11 bytes if you include the sync byte, Id byte, and checksum byte).

I am not sure if I understood correctly, but Do your answer means that LIN communication is a byte-based communication, so if interrupts do not overlap only at the start and end of a byte while 1 byte is in progress, simultaneous communication is possible.

In the example I used, when I checked it with a debugger, I confirmed that 29 interrupts occurred for LIN communication 1 time.
It is difficult to think of a way to prevent interrupts from overlapping. Do you have any other example code?

Best regards,

Donguk

There's no reason that the LIN and I2C can't run simultaneously; the contention comes at the interrupts, so you want those to be fewer/shorter and (I think?) you generally want to favor the LIN interrupts. [I suspect that's what you just said, but I wanted to make sure.]

1) You mentioned that you had set the LIN interrupt priority higher than I2C/ADC, but your screen shot ("Interrupt Configuration") didn't really show it.

In the Examples, the interrupt priority for each is set to "<Default>", which (presumably) means =0 (highest); more to the point, the priorities are all the same. Since you can't set LIN higher than =0, you could set I2C (and ADC?) lower (=1 or =2). Since the I2C has both FIFOs and flow control, it can deal with being postponed for some time.

Running the interrupts at different priorities means the LIN can pre-empt the I2C interrupt (code). This can work fine if you're careful to keep the two sets of data separate (let main() make the decisions).

2) LIN Commander uses a callback to deliver an Rx packet. This is called from the LIN interrupt; the Example callback is pretty simple, but you should be careful about putting too much into it.

3) There are also some settings which can improve the usage of the FIFOs, but those are slightly more involved. I'm curious how much you gain from (1) by itself.