This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 - SPIM Blocking mode with SD and FreeRTOS

Hi,

I am using SDK 14.0 on nRF52840 (DK), with sofdevice enabled and FreeRTOS port.

My question reagrds the "blocking mode" transfer - event handler was not provided in nrf_drv_spi_init().

How would a FreeRTOS system behave when a task is using the “blocking” transaction mode:

  1. When task is high priority (relative to other task(s))
  2. When task is low priority (relative to other task(s))
  3. When other task(s) are ready before it’s call to MCU sleep
  4. When other task(s) are becoming ready via ISR during it’s sleep
  5. Is there any difference if I use EasyDMA or not in this case?

Thanks, Elkana.

Parents
  • All tasks are running in thread mode. The RTC tick and Scheduler are running in interrupt context with least priority, which is one level higher in priority than thread mode. In short, any enabled interrupt would preempt a FreeRTOS task.

    1. Then the high priority task will be scheduled until it yields check this

    2. Then it will run until other high priority tasks become runnable either after unblocking by the current task or after the tick handler runs which in turns runs the scheduler.

    3. Then there will be a context switch to higher priority task.

    4. nothing happens during sleep. When an ISR has yielded forcing scheduler to run, then it will choose the newly available high priority task to run.

    5. you are freeing up CPU for this task. The callback from EasyDMA will be called from SPI interrupt context, so it is little different than running it in your task which is running in thread mode.

  • First of all, its not safe that high priority task goes to sleep. Since it cannot yield before going to sleep. And wakeup from sleep will make the scheduler run the high priority task again. If you say that the SPI transaction makes another task ready, then if the other task is higher in priority than the one that slept, then this newer task will be scheduled as soon as the RTC tick handler is run (not after SPI *R, since no one is yielding here). FreeRTOS always selects the higher priority tasks to run,

Reply
  • First of all, its not safe that high priority task goes to sleep. Since it cannot yield before going to sleep. And wakeup from sleep will make the scheduler run the high priority task again. If you say that the SPI transaction makes another task ready, then if the other task is higher in priority than the one that slept, then this newer task will be scheduled as soon as the RTC tick handler is run (not after SPI *R, since no one is yielding here). FreeRTOS always selects the higher priority tasks to run,

Children
No Data
Related