Daten im SRAM

wer

Neues Mitglied
02. Juli 2012
485
0
0
Sprachen
  1. Assembler
Hallo,

ich bin gerade dabei mir zu überlegen, welche Strategie für die Ablage von Daten im SRAM zu bevorzugen ist.

  1. Stack auf RAMEND, Daten auf $0100.
  2. Stack auf RAMEND-DATASIZE,Daten auf RAMEND-DATASIZE+1

Zunächst erschien mir die zweite Variante sicherer, da ich dachte, daß meine Daten dort nicht von einem Stack-Overflow überschrieben werden könnten. Aber dann dachte ich, daß es ja durchaus sein kann, daß der SP bis auf 0 runter (durch den IO-Bereich und die Register) marschieren kann und dann wieder auf RAMEND hochgewrappt werden könnte. Zweites Problem: Ein Stack-Underflow.

Im Simulator passiert folgendes:

POP bei leerem Stack:
Code:
	ldi	R16,$80
	mov	R0,R16
	pop	R1

SP liegt anfangs bei $40FF (ATmega1284P:16K SRAM). Vermutung: Bei einem POP wird SP nicht nur inkrementiert, sondern auch auf 0 zurückgesetzt, zeigt dann auf R0, so daß R1 auf $80 gesetzt wird. Ergebnis: SP wird auf die ungültige Adresse $4100 gesetzt und R1 bekommt (behält) den Wert 0.

Der Versuch den Stack auf $FFFF zu initialisieren scheitert:
Code:
	ldi	R16,$ff
	out	SPL,R16
	out	SPH,R16
	ldi	R16,$80
	mov	R0,R16
	pop	R1
SP ist jetzt $7FFF (???), wird beim POP auf 0 gewrappt, aber R1 ist immer noch 0.

Stack auf 0 initialisieren:
Code:
	ldi	R16,0
	out	SPL,R16
	out	SPH,R16

	mov	R0, R16
	ldi	R16,$80
	push	R16
R0 bleibt 0 (trotz PUSH von $80) und SP wird auf $7FFF gewrappt.

Bevor ich nun das ganze noch einmal mit dem realen Baustein ausprobiere, denn dem Simulator traue ich nicht so recht, hätte ich gerne Eure Erfahrungen gehört.

Gruß Wolfgang
 
Hi,

den Stack würde ich auf jeden Fall im internen SRAM lassen. Und zwar weil ...
Wenn du eine Taktfrequenz von 16MHz hast, dann ist ein Prozessorzyklus bei 62,5ns.
Ein "normales" SRAM hat eine Zugriffszeit von bereits 50-55ns.
Der Atmel ist also nen Stück schneller. Damit muß er also beim Zugriff auf das externe SRAM Wartezyklen einschieben was den Zugriff darauf verlangsamt. Wenn du nun deinen Stack ins externe SRAM packst, dann fährt dein Atmel mit angezogener Handbremse.

Gruß
Dino
 
Wenn du nun deinen Stack ins externe SRAM packst, dann fährt dein Atmel mit angezogener Handbremse.

Hallo Dino,

mir ist nicht so recht klar, wie Du jetzt auf externes RAM kommst. Allerdings ist mir auch nicht klar, wie der Simulator auf $8000 Bytes SRAM kommt. Wahrscheinlich stehe ich wieder auf einem der berühmten Schläuche.

Gruß, Wolfgang
 
Hmm... ich hatte Wolfgang schon so verstanden, daß der Stack im SRAM bleiben soll - nur eben woanders als am Ende.

Vorweg: Wo der SP intial liegt, kann man dem Datenblatt entnehmen. Bei den meisten älteren Controllern ist er 0x0000 (also im I/O-Bereich), bei den neueren RAMEND.

Zum SRAM selbst schau mal ins Datenblatt. Die ersten 0x3F Adressen gehen an den I/O-Bereich. Viele (praktisch alle neueren) besitzen noch einen erweiterten I/O-Bereich. Erst dann beginnt der physische SRAM. Bei einigen Tinies wird auch noch der Program-Flash mit in den SRAM eingeblendet (Remapped) - also nur Adresstechnisch...

