malloc auf PIC mc

Ist das die Fehlermeldung des Compilers?

Rufus t. Firefly wrote:
> Ist das die Fehlermeldung des Compilers?

Klingts denn so??? ;-)

Das Problem ist, dass ich malloc() nirgends finde.
Habe mal in der stdlib.h geschaut, aber da war sie nicht.

Ja, das klingt so.

  "scheint nicht zu funktionieren"

bedeutetet was vollkommen anderes als

  "scheint dem Compiler nicht bekannt zu sein"

bzw.

  "ich weiß nicht, in welcher Headerdatei das deklariert ist"



Mal ein "suche-in-allen-Dateien" mit "alloc" und "*.h" gemacht?

Mal in die Dokumentation Deines Compilers geschaut?

Mal nach "malloc.h" ausschau gehalten?

malloc() wird's auf dem PIC nicht geben, dazu ist er zu klein.
Wo soll der PIC den dynamischen Speicher hernehmen, wenn er kaum 
Speicher hat?

Mein Problem ist, ich möchte über I2C Ereignisse versenden.
So nach dem Schema:

1B [ID]
1B [LENGTH]
nB [DATA]

wie kann ich nun im Code das jeweilige Ereignis generieren?
Ich weiß ja vorneweg nicht, welches Ereignis eintritt.

Maximale Länge reservieren.

Klaus Falser wrote:
> Maximale Länge reservieren.

hm... wird nicht anders werden.
Wahrscheinlich hätte die Speicherverwaltung hier insgesamt mehr Platz 
weggenommen als nötig...

Schau mal bei Microchip dirket nach. Da gibts ne AppNote:
http://ww1.microchip.com/downloads/en/AppNotes/00914a.pdf

Wenn man mit dynamischer Speicherverwaltung arbeitet, muß sicher 
gestellt sein, daß das Programm deutlich mehr Speicher zur Verfügung 
gestellt bekommt, als es tatsächlich braucht. Einerseits verbraucht die 
Heapverwaltungs selbst einiges, zum anderen muß man mit 
Heapfragmentierung rechnen, die unter ungünstigen Umständen dazu führen 
kann, daß zwar rechnerisch der größte Teil des Speichers frei ist, der 
Heapallocator aber keinen ausreichend großen freien Block finden kann, 
um eine Allokation erfolgreich zu beenden.

Das sind schon ausreichend Gründe, keine dynamische Speicherverwaltung 
für die Winzbüchsen zu implementieren.

Dynamische Speicherverwaltung hat aber einen weiteren, sehr 
schwerwiegenden Nachteil, den man gerne übersieht: Sie ist die Grundlage 
für eine Klasse von Fehlern, die selbst für Experten äußerst harte Nüsse 
darstellen. Stichwort Heapcorruption.

Solche Fehler sind deshalb so schwer zu finden, weil
- es meist ziemlich aussichtslos ist, stabile Testbedingungen
  herzustellen.
- die Auswirkungen von Adressierfehlern u.U. erst sehr viel später
  und an ganz anderer Stelle zu Ausfällen führen, der Kausalzusam-
  menhang zwischen der Fehlerursache und der Auswirkung meist
  nachträglich nicht zu rekonstruieren ist.

Dabei sind weniger die Routinen des Heapmangers das Problem, als der 
Anwendungscode, denn letzterer ist i.d.R. deutlich weniger erprobt, als 
ersterer.

Das Ganze ist ein uneinschätzbares Sicherheitsrisiko - also Finger weg, 
wenn es um irgendwelche Gerätesteuerungen geht, die unter welchen 
Umständen auch immer irgendwo mal das schwächste Glied in einer 
Sicherheitskette sein könnten.

Ob das sein kann, übersieht man als Entwickler häufig nicht, denn Homo 
sapiens sapiens neigt dazu, alles mögliche zu Zwecken zu gebrauchen, für 
die es nicht vorgesehen war und vor Gericht und auf Hoher See ist man 
bekanntlich in der Hand eines Herren, den es garnicht gibt...