cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

New Contributor II

Hi,

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:

  1. 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...
  2. 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)
  3. Does the SPI transfer wiced_spi_transfer() runs in a blocking manner (i.e. running to completion before returning)?
  4. 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...

Thanks in advance for any advice

0 Likes
Reply
1 Solution
Moderator
Moderator

Hi,

--> After calling wiced_spi_init(),which calls SPI_Init(), you cannot change the SPI port communication parameters without calling the wiced_spi_deinit() api.

--> SPI transfer using wiced_spi_transfer is a blocking call in both DMA and non-DMA mode. It spin loops until the transfer is complete.

Thanks

View solution in original post

0 Likes
Reply
4 Replies
Moderator
Moderator

Hi,

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.

Thanks

0 Likes
Reply
New Contributor II

Hi,

Thanks for your reply.

In my app I have few SPI sensors sharing the same SPI bus (SPI4 in STM32F412)

Each sensor interrupts the MCU independently and cause to a respective thread to access the sensor.

As the SPI bus is shared, it can be accessed concurrently by more than a single thread.

I will also appreciate Cypress' reference to the question on the blocking/spin looping while the bus transaction is running.

Thanks

0 Likes
Reply
New Contributor II

Hi,

Any update on this?

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

Your direction on this is highly appreciated.

Thanks

0 Likes
Reply
Moderator
Moderator

Hi,

--> After calling wiced_spi_init(),which calls SPI_Init(), you cannot change the SPI port communication parameters without calling the wiced_spi_deinit() api.

--> SPI transfer using wiced_spi_transfer is a blocking call in both DMA and non-DMA mode. It spin loops until the transfer is complete.

Thanks

View solution in original post

0 Likes
Reply