Best Practice for manging DMA conflicts?
Posted: Thu Dec 04, 2014 12:37 am
Hello,
I'm working on porting a large project that uses some peripherals that share DMA channels. In our old code (no OS), we used interrupts for everything (no DMA). This is on an STM32F417.
Currently I am trying to get some code working that uses USART2 and I2C1 (but there will be others). In another thread it was adviced to work around DMA conflicts by disabling the driver. However, I noticed that if I disable the serial driver before the entire message is sent (like in the following snippet), the message is truncated (I assume this is because sdStop clears the DMA registers?).
Adding a sleep before the sdStop fixes the problem, but this is not acceptable for performance reasons. In fact it is much worse than our current interrupt-based solution. Are there workarounds possible? Or did I misunderstand something?
Right now it seems like the best option is just to write some (interrupt based, not using the DMA) drivers when a conflict can't be resolved by changing channel config.
I'm working on porting a large project that uses some peripherals that share DMA channels. In our old code (no OS), we used interrupts for everything (no DMA). This is on an STM32F417.
Currently I am trying to get some code working that uses USART2 and I2C1 (but there will be others). In another thread it was adviced to work around DMA conflicts by disabling the driver. However, I noticed that if I disable the serial driver before the entire message is sent (like in the following snippet), the message is truncated (I assume this is because sdStop clears the DMA registers?).
Code: Select all
msg_t usart_write(SerialDriver * usart, char *ptr, int len) {
sdStart(usart,&config);
msg_t ret = sdWrite(usart, (uint8_t*)ptr, len);
sdStop(usart);
return ret;
}
Adding a sleep before the sdStop fixes the problem, but this is not acceptable for performance reasons. In fact it is much worse than our current interrupt-based solution. Are there workarounds possible? Or did I misunderstand something?
Right now it seems like the best option is just to write some (interrupt based, not using the DMA) drivers when a conflict can't be resolved by changing channel config.