FreeRTOS PIC32 Scheduling Zeiten

Wenigstens ne Größenordnung wäre gut...

???

FreeRTOS Organisation verbietet alle Messungen und Vergleiche 
publizieren. Ganz anders ist das bei ChibiOS, dort ist alles publiziert. 
Leider ist PIC32 (MIPS) Architektur nicht (offiziell) unterstützt.
http://www.chibios.org/dokuwiki/doku.php?id=chibios:metrics

Vielleicht hier:
http://alexandria.tue.nl/extra2/afstversl/wsk-i/xu2008.pdf

@Harry:

Als größenordung ist das schonmal super (bei dem STM32 werden 
anscheinend zeiten um die 1us erreicht)...

Eine Task welche zyklisch alle 100us aufgerufen werden soll kann ich mit 
freertos trotzdem nicht realisieren da man sonst die "Tick-Frequenz" zu 
hoch (min 10kHz) setzten muss und das wohl zuviel perfomance frisst...

Zitat von freeRTOS.org
The tick interrupt is used to measure time. Therefore a higher tick 
frequency means time can be measured to a higher resolution. However, a 
high tick frequency also means that the kernel will use more CPU time so 
be less efficient. The RTOS demo applications all use a tick rate of 
1000Hz. This is used to test the kernel and is higher than would 
normally be required.

Was meint ihr dazu??

Ich will einen stromregler bauen (soll irgendwann mal ein dc servomotor 
Kontrolle werden)

Dabei weiß ich gar nicht ob 100 us überhaupt ausreichen.... Aber naja 
will es einfach mal ausprobieren....

Ob das mit freertos So funktioniert muss ich mal schauen aber So die 
Idee klingt ganz gut.... Hab immer gedacht ich muss den zyklischen 
Aufruf über die ticks machen...

Gruß
Andi

Hallo,

ich arbeite jetzt seit  2 Jahren mit FreeRTOS auf dem AT91SAM7.
Wo es nötig war, habe ich mit 1000Hz Schedulertick gearbeitet. Die Clock 
vom AT91 lag bei 48MHz.
Wenn man sich den SchedulerInterrupt anschaut:

  void vPreemptiveTick( void )
  {
    /* Save the context of the current task. */
    portSAVE_CONTEXT();
    showCurrent(0);
    /* Increment the tick count - this may wake a task. */
    vTaskIncrementTick();

    /* Find the highest priority task that is ready to run. */
    vTaskSwitchContext();

    /* End the interrupt in the AIC. */
    AT91C_BASE_AIC->AIC_EOICR = AT91C_BASE_PITC->PITC_PIVR;;

    portRESTORE_CONTEXT();
  }

so wird mehr Zeit in der ISR verschwendet.
Jedoch habe ich die Erfahrung gemacht, das beim AT91 noch jede Menge
Rechenzeit üprig ist.
Ich habe beispielsweise einen PID Regler mit floatingpoint emulation bei 
1ms Wiederholrate laufen und eine bei 10ms. Die niedriger priorisierten
Tasks kommen alle noch in Ausführung.
Aber es kommt halt darauf an, was man machen will.

Grüße
netseal

also ich habe mir gerade das Beispiel vom PIC32 angeschaut.

Dort wird der Tick Interrupt auf Prio 1 gesetzt. Dann wird ein UART 
Interrupt auf PRIO 2 gesetzt. Dieser kann folglich den Tick Interrupt 
unterbrechen...

Desweiter wird im Beispiel ein "High Frequ." Interrupt auf Prio 4 
gesetzt. Dieser hat die Höchste Prio und kann somit nicht unterbochen 
werden.

Hier der Orginaltext ausm Beispiel:
"
* By way of demonstration, the demo application defines
 * configMAX_SYSCALL_INTERRUPT_PRIORITY to be 3, 
configKERNEL_INTERRUPT_PRIORITY
 * to be 1, and all other interrupts as follows:
 *
 *  + The UART is allocated a priority of 2. This means it can interrupt 
the
 *    RTOS tick, and can also safely use queues.
 *  + Two timers are configured to generate interrupts just to test the 
nesting
 *    and queue access mechanisms. These timers are allocated priorities 
2 and 3
 *    respectively. Even though they both access the same two queues, 
the
 *    priority 3 interrupt can safely interrupt the priority 2 
interrupt. Both
 *    can interrupt the RTOS tick.
 *  + Finally a high frequency timer interrupt is configured to use 
priority 4 -
 *    therefore kernel activity will never prevent the high frequency 
timer from
 *    executing immediately that the interrupt is raised (within the 
limitations
 *    of the hardware itself). It would not be safe to access a queue 
from this
 *    interrupt as it is above configMAX_SYSCALL_INTERRUPT_PRIORITY. "

Gruß
Andi