Number of cycles to schedule on Cortex-M

Hello,
I am new and feel sorry to ask such a basic thing as an approximation to the maximum number of cycles to schedule a new task or interrupt.

I am looking for results for Cortex-M0 to Cortex-M7. I will need multiple of them, but it is not yet clear which one. This includes:

  • Preempt low priority task and schedule high priority task.
  • Schedule from task to task on same priority.
  • Schedule from inactivated high priority task to low priority pending task.
  • Number of cycles from interrupt becoming active until first instruction of the user interrupt handler.
  • Schedule from end of interrupt back to the task preempted by this interrupt.
  • Schedule from end of interrupt to a task higher than the task that the interrupt has preempted.
  • How much adds an FPU?
  • How much adds an MMU/MPU?
  • A typical configuration for an application with 16-64 tasks and 8 priority levels

The PendSV interrupt is the only place context switches occur - you can get info on PenSV timing in the FAQ: FreeRTOS FAQ relating to FreeRTOS memory management and usage. FreeRTOS is an Open Source RTOS Kernel for small embedded systems

Some of your questions, such as the overhead added by the FPU, you can get from the Cortex-M hardware documentation, as that is fixed. Interrupt entry varies only in whether tail chaining is invoked or not - that saves a few cycles - but again is fixed by hardware.

Thank you very much for reply. It is very helpful.

One specific question to interrupts. Do I correctly understand FreeRTOS uses a zero latency interrupt policy?

With this I mean an interrupt handler registered in the NVIC vector is perfectly valid when it implements the complete interrupt handler functionality. In other words: There is no general recommendation to use *FromISR like functions. Such functions might be intended/recommended to do further things, such as protocol decoding of received communication characters. Such *FromISR functions are not required for simple interrupt handlers that might only change a digital output.

I have many ISRs that do their work all in the ISR (because it is quick and needs minimal latency)

The FromISR routines are to ALLOW the ISR to interact with tasks, but ISRs do not need to use them unless they need that functionality.