Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
In my project I'm using SIP based on STM32F412 + CY4343W.
Looking at some demo projects using resources (e.g. SPI bus), I didn't notice any locking mechanism (mutex etc.)
My questions are:
Is access to a system resource, e.g. wiced_spi_transfer() is protected using mutex in case several threads are accessing the same resource concurrently? I followed the calls wiced_spi_transfer() --> STM32F4xx/platform_spi_transfer() and didn't find any locking...
If not, how this resource can be protected? I know when to lock a mutex but don't know when to unlock it, especially if using DMA (unless the call is blocking. See next question)
Does the SPI transfer wiced_spi_transfer() runs in a blocking manner (i.e. running to completion before returning)?
If it runs in blocking manner, does it spin looping till completion, or does it sleep (rtos sense)? It has huge implication on system performance...
Does your application requires simultaneous access of wiced_spi_transfer() API ? You can implement your own locking mechanism in the application to restrict the access of the API by simultaneous threads. I will try to implement this functionality and get back to you. Sorry for the inconvenience caused.
Can you guide as how to access several SPI peripherals on the same SPI bus.
Specifically (for STM32F412 based platform):
After calling wiced_spi_init() which chains platform_spi_init() --> SPI_Init(), can I change (without deinit()) the spi port communication parameters - speed, CPHA/CPOL, bits?
Is SPI transfer using wiced_spi_transfer() a blocking call when using DMA ?
if its blocking (i.e.it returns after the transfer is complete) - does it block on semaphore or does it spin loops until completed
if its unblocking (return immediately while transfer is handled in the background by the DMA) - how can I tell that the transaction is completed so I can unlock the resource ?? Can I hook some kind of callback