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.
bei 2k sram würde das ja bedeuten das der stack über 300b groß ist,.. heftig,... zeig mal bitte ein bisschen source,.. grüüße
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
Mal abgesehen davon das es merkwürdig ist: Ist es nicht wurscht wie dein speicher aufgeteilt ist?
@ 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
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.