RTOS, Lib-Funktionen schützen?

[Stephan (Gast)]

Hallo Leute,

ich hab beim stöbern auf http://www.koders.com was interessantes für 
mich gefunden.

"memb.h"
"memb.c" <- ist im Anhang

ich würde gerne dieses Konzept für mich in ähnlicher Version nutzen 
wollen.
Das ist das Beispiel im c-File:

 #include "memb.h"
 
 MEMB(cmem, 20, 8);

 int main(int argc, char *argv[]) {
    char *ptr;
    
    memb_init(&cmem);

    ptr = memb_alloc(&cmem);

    if(ptr != NULL) {
       do_something(ptr);
    } else {
       printf("Could not allocate memory.\n");
    }

    if(memb_free(&cmem, ptr) == 0) {
       printf("Deallocation succeeded.\n");
    }
 }

Jetzt zu meiner Frage:
wie kann ich diese Lib. für ein RTOS sicher machen??? (FreeRTOS)
Da alle Funktionen auf den gleichen Speicher zugreifen ist das etwas 
schwieriger für mich!

einzelne Funktionen und Anweisungen schütze ich so:

taskENTER_CRITICAL();
:
code
:
taskEXIT_CRITICAL();

Meine Überlegung war das ich in jeder Funktion mir den gemeinsam 
genutzen Speicher per Bin-Semaphor reserviere und das darüber steuere.
Aber ich glaub es gibt bestimmt einen besseren weg, oder?

mfg
Stephan

[Dirk (Gast)]

In FreeRTOS selber wird das im 3. Beispiel ganz simpel so gemacht:

#include <stdlib.h>

#include "FreeRTOS.h"
#include "task.h"

/*-----------------------------------------------------------*/

void *pvPortMalloc( size_t xWantedSize )
{
void *pvReturn;

  vTaskSuspendAll();
  {
    pvReturn = malloc( xWantedSize );
  }
  xTaskResumeAll();

  return pvReturn;
}
/*-----------------------------------------------------------*/

void vPortFree( void *pv )
{
  if( pv )
  {
    vTaskSuspendAll();
    {
      free( pv );
    }
    xTaskResumeAll();
  }
}

Ich würde das an Deiner Stelle auch so machen. Wenn Du mehr Speed 
brauchst, solltest Du die Speicherverwaltung eh an Deine Bedürfnisse 
anpassen.

[aha (Gast)]

Das Verwalten von Speicher ist als Resource zu betrachten und mit einer 
Semaphore zu schuetzen. Viele Leute vermeiden deshalb auch dynamisches 
Memory und arbeiten mit fest allozierten Strukturen.

[tuppes (Gast)]

Alle Tasks suspendieren und wieder loslassen kann teuer werden, je 
nachdem, wie viele Tasks da sind.

Es wird schneller sein, vorübergehend die globale Interrupt-Freigabe 
wegzunehmen - dann wird man auch nicht mehr unterbrochen.

Man muss dann wohl damit leben, dass alle Interrupts für einen kurzen 
Moment ausgebremst sind - wenn die Applikation das erträgt, ist es 
vielleicht das kleinere Übel.

Noch eine Alternative: Nur den Interrupt des RTOS-Timers sperren, die 
anderen weiterlaufen lassen. Konsequenz: Man verpasst eventuell einen 
Timertick, und die Uhr geht nach.

Die Moral von der Geschicht: Es gibt kein Patentrezept. Es gibt mehrere 
Wege, man muss den wählen, der den kleinsten Schaden anrichtet.

[(prx) A. K. (prx)]

tuppes wrote:

> Alle Tasks suspendieren und wieder loslassen kann teuer werden, je
> nachdem, wie viele Tasks da sind.

Der Name des API täuscht. Er schaltet lediglich den Scheduler ab.