Hallo ich versucche mit einem Mega32 in Messschleifen Werte von einem AD-Wandler einzulesen und dann per qsort den Median zu berechnen. Die Werte sind unsigned int (0-65535). Bei einem unsigned int Array[300] geht das wunderbar. Ab 450 Werten macht der Prozessor undefinierte Sachen... Komme ich da an die Grenze des RAM? Ist doch beim Mega32 2kB oder? Beim kompilieren sagt er mir nur 7% Data belegt und 500x2Byte =1kb?
Gast
#1344542
Sieh Dir vom Linker die Liste an, wie der RAM Speicher verwendet wird. Im RAM befinden sich ja auch der Stack und andere Variablen (weitere arrays).
ist das mit den 2kb richtig? hab grad gesehen, das der Array 2x im Programm vorkommt und dann wär ich doch bei 2kB... mit noch reslichen Variablen macht es dann Sinn, wenn er zwischen 450 -500 Probleme macht. Kann man sich davor nicht durch den Compiler schützen lassen? Bzw kann ich das ganze intelligenter lösen?
Gast
#1344554
>Bzw kann ich das ganze intelligenter lösen?
Dazu kenne ich Dich zu wenig :-)
Es ginge ein anderer µC mit mehr RAM (mega644 o.ä.) oder Du verwendest
nur ein Array, daß dynamisch belegt wird.
Jörn Ahrens schrieb: > ist das mit den 2kb richtig? Steht alles im Datenblatt > Kann man sich davor nicht durch den Compiler schützen lassen? Bzw kann > ich das ganze intelligenter lösen? Dazu müsste man dein Programm sehen. Wenn deine Memory Belegung allerdings meint du hättest nur 7% belegt und das kommt selbst dir spanisch vor, dann sollte man sich mal das Programm ansehen.
also die 7% enstehen durch die globalen Variablen. der Array war aber in einem anderen c-file jeweils in der Funktion deklariert und initialisiert worden.... Sofern ich diesen als Global einführe, komme ich dann auch auf die 103% Data auslastung...
Jörn Ahrens schrieb: > also die 7% enstehen durch die globalen Variablen. der Array war aber in > einem anderen c-file jeweils in der Funktion deklariert und > initialisiert worden.... Ah. Also eine funktionslokale Variable > Sofern ich diesen als Global einführe, komme > ich dann auch auf die 103% Data auslastung... Und damit weißt du dann auch, was das Problem ist.
> Kann man sich davor nicht durch den Compiler schützen lassen?
Nein.
Der Compiler weiß ja nicht in welcher Reihenfolge welche Funktionen wie
aufgerufen werden. Dazu müsste er einen Testlauf simulieren um
rausfinden zu können, wieviel Speicher das Programm dann letztendlich
zur Laufzeit belegt.
Solange diese künstliche Intelligenz aber nicht vorhanden ist, kannst du
nach der Heuristik vorgehen: Größere Speicherallokierungen nicht als
funktionslokale Variablen ausführen, sondern modulglobal (also mit
static im File) oder überhaupt global (auch wenn das Zähneknirschen
verursacht). Nur dann hast du eine Chance, dass die Memory-Statistik zum
Schluss wenigstens in etwa dem tatsächlichen Speicherverbrauch
entspricht.
ok vielen Dank. werde ich testen