vPortTickInterruptHandler, because it has Port at the beginning, should be in the porting layer. It should be called by some Timer Interrupt in that porting layer, from a timer that layer dedicates to it.
The port layer should set up that timer to generate an interrupt at a rate of configTIMER_RATE_HZ, and is being told the timer will be counting at a rate of configTICK_RATE_Hz.
Yes that has to be called from a periodic interrupt, which is normally generated from a timer peripheral. You will need to see which timers are available on the chip you are using. This example is specific to the PIC32MZ, which is also MIPS, because it uses a PIC32MZ timer Timer1 by default, but also allows the application writer to provide their own time source if they use Timer1 for something else.
It’s normally configCPU_CLOCK_HZ, rather than configTIMER_RATE_HZ, but the configCPU_CLOCK_HZ name assumes the CPU clock is also used to clock the timer peripheral.
You can set configCPU_CLOCK_HZ and configTICK_RATE_HZ to values that then get used in the calculation that sets up the timer peripheral - the idea being if you want a different tick frequency you just update the configTICK_RATE_HZ constant rather than change anything in the C code. Likewise if you change the frequency of the clock that drives the timer, you can update configCPU_CLOCK_HZ rather than change anything in the C code.
Thank you very much for your support!
As I understood now tick timer does contex save, increment vPortIncrementTick and restore contex and also help in nested interrtups
And portYeild does switch of context in RTOS appropriated cases
Actually, the Tick Interupt should be using portYIELD_FROM_ISR() since it is within an ISR (but on some ports it doesn’t matter).
portYIELD() is designed to be used in a task, so one task can say its time to let another task at my same priority have some time.
portYIELD_FROM_ISR() is designed to be used in an ISR that has done something, like post data to a queue with a higher priority task waiting, and it is therefore desired to perform a task scheduling operation now.
The tick timer interrupt always does a portYIELD_FROM_ISR(), as that is what makes the round robin scheduling work.
Did I understand correctly, instead of generating software interrupt I can use portYIELD_FROM_ISR() and call it from tick timer interrupt?
But what for vPortIncrementTick is used then?
They both call portYIELD()
Big question, are you trying to us a port or make a port. If you are making a port, then everything that begins with “port” is something you need to create (perhaps copying from a similar port)
A given port can handle quite a few individual processors, because in many cases they all use the same base processor (which is the same for a whole family) and the variations are just the memory and peripherals that are attached. Sometimes it needs a small adjustment to choose the right source for the tick interrupt.
Thus, even if there isn’t an exact demo for the system, there may well be a suitable port to use.
If there is something different about your processor from the ones that already have a port, you may be able to just slightly modify the existing port to make it work.
Some of your questions seem to imply you are making a port from scratch, which is an unusual thing to need to do, and perhaps you don’t understand the task well enough to actually do it, but my guess is you don’t really need to do it.
vPortIncrementTick is called from the tick interrupt handler which in-turn calls xTaskIncrementTick. xTaskIncrementTick returns pdTRUE if a new task needs to be scheduled (i.e. a context switch is needed). The software interrupt is pended for doing the context switch. The context switch code on this platform runs in the software interrupt handler, which roughly does the following -
Save context of the current task.
Call vTaskSwitchContext - This selects the next task to run.