Re: [Paparazzi-devel] Libopencm3 - STM32-F1 change interrupt priority

[matkovmike]

Hi Felix, 
 
thanks for the explanation about the sys_mon, now it makes more sense:) 
 
I ran a couple of quick tests (just looking at the telemetry data and 
sys_mon module, no data logging): 
A) rotorcraft running @512Hz + GX3 as ahrs @500Hz + int_euler for 
stabilization -> runs just fine (master 5.0) 
B) rotorcraft running @512Hz + GX3 as ahrs @500Hz + float_euler for 
stabilization -> VERY BAD timing (probably because of the floating point 
calculations at high rate?) (master 4.9) 
C) rotorcraft running @512Hz + GX3 as ahrs @125Hz + float_euler for 
stabilization (master 4.9) -> OK(!), note that floating point calculations 
runs at the same rate as in B), there is just 4x more UART traffic... 
 
Maybe rotorcraft code is written in a way it can handle the tasks and 
timing better? 
 
M 
 
As for yesterday tests w. fixedwing, here is the configuration for aspirin: 
  <firmware name="fixedwing"> 
    <target name="ap"             board="lisa_m_2.0"/> 
    <configure name="FLASH_MODE" value="JTAG"/> 
 
    <define name="AHRS_USE_GPS_HEADING"/> 
    <configure name="PERIODIC_FREQUENCY" value="500"/> 
    <define name="MODULES_FREQUENCY" value="500"/> 
 
    <subsystem name="control"/> 
 
<!-- Communication --> 
    <subsystem name="telemetry"     type="transparent"/> 
 
    <subsystem name="radio_control" type="ppm"> 
       <configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/> 
    </subsystem> 
 
<!-- Sensors --> 
    <subsystem name="imu"      type="aspirin_v2.2"/> 
    <subsystem name="ahrs"      type="int_cmpl_quat"/> 
    <subsystem name="gps"       type="ublox"/> 
    <subsystem name="navigation" type="extra"/> 
    <subsystem name="ins" type="alt_float" /> 
  </firmware> 
 
<!-- Modules --> 
  <!--modules main_freq="500"--> 
  <modules> 
    <!-- Airspeed Sensor --> 
    <load name="airspeed_adc_adv.xml"> 
    </load> 
 
    <!-- System Monitor --> 
    <load name="sys_mon.xml"/> 
    <load name="battery_monitor.xml"/> 
 
    <!-- UGEAR BLACKBOX --> 
    <load name="ugear_blackbox_uart.xml"/> 
  </modules> 
 
 
On Fri, Aug 23, 2013 at 8:15 AM, Felix Ruess <address@hidden> wrote: 
 
