Eigentlich gibt es das was ich machen will schon fertig aber es reizt mich so etwas auch mal selbst zu versuchen. Die fertige Lösung setzt auf einen kleinen MCU mit angeflanschtem FPGA das einen SDRAM Controller für einen 128Mbyte SDRAM Baustein darstellt. Ich möchte aber ohne FPGA auskommen. Dabei kommt mir sofort ein Atxmega mit EBI in den Sinn. Nur unterstützt der Atxmega maximal 16Mbyte und ich brauche aber in meinem Fall mindestens 64Mbyte, da gäbe es auch noch SDRAM Bausteine im TSOP-II das man noch gut löten kann. Hat da jemand eine Idee wie man das hinbiegen könnte. Das RAM muss nicht linear ansprechbar sein. Peter
Wie wäre es, die 2 fehlenden Adressleitungen über stinknormale Portpins zu lösen? Du brauchst halt sowas wie paging dann...
Was willst du denn eigentlich machen? Vielleicht gibt es für deinen Anwendungsfall eine bessere Lösung.
Ja die Idee mit den Portpins hatte ich auch, nur ist mir nicht klar wie ich die Addressen gemultiplexed in das SDRAM bringe. D.h. wie muss ich die Portpins mit CAS, RAS, etc. kombinieren um die zusätzlichen Addressen zu liefern. Reicht da so etwas wie ein 2-zu-1 MUX? Hier wäre ich sehr dankbar wenn da jemand eine Schaltung bereit hätte. Eine neue MCU Architektur wollte ich vermeiden weil dann muss ich alle meine Assembler Routinen neu schreiben und mich einarbeiten, das verursacht ziemlich Kosten. Wie gesagt, es gibt schon eine fertige Lösung für etwa 200Euro die macht das was ich brauche und sogar noch viel mehr, aber das Thema reizt mich als Selbstbauprojekt. Ich will noch nicht sagen was es genau ist, weil ich möchte hier nur die Frage zum RAM Bedarf geklärt haben. Der zweite noch offene Punkt im Projekt konnte ich mindestens schon mal mit langsamer Übertragungsrate verifizieren. D.h. das Prinzip funktioniert, die Bauteile für die finale Übertragungsrate sind unterwegs. Es hängt also auch vom Erfolg dieses Tests ab. Aber für den Proof of Concept dieses Punktes reichen 9kbyte RAM, d.h. ein Atmega1284P. Nur stimmt dann die Performance nicht, d.h. ein einzelner Block von 9kbyte kann dann zwar mit maximaler Übertragungsrate versendet werden, aber danach muss ich den nächsten Block vom Speichermedium laden und das will ich im Betrieb vermeiden.
Peter S. schrieb: > Ja die Idee mit den Portpins hatte ich auch, nur ist mir nicht klar wie > ich die Addressen gemultiplexed in das SDRAM bringe. Grösseres RAM verwenden und nicht muxen.
:
Bearbeitet durch User
A. K. schrieb: > Peter S. schrieb: > Ja die Idee mit den Portpins hatte ich auch, nur ist mir nicht klar wie > ich die Addressen gemultiplexed in das SDRAM bringe. > > Grösseres RAM verwenden und nicht muxen. ich würde auch nicht murksen machs lieber gescheit
Bei Deinen Randbedingungen (AVR, vom Bastler lötbar) sage ich: vergiss es. Wenn Du etwas haben willst, was in Deiner technischen Reichweite liegt: PIC32MZ1064DAG176 https://www.microchip.com/wwwproducts/en/PIC32MZ1064DAG176 Da müsstest Du schauen, ob Du mit den 32MB DRAM (zusätzlich zu den 256k SRAM) leben kannst. Weshalb empfehle ich Dir genau diesen Chip? 1. Du kannst ihn real bei Digikey etc kaufen und musst nicht bei Taobao oder so suchen. 2. Du kannst ihn löten. 0.5mm TQFP geht problemlos von Hand, auch wenn es viele Pins sind. 3. Die 32MB DDR2-DRAM sind im Chip mit drin. Externes DDR2-DRAM anzubinden ist nämlich nicht ganz ohne, und wenn Du nicht Knowhow, Erfahrung und die passenden Tools hast, wirst Du in Probleme laufen, von denen Du jetzt noch nicht einmal ansatzweise weißt, dass es sie gibt. Daher hast Du nur bei Multi-Chip-Packages mit internen DRAM eine reale Erfolgschance. 4. Du wirst nicht in Assembler programmieren. Wenn Du das machst, dann stimmt was mit Deinem Design nicht. Du hast nämlich so nette Sachen wie DMA und diverse Hardwarebeschleuniger, die einen Großteil der vermutlich anfallenden Aufgaben in Silizium und damit eine Größenordnung schneller erledigen können als die CPU. Und für den Rest ist klug programmiertes C fast immer schnell genug. 5. Da Du die vorhandene Hardware optimal nutzen solltest, wirst Du Dich ohnehin einarbeiten müssen. Wenn Du damit überfordert bist, dann bist Du in diesem Beruf einfach falsch, sag ich jetzt einfach mal. Wenn Du eine Architektur kennst, dann ist jede neue Architektur im Prinzip immer wieder das Gleiche - klar, Namen, Adressen und sonstige Details sind erstmal ganz anders, aber die Funktionsprinzipien haben sich in den letzten 40 Jahren nicht wirklich grundlegend geändert. Und Du solltest in Schule und Studium gelernt haben, wie man lernt. Vieles von dem, was ich hier schreibe, mag harsch und schroff klingen. Dahinter stehen aber 40 Jahre Erfahrung mit dem ganzen Zeug seit 6800, 8080 RCA1802 usw usw. fchk
:
Bearbeitet durch User
Das Beagle Bone Black hat 512 MB SDRAM. Der Prozessor ist weitgehend dokumentiert, kann bare-metal programmiert werden, ist dank PRU hart Echtzeit-fähig und kann praktisch alles was ein Mikrocontroller kann. Meistens wird man ihn aber mit Linux benutzen. Kostet ca 60€.
PS: Das gibt's auch als System-On--Package: https://octavosystems.com/octavo_products/osd335x-sm/ Allerdings total bastlerfreundliches BGA ;-) Ist zwar viele Größenordnungen komplexer als ein AVR. Aber wer so viel RAM braucht, braucht auch die Rechenleistung um mit solchen Datenmengen umzugehen? Oder werden die Daten nur durchgeschleust, z.B. an einen PC? Bei geeigneter Programmierung und Schnittstelle (z.B. USB-HS) kommt man mit viel weniger RAM aus.
Danke für die Tips, ein grösseres RAM und Muxen vergessen dürfte der einfachste Ansatz sein. Leider habe ich noch kein bastelfreundliches 1Gbit SDRAM gefunden, TSOP gibts nur bis 512Mbit. Aber ich könnte mich ja auch mit der 30Mbyte Variante der Aufgabe begnügen. Es muss einfach wesentlich mehr sein (um genau zu sein >20Mbyte) als die aktuelle langsame Lösung mit 4Mbyte. Beagle Bone habe ich auch angeschaut, genau die PRU's wären super und würden die Anforderung des Echtzeit Teils super abdecken. Ein Green liegt bei mir auf dem Tisch. Wenn ich denn schon eine andere Architektur wählen müsste dann diese. Und nein trotz Speicheranforderung brauche ich die Rechenleistung nicht, ein AVR tut es ohne Probleme. Es geht wirklich um das Durchschleusen von Daten und um eine vorhersehbare Reaktionszeit wenn ein anderer Bereich angefordert wird. Es ist die Reaktionszeit die kritisch ist. Manchmal reichen mehrere millisekunden und das Gerät wartet sogar auf ein ACK, dann könnte ich es ja auch direkt von der SD-Card lesen, aber manchmal sind es nur 30usec die ich Zeit habe bevor ich das erste byte senden muss. Die Routine die das umsetzten muss besteht aus weniger als 100 Assembler Instruktionen. Das schafft ein AVR locker in 30usec.
Peter S. schrieb: > Es geht wirklich um das Durchschleusen von Daten und um eine > vorhersehbare Reaktionszeit wenn ein anderer Bereich angefordert wird. Ein anderes System fordert also beliebige Daten an, kein Datenstrom? Kein Muster bei der Adresse? Sind die Daten denn variabel? Könnte man nicht ein großes Parallel Flash verwenden? Peter S. schrieb: > aber manchmal sind es nur 30usec die ich Zeit habe bevor ich das erste > byte senden muss. Kein Problem für den TI Sitara glaube ich... müsste man noch mal messen.
PS: Also diverse ARM-uC wie STM32 können das natürlich auch, aber mir fällt gerade kein fertiges Board mit 64 MB ein. Selbst-Bau ginge damit aber.
Könnte man die Daten auch live berechnen, ist es eine Art "Map" ? Viel Rechenleistung ist in der Größenordnung ggf. einfacher als viel Speicher.
Peter S. schrieb: > Und nein trotz Speicheranforderung brauche ich die Rechenleistung nicht, > ein AVR tut es ohne Probleme. Es geht wirklich um das Durchschleusen von > Daten und um eine vorhersehbare Reaktionszeit wenn ein anderer Bereich > angefordert wird. Es ist die Reaktionszeit die kritisch ist. Manchmal > reichen mehrere millisekunden und das Gerät wartet sogar auf ein ACK, > dann könnte ich es ja auch direkt von der SD-Card lesen, aber manchmal > sind es nur 30usec die ich Zeit habe bevor ich das erste byte senden > muss. Die Routine die das umsetzten muss besteht aus weniger als 100 > Assembler Instruktionen. Das schafft ein AVR locker in 30usec. Dann nimm einen ATmega64 oder was ähnliches, pack da 64kB SRAM dran und nutze den clever als FIFO zwischen deiner Datensenke und der SD-Karte. Damit sollte das machbar sein, wenn nicht gerade total wahlfreier Zugriff nötig ist. Als Zwischenlösung ATXmega mit 16MB SD-RAM. Beitrag "Re: Viel RAM am kleinen Controller" Möglicherweise kann man an den ATXmega auch mehrere SD-RAMs anschließen und per "manuellem" Chip select was hintricksen. Sprich, bei der Initialisierung werden alle CS aktiviert, danach nur einzeln. Könnte klappen. Aber irgendwann wird es albern.
Peter S. schrieb: > Und nein trotz Speicheranforderung brauche ich die Rechenleistung nicht, > ein AVR tut es ohne Probleme. Es geht wirklich um das Durchschleusen von > Daten und um eine vorhersehbare Reaktionszeit wenn ein anderer Bereich > angefordert wird. Es ist die Reaktionszeit die kritisch ist. Manchmal > reichen mehrere millisekunden und das Gerät wartet sogar auf ein ACK, > dann könnte ich es ja auch direkt von der SD-Card lesen, aber manchmal > sind es nur 30usec die ich Zeit habe bevor ich das erste byte senden > muss. Die Routine die das umsetzten muss besteht aus weniger als 100 > Assembler Instruktionen. Das schafft ein AVR locker in 30usec. Muss es RAM sein? Oder reicht Flash? Dann kann man einfach einen 512 oder 1024 Mbit Parallel-Flash an einen AVR anklemmen und auslesen. Einfach, preiswert, schnell.
OK, ich glaub so geht es. Man schaltet vier 16MB SDRAMs parallel! Damit werden sie alle gescheit angesteuert und auch mit Refresh versorgt. Der Trick ist in diesem Betrag zu finden. https://www.mikrocontroller.net/topic/goto_post/3931791 Durch die LDQM und UDQM wählt man aus, auf welchem Byte auf welchem IC die Daten landen sollen bzw. gelesen werden sollen! Damit muss man nur die acht xDQMs mit einem 1 aus 8 Dekoder ansteuern! Ein 74HC138 reicht! Der MUX steckt also schon in den SDRAMs.
Es darf auch Flash sein, aber gibt es das überhaupt, ein 1Gbit Flash das man via AVR ansprechen kann? Das letzte Mal als ich so etwas gesucht hatte, habe ich keines gefunden. Aber es wäre die ideale Lösung. Wer also einen 1Gbit Flash Baustein kennt den man an einem AVR einfach anschliessen kann (lesen und schreiben, irgendwie muss ich ja auch die Initialdaten schreiben) bitte melden. Das mit der FIFO Lösung ist eventuel eine Option, denn die schnellen Wechsel finden immer in einem Window von maximal 64kbyte statt. Aber ich weiss noch nicht wie das System reagiert, wenn es zwischen Windows wechselt und es länger dauert als eigentlich in der Beschreibung angegeben sind. Er sollte eigentlich auf ein ACK warten, aber andererseits steht da auch, dass der Wechsel zwischen Windows typischerweise <6ms dauern sollte. Aber in 6ms habe ich nicht 64kbyte von der SD-Card nachgeladen. D.h. wenn das Gerät einen Timer implementiert hat könnte es in einen Time-Out hinauslaufen, das möchte ich vermeiden, auch wenn das Gerät dann einen Retry macht. Werde ich natürlich ausprobieren sobald ich den Testsetup fertig habe. Die Übertragungsrate ist nicht das Problem, die Protokolumwandlung Parallel/Seriell macht ein Controllerbaustein für mich und die serielle Übertragungsrate beträgt etwa 4Mbps. D.h. ich muss etwa alle 2usec ein Byte übertragen. Auch nicht gerade die Herausforderung für einen AVR.
Falk B. schrieb: > OK, ich glaub so geht es. Man schaltet vier 16MB SDRAMs parallel! Und wo ist der Vorteil gegenüber einem DRAM-IC mit 64 MB? Peter S. schrieb: > Es darf auch Flash sein, aber gibt es das überhaupt, ein 1Gbit > Flash das > man via AVR ansprechen kann? Na logo, was denkst du ist in SD-Karten oder USB-Speichersticks drin? Viel Flash ist viel einfacher/billiger als viel RAM! Aber muss es unbedingt ein AVR sein? Sowas geht mit ARM's einfacher... Einfach mal blind eins rausgegriffen: https://www.micron.com/products/nor-flash/serial-nor-flash/part-catalog/mt25ql512abb8esf-0sit Peter S. schrieb: > Aber in 6ms habe ich nicht 64kbyte > von der SD-Card nachgeladen Das sind olle 10 MByte/Sec. Das schaffen SD-Karten sogar schreibend. Musst du halt per SD-Bus ("SDIO") und nicht per SPI machen.
Falk B. schrieb: > OK, ich glaub so geht es. Man schaltet vier 16MB SDRAMs parallel! Damit > werden sie alle gescheit angesteuert und auch mit Refresh versorgt. Der > Trick ist in diesem Betrag zu finden. > > https://www.mikrocontroller.net/topic/goto_post/3931791 > > Durch die LDQM und UDQM wählt man aus, auf welchem Byte auf welchem IC > die Daten landen sollen bzw. gelesen werden sollen! Damit muss man nur > die acht xDQMs mit einem 1 aus 8 Dekoder ansteuern! Ein 74HC138 reicht! > Der MUX steckt also schon in den SDRAMs. Danke. Das tönt doch schon sehr vielverprechend und das mit dem DQML/H statt Multiplexen ist eine super Idee denn davon weiss der SDRAM Controller nichts und somit stört es das Protokol nicht.
Peter S. schrieb: > Es darf auch Flash sein, aber gibt es das überhaupt, ein 1Gbit Flash das > man via AVR ansprechen kann? Aber sicher! Das ist schon fast trivial! S29GL01GS und dessen moderne Brüder. Die Ansteuerung kriegt man problemlos "zu Fuß" hin, einfach Adresse, CS uns OE anlegen, schwups hat man die Daten. Das Schreiben ist etwas aufwändiger aber auch problemlos mit dem AVR machbar. Im TSOP56 Gehäuse noch manuell lötbar.
Dr. Sommer schrieb: > Falk B. schrieb: >> OK, ich glaub so geht es. Man schaltet vier 16MB SDRAMs parallel! > > Und wo ist der Vorteil gegenüber einem DRAM-IC mit 64 MB? Man kann das ohne Handstände direkt an einem ATXmega betreiben!
Falk B. schrieb: > Man kann das ohne Handstände direkt an einem ATXmega betreiben! Achso. Der STM32F429 kann ohne Handstände direkt 256MB SDRAM oder NAND-Flash oder NOR-Flash ansprechen. Man braucht nur ein Board dafür...
Falk B. schrieb: > Peter S. schrieb: >> Es darf auch Flash sein, aber gibt es das überhaupt, ein 1Gbit Flash das >> man via AVR ansprechen kann? > > Aber sicher! Das ist schon fast trivial! > > S29GL01GS und dessen moderne Brüder. Die Ansteuerung kriegt man > problemlos "zu Fuß" hin, einfach Adresse, CS uns OE anlegen, schwups hat > man die Daten. Das Schreiben ist etwas aufwändiger aber auch problemlos > mit dem AVR machbar. > Im TSOP56 Gehäuse noch manuell lötbar. Wau was muss ich grosse Tomaten auf den Augen gehabt haben. Speicher ohne Ende zu günstigen Preisen. TSOP56 löten sollte kein Problem sein, ich löte ja regelmässig TQFP-100. Danke.
Dr. Sommer schrieb: >> OK, ich glaub so geht es. Man schaltet vier 16MB SDRAMs parallel! > > Und wo ist der Vorteil gegenüber einem DRAM-IC mit 64 MB? Er muss keine Adressleitung multiplexen.
:
Bearbeitet durch User
Auch SDRAMs werden mit gemultiplexten Adressleitungen angesteuert, das ist nun wirklich nichts neues. Könnte hier möglicherweise irgendwer einem Missverständnis unterliegen? SRAMs werden üblicherweise nicht mit gemultiplexten Adressen angesteuert, aber die haben auch aus diesem Grunde erheblich kleinere Kapazitäten. Ein --hypothetisches-- 64-MByte-SRAM mit 8 Bit Datenbusbreite müsste 26 Adressleitungen haben.
Nein es geht um die zusätzlichen Addressleitungen. Der ATXMEGA multiplexed nur eine beschränkte Anzahl von Leitungen. Für mehr als 8Mbyte muss man zu Tricks greifen. Selbst weitere Addressleitungen zu multiplexen geht nicht. Aber bytes via DQMs zu multiplexen das geht, das hat keinen Einfluss auf das SDRAM Controller Protocol. Auf alle Fälle vielen Dank für die vielen Anregungen. Jetzt geht es zuerst mal ans ausprobieren der verschiedenen Lösungsansätze.
Peter S. schrieb: > TSOP56 löten sollte kein Problem sein 512MBit Flash gibt es auch im SOIC16: https://de.farnell.com/cypress-semiconductor/s25fl512sagmfig11/flash-speicher-512mb-16soic/dp/2340548 Read: 52MB/s Write: 1,5MB/s
:
Bearbeitet durch User
512Mbit via SPI, auch sehr schön. Das würde sich auch in einem anderen meiner Projekte das mit einer SD-CARD arbeitet, aber wo ich nur 4 x 10Mbyte brauche sehr gut machen. Und natürlich auch für dieses Projekt.
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.