|
Anzeige
|
SDRAM - Byte Enable
Gast
#4212500
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.
Gast
#4212696
Noch eine Frage, was genau ist ein Byte select feature bei SDRAM ? Vmtl. beim SDRAM nicht nur komplette Speicherworte schreiben zu können, sondern darin die einzelne Bytes auswählen zu können. 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.
Gast
#4212736
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. @ 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.
Gast
#4212748
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.
Gast
#4227473
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
Gast
#4227486
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.
Gast
#4227532
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... 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. Beispiel:
ARMv3, byteweise statt r-m-w:
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:
Antwort schreiben |
Anzeige
|
