mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega32, AVRstudio und SRAM


Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
moin, moin.
ich habe ein Programm, in dem der SRAM in viele kleine Schnipsel geteilt 
ist. zwei davon sind etwas grösser in dem ich einmal 512byte speicher 
und in einem 980byte speicher. wenn ich diese in der reihenfolge 
vertausche, also erst die 980byte deklariere, geht bei dem programm gar 
nix mehr.
jemand ne idee warum das so ist. muss man immer erst die kleneren 
einheiten im SRAM deklarieren und dann der grösse aufsteigend???
das selbe problem hatte ich bei nem anderen proggi schonmal.
jemand ne idee warum???
gruss fubu

Autor: Marvin M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö, es ist egal, in welcher Reihenfolge Du Dir Deinen Ram 
verschnipselst.
Das hört sich für mich nach einem Stack-Problem an. Überprüfe mal, ob 
der Stack in einen der Ram-Schnipsel hineinreicht.

Autor: Kai Scheddin (zeusosc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei 2k sram würde das ja bedeuten das der stack über 300b groß ist,.. 
heftig,...

zeig mal bitte ein bisschen source,..
grüüße

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
nein am stack liegt es nicht, der wächst nit. nach rcall's kommen immer 
ret's. wennn ich nun die letzten beiden vertausche, also "ROOT_ram" und 
"cluster", dann geht von anfang an nur mist über die bühne. aber so 
gehts, kein plan warum???

grus und vielen dank

;_________________________
;HIER SIND SRAM EINTRÄGE
;------------------------

.dseg
sectors_per_cluster:  .byte 1

.dseg
sectors_per_cluster_end:   .byte 2

.dseg
first_DATA_cluster:  .byte 2

.dseg
next_DATA_cluster:  .byte 2

.dseg
VBR_start:  .byte 4

.dseg
FAT_start:  .byte 4

.dseg
ROOT_start:  .byte 4

.dseg
DATA_start:  .byte 4

.dseg
addresse:   .byte 4

.dseg
CMD:  .byte 6

.dseg
FRAMES_per_second: .byte 1

.dseg
FRAMES_per_second_end:   .byte 4

.dseg
response_save:  .byte 1

.dseg
response_ini:  .byte 2

.dseg
Volume_set:    .byte 1

.dseg
Volume_SCI:     .byte 1

.dseg
TREBBLE_set:    .byte 1

.dseg
BASS_set:    .byte 1

.dseg
GAIN_set:     .byte 1

.dseg
vorspulabfrage:    .byte 1

.dseg
back_taste0:     .byte 1

.dseg
TDA7318_data:      .byte 1

.dseg
response_read:  .byte 2

.dseg
root_counter_ende:  .byte 1

.dseg
root_counter_anfang:  .byte 1

.dseg
byte_speicher:  .byte 1

.dseg
minuten_speicher:  .byte 3

.dseg
sekunden_speicher:   .byte 2

.dseg
MP3_data_length:  .byte 4

.dseg
MP3_data_length_end:   .byte 4

.dseg
ID3_TAG_zeichen:  .byte 20

.dseg
cluster:   .byte 512

.dseg
ROOT_ram:  .byte 980

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal abgesehen davon das es merkwürdig ist: Ist es nicht wurscht wie dein 
speicher aufgeteilt ist?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ fubu1000 (Gast)

>nein am stack liegt es nicht, der wächst nit. nach rcall's kommen immer

Woher weisst du das? Hast du keine verschatelten Funktionsaufrufe?

Die tausend .desg kannst du dir sparen, es reicht ins am Anfang. Dann 
"schaltet" der Assembler in das Datensegment und bleibt dort, bis ein 
anderes Segment über .cseg oder .eseg gewählt wird.

>ret's. wennn ich nun die letzten beiden vertausche, also "ROOT_ram" und
>"cluster", dann geht von anfang an nur mist über die bühne. aber so
>gehts, kein plan warum???

Kann es sein, dass du den Stack nicht RICHTIG initialisiert hast? Der 
hat bei den grossen AVRs ZWEI Register!

    ldi   temp1, LOW(RAMEND)     ; Stackpointer initialisieren
    out   SPL, temp1
    ldi   temp1, HIGH(RAMEND)
    out   SPH, temp1

MFG
Falk

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi Mail@laeubi.de wrote:
> Mal abgesehen davon das es merkwürdig ist: Ist es nicht wurscht wie dein
> speicher aufgeteilt ist?

Nicht ganz. Man reserviert ja kein RAM, um es "zu besitzen", sondern um 
es zu benutzen. Und hier gibt es verschiedene Möglichkeiten. Es sind ja 
einige größere Bereiche dabei, auf die vermutlich indiziert (über 
Pointer) zugegriffen wird. Da kommt es z.B. darauf an, ob die 
Zugriffsroutinen vollständig adressieren oder voraussetzen, dass der 
"Buffer" keine Pagegrenzen überschreitet, was die Routinen zwar 
vereinfacht, aber böse Nebenwirkungen hat, wenn die Voraussetzungen 
nicht eingehalten werden.

Ich habe jetzt die Gesamtgröße nicht überprüft, aber wie sieht es mit 
dem Stack aus? Kann der vielleicht ins (reservierte) RAM reinlaufen? 
Überschreibt er wichtige Variablen, dann gibt es Ärger, überschreibt er 
aber ein paar Bytes von einem (noch nicht intensiv genutzten) Datenfeld, 
dann kann es schon recht lange dauern, bis der Fehler sichtbar wird.

MfG, Blaubär

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
ne den stack hab ich genauso initialiesiert wie du FALK, der code ist 
als textdatei über 130kb gross in assembler, das möchte ich keinem hier 
antun.
habe keine verschachtelungen drin, da die einzelnen segmente über rjmp 
angesprungen werden. rcall verwende ich immer nur für kurze aufgaben und 
dann springe ich sofort wieder zurück. ich mach auch keine push oder pop 
befehle, sondern sichere im arbeitsspeicher, deswegen die vielen 
verschachtelungen.
ich verstehs ja auch nicht, vermute schon fast das am AVRstudio liegt, 
das dann blöd macht???

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Troll Blaubär (blaubeer)

>Zugriffsroutinen vollständig adressieren oder voraussetzen, dass der
>"Buffer" keine Pagegrenzen überschreitet, was die Routinen zwar
>vereinfacht, aber böse Nebenwirkungen hat, wenn die Voraussetzungen
>nicht eingehalten werden.

Tststs, wer macht dnn sowas. Immer schön ZL UND ZH initialisieren.

>Ich habe jetzt die Gesamtgröße nicht überprüft, aber wie sieht es mit

1579 Bytes.

MfG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ fubu1000 (Gast)

>ne den stack hab ich genauso initialiesiert wie du FALK, der code ist
>als textdatei über 130kb gross in assembler, das möchte ich keinem hier
>antun.

Als Anhang ist das harmlos. Wer nicht will muss es nicht anclicken.
Und du bist sicher, dass du bei 130kB den vollen Überblick hast?!?

>habe keine verschachtelungen drin, da die einzelnen segmente über rjmp

Keine Verschaltelungen . .

>angesprungen werden. rcall verwende ich immer nur für kurze aufgaben und
>dann springe ich sofort wieder zurück. ich mach auch keine push oder pop
>befehle, sondern sichere im arbeitsspeicher, deswegen die vielen
>verschachtelungen.

deswegen die vielen Verschachtelungen . . .

"Kleiner" Widerspruch.

>ich verstehs ja auch nicht, vermute schon fast das am AVRstudio liegt,

Glaub ich nicht. Du wirst dich in deinem Ablauf verfransen. Häng mal den 
Code als Anhang dran.

MFG
Falk

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Tststs, wer macht dnn sowas. Immer schön ZL UND ZH initialisieren.

Initialisieren ja (muss aber nicht zwingend Z sein), aber beim Offset 
Addieren nicht unbedingt den Übertrag berücksichtigen, wenn 
sichergestellt ist, dass keine Pagegrenze drin ist. Alles schon gesehen.

MfG, Blaubär

Autor: Peter S. (psavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...der code ist als textdatei über 130kb gross in assembler,
>das möchte ich keinem hier antun.

Das solltest Du Dir auch nicht selber antun! Schon mal an C gedacht?

Autor: fubu1000 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ok,
bisschen experementiert, der speicher vom ROOT_ram ist so ausgelegt das 
ich 70 lieder auf nen SD packen könnte(980:14bytes=70).
habe bemerkt das doch nit alles geht, sobald ich über 50 lieder habe 
spinnt alles rum die dateien werden falsch angesprungen, bedeutet 
falsche liedanzeigen und fängt mitten drin irgendwo an.
also gut wer will, schaut mal in die datei rein, ich raffs gerade nit wo 
der fehler ist.
mfg und dank, fubu.

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok,
habe den fehler gefunden, AVRstudio setzt den STACK an 0x085F(byte 2047 
vom SRAM), also normal.
den ROOT_ram, allerdings an stelle 0x056E(byte 1294 vom SRAM), also nit 
gut, da ja eigentlich 980bytes freigehalten werden sollten für ROOT_ram.
wie kann ich das verhindern ???
gruss und vielen dank, fubu.

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Pointer auf ROOT_RAM und CLUSTER stimmen nicht. Dein Zugriff 
erfolgt auf die Adresse, die dem Doppelten der von Dir gewünschten 
Adresse entspricht. Die Zugriffe führen also in den Stack oder ins 
Nirvana.

Kurze Erklärung dazu:

Setzt Du einen Pointer auf RAM, so musst Du die korrekte Adresse 
angeben, denn RAM und LD/ST ist byteorientiert.  Dein "Label*2" ist also 
falsch.

Setzt Du den Z-Pointer auf Flash, dann musst Du ihn auf den doppelten 
Wert der Adresse (also des Labels, das ja die Adresse darstellt) setzen, 
wenn Du mit LPM auf Flash zugreifen willst. Denn Flash-Adressen sind 
wortorientiert, LPM liest aber nur ein Byte. Deshalb interpretiert LPM 
den Pointerinhalt anders, siehe auch Hilfe zu LPM. Dein "Label*2" ist 
also richtig.
Soll der Z-Pointer auf Flash für IJMP/ICALL genutzt werden, dann sind 
die Adressen wieder korrekt zu laden, da IJMP/ICALL das ganze Flash-Word 
(16 Bit) liest. Dies nur der Vollständigkeit halber, damit Du Dir nicht 
fälschlicherweise einprägst, alle Z-Pointer-Flash-Zugriffe würden "*2" 
erfordern.

Nach weiteren Fehlern habe ich jetzt nicht gesucht. Dazu fehlt mir die 
Motivation.

MfG, der blaue Troll

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke troll, das war der fehler, schäääämmmm.

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fubu1000 wrote:
> danke troll, das war der fehler, schäääämmmm.

Rollt es den jetzt??
So ganz ohne Interrupts, alles mit Warteschleifen?
Das würde mich echt mal interessieren.

Viel Erfolg, Troll Blaubär

Autor: fubu1000 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
joar,
ging vorher auch schon gut, aber nur bis 50 lieder halt.
jetzt funzt das super, egal wieviele.
iss schon im auto eingebaut, seit geraumer zeit, hatte nur nen paar 
verbesserungen machen wollen und ein paar fehler ausmerzen, wie man 
sieht.
gruss und nochmals danke, man lernt nie aus.
fubu

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fubu1000 wrote:
> joar,
> ging vorher auch schon gut, aber nur bis 50 lieder halt.
> jetzt funzt das super, egal wieviele.
> iss schon im auto eingebaut, seit geraumer zeit, hatte nur nen paar
> verbesserungen machen wollen und ein paar fehler ausmerzen, wie man
> sieht.
> gruss und nochmals danke, man lernt nie aus.
> fubu

Wie sieht denn die Hardware aus? (Schaltung, Aufbau) Kann man das mit 
zittrigen Pranken und trüben Augen realisieren? Die Anwendung wäre 
allerdings nicht Musik-Konsum, sondern eine Geräusch-Sammlung, daher 
wäre Ansteuerung mit einer "Geräusch-Nummer" interessant.

MfG, bärischer blauer Troll

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie krass muss man eigentlich drauf sein, um einen MP3 Player in 
Assembler zu schreiben, obwohl man locker 32KiB Flash-ROM hat?

Also bei 120KiB reine Sourcecodes hätte ich schon längst aufgehört.

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon Küppers wrote:
> Wie krass muss man eigentlich drauf sein, um einen MP3 Player in
> Assembler zu schreiben, obwohl man locker 32KiB Flash-ROM hat?

Kann es sein, dass Du trollst???

>
> Also bei 120KiB reine Sourcecodes hätte ich schon längst aufgehört.

Tja, nicht Jeder gibt beizeiten auf.

MfG, trolliger Blaubär

Autor: Nanoboy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@fubu1000

Hast du einen plausiblen Grund, der das Nichtverwenden von Groß- und 
Kleinschreibung in deinen Beiträgen -entgegen des ausdrücklichen Wunschs 
des Moderators- rechtfertigt?

Autor: fubu1000 der KRASSE ^^ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Troll: Kein problem ist alles nicht-SMD. Müsstest nur die Dateinamen 
aus
        der ROOT_ram auslesen und aufm Display darstellen. Willste 
Schalt-
        plan haben von dem Dingen, dann poste ich das hier. Wenn du 
willst
        erläutere ich dir den Code auch näher.

@nnanoboy: ich würde sagen das schreibt sich schneller und dazu
           kommt noch das wörtchen, faulheit !

Autor: Troll Blaubär (blaubeer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fubu1000 der KRASSE ^^ wrote:
> @Troll: Kein problem ist alles nicht-SMD. Müsstest nur die Dateinamen
> aus
>         der ROOT_ram auslesen und aufm Display darstellen. Willste
> Schalt-
>         plan haben von dem Dingen, dann poste ich das hier. Wenn du
> willst
>         erläutere ich dir den Code auch näher.
>
> @nnanoboy: ich würde sagen das schreibt sich schneller und dazu
>            kommt noch das wörtchen, faulheit !

Ein übersichtlicher Schaltplan wäre nicht zu verachten. Mal drüberschaun 
schadet ja nicht.

MfG, BlauTrollBärli

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.