I2C and SPI potential DMA conflict

[alan5]

I'm using a STM32L152 with:

SPI2 (to communicate with CC3000)
I2C2 (to communicate with some sensors)
SD1 (for serial comms (chprintf())

It would seem if SPI2 and I2C2 are both started then I run into some difficulties... From other threads on this forum I'm assuming this is a DMA problem. The STM32L152 has a single 12 channel DMA controller. So would I right in saying that I cannot have the I2C and SPI drivers active/started at the same as they both grab the same DMA channel?

While I understand the basic concept of DMA I am not too familiar with the inner workings of its implementation on the STM32. A prod in the right direction would be appreciated

Assuming this is the case, is there any internal protection e.g. a built-in mutex for such a thing? I know SPI and I2C have an acquire bus function, but looking into it, this seems to protect the I2C/SPI driver and not the underlying DMA driver.

It was a few months ago when I picked the particular drivers being used. When I get some extra time I'll cross reference the GPIO with DMA channels to see if any don't overlap. However, ideally I would like a DMA friendly solution as well.

Cheers

[Giovanni]

Hi,

Your assumption is correct, you can have multiple drivers using the same DMA channels but you cannot start them at the same time. You need to start/stop the first one then start/stop the the other and so on.

Giovanni

[colin]

I had this same question regarding the STM32F051 that I was looking at. I think a good solution would actually be to implement an interrupt-driven option for the I2C driver, then the I2C would not require DMA at all.

I would suggest that the common difference in speed between SPI and I2C is about a factor of 100. That is, 0.1 Mbit/s vs 10 Mbit/s. In my experience I2C generally is used to transfer small blocks of data on the order of 3 bytes to 100 bytes per message (and usually at 100 kHz). With its much higher throughput of 10 MHz to 20 MHz or more, SPI is much better for higher throughput and larger messages and is usually used for high speed serial flash memory, graphical LCDs 128x64 and larger, SD cards, and other things that transfer 100 bytes or 1000 bytes in a chunk. So SPI will generally benefit from DMA much more than I2C since the "fire-and-forget" nature of DMA is more suited for these longer SPI transactions that would otherwise be interrupting the MCU core every microsecond or something at 10 MHz+ bus speed.

I may actually take a crack at adding an I2C option to the STM32 I2Cv2 driver at some point, if I ever get around to it.

[alan5]

Hi,

Your assumption is correct, you can have multiple drivers using the same DMA channels but you cannot start them at the same time. You need to start/stop the first one then start/stop the the other and so on.

Giovanni

Thanks for confirming my suspicions

Since DMA is an underlying concern, would storing a pointer to a user defined mutex in the I2C/SPI driver be potentially more advantageous than a fixed mutex?
It is more complexity for the end user since they would have to ensure appropriate peripherals share the correct mutex (or just throw everything at the same mutex) but offers more convenient protection.
I don't know how many people are using enough peripherals / smaller devices to need to care about this though.

[steved]

I would suggest that the common difference in speed between SPI and I2C is about a factor of 100. That is, 0.1 Mbit/s vs 10 Mbit/s. In my experience I2C generally is used to transfer small blocks of data on the order of 3 bytes to 100 bytes per message (and usually at 100 kHz). With its much higher throughput of 10 MHz to 20 MHz or more, SPI is much better for higher throughput and larger messages and is usually used for high speed serial flash memory, graphical LCDs 128x64 and larger, SD cards, and other things that transfer 100 bytes or 1000 bytes in a chunk. So SPI will generally benefit from DMA much more than I2C since the "fire-and-forget" nature of DMA is more suited for these longer SPI transactions that would otherwise be interrupting the MCU core every microsecond or something at 10 MHz+ bus speed.

I may actually take a crack at adding an I2C option to the STM32 I2Cv2 driver at some point, if I ever get around to it.

If the conflict is between serial and I2C, there is an interrupt-driven serial driver here

I agree with your comments about I2C, and did start implementing an interrupt-driven I2C driver, albeit with a slightly different reason - I wanted variable length receive, stopping on receipt of a specific character. Ran out of time before I got it working though. From memory, the interrupt handling didn't sit well in the existing driver, since I was trying not to break the existing DMA capability.