Forum: Mikrocontroller und Digitale Elektronik MCU mit 64Mbyte RAM


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Peter S. (cbscpe)


Lesenswert?

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

von Seitenaufteilung aktivieren (Gast)


Lesenswert?

Wie wäre es, die 2 fehlenden Adressleitungen über stinknormale Portpins 
zu lösen? Du brauchst halt sowas wie paging dann...

von Johannes M. (johannesm)


Lesenswert?

z.B. SAMV71, SAME70 oder ähnliche. Können bis zu 256 MB ansprechen.

von Mike J. (linuxmint_user)


Lesenswert?

Was willst du denn eigentlich machen?

Vielleicht gibt es für deinen Anwendungsfall eine bessere Lösung.

von Peter S. (cbscpe)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Lass es besser sein (Gast)


Lesenswert?

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

von Frank K. (fchk)


Lesenswert?

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
von Dr. Sommer (Gast)


Lesenswert?

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€.

von Dr. Sommer (Gast)


Lesenswert?

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.

von PittyJ (Gast)


Lesenswert?

Da gibt es doch ARMs an jeder Ecke. Man muss sich nur von der 
Atmal-Schiene lösen.

von Peter S. (cbscpe)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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.

von Max M. (maxmicr)


Lesenswert?

Kann man das auch per SPI erledigen? Also wären 20MHz SPI schnell genug?

von Dr. Sommer (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Peter S. (cbscpe)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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.

von Peter S. (cbscpe)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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!

von Dr. Sommer (Gast)


Lesenswert?

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...

von Peter S. (cbscpe)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter S. (cbscpe)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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
von Peter S. (cbscpe)


Lesenswert?

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.

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]
  • [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.