Controller alloziert keinen Speicher

[Christian (Gast)]

Hallo zusammen,

auf einem ATMega 128 brauche ich die Datenstruktur einer Warteschlange. 
Dafür habe ich eine Funktion zum hinzufügen eines Knotens. Der Funktion 
wird der Inhalt des Knoten (Q_datentyp e) sowie die eigentliche 
Warteschlange (queue *q) übergeben. Rufe ich nun die Funktion auf (ohne 
Compiler Errors) geht die IF-Abfrage immer in den ELSE-Teil. Unter Linux 
funktioniert die Funktion und die ganze Warteschlange einwandfrei.

int q_enqueue( Q_datentyp e, queue *q )  {
    q_knoten *neu = (q_knoten*)malloc(sizeof(q_knoten));
    if(neu != NULL) {
        neu->q_daten = e;
        if(!q_empty(*q)) {
            neu->next = q->head;
            q->head = neu;
        } else {
            q->head = neu;
            q->tail = neu;
        }
        return 1;
    } else {
        return 0;
    }
}

Hat vlt. jemand eine Idee woran das liegt? Als Compiler nutze ich den 
von CodeVision.

[Peter (Gast)]

Christian schrieb:
> jemand eine Idee woran das liegt?

das der atmel zu wenig freien speicher hat - kann ich mir vorstellen. 
Das wird wohl auch der Grund sein warum kaum jemand ersthaft malloc auf 
einem Atmel haben will.

[Christian (Gast)]

Peter schrieb:
> Christian schrieb:
>> jemand eine Idee woran das liegt?
>
> das der atmel zu wenig freien speicher hat - kann ich mir vorstellen.
> Das wird wohl auch der Grund sein warum kaum jemand ersthaft malloc auf
> einem Atmel haben will.

Das kann ich mir nicht vorstellen. Momentan initialisiert das Programm 
nur eine Hand voll Variablen. Bei einem anderen Projekt auf einem ATMega 
644 lief die Warteschlange problemlos. Da wurden auch wesentlich mehr 
Variablen genutzt und das ganze allerdings mit WinAVR compiliert.

[tom (Gast)]

...autsch, dynamische Speicherverwaltung auf einem kleinen uC, davon 
würde ich erstmal schon prinzipiell abraten !
Überlege Dir eine statische Lösung, wie z.B. einen Ringpuffer o.ä.

gruss, tom.

[Christian (Gast)]

tom schrieb:
> ...autsch, dynamische Speicherverwaltung auf einem kleinen uC, davon
> würde ich erstmal schon prinzipiell abraten !
> ...
> gruss, tom.


Was spricht denn dagegen? Ich habe Daten mit unterschiedlicher Länge und 
mit einem Array würde ich mehr Platz im RAM verschwenden als mit den 
paar Zeilen Code. Und wie schon erwähnt, auf einem ATMega 644 lief es 
einwandfrei.

[Purzel H. (hacky)]

Dynamischer Speicher ist etwas was man in Controllern generell 
vermeidet. Denn sonst muss man sich an einem idiotischen Ort im Programm 
darum kuemmern was geschehen soll wenn es keinen Freien mehr hat. Zudem 
ist die Zeit zur Allokation nicht konstant.

[Karl H. (kbuchegg)]

Christian schrieb:

> Was spricht denn dagegen?

Das du in Summe weniger Platz zur Verfügung hast als wie wenn du 
statisch allokierst. Und wenn du nur heftig genug allokierst und wieder 
freigibst, dann schlägt dir die Speicherfragmentierung ein Schnippchen.
Rein rechnerisch hast du zb 500 Bytes frei und trotzdem kriegst du eine 
läppische Speicheranforderung mit 50 Bytes nicht mehr durch.

> Ich habe Daten mit unterschiedlicher Länge und
> mit einem Array würde ich mehr Platz im RAM verschwenden als mit den
> paar Zeilen Code.

1) Das genaue Gegenteil ist der Fall
2) Und? Kriegst du von Atmel für nicht benutzten Speicher Geld zurück?


> Rufe ich nun die Funktion auf (ohne
> Compiler Errors) geht die IF-Abfrage immer in den ELSE-Teil.

du hast 2 if und 2 else.
Also: Welches?

>    if(neu != NULL) {

dann wird dir wohl malloc keinen Speicher mehr besorgen können

>        if(!q_empty(*q)) {

dann musst du rausfinden, warum q_empty deine queue immer als leer 
ansieht

[Christian (Gast)]

Karl heinz Buchegger schrieb:
> du hast 2 if und 2 else.
> Also: Welches?

das erste if

if(neu != NULL)

 schlägt fehl.

Mir ist eingefallen das ich mir die Fusebits nicht angeguckt haben. 
Könnte es daran scheitern oder an der Optimierung des Compilers? Daran 
das kein Platz ist glaube ich nicht, denn ich habe in dem ganzen 
Programm keine zehn Variablen deklariert.

[Olaf (Gast)]

> Daran das kein Platz ist glaube ich nicht,

Warum willst du glauben? Das hat doch schoen bei Goettern nicht 
funktioniert. Lass dir von deinem Compiler ein mapfile erzeugen
und schaue nach wie gross deine Variablen sind und wo der Stack liegt
und noch interessanter wo malloc seinen heap hat.

Olaf

p.s: Auch ich denke das es unklug ist malloc zu benutzen. .-)

[tom (Gast)]

@Christian

...nichts für ungut, niemand hat die Absicht Dir Dein Designkonzept 
auszureden, wirklich nicht.
Die aufgeführten Gründe sind aber real vorhanden und die pure+reine 
Informatik trifft auf die reale raue und asketisch-spartanische Welt der 
embedded Systeme g.

Also, wenn es auf einem atmega644 funzt und Du das auf einem 128'er zum 
Leben erwecken willst: "So gehe er dann hin, benütze den gleichen 
Compiler und modifiziere das originale Makefile für seine 128'er Zwecke 
!".
So sprach der König und murmelte nachdenklich in seinen Bart - "Geh Zeh 
Zeh" - welch seltsame Aufforderung.

Gutt Lack und Gute Nacht, all Euch kleinen Bits, Beits und Müh-Zehs !