|
Anzeige
|
Restspeicher im µC "erkennen"
Gast
#555514
Hi, gibts eine Funktion, mit der man feststellen kann, wieviel RAM noch im µC (hier der c164 ) frei ist? Oder geht es nur wenn ich solange malloce bis ich nen fehler bekomme, und das alloziierte zusammenrechne? thnx
Gast
#555544
Der Speichermechanismus verwaltet natuerlich das RAM und weiss immer wieviel noch da ist. Wobei die Frage ist was das Wissen drum den Prozess angeht. Hat der Prozess denn eine Alternative zum Malloc()? Wenn er eine Alternative hat, kann er's gleich sein lassen. In der Tat vermeidet man dynamischen Speicher in eingebetteten Systemen von vorne weg. Mit einem passenden Design. Meist muss man ja auch noch irgendwelches Zeitverhalten garantieren. Und das schafft man nicht wenn man im falschen Moment dynamischen Speicher umorganisieren muss.
Gast
#555556
Naja, bei mir wird in embedded c++ Programmiert( :( lä#sst sich bescheiden auf dem c164 debuggen),und da ist new halt an der tagesordnung.
Gast
#555560
Gut, das kann man machen. Und was geschieht wenn kein RAM mehr da ist ? Wartet der Prozess bis wieder welches frei wird ? Super.
Gast
#555569
da sollte man schon genauer wissen wie das jeweilige malloc() oder new() arbeitet, z.B. ob immer grössere Blöcke alloziert werden (um Speicherzerstückelung zu vermeiden) oder ob bytegenau Speicher geholt wird. Dann können viele kleine Allozierungen aber zu viel Verwaltung erzeugen. Und Aufrufe von Funktionen kosten Speicher für Returnadressen und Variablen auf dem Stack, da sollte man bei einem System mit begrenzten Resourcen gut aufpassen.
Gast
#555573
Deshalb benoetigen C++ Systeme auch etwas grosszuegiger bemessenen Speicher. Sobald man eine 32bit Maschine mit ein paar Duzend MByte hat und das Zeitverhalten einen Relayschrank ersetzen soll kann man sich auf solche Abenteuer einlassen. :-) Wo steht geschrieben, daß new immer malloc aufrufen muß ? Wenn die Variablen nur zu Lebzeiten der erzeugenden Funktion gebraucht werden, können sie auch ganz normal auf dem Stack angelegt werden. Es hängt ganz vom Compiler ab, wie er das macht. Peter
Gast
#555587
auch ein paar MB Speicher kann man in Sekundenschnelle zumüllen... Ich würde versuchen an die Verwaltungsvariablen der C-Lib zu kommen wo freie Blöcke oder Bytes mitgezählt werden. > Oder geht es nur wenn ich solange malloce bis > ich nen fehler bekomme, und das alloziierte zusammenrechne? Nein, das ist kein brauchbares Maß, denn das Ergebnis hängt bei Fragmentierung von der Blockgröße ab, mit der man die Testallokationen macht. Wenn Dus genau wissen willst, mußt Du Dir eine Routine schreiben, die die Freiliste des Speicherverwalters abklappert und die Längen addiert. Das Ergebnis ist aber auch nur mehr oder weniger von akademischem Wert...
Gast
#555678
Danke für die Tipps. Hab mir gerade mal die Erweiteruzng für den c++ angesehen, der macht bei new auch nur ein malloc, und wenn es fehlschlägt geht er in ne endlosschleife. Ich hab in die "new-funktion" mal ne LED angeschalten wenn nen problem auftritt, aber daran lags wohl nicht. :( naja. mal weitersehen, hab eigentlich vermutet, das es mit ram zu tun hat, da der Fehler immer so nach 700 durchläufen kam, jedesmal ein objektanlegen und nachher wegwerfen. Ich schau mir mal die andren exceptions an, die der controller hat, vielleich finde ich da was. thnx Sieh mal nach, ob Dein Compiler den newhandler unterstützt - der wird aufgerufen, wenn new keinen freien Speicher mehr findet. Auch wenn Du c++ verwendest ist das kein Grund für eine dynamische Speicheranforderung auf einem embedded System. Bei entsprechendem Design kommst Du ohne new oder malloc aus. Du könntest natürlich ein placement new mit einer eigenen Heap-Verwaltung verwenden. Oder in Deinem Compiler Handbuch nachschlagen welche Methode von new verwendet werden und diese selbst implementieren. (Dann darfst Du natürlich die entsprechenden Teile der Runtime nicht dazu linken). Antwort schreiben |
Anzeige
|
