Hallo, ich bin gerade dabei auf einem CortexM4 (STM-Discoveryboard) eine C lib zu portieren, die ursprünglich für PC geschrieben wurde. Ich benutzte die newlib/nanolib + floatingpoint printf und scanf Unterstützung. Da diese lib mit Dateien umgeht, habe ich in die syscalls einen eigenen kleinen Dateihandler geschrieben. Das funktioniert auch soweit ganz gut, da es sich nur um eine Config-Datei dreht, die dort mit fopen, fread, etc. eingelesen wird. Weiterhin benutzt die lib intensiv dynamischen Speicher mit calloc, malloc, free. Irgendwie bekomme ich hier aber Probleme, da es bei einem calloc irgendwann im Hardfault landet. Jedoch wird davor einiges an calloc ohne Probleme aufgerufen. Ich habe in der syscalls _sbrk schon einiges durchprobiert und debuggt. Der heap auch noch reichen. Den hatte ich zum Test auch erhöht, es bricht dennoch an der selben Stelle ab (Hardfault). Da meine Beschreibung jetzt nicht zu eindeutig ist, habe ich nur ein paar Allgemeine Fragen: 1. Hat jemand einen guten Link wo die syscalls gut anhand des Cortex erläutert werden? Die Newlib Doku finde ich nicht gerade ausführlich. z.B. Obwohl das fread nur 10 Zeichen aus der Datei lesen will, bekomme ich ins syscall _read 1024 Zeichen zum auslesen vorgesetzt. Wird da irgendwo intern was gebuffert? Also, wo könnte man so was nachlesen? 2. Wie soll das mit dem dynamischen Speicher auf dem CortexM überhaupt funktionieren? Mit der minimalen syscalls Implementierung erhalte ich bisher kein free (negatives inc) in die _sbrk... Auch muss doch jeder malloc anschließend sein free ausführen, bevor ein weiteres malloc ausgeführt wird, sonst bekommt die einfach + 100 byte - 100 byte Heapberechnung totale Probleme?! Oder nicht? Es hat keinen wirtschaftlichen Charakter... ich wills einfach nur für mich lernen und habe bisher keine gute Doku gefunden. Danke Stefan
hmmm... habs irgendwie hin bekommen... Habe immer noch das "Problem", dass bei: caddr_t _sbrk(int incr) ich bisher kein negatives incr verzeichnen konnte... Evtl. verwaltet die newlib den nun fragmentierten heap intern selbst oder es geht noch etwas grundlegendes schief.... Aktuell läuft alles wie ich es mir vorstelle... es ist aber mehr durch probieren als durch Wissen entstanden :-/
Ich nutze auch die newlibnano. AllerDings habe ich hierzu kein Hintergrundwissen. Bei mir erledigt das die ide: visualgdb. Vllt kann man dir dort weiterhelfen. Man kann dort zwischen verschiedenen libs wählen.
Die Newlib nutzt _sbrk nur, um Speicher zu alloziieren; die eigentliche Verwaltung davon findet an anderer Stelle in der Newlib statt. Ich wüsste spontan auch nicht, warum der Heap überhaupt verkleinert werden sollte - gibt ja nur eine Anwendung. Streams sind in C normalerweise gepuffert, was die Newlib auch implementiert. Beispielsweise wird stdout nur bei Zeilenumbrüchen (oder vollen Puffern) geflusht. Dein _read() sollte also nur die vorhandenen Daten zurückgeben, und beim nächsten Aufruf dann null (= EOF). Das alles ist unabhängig vom ARM Cortex und gilt so auf beliebigen Architekturen. Im Zweifelsfall musst du in den Code für die Newlib oder die entsprechenden Standards gucken.
@S. R. Erstmal danke für die Info. Okay, wenn mir die Newlib (nano) das alles schon abnimmt, bin ich nicht böse. Dann werde ich mir jetzt keine tieferen Gedanken darüber machen. Es scheint ja soweit zu laufen... VG Stefan
Das traditionalle sbrk() läßt keinen negativen Increment zu. Bei den Ur-Unixen konnten Prozessimages nur größer werden, nicht kleiner. Das war auch gar nicht notwendig, wenn ein Prozeß mal "zuviel" Speicher allokiert hat, der später nicht mehr gebraucht wurde, wurde der halt ausgelagert und landete ungenutzt im Swap. Bei einer Microcontroller-Anwendung ist das natürlich schwierig, wird aber auch gar nicht gebraucht - schließlich sind keine anderen Prozesse da, die sich um den Speicher streiten könnten.
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.