memory-mapped i/o bei stm32f4discovery

[Dummy (Gast)]

Hallo zusammen,

ich hab ein STM32F4Discovery-Board und möchte das Wiz830mj BreakoutBoard 
mit dem W5300 daran anschließen.

Ich hab das Wiz830mj noch nicht, aber müsste jeden Tag kommen. Deswegen 
hab ich mir gedacht ich fang schon mal an, das Programm für meinen 
Mikrocontroller zu schreiben, dass ich dann gleich loslegen kann.

Jetzt hab ich dazu das Datenblatt des W5300 studiert und der haut mir 
gleich was von Memory-Mapped I/O Space um die Ohren. Tut mir Leid, dass 
ich noch so ein Newbie bin, aber bis dahin hatte ich noch nie was davon 
gehört.

Bis jetzt habe ich rausgefunden, dass dafür einfach Adressen aus dem 
Speicherbereich genommen werden und dann auf die Register des 
EthernetControllers zeigen.

Das verstehe ich aber noch nicht so ganz. Zuerst dachte ich, ich leg 
einfach auf die Adressleitung des Ethernetcontrollers, die ich mit den 
GPIO-Ports meines stm32 verbunden habe, die Adresse der Register und 
schreib dann über die Datenleitungen den Wert in die Register.

Aber das kann doch nicht Memory-Mapped I/O sein? Da müsste doch 
eigentlich dann der Adressbus des stm32 nach draussen geführt werden, 
oder was verstehe ich da falsch? Ich kann nämlich beim Discovery-Board 
keinen nach aussen geführten Adressbus finden...

Und zu Memory-Mapped I/O Space finde ich auch im Datenblatt und im 
ReferenceManual des stm32f407vgt6 nicht viel.

Könnt ihr mir das kurz erklären? Würde vielleicht mein erster Ansatz 
(Adressleitung des Ethernet-Controllers an GPIO-Ports hängen) auch 
funktionieren. Aber selbst wenn, würde mich trotzdem interessieren, wie 
das mit richtigem Memory-Mapped IO funktioniert...

Vielen Dank schon mal
Dummy

Hier noch die PDFs:
ReferenceManual: 
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/DM00031020.pdf
Datenblatt stm32f407vgt6:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/DM00037051.pdf
Datenblatt w5300:
http://www.mct.net/download/wiznet/w5300.pdf

[Uwe (Gast)]

Flexible static memory controller (FSMC) im Datnblatt des STM32F4.
Sollte man als SRAM ansprechen können.

[Dummy (Gast)]

ah super, danke

das war das Stichwort, das mir gefehlt hat. Kannst du mir vielleicht 
noch erklären, warum als SRAM? Wenn ich mal ein anderes Gerät 
anschließen will, woher weiß ich, als was ich die ansprechen könnte?

Danke jedenfalls nochmal...

[Ralf (Gast)]

> Kannst du mir vielleicht noch erklären, warum als SRAM? Wenn ich mal ein
> anderes Gerät anschließen will, woher weiß ich, als was ich die ansprechen
> könnte?
Weil früher SRAM den Hauptbereich des externen Memory-Interfaces belegt 
hat (von den Adressen her) bzw. weil das EMIF eben für SRAM vorgesehen 
war.
Ein kleiner Teil des verfügbaren Adressraums (beispielsweise die letzten 
256 Byte) wurde über Logikgatter für memory-mapped-IO freigemacht. Wurde 
auf die Adressen im MMIO-Bereich zugegriffen ist nicht das SRAM 
angesteuert worden, sondern beispielsweise Latches für IO-Erweiterungen, 
Displays etc.

Auf SRAM bezieht sich die ganze Sache eben deswegen, weil wie schon 
angedeutet die primäre Anwendung der Anschluss eines SRAMs zur 
Erweiterung des Speichers ist und weil du bei einem SRAM eben alles 
"vereint" hast: Schreiben (Write/WR-Signal), Lesen (Read/RD-Signal), 
Auswahl(ChipSelect/CS-Signal), etc. Wobei das CS-Signal je nach 
Controller entweder über die Adressen mittels zusätzlicher Logikgatter 
gebildet wurde oder es der Controller bereits selbst zur Verfügung 
stellt. Hatte man nur ein RAM oder EPROM am EMIF angeschlossen hat man 
mitunter das CS-Signal fest auf aktiven Pegel gelegt.
Ich hab beispielsweise beim 8051 früher ein HD44780-Display und ne 
Matrix-Tastatur auch über EMIF angesteuert, die entsprechenden 
Logikgatter für die Adressdekodierung brauchts da halt - aber das nennt 
man memory-mapped-IO, weil eben das Display sowie die Tastatur über das 
EMIF in den Speicherbereich (Memory) gelegt wird (mapped).

Ralf