FreeRTOS Seperate Thread

Hello Everyone.
I’m working on an algorithm.
I’m Using RISC-V architecture with FreeRtos.
I wrote a BLDC motor Commutation function where i read the Hall sensor and write the PWM in the respective gate drivers.

I want to use 3 task,
1st Read the Ethernet, then in 2nd task i will use the Ethernet value to choose the motor direction and duty cycle and then in 3rd task i will move the motor.
but the motor will not rotate properly because of the delay in 1st and 2nd task (if i don’t use any delay then there will be some delay ) and in 3rd task motor will not commutate properly.
is there any way to run the motor commutation function separately in a separate thread and other function with task in RISC V.
Thank you very much.

Your commutation task needs to be the highest priority as it is time critical. If it is actually changing the I/O bits to PWM the gates, it likely needs to actually be an ISR for a timer that it providing the time base for the PWM. It is MUCH easier if you have some hardware timer that can generate the actual PWM pattern, and have a task or interrupt update the parameters of this timer to provide commutation and control.

Thank you Richard.
but there is no interrupt, because it’s a simple routine , i read the 3 Hall sensor inputs with 3 GPIO inputs and then Use this information to drive the three phase of Information.
How i use this scheme with interrupt.
I already tried with IRQ Handler with Hall sensors.

i used 3 interrupts pin but when i call the interrupt handler function, then it read only one interrupt(one Hall sensor) at a time, and give only 3 values at different hall sensors, but i need 0-7 values which will come if IRQ read 2 Hall sensor simultaneously.
If you have any idea then please share with me.
Thank you very much

You NEED to use an interrupt, as otherwise you must be continually polling the sensors, and thus have no time to do anything else (maybe right after you see a sensor change you could do something short, but that would require VERY careful program design). The ISR can still read all 3 sensors (or just use the know values from the other sensors saved globally). Ideally, you would make it so that you could just read all 3 sensors from a single I/O port.

Most applications that use an RTOS live on interrupts. There may be some tasks not directly associated with an interrupt (like your 2nd task which decodes messages and produces control), but even these are often connected to an interrupt. In your example, the Ethernet adaptor generates interrupts for packets, its ISR does some processing and the driver task does the higher level stuff for it. That task, the distributes the packets with the right information to the second task, so the 2nd task is indirectly tied to the ethernet interrupt.

Every motor control system I have done that needed commutation control needed the commutation to be done in an ISR Maybe a coarse stepper could have it be done at task level based on a timer, but for anything else, the timing requirements are just to tight for anything but an ISR.