mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 FSMC PSRAM / Muxed. wie nun?


Autor: Holger Krähenbühl (holgerkraehe)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich möchte an einem STM32f205VET 100pin LQFP ein SRAM anschliessen.
Nun habe ich den cube MX gestartet und mal geschaut.
Leider kann ich nur muxes psram auswählen.

Es scheint so zu sein, dass die Daten und Adressleitungen die selben 
Pins sind. Wie schliesse ich denn hier ein normales SRAM an?

Zudem frage ich mich, wo der unterschied vom SRAM zum PSRAM ist?
Bevor hier wiki artikel kommen, ja ich weiss, das PSRAM ist ein 
PseudoSRAM welches intern ein DRAM hat mit refresh elektronik. Gegen 
aussen sollte es sich aber ja so verhalten wie ein SRAM. Also weshalb 
die Auswahl PSRAM?


Danke schonmal

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehr Pin, mehr Bus.

Wenn du den 205ZET mit 144 Pins nimmst sind auch alle Busleitungen ohne 
Multiplex verfügbar.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> alle Busleitungen ohne
> Multiplex verfügbar.

wie könnte ich denn die leitungen multiplexen?

Ich würde lieber mit dem 100piner fahren.

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am besten so wie wir es schon beim 8086 bzw. 8088 gemacht haben, mit 
einem Adressregister für den SRAM.

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry, ich bin von der neueren Generation.

Einmal liegt die Adresse am Mikrocontroller an, dann muss ich die ja 
irgendwie zwischenspeichern und an das SRAM anlegen.

Dann liegen dort die Daten an.


Keine Ahnung wie das aussehen könnte.

: Bearbeitet durch User
Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In der Schaltung vom Atxmega oben, sind die Adressregister unten links 
zu sehen.

Für STM32 gibt es aber auch z.B. hier was

http://wiki.chibios.org/dokuwiki/doku.php?id=chibi...

Eine Appnote von ST ist sicher auch zu finden.

Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> wie könnte ich denn die leitungen multiplexen?
>
> Ich würde lieber mit dem 100piner fahren.

... und hinterher jammerst du uns hier im Forum vor wie
lange die RAM-Zugriffszeiten sind bzw wie lahmarschig sich
dein Controller verhält.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> ... und hinterher jammerst du uns hier im Forum vor wie
> lange die RAM-Zugriffszeiten sind bzw wie lahmarschig sich
> dein Controller verhält.

Gutes Argument.

Also lieber den 144pinner.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Gutes Argument.
>
> Also lieber den 144pinner.

Das sollte doch aber jedem selber einleuchten. Das ist ja gerade der 
Witz an der Sache mit Multiplex... Weniger Pins nötig, dafür um Faktor n 
langsamer.

Beim grösseren Prozi wirst du mindestens Faktor 2 schneller sein. 
Ausserdem eröffnet es weitere Annehmlichkeiten (einfacheres Layout, 
weniger Bauteile, weniger Fehlermöglichkeiten...)

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> STM Apprentice schrieb:
>> ... und hinterher jammerst du uns hier im Forum vor wie
>> lange die RAM-Zugriffszeiten sind bzw wie lahmarschig sich
>> dein Controller verhält.
>
> Gutes Argument.

Aber nur dann, wenn man auf die paar ns angewiesen ist. Wenn 
Burst-Zugriffe möglich sind, stört die Multiplexerei noch weniger.
Bei kleinerem RAM-Bedarf kann man auch HS-Typen mit 10 ns Zugriffszeit 
nehmen. Keine Panik!

Patrick B. schrieb:
> Beim grösseren Prozi wirst du mindestens Faktor 2 schneller sein.

Quatsch.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, bisher habe ich noch kein Schema gesehen, bei welchem die 
Adressleitungen zusammen mit den Datenleitungen verwendet werden.

Kennt jemand eine Application note mit sowas?

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt, ist schon etwas her:

http://arsene.perez-mas.pagesperso-orange.fr/syste...

beachte die Bezeichnung AD0..AD7 und A8..A15

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Nun, bisher habe ich noch kein Schema gesehen, bei welchem die
> Adressleitungen zusammen mit den Datenleitungen verwendet werden.

Ältere Schaltungen dazu findet man beim 8031, bei dem die 
Adressleitungen A0-A7 in einem xx573-Latch gespeichert werden mußten. 
Beim ATmega128 ist ebenfalls ein xx573 erforderlich.
Das sind jeweils Schaltungen für 8 Adressleitungen.

Beim STM32Fxxx braucht man ein 16 Bit Latch und da das Signal FSMC_NADV 
aktiv-low ist, verwendet man am besten zwei 8 Bit Register xx574.
Es gibt auch Bausteine, die für einen Multiplex-Bus ausgelegt sind und 
die Latches/Register mit auf dem Chip haben.

Welches RAM willst Du denn einsetzen? Sobald der Adress/Datenbus 16 Bit 
breit sein muß, kann man auch 16 Bit breite RAMs verwenden.

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Patrick B. schrieb:
>> Beim grösseren Prozi wirst du mindestens Faktor 2 schneller sein.
>
> Quatsch.

Achja? Begründung?
Daten und Adressen sind beim kleinen ja auf dem selben Pins. Wenn jetzt 
zuerst die Adresse angelegt werden kann, und dann die Daten sind 2 Takte 
nötig (ok, für Lesen noch 1 weiterer Takt). Internes Handling des 
Prozessors mal nicht berücksichtigt.
Wenn Daten- und Adressleitungen auf separaten Pins sind entfällt 1 Takt. 
Ergo für Schreiboperation doppelt so schnell, beim lesen 33% schneller.
Oder habe ich da was falsch verstanden?

