I am using the freertos SPI API from ASF. In the freertos spiwrite/spiread packets, the API uses the DMA and also gives the ability to pass a semaphore to be notified on transfer completion.
So, if using several tasks and each task can communicate via the same SPI but on different CS, I need to modify the freertos spiread/spiwrite functions so it will first acquire the semaphores, then change the CS with “spisetperipheralchipselect_value”, and then configuring the PDC… right?
This is because it is not one atom operation, and I don’t want that one task will change the CS and before it will transmit, it will switch to another task that will, again chge to a different CS, then it will switch back to the first task that will start transmitting, but now to the wrong CS…
Is this correct?
I just looked at the demos that come with the driver and they appear to be setting the CS lines manually. The driver has two semaphores/mutexes, one to obtain access to the port and one to be notified of when the operation on the port is complete - is that the case? If so then it is only the semaphore used to get access to the port that prevents you from using the driver unmodified I think, and I would try to avoid modifying the driver.
You could provide your own access mutex so the operation would be as follows.
Create an access mutex in your application.
Open the SPI port using the driver but don't configure it to use an RX mutex, as you already have one in your application.
When a task wants access to the SPI have it first obtain the access mutex within your application, rather than in the driver.
Once access is obtained, set the CS as you require, then use the driver again. You can provide a notification mutex if you wish - just make sure that when the transfer is complete your application gives back the access mutex.