Ebenso sind die Rechenregister da miteingeblendet - ok, hattest Du ja selbst erwähnt.

In der Prozessordefinitionsdatei sind aber die entsprechenden Konstanten bereits definiert (also die Startadresse des echten SRAM, und dessen Größe).

Der Sinn Deiner Fragerei erschließt sich mir allerdings nicht.
Aufgrund des wachsens nach unten macht der Stack irgendwo hinten im SRAM Sinn (ob er in den I/O-Space laufen würde, in Deinen Datenbereich, oder auf nichtexistente Adressen fällt, ist eigentlich unwichtig - das alles darf nicht geschehen).

Die Definition von Variablen (mit .db , .dw ) wächst hingegen von unten nach oben - macht also eher vorn Sinn (wächst betrifft hier nur den Assembler, klar).
Oder geht's Dir um dynamisch wachsende Datenstrukturen?
Was soll denn da sonst noch dazwischen?

Ansonsten ist es doch aber eh Jacke wie Hose... Du hast halt 'ne begrenzte Menge Arbeitsspeicher zur Verfügung. Davon brauchst Du X für den Stack, und Y für Variablen. Entweder das reicht, oder nicht. WO dabei WELCHE Daten stehen, ist doch erstmal egal...

Nachtrag: 0x40FF ist bei dem Chip "RAMEND", 0x0100 "SRAM_START"
0x0000 .. 0x001F = Rechenregister
0x0020 .. 0x005F = I/O-Space
0x0060 .. 0x00FF = Extended I/O
0x0100 .. 0x40FF = internal SRAM
 
Hmm... ich hatte Wolfgang schon so verstanden, daß der Stack im SRAM bleiben soll - nur eben woanders als am Ende.
Richtig!
Der Sinn Deiner Fragerei erschließt sich mir allerdings nicht.
Aufgrund des wachsens nach unten macht der Stack irgendwo hinten im SRAM Sinn (ob er in den I/O-Space laufen würde, in Deinen Datenbereich, oder auf nichtexistente Adressen fällt, ist eigentlich unwichtig - das alles darf nicht geschehen).
Natürlich darf das nicht geschehen. Es ist trotzdem interessant zu sehen, was genau passiert.
Nachtrag: 0x40FF ist bei dem Chip "RAMEND", 0x0100 "SRAM_START"
0x0000 .. 0x0001 = Rechenregister
0x0020 .. 0x005F = I/O-Space
0x0060 .. 0x00FF = Extended I/O
0x0100 .. 0x40FF = internal SRAM
0x0000 .. 0x001F = Rechenregister

Was doch seltsam ist, oder scheint, daß die Register nicht unbedingt überschrieben werden, bzw. daß der SP größer als RAMEND werden kann!

Könnte man letzteres nicht benutzen um einen Stack-Overflow oder Underflow zu detectieren?

Gruß, Wolfgang
 
Ups... Fehler korrigiert...

Zum Thema:
Im Datenblatt (8059D–AVR–11/09) scheint da was falsch zu sein Der SP belegt da nur 13 Bits in 2 Registern, Initialwert soll da 0x10FF sein, Maximum wäre dann ja 0x1FFF - das kann nicht stimmen...
Richtig sollte sein:
Initial=RAMEND=0x40FF oder eben 0b 0100 0000 1111 1111 - also eben 15 verwendete Bits. Das letzte Bit wäre readonly und somit immer 0. Da Du auf die anderen Bits aber Zugriff hast, kannst Du auch irgendwas anderes (größer als 0x40FF) reinschreiben. Höchstens jedoch 0b 0111 1111 1111 1111 was eben 0x7FFF ist. Mit dieser Adresse ist zwar keine Zelle mehr verbunden, aber das Register kann diese Zahl mit 15 Bit logischerweise aufnehmen.

Inwiefern Simulator und Hardware hier zum selben Effekt führen, kann ich Dir aber auch nicht sagen...
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)