: Bearbeitet durch User
Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
> Oder habe ich da was falsch verstanden?

Du glaubst, der lahme µC müßte das superschnelle RAM möglichst zügig 
adressieren. Das Gegenteil ist der Fall: der µC muß Wartezyklen 
einfügen, bis das RAM erste Daten liefern kann.
Ein moderner µC kann wissen, was er zuletzt ins Adresslatch geschrieben 
hat und diesen Zyklus nur bei Bedarf einfügen. Bei RAMs, die Burstmode 
unterstützen, ist dies wohl immer der Fall.

Beim Schreiben von Daten kann ein 32 Bit Datenwort vom µC sehr schnell 
geschrieben werden; der FSMC sorgt anschließend dafür, das die Bytes 
richtig im RAM landen. Der µC werkelt derweil schon längst weiter.

Sie Dir das Timing im Datenblatt vom STM32Fxxx an!

Autor: friendo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>der µC muß Wartezyklen einfügen, bis das RAM erste Daten liefern kann
Besonders, wenn der TO aus Sparsamkeit sich für PSRAM entscheidet.
Ist intern wie SDRAM(*), mit der selben Latenz, siehe Datenblatt PSRAM.
Hat ja nen Grund, warum PSRAM so billig ist im Vergleich zu SRAM.
PSRAM-> PseudoSRAM , nach außen hin wie SRAM, aber im Zugriff langsam,
besonders der wahlfreie.

* intern Kondensatoren als Speicherzellen statt FlipFlops (nicht die 
Schuhe !) nur der Refresh wird auch intern abgehandelt, darum weniger 
Aufwand in der CPU.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte folgendes RAM verwenden:


IS61WV6416EEBLL-10TLI

http://www.mouser.com/ds/2/198/61-64WV6416EEBLL-319024.pdf

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ich möchte folgendes RAM verwenden:

Gibt es bestimmte Gründe dafür?

Ich würde Dir eher einen STM32F427 empfehlen, der das zusätzliche RAM 
schon auf dem Chip hat.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Holger K. schrieb:
>> Ich möchte folgendes RAM verwenden:
>
> Gibt es bestimmte Gründe dafür?
>
> Ich würde Dir eher einen STM32F427 empfehlen, der das zusätzliche RAM
> schon auf dem Chip hat.

Ja, ich brauche es als zwischenspeicher für Bilder, welche auf ein 
Display kommen.

1 Mbit ist der anfang. später dann 16MBit

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ja, ich brauche es als zwischenspeicher für Bilder, welche auf ein
> Display kommen.

Daraus wird bei mir noch kein Schuh. Du müßtest schon mehr über Deine 
Anforderungen erzählen. Ein schnelles SRAM mit Fehlerkorrektur, wie es 
das o.g. Teil ist, scheint erst einmal völlig überflüssig zu sein.

Welche Bilder, welches Display, welches Timing?

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also...

Display: 
http://www.buydisplay.com/default/serial-spi-3-5-i...

Controller: STM32F205ZET6

Display ist mit SPI am Controller. Ebenfalls ist eine SD-Karte über SPI 
am Controller angeschlossen.

Bilder liegen als PNG auf der Karte und müssen dekomprimiert werden 
bevor sie aufs display kommen.

Hintergrund: ich möchte einmal ein sehr sehr einfaches GPS Gerät für in 
die Berge basteln.

Klar gibts sowas bereits fertig zu kaufen. Aber ich bin irgendwo 
immernoch ein Bastler und habe freude an sowas.

In einem anderen Thread frage ich gerade nach, wie man solche Bilder 
idealerweise mit GPS Daten verknüpft. Herausgekommen ist das Programm 
Taho welches Kachelweise Bilder von OpenStreetMap laden kann.
Zusätzlich gibt es dann noch ein Kalibrationsfile, welches die kanten 
des Bildes mit koordinaten definiert.

Also linke kante = Koordinate xy, rechte Kante = Koordinate xy etc...


Nun möchte ich die GPS Position (von einem GPS Modul) auslesen und 
anhand dieser die verschiedenen Kalibrationsfiles durchgehen. Wenn ich 
nun das entsprechende gefunden habe, lade ich das zugehörige bild, und 
entsprechend die um die kachel herumliegenden bilder ebenfalls.

Damit dies möglichst zügig geht, sollte ich wohl die entsprechenden 
bilder zuvor von PNG in RGB wandeln, und das ergebniss im SRAM ablegen.

Dann mittels DMA vom SRAM ans SPI senden.
Oder wie seht ihr das?

Sobald man sich bewegt, sollen dann die bilder entsprechend um x pixel 
verschoben werden.

Ziemlich simpel eigentlich. Sollte also machbar sein.

Es sollte einfach nicht elendig langsam laden.

Autor: friendo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kauf dir erst mal ein STM32F429-Disco bevor du eigene Hardware machst.
Das ist gut investiertes Geld und spart dir das Lehrgeld, das erste 
Design komplett in den Sand zu setzen.
Ein STM32F2 mit extra 128kB externen RAM ist so was von Fehlkonzept.
Wenn du das STM32F429-disco softwaremäßig als GPS-Tracker im Griff hast 
kannst du ja immer noch mit den dann korrekten Anforderungen ein eigenes 
Board machen.
STM32F205ZET6 + Display mit SPI + SD-Karte über SPI wirst du schnell 
über den Haufen werfen, weil "Es sollte einfach nicht elendig langsam 
laden".

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht genehmigt Mutti zum probieren eines von diesen:

http://de.rs-online.com/web/p/mikrocontroller/8820278/

für ernsthafte Versuche in Richtung Grafik zu empfehlen.

Wenn es nicht beliebt, kann es auch ohne übermäßigen Wertverlust wieder 
veräußert werden.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.