Hi Leute, wie kann man im AVR Studio den SRAM auslesen? Ich debugge mit nem ICE MKII. Im AVR Studio gibt es ein Memory Window. Dort finde ich aber nichts zum "SRAM"... Mein eigentliches Problem ist aber, dass ich gerne wissen würde, ob der SRAM voll ist oder nicht! Wenn ja, was passiert wenn er voll ist? Explosion?
Johann schrieb: > Im AVR Studio gibt es ein Memory Window. Und was stört dich daran? Dass kein "SRAM" dransteht? Ein Fahrrad fährt auch dann, wenn auf dem Reifen nicht "Reifen" draufsteht.
Da fallen den alle Daten aus dem AVR heraus und machen eine große Sauerei auf dem Tisch. Jetzt im Ernst. Im Studio <View> <Memory> und <Data> (SRAM da Start bei 0060).
Du musst darauf achten die Daten nicht nur zu Schreiben sondern auch zu Lesen dann platzt da auch nichts. duck und wech
>Du musst darauf achten die Daten nicht nur zu Schreiben sondern auch zu >Lesen dann platzt da auch nichts. Und wie macht man das ein software-WOM (write only momory)?
Das ist in Wirklichkeit eine Lizenzsache wieviel das WOM aufnehmen kann, reine Softwarebeschraenkung.
Frankl schrieb: > Im Studio <View> <Memory> und <Data> (SRAM da Start bei > > 0060). Hatte ich mir schon gedacht. Hab jetzt mal geschaut und fast jedes meiner 512 Byte is belegt! Wird SRAM nach benutzen wieder gelöscht? Woran erkenne ich, ob ich "zu wenig" SRAM zur verfügung habe??
Johann schrieb: > Hab jetzt mal geschaut und fast jedes meiner 512 Byte is belegt! Wird > SRAM nach benutzen wieder gelöscht? Nein.
Johann schrieb: > Mein eigentliches Problem ist aber, dass ich gerne wissen würde, ob der > SRAM voll ist oder nicht! Wenn ja, was passiert wenn er voll ist? > Explosion? Wenn das SRAM voll ist, dann verschwindet die Lücke zwischen Heap bzw. globalen Variablen und Stack. Im nächsten Schritt überschreibt dann ein Speicherbereich den anderen und es gibt abstruse Fehler. Das kann passieren, obwohl .data, .bss und .noinit noch ins SRAM passen. Aber leider der Stack, der mit jeder aufgerufenen Funktion wächst, nicht mehr. Hilfreich sind diese Infos: http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc#Nutzung_des_SRAM_durch_avr-gcc Servus Michael
Kann ich denn pauschal davon ausgehen, dass wenn beim kompilieren "Data" rund die 50% voll ist der SRAM nicht überlaufen wird? Oder bringt einem diese Ausgabe gar nichts?
Johann schrieb: > Kann ich denn pauschal davon ausgehen, dass wenn beim kompilieren "Data" > rund die 50% voll ist der SRAM nicht überlaufen wird? Oder bringt einem > diese Ausgabe gar nichts? Eine sichere Aussage ist es nicht, denn über dynamisch beanspruchten Speicher, wie malloc/free oder den Stack, sagt sie nichts aus.
Hi Zu deinem Verständnis: der SRam ist der Arbeitsspeicher deines µC's. Stell dir ein Blatt Papier vor. Oben schreibst du deine Variablen hinein, also dort sind die Speicherzellen, die du als Variablen definiert hast. Z.B. Mein_Counter: .Byte1 Diese Variablen beeinflußt dein Programm, setzt Werte sozusagen. Gelöscht wird da nix. Nun kommt noch der Controller, denn er muß wissen, wo er war, wenn er auf einen Call trifft oder ein Interrupt ihn aus seiner routinemäßigen Arbeit abruft. Dazu hat er einen Stack. Das ist der Bereich auf deinem Blatt Papier von unten. Dort merkt er sich seine Rücksprungadressen und alles, was ihm per Push zum Merken notwendig erscheint. Dbei setzt er einfach seinen Adresszeiger auf die entsprechende Speicherstelle und trägt dort etwas ein. So bei einem Call die nächste routinemäßige Programmadresse, bei einem Push den Inhalt eines Registers. Findet er ein Ret (Rücksprung aus Unterprogramm, so holt er sich den Wert aus dem Stack, so nennt man dden Speicherbereich, und adressiert seinen Programm- oder Befehlszeiger mit diesem Wert. Ein Pop trägt den Wert vom Stack in das entsprechende Register ein. Danach wird der Stackzeiger entsrechend aktualisiert, also hochgesetzt. Man kann also sagen, die Variablen füllen den Speicher von unten und der Stack von oben abwärts. Hast du viele Variablen, so bleibt wenig für den Stack übrig, denn wenn der Controller einen Call sieht, beschreibt er gnadenlos den Stack. und setzt den Zeiger nach unten. Im schlimmsten Fall überschreibt der Stack den Variablenspeicher. Wenn du bspw. einen Interrupt hast, der sich innerhalb seiner Routine wieder aufruft, oder einen Call, der innerhalb des UP's wieder sich selbst aufruft, hast du nullkommanix den Stach im Variablenbereich und dein Controller läuft ins Nirwana. Übrigends, gelöscht wird gar nix, lediglich der Flashvor einer Neuprogrammierung mit einem Default-Wert geladen ( idR mit 255 dez oder FF hex.) Manche sagen, das Programm ist gelöscht. Ja, das Programm, aber nicht der Speicher... Gruß oldmax
Thread beobachten
Seitenaufteilung abschaltenBitte 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.