What demo is more closer to MIPS & gcc

Hello!

Im going to use FreeRTOS for MIPS32/64 MCUs
But to do what, according

I have to choose suitable demo from the presented.
Cause for MIPS it hasnt got any I suppose what Its possoble to choose closest in architecture.

In my case I have to use MIPS-MTI-ELF so I can choose from GCC folder only.
And in this case I see RISC-V is more suitable.
But Im not sure…, correct me please

Thank you in advaunce

The PIC32 MX and MZ ports are both MIPS cores. The compiler is also GCC, although called something else by Microchip. Would provide link but I’m on my cellphone.

Adding link: https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/main/portable/MPLAB - there is a documentation page for the PIC32 demos on the FreeRTOS.org site, but I think you are just after the port code. It should be noted this is the most complex of all the FreeRTOS ports, mainly to enable nested interrupt support.

Thank you very much!

Can you prompt what I shold do to enable interrtupt support?, please

As I undestood I have to :

  1. saving the EPC and Status registers,
  • any GPRs that may be modified by the nested exception routine, disabling
  • the appropriate IM bits in Status to prevent an interrupt loop, putting
  • the processor in kernel mode, and re-enabling interrupts
  1. add this in vPortYieldISR
    As im right?, or I must add 1 point in handler which occured whithin presented another?

Do the instructions under the “interrupt service routines” section on this page help? Free RTOS for PIC32MZ microcontroller with MIPS M14K core (scroll down just a little to see the relevant section).

Thank you for your support!

But now I confused a little, can you explain,please, from what vPortTickInterruptHandler has to occurs???
From any peripheral timer?
Is it one of the famous procedure of porting???

And what for then these defines?:
#define configTIMER_RATE_HZ
#define configTICK_RATE_HZ

P.S. I still ask for MIPS

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

But what for then :

  1. Installing the software yield handler ;

  2. vApplicationSetupSoftwareInterrupt();

Thanks in advaunce

Can you also explain in defferences beween vPortYield and vPortYieldISR ?, please
Is it neccesary to create software interrupt vector to locate in it vPortYieldISR ?

portYIELD() should be used in a task, or better yet, use taskYIELD().

portYIELD_FROM_ISR() is intended to be used inside an ISR.

The _FROM_ISR() functions are the (generally) the only FreeRTOS functions that should be used from inside an ISR, and those functions generally are not to be used from a task.

Thank you for your replay!

But now I didnt understand where portYIELD should switch the task then ?
I thought what in working of 2 tasks with the same priotitys an exist the following altghorithm :

  1. Start of scheduler;
  2. Start of first task;
  3. Idle state;
  4. tick timer interrupt (vApplicationSetupTickTimerInterrupt();)-> call vPortIncrementTick → portYIELD() → call programm interrupt;
  5. switch of context(save and then restore).

As Im right in my understanding?
If its true then tick timer have to cause program(software) timer and the last cause portYiled wherein I havenot to think about vPortYieldISR ?

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.

Thank you very much!

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.

I didnt understand, sorry
Now I see in PIC32MZ porting and dont undesratand why in vPortIncrementTick
software interrtupt is called :
/* Pend a context switch. */
_CP0_BIS_CAUSE( portCORE_SW_0 );

In context of context switch)

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 -

  1. Save context of the current task.
  2. Call vTaskSwitchContext - This selects the next task to run.
  3. Restore context of the newly selected task.

Thanks.

Thank you very much for your replay!!!
Now I see, it turns out that software interrupt handler is vPortYieldISR in this(PIC32MZ) case???

And can you explain please what source call software interrupt ?