SDRAM - Byte Enable

[RM0090 (Gast)]

Hallo,

ich verwende einen STM32 mit 32 Mbyte externem SDRAM, den ich gerne über 
den STCube konfigurieren möchte.
Beim Reiter FMC gibt es einen Unterreiter mit SDRAM1. Wähle ich Data: 32 
Bits, kann ich bei der Option Byte enable zwischen disabled und 32-bit 
byte enable wählen.

Was genau bewirken diese Einstellungen ? Wisst ihr, wann sie verwendet 
werden und wann nicht ? Im User Manual vom STM32F4 habe ich nichts 
genaues darüber gefunden.

Vielen Dank.

[RM0090 (Gast)]

Noch eine Frage, was genau ist ein Byte select feature bei SDRAM ?

[(prx) A. K. (prx)]

Vmtl. beim SDRAM nicht nur komplette Speicherworte schreiben zu können, 
sondern darin die einzelne Bytes auswählen zu können.

[Falk B. (falk)]

Damit kann man festlegen, welches der 4 Bytes eines 32 Bit Datenworts 
wirklich gelesen bzw. geschrieben werden soll. Damit kann man ggf. 
Einzelzugriffe auf Bytes machen und muss nicht jedes mal ein ganzes 32 
Bit Wort verarbeiten.

[RM0090 (Gast)]

ok, vielen Dank für die Hilfe.

Wenn ich mein SDRAM mit 32 Bit an den Controller angeschlossen habe, 
nach welchen Kriterien wähle ich dann aus, ob ich die Option: Byte 
enable  auf disable oder auf 32-bit byte enable einstelle ?

Bei 32-bit byte enable werden mir dann 4 Leitungen hinzugefügt, mit 
denen ich ein Byte des 32 Bit Dantenwortes auswählen kann.

[Falk B. (falk)]

@ RM0090 (Gast)

>Wenn ich mein SDRAM mit 32 Bit an den Controller angeschlossen habe,
>nach welchen Kriterien wähle ich dann aus, ob ich die Option: Byte
>enable  auf disable oder auf 32-bit byte enable einstelle ?

Möglicherweise kann dann der Compiler etwas besseren Code erzeugen, wenn 
es um die Behandlung von Datentypen kleiner als 32 Bit geht. Damit 
könnte einige Speicherzugriffe schneller werden. Ob das aber wirklich 
nennenswert viel ausmacht, wage ich zu bezweifeln.

>Bei 32-bit byte enable werden mir dann 4 Leitungen hinzugefügt, mit
>denen ich ein Byte des 32 Bit Dantenwortes auswählen kann.

Klar, denn ein 32 Bit Wort hat 4 Bytes. Allerdings muss dein SDRAM diese 
4 Leitungen auch unterstützen, das haben nicht alle.

[RM0090 (Gast)]

AHB transaction data size can be 8-, 16- or 32 bit wide whereas the 
accessed external device has a fixed data width.

- AHB transaction size is smaller than the memory size:

In this case, the FMC allows read/write transactions and accesses the 
right data trough its byte lanes BL[3:0]

Ich sehe noch nicht ganz den Vorteil darin, die Option 32-bit byte 
enabled zu wählen.

[Jens (Gast)]

RM0090 schrieb:
> Ich sehe noch nicht ganz den Vorteil darin, die Option 32-bit byte
> enabled zu wählen.
Wenn Du über einen 32-Bit-Bus mal nur 8-Bit schreiben willst, muss die 
CPU ein read-modify-write durchführen. Wenn es die byte-enables gibt, 
reicht ein einfaches write.

Aber damit das funktioniert müssen mehrere Kriterien erfüllt sein: der 
Speicher muss es können, der Speicherkontroller muss es können, die CPU 
muss es können und nicht zuletzt auch der Compiler.

Jens

[W.S. (Gast)]

Jens schrieb:
> der
> Speicher muss es können, der Speicherkontroller muss es können, die CPU
> muss es können und nicht zuletzt auch der Compiler.

nanana..
Dem Compiler ist das egal. Die CPU kann es, der Speichercontroller kann 
es auch und jeder externe SDRAM kann es auch. Das, was der TO hier 
nachfragt, ist einerseits die richtige Beschaltung zwischen µC und RAM 
und andererseits die richtige Initialisierung des Speichercontrollers 
UND des RAM. Ja, der SDRAM muß eben auch richtig initialisiert werden, 
sonst geht es nicht.

Wenn der TO in den Dokus von ST nix verstehbares gefunden hat, dann rate 
ich ihm, die Doku entsprechender Controller von NXP zu lesen. Dort ist 
es jedenfalls ausreichend beschrieben.

W.S.

[Jens (Gast)]

W.S. schrieb:
> Dem Compiler ist das egal.
Hmm. Ich bilde mir ein, das der Microblaze-GCC mal generell 
read-modify-write gemacht hat. Ist aber schon eine Weile her, da 
verblasst die Erinnerung...

[(prx) A. K. (prx)]

Jens schrieb:
> Hmm. Ich bilde mir ein, das der Microblaze-GCC mal generell
> read-modify-write gemacht hat.

Wenn die Befehlssatz-Architektur nur wortweise schreiben kann, dann wird 
der Compiler das natürlich berücksichtigen. Keine Ahnung wie das 
Microblaze hält.

ARM Cores vor ARMv4 kennen zwar Bytes, aber keine Halbworte. Wenn GCC 
derart alte Cores noch unterstützt, dann wird er für 16-Bit Datentypen 
r-w-m durchführen, wenn ein entsprechender Core eingestellt wird.

Spätere ARMs können auch Halbworte direkt schreiben. Da gibt es keinen 
Grund für den Compiler, das nicht zu nutzen. Wenn dann bestimmte 
Speicherinterfaces es nicht können, dann ist es Aufgabe des zuständigen 
Interface-Moduls, es umzusetzen.

Es könnte bei Controllern auch Speicherbereiche für eine spezielle 
Funktion geben, auf die nicht in beliebiger Weise zugegriffen werden 
kann. Dann wäre es Sache der Software, das zu berücksichtigen.

[(prx) A. K. (prx)]

Beispiel:

short x;

int get(void)
{
        return x;
}

void put(int y)
{
        x = y;
}

ARMv3, byteweise statt r-m-w:

get:    ldr     r3, .L2
        ldrb    r0, [r3, #1]    @ zero_extendqisi2
        ldrb    r2, [r3]        @ zero_extendqisi2
        mov     r0, r0, asl #24
        orr     r0, r2, r0, asr #16
        bx      lr
put:    ldr     r3, .L5
        strb    r0, [r3]
        mov     r0, r0, asr #8
        strb    r0, [r3, #1]
        bx      lr

Laden ginge auf ganz alten Cores auch effizienter, da bei denen das 
Halbwort per LDR richtig geladen wird und nur die zero/sign-extension 
fehlt.

ARMv4:

get:    ldr     r3, .L2
        ldrsh   r0, [r3]
        bx      lr
put:    ldr     r3, .L5
        strh    r0, [r3]        @ movhi
        bx      lr