Hallo zusammen, weiß jemand wie ich auf einem PIC mit dem C18-Compiler dynamisch Speicher anfordern und freigeben kann? malloc() scheint nicht zu funktionieren...
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.
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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.