Hallöchen zusammen, ich habe mal eine Frage bezüglich des STM32. Ich bin gerade dabei mich in diesen Controller (genauer die F4-Reihe) einzuarbeiten und habe eine Frage zum FSMC. Laut Datenblatt gehen ja nur SRAMs oder PSRAMs. Da die PSRAMs aber fast ausschließlich als BGA erhältlich sind bleibt ja nur das "normale" SRAM. Nur das da bei spätestens 2MByte Feierabend ist (sonst ist man wieder bei BGA). Meine Idee bzw Frage ist nun ob ich beispielsweise den STM32 via FSMC an einen FPGA anschließe und der FPGA ein SDRAM bedient um dem STM32 den externen Speicher bereitzustellen. Ich bin im FSMC noch nicht so tief drin, aber wäre das theroetisch möglich ? Sowie ich gelesen hab gibt es auch ein WAIT-Signal bzw kann halt die Setup/Hold-Zeiten anpassen, mit dem man den FSMC warten lassen kann (ob der bei einem WAIT nach einer gewissen Zeit dann nen BusFault schmeißt weiß ich allerdings nicht). Eine andere Möglichkeit wäre das ich immer nur Seitenweise auf das SDRAM zugreife. Sprich der FPGA bekommt vom STM32 gesagt er soll Seite 2345 in ein internes BlockRAM laden, und der STM32 kann sich dieses dann abholen (beim BlockRAM hätte man zudem wenige Waitstates (wenn überhaupt). Die Idee hinter dem ganzen liegt zum einen darin das ich eben mehr Speicher an den STM32 ankorken will, und zum anderen über den FPGA noch weitere Hardware zur Verfügung stellen kann die ich dann über Memory Mapping erreichen kann. So möchte ich z.b. noch weitere I2S Interfaces und evtl ein VGA Interface mit implementieren. Wäre halt nur schön wenn ich das SDRAM irgendwie so angebunden bekomme das ich ohne Klimmzüge den gesamten Speicher erreichen kann (selbst wenn das durch das ganze Setup des SDRAMs relativ lange dauert bis mein Datenwort anliegt bzw weggeschrieben ist). Hat jemand sich schonmal über so eine Konstellation Gedanken gemacht ? Oder ist diese Idee durch Umstände die ich im Datenblatt noch nicht geblickt habe zum scheitern verurteilt ?
Wieso schaust Du nicht nach einem Prozessor der eingebaut hat, was Du brauchst? SoCs mit ARM Core gibt´s tonnenweise, das wird sicher billiger und einfacher als einem STM32 mit einem FPGA aufzuhelfen.
Ich würde schon ganz gerne erstmal beim STM32 bleiben. Allein schon weil ich mit dem Discovery Board und Coocox ganz gut klarkomme (und an einer gescheiten kostenlosen gut funktionierenden Toolchain ist mein Einstieg in die ARM-Welt bisher gebremst worden). Das ganze war bzw ist auch erstmal nur ne Idee. Für mich ist liegt der Reiz darin den FPGA per Memory Mapping an den STM32 anzubinden und dem zusätzliche Hardware beizubringen (wie gesagt hauptsächlich I2S, da bei vielen Prozessoren auch von anderen Herstellern meist nur 2 I2S vorhanden sind und ich mit dem STM32 schon ganz gerne Richtung Audio gehen würde. Und da wäre etwas mehr Speicher auch ganz schick, wobei man mit 2 MByte auch schon recht weit kommt, aber ich würd mir gerne was Luft nach oben lassen. Also es ist nicht wirklich ein System was ich aufbaue und danach den Prozessor aussuche, sondern schaue was ich mit einem gegebenen Prozi alles machen kann. Und wenn jmd gesagt hätte : "Ja mit nem FPGA geht das das du nen SDRAM dran flanschen kannst, weil hab ich auch schonmal gemacht" wäre halt schön :-) Obwohl programmierbare bzw "austauschbare" Hardware in einem FPGA via Memory Mapping ansprechen hat auch schon was. Zur not würde es auch ein "normales" SRAM tun und der FPGA mimt dann die IO-Bitch. Und ich denke das sollte hinhauen :-)
Wieso sollte das mit einem FPGA nicht gehen? Sowas zum "Spielen" und Lernen aufzubauen ist sicher reizvoll. Für ein professionell eingesetztes System aber weniger sinnig.
SDRAM an FPGA und mittels FSMC ansprechen geht, benötigt aber auch Erfahrung mit programmierbarer Logik. Hast du dich mal mit Speichercontroller im FPGA beschäftigt? Hast du Erfahrung mit programmierbarer Logik? Wenn nicht, wäre der erste Schritt sich in die Materie mal einzulesen und dann zu entscheiden, ob man den Aufwand betreiben will. Programmierbare Logik bringt so seine Tücken mit sich. Vor allem, wenn der FPGA auch noch die Speicherzugriffe so verteilen muss, damit der Displaycontroller auch permanent seine Daten bekommt, falls man gleich noch ein TFT Display ansteuern möchte. Grüße
Wenn Du größere Mengen an RAM anklemmen willst, landest Du schnell bei DDR2. Geht alles, aber das FPGA muss die passenden Transceiver oder einen DDR2-Controller als Hard-Macro eingebaut haben. Gibts alles, z.B. bei den Spartan 6, aber auch hier bist Du wieder bei BGA, weil die kleinen im TQFP144 keine Memory Controller haben. Egal, welchen Weg Du gehst - Du landest immer relativ schnell bei BGA und 6-8 Layern. Wenn Du Dich an dieses Thema ranmachen willst, empfehle ich dringend, auf eine funktionsfähige Hardwareplattform zu setzen. Das hier ist zB ganz nett: http://shop.in-circuit.de/products/Home/ICnova-CPU-Module/7/ICnova-SAM9G45-XC3S700AN-OEM Ich gehe davon aus, dass Du das hier so nicht hinbekommen wirst. Nicht so, wie Du hier fragst. Sammle erstmal Erfahrungen mit einer funktionierenden Hardware, damit hast Du mehr als genug zu tun. Wenn Du in einem Jahr das alles beherrschst, kannst Du Dich an Deine eigene Hardwareplattform machen. Vorher wird das nix. fchk
@Marco Mit FPGAs hab ich schonmal was gemacht. Hab das Audio-Projekt "verbrochen" :-) http://www.mikrocontroller.net/articles/Audio-DSP_mit_Spartan_3-FPGA Eine SD-RAM Ansteuerung hab ich schonmal gemacht. Ist als Multiport (nacheinander abarbeiten) ausgelegt :-). Ein Display könnte mit dem Burst-Mode abgesteuert werden. Allerdings haben die Zugriffe dadurch u.u. sehr lange Wartezeit. Und da ist halt die Frage ob der STM dann nicht irgendwann sagt : Nö, du blockierst den Bus, is nicht und schmeißt nen BusFault. Oder wenn ich die Ansteuerung nur für den STM (Einzelzugriffe, ohne Burst) mache hab ich ja dennoch die Setupzeit oder mache gerade einen Refresh der dann den Zugriff verzögert. Und da ist eben die Frage wie der STM damit umgehen würde, bzw wie lange ich verzögern kann bevor der FSMC stinkig wird. Oder ob das ganze prinzipiell nicht hinhauen kann, aus welchem Grund auch immer :-)
@Frank Also DDR-Ram hab ich nicht vor. SDRAM, FPGA und STM bekommt man noch BGA-frei. Ich hab schon ein paar einfache FPGA-Boards (ca 50MHz) gemacht und da bin ich mit 2-lagig ausgekommen. Das Board ist schön und gut, aber doch ein wenig oversized, und Linux peile ich nicht an. Mir reichen im Prinzip ein SDRAM (16MByte), ein FPGA und der STM. Und Industriequalität muß es auch nicht haben. >Sammle erstmal Erfahrungen mit einer funktionierenden Hardware Dafür hab ich FPGA-Boards (fertig und selbstgemacht) und das Discovery.
Rene B. schrieb: > @Marco > > Mit FPGAs hab ich schonmal was gemacht. Hab das Audio-Projekt > "verbrochen" :-) > > http://www.mikrocontroller.net/articles/Audio-DSP_mit_Spartan_3-FPGA > > Eine SD-RAM Ansteuerung hab ich schonmal gemacht. Ist als Multiport > (nacheinander abarbeiten) ausgelegt :-). Ein Display könnte mit dem > Burst-Mode abgesteuert werden. Allerdings haben die Zugriffe dadurch > u.u. sehr lange Wartezeit. Und da ist halt die Frage ob der STM dann > nicht irgendwann sagt : Nö, du blockierst den Bus, is nicht und schmeißt > nen BusFault. > Oder wenn ich die Ansteuerung nur für den STM (Einzelzugriffe, ohne > Burst) mache hab ich ja dennoch die Setupzeit oder mache gerade einen > Refresh der dann den Zugriff verzögert. Und da ist eben die Frage wie > der STM damit umgehen würde, bzw wie lange ich verzögern kann bevor der > FSMC stinkig wird. > Oder ob das ganze prinzipiell nicht hinhauen kann, aus welchem Grund > auch immer :-) Ich hab mal gerade das Ref. Manual vom STM32F4 überflogen und nichts zu maximalen Wartezeiten gefunden, also wäre es auf jeden Fall ein Versuch wert, wenn du so etwas machen willst. Immerhin geht mit dem STM32F4 ja sogar synchroner Zugriff, das macht die Kommunikation mit dem FPGA noch ein wenig einfacher. Wenn der wirklich einen Busfault werden sollte, dann musst du halt einfach noch mal an die Zugriffsarbitrierung ran ;-) Ich hab mal sowas ähnliches ohne Wait Signal für ein TFT Display gemacht, bei dem der FPGA die Kontrolle über den Speicher hatte. War am Ende nur noch eine Frage der Waitstates, die der Controller einlegen musste, damit die Daten sicher anliegen. Aber ich würde jetzt immer einer Controller nehmen, der einen TFT Controller mitbringt. P.S. Schönes Projekt, dein Audio-DSP
Hallo, Silica hat in die Richtung auch etwas anzubieten: STM32F2 - Spartan6 - DDR3 Silica Xynergy Board - STM32 meets Spartan-6 http://www.silica.com/product/silica-xynergy-board-stm32-meets-spartan-6.html
@Marco Danke für die Infos. Ich werd mir das Datenblatt auch nochmal genau anschauen, und das mal durchplanen und durchspielen. Egal ob der FPGA nun Speicherschubser spielt (egal ob "direkte" Anbindung, oder über BlockRAMs die vom SDRAM per Burst-Mode vollgeschrieben werden) und/oder weitere Hardware (mehrere I2S, VGA) bereitstellt. Danke für das Lob bzgl des Audio-Projektes. Da möchte ich dann eben auch wieder so ein bissl anknüpfen. Bisher hat ein AVR per SPI mit dem FPGA geredet, und der FPGA alle "schnellen" Sachen gemacht. Aber ich denke wenn ich den FPGA nun als Memory Mapped Device einbinde und dann evtl. noch DMA nutzen kann hat man nochmal ein paar Möglichkeiten mehr. Und je nachdem wie ich es aufbaue kann der FPGA ja auch noch Audio-Rechen-Aufgaben übernehmen. Jedenfalls denke ich wäre das ne ganz gute Platform. @Christian Das Board hatte ich auch schon gesehen, aber irgendwie sträube ich mich noch gegen DDR-RAM. Bei SDRAM hat man noch ganz gute Chancen das alles selbst in den Griff zu bekommen was Layout und Ansteuerung angeht (SDRAM ist jetzt ja nicht sooo schwer anzusteuern im Gegensatz zu DDR-RAM, ganz zu schweigen vom Layout von DDR-RAMs).
Thread beobachten
Seitenaufteilung abschaltenBitte 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.