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
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.
@ 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
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
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???
@ 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
@ 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
> 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
>...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?
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.
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.
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
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
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
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
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.
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
@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?
@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 !
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