> Hi Michal, 
> 
> I added some more information to 
> http://paparazzi.enac.fr/wiki/Module/System_monitor. I hope that answers 
> your question about the periodic_cycle... 
> 
> Nice job on the testing/plotting so far ;-) We clearly need to have a 
> closer look at this... 
> I didn't observe any variations like that in my setups so far (will check 
> again tonight when I have access to the hardware again). 
> There are quite a number of reasons why this could happen... 
> E.g. if have an algorithm that takes a lot of time, it could delay the 
> next periodic function. As we don't have any preemption (yet) this is some 
> sort of cooperative scheduling. 
> It could be triggered by an event like new gyro data and hence run in the 
> event loop, or be one of the autopilot periodic functions like running 
> guidance (e.g. if you try to run that in float without a floating point 
> unit it will probably take too long) 
> 
> What configuration (stabilization, ahrs, ins, etc..) were you using for 
> the aspirin tests? 
> 
> Cheers, Felix 
> 
> 
> On Fri, Aug 23, 2013 at 2:50 AM, Michal Podhradsky < 
> address@hidden> wrote: 
> 
>> Hi Felix, 
>> 
>> so I looked into it a bit more. First test with system monitor, using 
>> fixedwing with GX3 at 500Hz, and PERIODIC_FREQUENCY=500Hz. 
>> The periodic time is an average, so it is exactly at 2ms. The max 
>> periodic cycle is however over the periodic time -> something is going on 
>> there. 
>> 
>> Although I am not sure how to interpret the periodic_cycle. The average 
>> is 1.25ms, which represents 800Hz, but I am not aware of any loop going 
>> that fast. 
>> 
>> I made a simple logger module to monitor system time on the autopilot. It 
>> runs at the same frequency as the periodic frequency, and sends through 
>> UART current system time  (get_sys_time_usec() from 
>> arch/stm32/mcu_periph/sys_time_arch.h). I ran couple of tests with 
>> different configurations. 
>> 
>> Test 1: -> data1.png 
>> Aspirin IMU, 60Hz periodic frequency. Just to get the baseline. 
>> After first 80sec I plugged in GX3 configured to just output data @500Hz 
>> (loads of data on UART). The data from GX3 weren't processed any further 
>> though. 
>> 
>> I calculated difference between the received timestamps and converted 
>> that to frequency. Data1 shows the result. You can see that most of the 
>> data come with frequency between 58 and 62Hz, which is +-3% around the 
>> defined periodic frequency. It is not great, but sufficient for now. Then 
>> every half second you get a timestamp at 56.6/64Hz (that is +-6% which is 
>> not acceptable precision). 
>> 
>> At T=~80sec I plugged in GX3 and you can see that the frequency of 
>> timestamps starts to oscillate. Not much, but it definitely observable. 
>> 
>> 
>> Test 2: -> data2.png 
>>  GX3, 60Hz periodic frequency. GX3 configured to output attitude data 
>> @125Hz which is slightly higher, but its only effect is a higher load on 
>> CPU. See data2 
>> Most of the time the measured frequency is right 60Hz, but every 250ms 
>> the loop gets delayed (you can see the frequency drops to 58Hz and then 
>> jumps to 62Hz (probably the next loop is somehow faster). 
>> 
>> So at lower frequencies everything works just fine. 
>> 
>> 
>> Test3 -> data3a.png and data3b.png 
>> GX3, 500Hz periodic frequency, GX3 @500Hz. 
>> 
>> Now the things starts to be messy. You can see that the system frequency 
>> is all over the place, and there is some periodicity in the behaviour. The 
>> mean is still 500Hz, but the actual frequency is between 400Hz and 600Hz. 
>> 
>> Test4 -> data4.png 
>> Aspirin @500Hz, basically the same behaviour as with GX3. 
>> 
>> Since the problem with timing is the same with Aspirin as with GX3, it 
>> probably wont be UART/SPI drivers/isr routines. 
>> 
>> Any idea which other part of code could delay the loop like that? 
>> 
>> Cheers 
>> M 
>> 
>> 
>> On Wed, Aug 21, 2013 at 2:34 AM, Felix Ruess <address@hidden>wrote: 
>> 
>>> Hi Michal, 
>>> 
>>> That's rather bad... I don't have any timing problems here, but then I'm 
>>> not blowing heaps of data through UART... 
>>> You can also use the sys_mon module [1] to check if the timing of your 
>>> main periodic is ok. 
>>> The priorities should probably be configurable.... can you make some 
>>> tests if this helps or if it is something else? 
>>> 
>>> [1] http://paparazzi.enac.fr/wiki/Module/System_monitor 
>>> 
>>> Cheers, Felix 
>>> 
>>> 
>>> On Wed, Aug 21, 2013 at 1:02 AM, Michal Podhradsky < 
>>> address@hidden> wrote: 
>>> 
>>>> Hi all, 
>>>> 
>>>> I have a question about timing on Lia 1.1 (stm32f1). I recently noticed 
>>>> that the timing on the MCU is not solid. 
>>>> I made a simple module with a periodic function which toggles an LED, 
>>>> ran it at PERIODIC_FREQUENCY and then plugged in a scope to see if the LED 
>>>> switching has a constant frequency. 
>>>> 
>>>> I am using PERIODIC_FREQUENCY=512Hz, and the frequency moves around 
>>>> 30%, and occasionally bounces down to ~300Hz. If necessary, I can post 
>>>> video from the scope if needed. 
>>>> 
>>>> Seems to be caused by interrupt priorities (e.g. excessive traffic on 
>>>> one of the UARTS can delay the main loop etc). The function 
>>>> nvic_set_priority() which mentioned Esden is used (master) only on a few 
>>>> peripherals (i2c, spi, adc, ppm), most often setting the priority to 0. 
>>>> 
>>>> According to Cortex M3 programming manual, "*If software does not 
>>>> configure any priorities, then all exceptions with a configurable priority 
>>>> have a priority of 0.*" 
>>>> if all the configurable interrupts have the same (highest) priority, 
>>>> then there is no way to move the more important interrupts (e.g. UART with 
>>>> lots of data coming through) any higher. 
>>>> 
>>>> The possible solution seems to be to set explicitly isr priority on 
>>>> each peripheral (maybe an issue for github?). 
>>>> 
>>>> What do you think of that? Did you have similar issues with the timing? 
>>>> 
>>>> Regards 
>>>> M 
>>>> 
>>>> 
>>>> 
>>>> On Mon, Apr 22, 2013 at 10:14 AM, Michal Podhradsky < 
>>>> address@hidden> wrote: 
>>>> 
>>>>> Hi Esden, 
>>>>> 
>>>>> thanks for clarification! 
>>>>> 
>>>>> M 
>>>>> 
>>>>> 
>>>>> On Fri, Apr 19, 2013 at 4:01 PM, Piotr Esden-Tempski < 
>>>>> address@hidden> wrote: 
>>>>> 
>>>>>> Hi Michal, 
>>>>>> 
>>>>>> I think you are mistaking the vector table slot numbers there for 
>>>>>> priorities. These are the positions of the function pointers inside the 
>>>>>> vector table. If you change those numbers then things will obviously 
>>>>>> explode. 
>>>>>> 
>>>>>> (just for reference, here the defines get their weak functions 
>>>>>> assigned: sw/ext/libopencm3/lib/stm32/f1/vector_nvic.c, and here the 
>>>>>> vector 
>>>>>> is being put together: sw/ext/libopencm3/lib/cm3/vector.c) 
>>>>>> 
>>>>>> IRQ priorities are set using the NVIC_IPR register, or using 
>>>>>> nvic_set_priority function. 
>>>>>> 
>>>>>> I hope this helps. 
>>>>>> 
>>>>>> Cheers Esden 
>>>>>> 
>>>>>> P.S. both files nvic.h and vector_nvic.c are generated using the 
>>>>>> sw/ext/libopencm3/scripts/irq2nvic_h from 
>>>>>> sw/ext/libopencm3/include/libopencm3/stm32/f1/irq.yaml so you should not 
>>>>>> edit those files by hand. 
>>>>>> 
>>>>>> On Apr 19, 2013, at 2:12 PM, Michal Podhradsky < 
>>>>>> address@hidden> wrote: 
>>>>>> 
>>>>>> > Hi folks, 
>>>>>> > 
>>>>>> > I have a question about interrupt priorities for STM32F1 chip (Lia 
>>>>>> 1.1/Lisa_M 2.0). 
>>>>>> > 
>>>>>> > In sw/ext/libopencm3/include/libopencm3/stm32/f1/nvic.h are defined 
>>>>>> priorities for user interrupts. However, if I try to change the priority 
>>>>>> for example for NVIC_USART2_IRQ (let's say make it higher priority than 
>>>>>> NVIC_USART1_IRQ), the  code compiles, but then the program hangs up 
>>>>>> instantly in usart_isr interrupt routine (debugged with JTAG). 
>>>>>> > 
>>>>>> > Can the priorities be set somewhere else or is it a feature to have 
>>>>>> "hardcoded" priorities? 
>>>>>> > 
>>>>>> > Thanks 
>>>>>> > Michal 
>>>>>> > _______________________________________________ 
>>>>>> > Paparazzi-devel mailing list 
>>>>>> > address@hidden 
>>>>>> > https://lists.nongnu.org/mailman/listinfo/paparazzi-devel 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ 
>>>>>> Paparazzi-devel mailing list 
>>>>>> address@hidden 
>>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________ 
>>>> Paparazzi-devel mailing list 
>>>> address@hidden 
>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel 
>>>> 
>>>> 
>>> 
>>> _______________________________________________ 
>>> Paparazzi-devel mailing list 
>>> address@hidden 
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel 
>>> 
>>> 
>> 
>> _______________________________________________ 
>> Paparazzi-devel mailing list 
>> address@hidden 
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel 
>> 
>> 
> 
> _______________________________________________ 
> Paparazzi-devel mailing list 
> address@hidden 
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel 
> 
> 

--- Select 'Retrieve' in options menu to retrieve whole e-mail ---