Re: The real-time performance of nuttx

fft Sun, 03 Apr 2022 08:38:31 -0700

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&nbsp; 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&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 &nbsp;
nsh&gt; 
ps&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 &nbsp;
&nbsp; PID GROUP PRI POLICY&nbsp;&nbsp; TYPE&nbsp;&nbsp;&nbsp; NPX 
STATE&nbsp;&nbsp;&nbsp; EVENT&nbsp;&nbsp;&nbsp;&nbsp; SIGMASK&nbsp;&nbsp; 
STACK&nbsp;&nbsp; USED&nbsp; FILLED 
COMMAND&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 &nbsp;
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp; 0 
FIFO&nbsp;&nbsp;&nbsp;&nbsp; Kthread N-- 
Ready&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 00000000 001000 000308&nbsp; 30.8%&nbsp; Idle 
Task&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 &nbsp;
&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp; 1 100 
RR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Task&nbsp;&nbsp;&nbsp; --- 
Running&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
00000000 002024 001436&nbsp; 70.9%&nbsp; 
nsh_main&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 
&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp;&nbsp;&nbsp; 3 150 
RR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Task&nbsp;&nbsp;&nbsp; --- Waiting&nbsp; 
Signal&nbsp;&nbsp;&nbsp; 00000000 002008 001000&nbsp; 49.8%&nbsp; foc task foc 
task of fft&nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp;&nbsp;&nbsp; 3 255 
RR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pthread --- Waiting&nbsp; 
Signal&nbsp;&nbsp;&nbsp; 00000000 004096 001140&nbsp; 27.8%&nbsp; pt-0x801b679 
0x20005bd8&nbsp;&nbsp;&nbsp; &nbsp;
&nbsp;&nbsp;&nbsp; 7&nbsp;&nbsp;&nbsp;&nbsp; 3 100 
RR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pthread --- Waiting&nbsp; Semaphore 
00000000 002048 000732&nbsp; 35.7%&nbsp; pt-0x8019d71 
0x20005bd8&nbsp;&nbsp;&nbsp; &nbsp;
nsh&gt; 



pt-0x8019d71 is a USB CDCACM RX thread


Best regard
Zou

 


------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"raiden00pl"<raiden0...@gmail.com&gt;;
Date: &nbsp;Sun, Apr 3, 2022 09:35 PM
To: &nbsp;"dev"<dev@nuttx.apache.org&gt;; 

Subject: &nbsp;Re: The real-time performance of nuttx

&nbsp;

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:
&nbsp; &nbsp; &nbsp;STM32F446RE
&nbsp; &nbsp; &nbsp;CPU freq 180MHz
&nbsp; &nbsp; &nbsp;CONFIG_EXAMPLES_FOC_PWM_FREQ=10000
&nbsp; &nbsp; &nbsp;CONFIG_EXAMPLES_FOC_NOTIFIER_FREQ=10000
&nbsp;&nbsp; 
Context: &nbsp;
&nbsp; &nbsp; &nbsp;ISR34 - FOC ADC handler
&nbsp; &nbsp; &nbsp;ISR72 - Aux ADC DMA handler (VBUS + POT)
&nbsp; &nbsp; &nbsp;ISR15 - SysTick
&nbsp; &nbsp; &nbsp;ISR3 &nbsp;- Hard Fault
&nbsp; &nbsp; &nbsp;pt-0x - FOC control pthread (priority 255)
&nbsp; &nbsp; &nbsp;foc &nbsp; - 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&nbsp;fft <f...@feedforward.com.cn&gt; 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:



&nbsp; while (motor.mq.quit == false)
&nbsp; &nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ...FOC control 
code...


&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; /* Get FOC device state */
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ret = 
foc_dev_state_get(&amp;dev);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; if (ret < 0)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 
PRINTF("ERROR: foc_dev_state_get failed %d!\n", ret);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; goto 
errout;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; }


&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ...FOC control 
code...

&nbsp; &nbsp; }



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

Re: The real-time performance of nuttx

Reply via email to