FreeRTOS PIC32 Scheduling Zeiten

[Andi (Gast)]

Hallo,

ich würde gerne mal das FreeRTOS (http://www.freertos.org/) auf einem 
PIC32 (MX7 baureihe) einbetten.

Meine Frage ist wie lange der scheduler zur Taskumschaltung braucht.

Ich betriebe den PIC mit interner PLL auf der maximalen Taktrate von 
80MHz.

Gruß
Andi

[Purzel H. (hacky)]

Die Anzahl befehle fuer einen Taskwechsel sollte sich doch am Sorcecode 
abzaehlen lassen.

[Andi (Gast)]

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

[Andi (Gast)]

???

[A. B. (funky)]

hat mich auch interessiert, aber habe nix gefunden.
da FreeRtos auch relativ viele Architekturen unterstützt wird man das 
wohl mal selber messen müssen. Auf der Homepage hab ich zumindest nix 
gefunden.
In irgendner Masterarbeit hat jemand Benchmarks gemacht, aber das war 
für irgendwelche anderen Architekturen...also sicher nicht wirklich 
vergleichbar

[Harry (Gast)]

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

[Harry (Gast)]

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

[A. B. (funky)]

genau die Masterarbeit meinte ich auch :D

[Andi (Gast)]

@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??

[A. B. (funky)]

du kannst aber sicherlich einen Timer setzen welcher alle 100us 
aufgerufen wird, und dieser generiert dann ein signal an einen wartenden 
task welcher vom scheduler aufgerufen wird.
Was musst du denn alle 100u machen?


Zumindest bei Keil RTX geht das so, und FreeRTOS bietet sicher auch 
solche Möglichkeiten. Wobei ich jetzt nicht weiss, was man bei externen 
IRQs und FreeRtos beachten muss. RTX lässt externe IRQs zu und 
deaktiviert sie nicht...kann bei einem anderem RTOS aber anders gelöst 
sein

[Andi (Gast)]

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

[netseal (Gast)]

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

[Andi (Gast)]

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