I have a working application that is getting complicated and I’m thinking about moving it to FreeRTOS.
Now my main concern is that it uses DMA triggered by UartRX INT to move a bunch of bytes to an array which then gets shuffled to an SD via SPI.
What are the problems I may face by leaving this mechanism as it is while integrating the rest of the app in FreeRTOS?
I could set up the buffers as global variables, so that they wouldn’t bog any process’ stack (I use 4K buffers, so quite big to shuffle around). Would this be sufficient?
I currently use FatFS and it takes about 5 ms to write an entire buffer.
It is pure code flowing, no DMA as I couldn’t find a working implementation and I couldn’t make my own (if anyone wanted to share one, I would be most appreciating!).
So it must (i think) remain operational for the whole transfer, I don’t know what would happen if the process got preempted.
Where are your 4K buffers allocated now? If they are on the stack, then you could leave them on the stack in your FreeRTOS version so long as you create the task with a big enough stack. It would probably be easier to have them as file scope variables though to make sure the stack variable does not vanish when the DMA is still using it.
The mechanism you describe is quite normal I think, and FreeRTOS will work fine with that. The DMA will do its own thing whatever, you just have to consider how the DMA interrupt is handled. How you do that will depend on its time criticality, and which FreeRTOS port you are using.
If you are using SPI to the SD card then getting interrupted should not be a problem. What will be a problem is having two tasks access the SD card at the same time, and in FreeRTOS you can prevent that using a simple mutex.