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
Angehängte Dateien:
-
psram.png
84 KB
Mehr Pin, mehr Bus. Wenn du den 205ZET mit 144 Pins nimmst sind auch alle Busleitungen ohne Multiplex verfügbar.
pegel schrieb: > alle Busleitungen ohne > Multiplex verfügbar. wie könnte ich denn die leitungen multiplexen? Ich würde lieber mit dem 100piner fahren.
Am besten so wie wir es schon beim 8086 bzw. 8088 gemacht haben, mit einem Adressregister für den SRAM.
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
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=chibios:community:plans:external_ram Eine Appnote von ST ist sicher auch zu finden.
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.
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.
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
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.
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?
Wie gesagt, ist schon etwas her: http://arsene.perez-mas.pagesperso-orange.fr/systemes/uc/multiplex_d_a.gif beachte die Bezeichnung AD0..AD7 und A8..A15
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.
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
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!
>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.
Ich möchte folgendes RAM verwenden: IS61WV6416EEBLL-10TLI http://www.mouser.com/ds/2/198/61-64WV6416EEBLL-319024.pdf
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.
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
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?
Also... Display: http://www.buydisplay.com/default/serial-spi-3-5-inch-tft-lcd-module-in-320x480-optl-touchscreen-ili9488 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.
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".
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.