Speicherplatz freigeben?

Hallo,

das würde mich mal auch interessieren.

Das mit dem Zeiger ist ja klar, aber wie macht man daß bei
einer Interruptroutine ?
Die ruft der Prozessor ja selber auf; da kann ich nichts übergeben.

Wie kriegt man also eine Verbindung zwischen der Variablen der ISR und
der einen lokalen Funktion ?

Ich wüßte auf die schnelle keinen praktikablen Weg.

Jogibär

> Das mit dem Zeiger ist ja klar, aber wie macht man daß bei
> einer Interruptroutine ?
> Die ruft der Prozessor ja selber auf; da kann ich nichts übergeben.

Ohne eine globale Variable kommst du da nicht weg.
Aber die globale Variable kann ein Pointer sein, welcher
dann auf die eigentlichen Daten zeigt.

struct MeineDaten
{
  int MemberA;
  int MemberB;
  char Buffer[200];
  unsigned char Image[400];
};

volatile struct MeineDaten* pData;

ISR( was_auch_immer_vect )
{
  if( pData ) {
    // mach was mit den Daten
    pData->MemberA = 5;
    pData->MemberB = 8;
  }
}

void foo()
{
  struct MeineDaten Data;

  // die lokalen Variablen für die ISR bereitstellen

  pData = &Data;

  //
  // so , jetzt kann die ISR arbeiten
  //

  // funktion wird verlassen, die ISR wieder von den
  // Daten abklemmen
  pData = NULL;
}

int main()
{
   .....
   foo();

   while( 1 );
}

> Ein erster Schritt benötigt eine Anzahl Variabeln
> (insbesondere Arrays), die später nicht mehr benötigt werden und
> nur viel Platz wegnehmen.

Genau diese Aufgabenstellung ist die Grundidee hinter einer
union:

* Ein Programm läuft in Abschnitten ab.
* Jeder Abschnitt hat seine eigenen Variablen, die nur in diesem
  Abschnitt gebraucht werden
* Ausserhalb des Abschnittes sind die Variablen nutzlos und liegen
  nur im Speicher rum
* Mittels einer union kann vereinbart werden, dass die Variablen
  mehrerer Abschnitte quasi übereinandergelegt werden sollen und
  damit verschiedene Abschnitte immer denselben Speicher benutzen.

> Ehrlich gesagt weiß ich auch nicht, wieviel genau die
> Speicherverwaltung kostet.

10 Bytes statischen RAM-Verbrauch, sowie 2 Bytes RAM
zusätzlich pro alloziertem Block, um die Größe dieses Blocks
aufzuzeichnen.  1-Byte-Blöcke werden auf 2 Bytes aufgerundet.

542 Bytes Code auf den ,kleinen' Prozessoren (die kein MOVW
und MUL haben), 498 Bytes Code auf den großen Prozessoren.

Also vielleicht nicht gerade sinnvoll für einen ATtiny2313 :),
ab einem ATmega8 kann man drüber nachdenken, ab einem ATmega32
interessiert der Ressourcenverbrauch wohl kaum noch, da bleibt
dann nur noch die Frage nach den möglichen Auswirkungen der
Speicherfragmentierung.  Da es im Thread um Bildverarbeitung
geht, wird es wohl nicht gerade der allerkleinste AVR sein.

Kleiner Tip:
Mittels Makros hat sich schon so mancher so manchen
Schreibaufwand eingespart.

#define VARIABLE  union.struct.variable

und schon wird aus einem

   union.struct.variable = 5;

ein simples

   VARIABLE = 5;

Nutze die Macht, Luke. Äh, mr. chip

> und ich weiss nicht, wie
> schnell da der Zugriff intern gehandhabt wird.

Da beim Zugriff alles statisch ist, und der Compiler
die Adressen ausrechnen kann, kannst du mal davon ausgehen
dass er das auch tun wird.

Exakt

> Mit unions funktioniert das ganze eigentlich am besten - besser als
> mit malloc() und free(), denn hier müsste jede einzelne Variable
> angefordert und wieder entfernt werden,

Ist eine Frage der Lebenszeit.  Wenn die Variablen alle praktisch
immer leben, dann sind die unions sicher am besten.  Wenn du eine
stochastische Verteilung der Lebensdauer hast, belegst du bei der
malloc()-Variante halt nur den Speicher, den du gerade brauchst.

> Ich denke, dies ist auf einem kleinen Mikrocontroller bei derart
> speicherintensiven Anwendungen auch die Regel - man muss jedes
> einzelne Byte genau einteilen, sonst hat das wüste Folgen...

Würde ich so nicht ganz stehen lassen.  Stochastik kann ebenfalls gut
funktionieren, auch wenn es auf den ersten Blick wie Chaos aussieht.

Die Diskussion erinnert mich an den Streit, was das bessere
Vernetzungsprinzip ist: die ,,reine Lehre'' besteht darauf, dass
jeder
nur dann senden kann, wenn er ,,dran'' ist.  Zu diesem Zweck wird
ein
Staffelstab herumgereicht, der jeder Station sagt, wann sie dran ist.
Wenn sie nichts zu senden hat, gibt sie diesen weiter.

Die Alternative ist, dass jeder sendet, ,,wann er will'', nur zuvor
mal nachsieht, ob nicht vielleicht gerade jemand anders sendet.  In
diesem Fall ,,ein bisschen'' wartet.

Das erste nennt sich `token ring', das zweite `Ethernet'.
Mittlerweile dürfte ziemlich klar sein, wer der Gewinner dieses
Streits war.

Mit dem Speicher ist das ganz genauso.  Die Stochastik hat natürlich
ihre Grenzen: bei ,Verstopfung' ist das jeweilige deterministische
System zuverlässiger.  Der Tote Ring erreicht gleichmäßige
Übertragungsraten auch noch kurz vor der Sättigung, während Ethernet
in diesem Bereich durch die häufigen retries einbricht.  Wenn dein
Speicher also bis zum letzten Byte ausgereizt ist, wird die Stochastik
nicht mehr gut funktionieren, weil immer häufig der Zustand `out of
memory' zuschlägt.