FOC implementation based on high priority interrupts for sure will be faster
and can save some processor bandwidth.
It makes sense for FOC sensorless controllers (eg. ESC) and allows the
highest
motor performance for given hardware. But this requires handling entire FOC
logic on
the kernel side which has many drawbacks.
This is definitely not a general and modular solution for FOC drivers and
this
is the main reason why I placed as much FOC logic as possible on the
application side.
The mathematical blocks that build the FOC controller are still available on
the kernel side (libdsp) mainly for the people who want to put their
controller
logic on interrupt level to get the best performance possible.
> nsh>
> ps
>
> PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK
> USED FILLED COMMAND
> 0 0 0 FIFO Kthread N-- Ready 00000000 001000
> 000308 30.8% Idle Task
> 1 1 100 RR Task --- Running 00000000 002024
> 001436 70.9% nsh_main
> 3 3 150 RR Task --- Waiting Signal 00000000 002008
> 001000 49.8% foc task foc task of fft
> 6 3 255 RR pthread --- Waiting Signal 00000000 004096
> 001140 27.8% pt-0x801b679 0x20005bd8
> 7 3 100 RR pthread --- Waiting Semaphore 00000000 002048
> 000732 35.7% pt-0x8019d71 0x20005bd8
>
> pt-0x8019d71 is a USB CDCACM RX thread
>
I have an ODriver hardware somewhere and I ported it to work with NuttX. I
think it has the same MCU as yours and there is USB connected to MCU so I
will try to reproduce your problem.
niedz., 3 kwi 2022 o 17:38 fft <f...@feedforward.com.cn> napisał(a):
>
> Hello Mateusz,
>
> Thanks for your help, I'm not proficient in using SystemView, but i will
> analyze your cool results. I'm use count register value of timer12 to
> measure the various execution times. I found in most normal cases, block
> time of foc_dev_state_get is about 50~60us, and sporadic 80~110us block
> time.
> My custom task in my case:
>
> nsh>
>
> nsh>
> ps
>
> PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK
> USED FILLED COMMAND
> 0 0 0 FIFO Kthread N-- Ready 00000000 001000
> 000308 30.8% Idle Task
> 1 1 100 RR Task --- Running 00000000 002024
> 001436 70.9% nsh_main
> 3 3 150 RR Task --- Waiting Signal 00000000 002008
> 001000 49.8% foc task foc task of fft
> 6 3 255 RR pthread --- Waiting Signal 00000000 004096
> 001140 27.8% pt-0x801b679 0x20005bd8
> 7 3 100 RR pthread --- Waiting Semaphore 00000000 002048
> 000732 35.7% pt-0x8019d71 0x20005bd8
> nsh>
>
> pt-0x8019d71 is a USB CDCACM RX thread
>
> Best regard
> Zou
>
> ------------------ Original ------------------
> *From: * "raiden00pl"<raiden0...@gmail.com>;
> *Date: * Sun, Apr 3, 2022 09:35 PM
> *To: * "dev"<dev@nuttx.apache.org>;
> *Subject: * Re: The real-time performance of nuttx
>
> Hi,
> I just started analyzing the FOC example with SystemView and I found some
> problems that can be connected with what you are observing.
>
> My configuration:
> STM32F446RE
> CPU freq 180MHz
> CONFIG_EXAMPLES_FOC_PWM_FREQ=10000
> CONFIG_EXAMPLES_FOC_NOTIFIER_FREQ=10000
>
> Context:
> ISR34 - FOC ADC handler
> ISR72 - Aux ADC DMA handler (VBUS + POT)
> ISR15 - SysTick
> ISR3 - Hard Fault
> pt-0x - FOC control pthread (priority 255)
> foc - FOC main, aux low priority work (priority 100)
>
> 1. Normal operation - FOC control thread executed every 100us
>
>
>
> 2. The first problem - system timer (in my case Systick - ISR15) drifts
> according to PWM / ADC trigger (ISR34)
>
>
>
>
>
> 3. Previous causes the aux threads being woken up in random moments in
> relation to the FOC controller thread
>
>
>
>
>
> 4. In the worst cases, this extends the time between successive calls of
> the FOC controller thread
>
>
>
>
>
> 6. The last diagram presents a case that I don't fully understand. The FOC
> control thread (priority 255) is interrupted by low priority thread
> (priority 100) - around 140.0 us
>
>
>
> niedz., 3 kwi 2022 o 09:56 fft <f...@feedforward.com.cn> napisał(a):
>
>> sorry, the picture of last email was lost!
>>
>> Hi team:
>>
>> I've been puzzled by a strange problem for a long time, when i use FOC
>> motor control. It seems that the FOC control thread failed to be scheduled
>> in real time. The code structure of ./apps/examples/foc/foc_float_thr.c can
>> be simplified description is as follows:
>>
>> while (motor.mq.quit == false)
>> {
>> ...FOC control code...
>>
>> /* Get FOC device state */
>> ret = foc_dev_state_get(&dev);
>> if (ret < 0)
>> {
>> PRINTF("ERROR: foc_dev_state_get failed %d!\n", ret);
>> goto errout;
>> }
>>
>> ...FOC control code...
>>
>> }
>>
>> where foc_dev_state_get will be periodic blocked by waiting semaphore,
>> and ADC interrupt periodic give semaphore.
>> My custom board is based on stm32f405 and my config about foc as shown
>> below:
>>
>> CONFIG_EXAMPLE_FOC_PWM_FREQ=20000
>> CONFIG_EXAMPLE_FOC_NOTIFIER_FREQ=10000
>> CONFIG_EXAMPLE_FOC_CONTROL_PRIO=255
>>
>> So, the FOC control code will be executed every 100us theoretically, In
>> fact, this is true in most cases tested on real hardware, but there's
>> sporadic unexpected states, that the execution interval between two FOC
>> control is 120~170us, There's no effect when the motor speed is low, but
>> when the motor speed is very high(up to 60000 erpm), this will cause
>> serious problem, the motor may suddenly get stuck and burn. What puzzles me
>> is the priority of FOC control thread already been set to the highest 255,
>> and i have enabled the CONFIG_PRIORITY_INHERITANCE, why the FOC control
>> threads was delayed so serious ? BTW, ther execution time of single FOC
>> control loop is 60~70us, and there's 5 custom task in my case:
>>
>> Is my configuration incorrect or the real-time performance of nuttx can
>> not meet the requirements?
>> Does anyone else have the same problem?
>>
>> Best regard
>> Zou
>>
>
