Forum: Mikrocontroller und Digitale Elektronik Viel RAM am kleinen Controller


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 Falk B. (falk)


Lesenswert?

Hallo Gemeinde,

ich möchte 4-8MB RAM an einen kleinen uC anflanschen. AVR geht nicht 
wirklich, auch wenn man es über manuelles Banking und externes 
Businterface hinbekommen würde. Das Problem ist eher der Preis, 2Mx8 
SRAM kosten so um die 15 Euro bei Digikey, 4-8Mb also 30-60 Euro. 
Uncool.

ATXmega kann SDRAM, leider ist die blumige Ankündigung eines 4 
Port-Modus und 8 Bit Datenbus reine Theorie. Es gibt bislang keine 
ATXmegas mit 4 EBI Ports (Port L fehlt, größtes Gehäuses sind TQFP100).

Beitrag "Re: XMega 128 mit 32MByte SDRAM betreiben"

Die STM32F4 können nur SRAM/Flash ansteuern, hier das gleiche 
Preisproblem, wenn gleich man damit deutlich mehr CPU-Power bekommt (die 
aber in der Anwendung nicht benötigt werden, ein ATXmega mit 32 MHz 
würde gut passen).

Welche Alternativen gibt es? Nein, bitte keine Bastellösungen ala SDRAM 
"zu Fuß" ansteuern. Exotische SDRAMs mit 4 oder 8 Bit Datenbus sind 
keine Option, es geht nicht nur um Einzellösungen, das Zeug soll in den 
nächsten 5 Jahren produzierbar bleiben.

Ein "großer" ARM9 oder so von Atmel kann SDRAM und NOR/NAND-Flash 
ansprechen, ist aber erst recht Overkill und in der Benutzung OHNE Linux 
etc. nicht sonderlich einfach. Also sind auch Dinger ala Raspberry Pi 
aus dem Rennen.

Im Moment tendiere ich einfach zu normalem 128 Mbit SDRAM in 
Konfiguration 8Mx16, das ist Standardzeug und in ein paar Jahren noch 
verfügbar. Allerdings bleiben dann nur 2MB Speicher (wegen 4 Bit 
Datenbus, 12 Bit ungenutzt!), das gefällt mir nicht so ganz. 256 Mbit 
kann der ATXmega nicht ansteuern, es fehlt A12. Manuell reinmogeln über 
ein GPIO? Banking ist hier denkbar. Oder spuckt man da dem Refresh in 
die Suppe?

Ja, es gibt noch PSRAM, ein DRAM mit SRAM Interface. Aber das sind auch 
Exoten, bei Digikey gibt sie es nur im BGA Gehäuse, das kann ich aber 
als Prototyp nicht selber löten, ausserdem gibt es keine Auswahl/große 
Verfügbarkeit.

Wer hat Ideen und Empfehlungen? Wie sieht es im LPC-Lager aus? Sind dort 
SDRAM-Interfaces in "kleinen" Controllern verfügbar?

MFG
Falk

: Verschoben durch Moderator
von holger (Gast)


Lesenswert?

>Die STM32F4 können nur SRAM/Flash ansteuern, hier das gleiche

Die STM32F429 können SDRAM ansteuern.
Zum testen auch als STM32F429-Discovery mit 8MB und
320x240 RGB Display für ca 30Euro zu haben.

von Frank K. (fchk)


Lesenswert?

http://www.nxp.com/products/microcontrollers/cortex_m3/lpc1800/#products
Die können SDRAM ansteuern. Oder LPC177x/178x.

fchk

von Haro (Gast)


Lesenswert?


von Jens (Gast)


Lesenswert?

Falk Brunner schrieb:
> Welche Alternativen gibt es? Nein, bitte keine Bastellösungen ala SDRAM
> "zu Fuß" ansteuern.
Ich habe hier einen 30-poligen SIMM-Riegel am ATmega128.
Als gebastel würde ich es nicht bezeichnen. 256k, 1 MByte und 4 MByte, 
alle Riegel funktionieren problemlos. Der Refresh benötigt nicht 
wirklich viel Rechenzeit. Unschön ist die 'Zugriffszeit' (row adress, 
column adress, data IO).
Problematisch ist aber definitiv die von Dir geforderte Verfügbarkeit.

Aber alles was nach DRAM kommt (SDRAM, DDR, DDR2, ...) würde ich nicht 
mehr per Software ansteuern wollen, sondern nur mit einem ordentlichen 
Memory-Controller.

Jens

von Georg (Gast)


Lesenswert?

Falk Brunner schrieb:
> Das Problem ist eher der Preis, 2Mx8
> SRAM kosten so um die 15 Euro bei Digikey, 4-8Mb also 30-60 Euro.
> Uncool.

SRAM 512kx8 kostet rund 2 EUR, 4 MB also 16 EUR. Da ist es schon 
fraglich, ob sich der Aufwand für DRAM lohnt. Dass solche Chips heute 
nur in SMD lieferbar sind, damit wirst du dich wohl oder übel abfinden 
müssen, und im BGA ist der Platzverbrauch nur 1/4 von 
Gull-Wing-Bauformen.

Falk Brunner schrieb:
> das Zeug soll in den
> nächsten 5 Jahren produzierbar bleiben.

Dann solltest du auch Bausteine nach heutiger Technologie einsetzen und 
dich nicht danach richten, was du von Hand löten kannst. Nostalgie ist 
kein guter Ratgeber für zukunftssichere Produkte.

Georg

von (prx) A. K. (prx)


Lesenswert?

Jens schrieb:
> Ich habe hier einen 30-poligen SIMM-Riegel am ATmega128.

Bei "das Zeug soll in den nächsten 5 Jahren produzierbar bleiben" würde 
ich nicht unbedingt auf eBay als Bezugsquelle setzen wollen. Oder werden 
diese Riegel tatsächlich noch produziert.

von Jens (Gast)


Lesenswert?

A. K. schrieb:
> Oder werden
> diese Riegel tatsächlich noch produziert.
Kein Ahnung. Aber deswegen schrieb ich auch:

Jens schrieb:
> Problematisch ist aber definitiv die von Dir geforderte Verfügbarkeit.

Anders sieht es bei den Sockeln aus:
http://de.rs-online.com/web/c/steckverbinder/ic-sockel/simm/
Trotzdem: Thema verfehlt...

Georg schrieb:
> Dann solltest du auch Bausteine nach heutiger Technologie einsetzen und
> dich nicht danach richten, was du von Hand löten kannst. Nostalgie ist
> kein guter Ratgeber für zukunftssichere Produkte.
Diesen Rat würde ich auch beherzigen.

Jens

von Falk B. (falk)


Lesenswert?

>Konfiguration 8Mx16, das ist Standardzeug und in ein paar Jahren noch
>verfügbar. Allerdings bleiben dann nur 2MB Speicher (wegen 4 Bit
>Datenbus, 12 Bit ungenutzt!), das gefällt mir nicht so ganz.

Moment, ich glaub hier war ich mal wieder im Kopfrechnen schwach. 128 
Mbit als 8Mx16Bit ergeben bei 4 Bit Datenbus immer noch 8Mx4 d.h. 4MB. 
Damit ist das Minimalziel erreicht. 8MB sind nur nice to have.

Ich hab schon überlegt, ob man das 2. Nibble mit einem Trick in das 2. 
Byte speichern kann. Wenn man A0 einmal mit LDQM sowie invertiert mit 
UDQM verbindet, könnte man vielleicht in ein 16 Bit Wort zwei Nibble 
speichern. Aber ich glaube durch das Multiplexind der RAS/CAS Adressen 
klappt das nicht so ganz. Muss ich morgen mal in Ruhe durchdenken. Ist 
aber nur nice to have.

von Falk B. (falk)


Lesenswert?

@Georg (Gast)

>> Das Problem ist eher der Preis, 2Mx8
>> SRAM kosten so um die 15 Euro bei Digikey, 4-8Mb also 30-60 Euro.
>> Uncool.

>SRAM 512kx8 kostet rund 2 EUR, 4 MB also 16 EUR.

Das wären 8 ICs. Naja.

> Da ist es schon
>fraglich, ob sich der Aufwand für DRAM lohnt.

Welcher Aufwand? SDRAM kann man direkt an den ATXmega anschließen, Plug 
& Play.

> Dass solche Chips heute
>nur in SMD lieferbar sind, damit wirst du dich wohl oder übel abfinden
>müssen,

Das war gar nicht das Problem.

>und im BGA ist der Platzverbrauch nur 1/4 von Gull-Wing-Bauformen.

Mag sein, ist hier aber unkritisch.

>Dann solltest du auch Bausteine nach heutiger Technologie einsetzen und
>dich nicht danach richten, was du von Hand löten kannst. Nostalgie ist
>kein guter Ratgeber für zukunftssichere Produkte.

Stimmt schon, aber so gaaaanz zwingend ist BGA noch nicht ganz. Aber 
dass SDRAM allgemein und in nicht-BGA Gehäusen im Speziellen schon lange 
auf dem absteigenden Ast ist, ist schon klar. Naja, im Zweifelsfall nehm 
ich halt doch BGA.

von avr (Gast)


Lesenswert?

Falk Brunner schrieb:
> ATXmega kann SDRAM, leider ist die blumige Ankündigung eines 4
> Port-Modus und 8 Bit Datenbus reine Theorie. Es gibt bislang keine
> ATXmegas mit 4 EBI Ports (Port L fehlt, größtes Gehäuses sind TQFP100).

Mit SDRam hab ich das nie getestet, allerdings mit SRAM. Die neueren 
AtXmegas (in deinem Fall xmega*a1u) können die fehlenden 8pins auf PORTE 
oder PORTF mappen (EBIOUT-Register). Damit sollte 8bit SDRam, wie 
angekündigt, funktionieren.
1
The maximum configuration of the external bus interface (EBI) requires up to 32 dedicated pins. For devices with
2
only 24 EBI pins available, eight additional pins can be
3
enabled and placed on alternate pin locations in order to
4
get a full 32-pin EBI. The port pins must be configured as
5
output for signals to be available on the pins. These bits
6
are available on devices with only three ports dedicated for the EBI interface. The selections are valid only if the
7
EBI is configured to operate in four-port mode.

von Stefan (Gast)


Lesenswert?

Du kannst auch den AT32UC3C0 nehmen (von 64K-512K flash)
Preise gehen bei Digikey mit 6$ los und immer noch überschaubares 144pin 
Package.

von (prx) A. K. (prx)


Lesenswert?

Falk Brunner schrieb:
> Aber ich glaube durch das Multiplexind der RAS/CAS Adressen
> klappt das nicht so ganz.

Doch das geht. A0 geht in diesem Fall nur an die Byteselects, hat mit 
dem Muxing nichts zu tun. Die gemuxten RAM Adressen leiten sich von A1 
aufwärts ab. Der Refresh wird keine Adressen brauchen, nehme ich an, 
aber andererseits ist es egal, obs A0 oder Asonstwas ist.

: Bearbeitet durch User
von grundschüler (Gast)


Lesenswert?

meine Suche
Beitrag "Zusatz-Speicher für AVR/ARM mx29lv?"
nach Speicher hat beim stm32f429 geendet.
Stm verbaut bei seinen 25€-boards 64Mbit Speicher. Die müssen also recht 
billig sein. Wenn du das komplette board nicht nehmen willst, schau dir 
mal an welchen Speicher Stm verbaut - is42s16400j.

von Markus M. (mmvisual)


Lesenswert?


von Falk B. (falk)


Lesenswert?

@ A. K. (prx)

>> Aber ich glaube durch das Multiplexind der RAS/CAS Adressen
>> klappt das nicht so ganz.

>Doch das geht. A0 geht in diesem Fall nur an die Byteselects, hat mit
>dem Muxing nichts zu tun. Die gemuxten RAM Adressen leiten sich von A1
>aufwärts ab.

Schon klar, aber durch das Multiplexen fehlt beim RAS das A0, wenn ich 
mich nicht irre. Beispiel.

Der von mir anvisierte 128Mbit SDRAM hat 12 Bit RAS und 9 Bit CAS 
Adressen, plus die 2 Bank Select Bits macht das 23 Bit bzw. 8M 
Adressraum. Scheint zu passen ;-)
OK, den ATXmega kann man so konfigurieren. ABER! Die interne Adresse 
wird ja gemultiplext! D.h.

Im RAS Zyklus werden A9-A22 über die Leitungen A0-A11 + die beiden 
BA0/Ba1 übertragen
Im CAS Zyklus werden A0-A8 über die Leitungen A0-A8 + die beiden BA0/BA1 
übertragen

Wenn wir jetzt tricksen wollen, und A0 als MUX Bit vom Adressbus 
abkoppeln und nur A1-A11 verdrahten, dann fehlt A0 im RAS Zyklus!

Das wird wohl leider doch nichts. :-0

von Falk B. (falk)


Lesenswert?

@ avr (Gast)

>AtXmegas (in deinem Fall xmega*a1u) können die fehlenden 8pins auf PORTE
>oder PORTF mappen (EBIOUT-Register). Damit sollte 8bit SDRam, wie
>angekündigt, funktionieren.

Huh! Das klingt ja mal gut! Wo steht das? Im Datasheet oder USer Manual?

OK, habs gefunden, im XMEGA AU Manual unter 13.14.5 EBIOUT – EBI Output 
register.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Falk Brunner schrieb:
> Wenn wir jetzt tricksen wollen, und A0 als MUX Bit vom Adressbus
> abkoppeln und nur A1-A11 verdrahten, dann fehlt A0 im RAS Zyklus!

Es zwingt dich niemand, ausgerechnet A0 zu verwenden. Ich habe grad 
keines der beiden Datasheets rumliegen, aber da sollte es doch irgendein 
Bit geben, das übrig bleibt, z.B. wenn man so tut als sei das RAM 
grösser als es wirklich ist. Oder der Xmega kann mehr als 1 SDRAMChip 
ansteuern, dann muss es irgendeine Art Chipselect geben.

Ein 128Mbx16 DRAM hat 8M Worte = 23 Bits. Da man nur eine gradzahlige 
Anzahl Bits muxen kann müsste eines übrig bleiben.

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

@ A. K. (prx)

>> Wenn wir jetzt tricksen wollen, und A0 als MUX Bit vom Adressbus
>> abkoppeln und nur A1-A11 verdrahten, dann fehlt A0 im RAS Zyklus!

>Es zwingt dich niemand, ausgerechnet A0 zu verwenden.

Jain. Es muss aber ein Bit vom CAS sein, sonst wird das nix mit dem 
Zugriff innerhalb einer Page.

> Ich habe grad
>keines der beiden Datasheets rumliegen, aber da sollte es doch irgendein
>Bit geben, das übrig bleibt, z.B. wenn man so tut als sei das RAM
>grösser als es wirklich ist.

Geht glaub ich nicht, weil der ATXmega nur 11-12 Bits für RAS und 8-11 
Bits für CAS ansteuern kann. Man bräuchte 1 CAS Bit mehr als RAS. Haben 
wir aber nicht!

> Oder der Xmega kann mehr als 1 SDRAMChip
>ansteuern,

Kann er nicht.

> dann muss es irgendeine Art Chipselect geben.

Gibt es, aber nur 1.

Aber das Problem scheint mit dem Portmapping gelöst. Damit kann man 
einen 128 Mbit x16 SDRAM immerhin mit 8MB direkt ansteuern. (Wenn es 
denn wie im Datenblatt beschrieben funktioniert)

Beitrag "Re: Viel RAM am kleinen Controller"

Ich melde mich, wenn ich die Hardware habe und es hoffentlich läuft. Das 
wird so Anfang nächsten Jahres sein.

Danke an alle Beteiligten.

von (prx) A. K. (prx)


Lesenswert?

Falk Brunner schrieb:
> Jain. Es muss aber ein Bit vom CAS sein, sonst wird das nix mit dem
> Zugriff innerhalb einer Page.

Und wenn es eine RAS Adresse ist, dann brauchst du ein Latch oder 
Register. Aber wenn der Xmega tatsächlich nur 23 Adressbits muxen kann, 
egal wie konfiguriert, dann gibts wirklich nichts.

Edit: Atmel schreibt, die könnten 16MB SDRAMs adressieren. Das sind 24 
Adressbits. Klingt nach 2x12 Bits. Da du oben von 12 RAS und 11 CAS Bits 
geschrieben hast müsste genau ein CAS Bits übrig sein. Hast du einen 
Link auf die Doku vom EBI?

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

holger schrieb:
> Die STM32F429 können SDRAM ansteuern.
> Zum testen auch als STM32F429-Discovery mit 8MB und
> 320x240 RGB Display für ca 30Euro zu haben.

Das Problem beim F429 ist lediglich die völlig irrsinnige 
Anschlussbelegung für den RAM. Der STM'ler, der sich die ausgedacht hat, 
sollte mal einen Arzt aufsuchen. Ansonsten funktioniert der RAM gut und 
schnell.

http://mikrocontroller.bplaced.net/wordpress/wp-content/uploads/2013/10/Pinbelegung_f429_v100.html

von Falk B. (falk)


Lesenswert?

@ A. K. (prx)

>Edit: Atmel schreibt, die könnten 16MB SDRAMs adressieren. Das sind 24
>Adressbits. Klingt nach 2x12 Bits. Da du oben von 12 RAS und 11 CAS Bits
>geschrieben hast müsste genau ein CAS Bits übrig sein. Hast du einen
>Link auf die Doku vom EBI?

http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf

von (prx) A. K. (prx)


Lesenswert?

Das sind ja wirklich Spassvögel bei Atmel. Schreiben rein, dass sie 
128Mb SDRAMs adressieren können. Aber meinen damit 128Mbx16 Typen mit 8 
angeschlossenen Datenbits, weshalb der Speicher nur halb genutzt werden 
kann. Und das schreiben sie natürlich nicht rein. Kannst ja den 
Byteselect per Software als Bankselect hinzufügen ;-)

: Bearbeitet durch User
von Max D. (max_d)


Lesenswert?

Bevor du ewig hinter irgendwelchen Lösungen her-rennst nimm einen RPi. 
Der kostet inzwischen (als Einzelstück) bei der angelika 23 € (für das a 
modell). Für den Preis kriegst du im Extremfall nichtmal deinen 
Wunsch-SRAM. Mit dem Pi hast du aber auch gleichzeitig ein OS das alles 
für dich erledigt. Wenn du es etwas spartanischer willst wüsste ich noch 
den Arrietta G25 (ist aber nur marginal billiger).
Solange du nicht tausende Stück herstellen willst ist die Lösung einfach 
durch die gesparte Zeit viel billiger...

von Markus H. (dasrotemopped)


Angehängte Dateien:

Lesenswert?

>Atmel schreibt, die könnten 16MB SDRAMs adressieren. Das sind 24
>Adressbits.

Bei SRAM ja, bei SDRAM, nein.
SDRAM wird in Bursts gelesen, je nach Chip von 512 bis 2048 Datenpakete 
pro Burst. Die Adressleitungen sind wesendlich weniger bei SDRAM als bei 
SRAM bei gleicher Speichergröße, die addressiert wird.
Der STM32F429 hat z.B einen 16Bit Datenbus mit max 13 Adressleitungen 
und kann so pro SDRAM Bank 64MB adressieren. (Im großen Gehäuse auch mit 
32bit Datenbus, FYI)

>Aber meinen damit 128Mbx16 Typen mit 8 angeschlossenen Datenbits, weshalb >der 
Speicher nur halb genutzt werden kann.

Auch falsch, SDRAM kann(muss aber nicht) bei 16 bit Datenbus im Byte 
Modus arbeiten, da hat man noch mal alles in upperByte und lower Byte 
aufgeteilt.

Beim Xmega bietet sich SDRAM an statt SRAM, wegen mehr Speicher bei 
weniger belegten IOs, vom Preis mal ganz abgesehen.

Gruß,

dasrotmeopped.

von Falk B. (falk)


Lesenswert?

@ Max D. (max_d)

>Bevor du ewig hinter irgendwelchen Lösungen her-rennst nimm einen RPi.

Nö. Sagte ich bereits.

>Wunsch-SRAM. Mit dem Pi hast du aber auch gleichzeitig ein OS das alles
>für dich erledigt.

Ja, vor allem mich und meine Anwendung. ;-)

Das ganze braucht ein SEHR präzises Timing mit möglichst geringem 
Jitter, das macht man am einfachsten un Besten ohne OS. Das Ganze läuft 
ja schon fix und fertig! Jetzt geht es darum, den bisherigen Speicher 
(serieller Flash) gegen SDRAM zu tauschen. Dasd bringt Weniger CPU-Last 
und unbegrenzte Schreibzyklen.

>Solange du nicht tausende Stück herstellen willst ist die Lösung einfach
>durch die gesparte Zeit viel billiger...

Wenn man nur einen Hammer hat, sieht alles wie ein Nagel aus.

von Falk B. (falk)


Lesenswert?

@Markus Horbach (dasrotemopped)

>SDRAM wird in Bursts gelesen, je nach Chip von 512 bis 2048 Datenpakete
>pro Burst.

Oder auch deutlich weniger. Es kann auch 1 sein, was AFAIK ich beim 
ATXmega auch der Fall ist. Denn der hat keinen Cache. Damit wird der 
SDRAM zwar erheblich ausgebremst, aber für den AVR reicht es noch.

>>Aber meinen damit 128Mbx16 Typen mit 8 angeschlossenen Datenbits, weshalb >>der 
Speicher nur halb genutzt werden kann.

>Auch falsch, SDRAM kann(muss aber nicht) bei 16 bit Datenbus im Byte
>Modus arbeiten, da hat man noch mal alles in upperByte und lower Byte
>aufgeteilt.

Ja und? Was nützt dir das, wenn dein Controller nur einen 8 Bit Datenbus 
hat? Auf die 2. Hälfte kann man bei einem x16 SDRAM NICHT zugreifen, das 
haben wir hier ja ne ganze Weile diskutiert!

>Beim Xmega bietet sich SDRAM an statt SRAM, wegen mehr Speicher bei
>weniger belegten IOs, vom Preis mal ganz abgesehen.

Du trägst Eulen nach Athen.

von uwe (Gast)


Lesenswert?

>Ja und? Was nützt dir das, wenn dein Controller nur einen 8 Bit Datenbus
>hat? Auf die 2. Hälfte kann man bei einem x16 SDRAM NICHT zugreifen, das
>haben wir hier ja ne ganze Weile diskutiert!

Naja wenn man D7-D0 mit D15-D8 verbindet und immer nur einen select per 
Hardware zuläßt (z.B. mit 74138). Die nicht aktive Bushälfte ist ja beim 
Read Hochohmig und wird beim write nicht beachtet.

von uwe (Gast)


Lesenswert?

Sollte doch gehen oder hab ich nen Denkfehler?

von Falk B. (falk)


Lesenswert?

@ uwe (Gast)

>>hat? Auf die 2. Hälfte kann man bei einem x16 SDRAM NICHT zugreifen, das
>>haben wir hier ja ne ganze Weile diskutiert!

>Naja wenn man D7-D0 mit D15-D8 verbindet und immer nur einen select per
>Hardware zuläßt (z.B. mit 74138).

Das hatten wir alles schon diskutiert. Der MUX ist eigentlich schon im 
SDRAM drin und kann über die beiden UDQM/LDQM EIngänge gesteuert werden. 
Es passt aber nicht mit der getricksten Adressierung! Lies den Thread!

von uwe (Gast)


Lesenswert?

Also im is42s16400j ist kein MUX drinne. LDQM und UDQM schalten bei High 
Signal im Read Modus in den hochohmigen Zustand und bei write wird halt 
ignoriert was da gerade an der entsprechenden Bushälfte anliegt.
Wen ich das richtig gelesen hab müßte sich CS3 als Signal zum steuern 
von LDQM und UDQM so wie ich vorhin geschrieben nutzen lassen.
Warum sollte das nicht gehen. wenn nicht muß man halt per Software auf 
die obere oder untere hälfte umschalten.

von uwe (Gast)


Lesenswert?

Hab mir gerade das XMEGA AU Datenblatt EBI ab S.319 und das Datenblatt 
vom RAM angeschaut und sehen jetzt keinen Grund warum das nicht gehen 
sollte.

von Falk B. (falk)


Lesenswert?

@ uwe (Gast)

>Also im is42s16400j ist kein MUX drinne. LDQM und UDQM schalten bei High
>Signal im Read Modus in den hochohmigen Zustand und bei write wird halt
>ignoriert was da gerade an der entsprechenden Bushälfte anliegt.

Eben DAS ist praktisch ein MUX! Denk mal nach.

>Wen ich das richtig gelesen hab müßte sich CS3 als Signal zum steuern
>von LDQM und UDQM so wie ich vorhin geschrieben nutzen lassen.

Nein.

>Warum sollte das nicht gehen. wenn nicht muß man halt per Software auf
>die obere oder untere hälfte umschalten.

Das wirst du kaum schaffen, wenn der SDRAM mit vollem Takt am ATXmega 
läuft. Und "zu Fuß" will den keiner ansteuern.

von Falk B. (falk)


Lesenswert?

@ uwe (Gast)

>Hab mir gerade das XMEGA AU Datenblatt EBI ab S.319 und das Datenblatt
>vom RAM angeschaut und sehen jetzt keinen Grund warum das nicht gehen
>sollte.

Lies den Thread! Oder bau es PRAKTISCH auf und beweise, dass es doch 
geht. Wir lassen uns gern eines Besseren belehren, aber nur mit 
praktischen Ergebnissen!

von (prx) A. K. (prx)


Lesenswert?

uwe schrieb:
> Hab mir gerade das XMEGA AU Datenblatt EBI ab S.319 und das Datenblatt
> vom RAM angeschaut und sehen jetzt keinen Grund warum das nicht gehen
> sollte.

Weil der Xmega bei SDRAM Zugriff nur 23 Adressbits kann, 12 RAS und 11 
CAS. Das reicht nicht für die ganzen 16MB des 128Mbit RAMs.

Man müsste einen Portpin für Bankswitching opfern.

von uwe (Gast)


Lesenswert?

> Eben DAS ist praktisch ein MUX!
Sind nur zwei tristate Buffer. Mit denen kann man sich nen MUX basteln 
wenn man die Enable Leitungen invertiert ansteuert und die Datenpins der 
oberen und unteren hälfte miteinander verbindet.
>Das wirst du kaum schaffen, wenn der SDRAM mit vollem Takt am ATXmega
>läuft. Und "zu Fuß" will den keiner ansteuern.
>> Jetzt geht es darum, den bisherigen Speicher
>>(serieller Flash) gegen SDRAM zu tauschen.
Hört sich an als hätte er viel Zeit zum umschalten.Er kann die unteren 
8MByte vollschreiben und dann ganz locker auf die oberen umschalten. 
Oder er benutzt die oberen für was ganz anderes.

von Falk B. (falk)


Lesenswert?

@ uwe (Gast)

>> Eben DAS ist praktisch ein MUX!
>Sind nur zwei tristate Buffer. Mit denen kann man sich nen MUX basteln
>wenn man die Enable Leitungen invertiert ansteuert und die Datenpins der
>oberen und unteren hälfte miteinander verbindet.

EBEN!

>>> Jetzt geht es darum, den bisherigen Speicher
>>>(serieller Flash) gegen SDRAM zu tauschen.

>Hört sich an als hätte er viel Zeit zum umschalten.

>Er kann die unteren
>8MByte vollschreiben und dann ganz locker auf die oberen umschalten.
>Oder er benutzt die oberen für was ganz anderes.

Ja, das kann man machen.

OK, ich glaube jetzt verstehe ich. Meine/unser Ziel war es am Anfang, 
das Ganze OHNE Bankumschaltung hinzutricksen, geht aber nicht.
Wenn man aber mit Bankumschaltung leben kann (was in meiner Anwendung 
der Fall ist), dann kann man über die LDQM und UDQM eine Bankumschaltung 
realisieren. Jetzt hab ich's auch kapiert ;-)

Na dann will ich mal die 16MB an den ATXmega anflanschen (ist schon ein 
wenig aberwitzig an einem 8 Bitter, mein guter alter Amiga hatte damals 
nur 8MB FastRAM, dafür aber nen 68030er auf der Turbokarte ;-)

von Frank K. (fchk)


Lesenswert?

Und warum nicht einfach einen geeigneten Cortex M3/M4 nehmen? Ganz ohne 
Tricks? Einfach nur nach Kochrezept aus Datenblatt und Evalboard? Gibt 
ja genügend davon. NXP, STM und TI verkaufen Dir sogar welche. Du kannst 
auch einen ARM7 wie zB LPC2368 verwenden, wenn es sehr gut abgehangen 
und ja nicht zu leistungsfähig sein darf.

fchk

von Falk B. (falk)


Lesenswert?

@ Frank K. (fchk)

>Und warum nicht einfach einen geeigneten Cortex M3/M4 nehmen?

Ja, kann man machen, aber der ATXmega ist halt deutlich näher am AVR ;-)
Jaja, ARM ist schon irgendwie zukunftsweisender und man muss auch keine 
Handstände mit Pointern etc. machen. Beim nächsten Projekt vielleicht 
;-)

> Ganz ohne Tricks?

Tricksen muss ich ja nicht wirklich. 8MB sind direkt verfügbar, die 2. 
8MB mit einem minimalen Trick. Da hab ich schon deutlich schlimmere 
Sachen machen müssen.

> Einfach nur nach Kochrezept aus Datenblatt und Evalboard?

Ist hier nicht anders.

>auch einen ARM7 wie zB LPC2368 verwenden, wenn es sehr gut abgehangen
>und ja nicht zu leistungsfähig sein darf.

;-)

Trotzdem Danke.

von Frank K. (fchk)


Lesenswert?

oder AVR32, da gibts auch etliche mit SDRAM Interface.

fchk

von Falk B. (falk)


Lesenswert?

@ Frank K. (fchk)

>oder AVR32, da gibts auch etliche mit SDRAM Interface.

Ist mir zu exotisch, da bin ich eher ein Mainstreamer.

von avr (Gast)


Lesenswert?

Ein Punkt für den xmega ist evtl. auch der preis. Cortexe mit sdram 
interface kosten erschreckenderweise mehr als das doppelte. Zumindest 
kenne ich keinen den man einzeln unter 10€ bekommt.

von Falk B. (falk)


Lesenswert?

@ avr (Gast)

>Ein Punkt für den xmega ist evtl. auch der preis. Cortexe mit sdram
>interface kosten erschreckenderweise mehr als das doppelte. Zumindest
>kenne ich keinen den man einzeln unter 10€ bekommt.

Die STM429 kosten bei Digikey unm die 15-18 Euro. Für so eien Controller 
mit 2 MB Flash, RAM etc. finde ich das OK. Der Preis spielt hier aber 
keine große Rolle. Ist kein Massenprodukt und auch nicht preissensitiv 
sondern Spezialmesstechnik.

von m.n. (Gast)


Lesenswert?

Falk Brunner schrieb:
> Das Problem ist eher der Preis,

Falk Brunner schrieb:
> Der Preis spielt hier aber
> keine große Rolle. Ist kein Massenprodukt und auch nicht preissensitiv
> sondern Spezialmesstechnik.

Preis ja, oder Preis nein?

Sieh Dir mal die 2M x 8 und 4M x 8 an; da würde ich mich nicht mit SDRAM 
beschäftigen zumal es ja nur um 4-8 MB geht. 
https://www.schukat.com/schukat/schukat_cms_de.nsf/index/warengruppe?OpenDocument&wg=Y8327&refDoc=CMSF9DC7BDB79B07DCFC12570C70035E16C

von Frank K. (fchk)


Lesenswert?

avr schrieb:
> Ein Punkt für den xmega ist evtl. auch der preis. Cortexe mit sdram
> interface kosten erschreckenderweise mehr als das doppelte. Zumindest
> kenne ich keinen den man einzeln unter 10€ bekommt.

Gegenbeispiel:
http://de.farnell.com/nxp/lpc1774fbd144-551/mcu-32bit-arm-cortex-m3-144lqfp/dp/2094297
http://de.farnell.com/nxp/lpc1774fbd208-551/mcu-32bit-arm-cortex-m3-208lqfp/dp/2094298
http://de.farnell.com/nxp/lpc1830fbd144-551/mcu-32bit-arm-cortex-m3-144lqfp/dp/2094309

Farnell ist auch eher teuer.

fchk

von Falk B. (falk)


Lesenswert?

@m.n. (Gast)

Auch zitieren will gelernt sein.

>> Das Problem ist eher der Preis,

Hier ging es um den Preis von SRAM und PSRAM. Da waren 30-60 Euro im 
Gespräch.

>Sieh Dir mal die 2M x 8 und 4M x 8 an; da würde ich mich nicht mit SDRAM
>beschäftigen zumal es ja nur um 4-8 MB geht.
>https://www.schukat.com/schukat/schukat_cms_de.nsf...

Nö, das Thema ist doch durch. Wenn der ATXmega sein eigenes Datenblatt 
kennt, dann krieg ich 16MB für schlappe 3 Euro zum laufen. Gekauft.

von m.n. (Gast)


Lesenswert?

Falk Brunner schrieb:
> Auch zitieren will gelernt sein.

Na, dann übe ich noch ein wenig.

Falk Brunner schrieb:
> Ist kein Massenprodukt und auch nicht preissensitiv
> sondern Spezialmesstechnik.

Falk Brunner schrieb:
> dann krieg ich 16MB für schlappe 3 Euro zum laufen.

'Spezialmesstechnik'? Doch wohl eher Billigbastelkram ;-)

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

Wie es aussieht, lief der SDRAM auf Anhieb. Das klingt zwar immer 
gefährlich, wenn Sachen ohne Probleme gleich funktionieren, ist aber 
manchmal so ;-) Super schnell ist er nicht, nach meinen Messungen 
~6.7MB/s Datendurchsatz bei Nutzung von DMA. Nicht wirklich viel für 
einen SDRAM mit 65 MHz Takt, ist aber nun mal so. Der SDRAM-Controller 
im ATXmega ist sehr einfach gestrickt, der nutzt den SDRAM nur sehr 
schwach aus. Ist aber immerhin ca. 7-8mal schneller als meine bisherige 
Lösung mit seriellem Flash. Der ATXmega gefällt mir jeden Tag besser ;-)
Als Massenspeicher mit Blocktransfer via DMA ist der SDRAM schon OK, als 
Arbeitspeicher mit direkter Nutzung im Programm ist er eher weniger 
geeignet, wenn es auf Geschwindigkeit ankommt. Denn der Zugriff ist 
lahm, ca. 5 CPU Takte braucht ein Zugriff, obwohl der SDRAM mit 
doppelter CPU-Frequenz läuft (DMA-Betrieb!). 8-0 Ein weiteres Problem 
ist die fehlende Unterstützung von Speicherzugriffen >64kB im avr gcc, 
das geht nur indirekt über Hilfsfunktionen, was die Sache wieder 
reichlich umständlich und langsam macht. Kommerzielle Compiler ala IAR 
scheinen eine vollständige Unterstützung zu haben, kosten aber 
ordentlich Geld.
Wie gesagt, als billiger, großer, einigermassen schneller Massenspeicher 
ist der SDRAM gut brauchbar, richtig toll ohne Kompromisse für die 
direkte Verarbeitung großer Datenmengen ist er aber eher nicht geeignet. 
Da sollte man besser einen aktuellen 32 Bitter nehmen, da ist das alles 
deutlich einfacher und leistungsfähiger. Für meine Anwendung hier ist es 
ausreichend gut.

Anbei das Projekt mit der Initialisierung und dem SDRAM Test sowie 
Geschwindigkeitsmessung. Ausgabe über UART C1, siehe Schaltplan.
Achtung, RXD und TXD sind die Namen vom FT232, der dort angeschlossen 
ist!

Der SDRAM ist ein 08/15 128Mbit Typ, es dürfte so ziemlich jeder 
funktionieren. Er wird mit 64 MHz getaktet, weniger als die Häfte, die 
selbst die langsamste Version verträgt. Über einen kleinen Trick kann 
der 16 Bit Datenbus des SDRAMs als 2 Seiten a 8MB genutzt werden, und 
das praktisch ohne Zusatzlogik! Die "Verdrehng" der Datenleitungen 
(DQ0-DQ15) geschah zur Vereinfachung des Layouts.
Ob nun alle Delayeinstellungen für den SDRAM optimal sind weiß ich 
nicht. Es scheint aber zu funktionieren.
Im Test wird der interne 32 MHz RC Oszillator verwendet, nicht der im 
Schaltplan dargestellt 16,384 MHz Quarz. Das liegt daran, dass es dort 
noch ein kleines Problem mit dem Anschwingen der PLL gibt, was u.a. an 
einem kleinen Layoutfehler liegt. Der UART geht aber dennoch genau 
genug.
Wenn man die beiden Methoden zum Warten auf des Ende der DMA-Übertragung 
testet (#define SDRAM_TEST_ISR) wird man keinen unterschied feststellen. 
Warum? ganz einfach. Die CPU greift nur auf den Flash und die 
IO-Register zu, der DMA-Kanal nur auf den internen SRAM und den externen 
SDRAM. All diese Komponenten sind als unabhängige Module über die 
Busmatrix ansprechbar, somit wird keiner ausgebremst.Siehe Datenblatt 
XMEGA_AU_Manual, Abschnitt 4.10 "Data memory and bus arbitration"

Danke nochmal an avr für den entscheidenden Hinweis!

Beitrag "Re: Viel RAM am kleinen Controller"

Viel Spaß damit und viel Erfolg beim Nachbauen.

MfG
Falk

P S Wenn ich demnächst ein Oszi zur Hand habe, kann ich ein paar Bilder 
von der Signalqualität nachliefern.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Falk Brunner schrieb:
> Ein weiteres Problem
> ist die fehlende Unterstützung von Speicherzugriffen >64kB im avr gcc,
> das geht nur indirekt über Hilfsfunktionen, was die Sache wieder
> reichlich umständlich und langsam macht.

Du benutzt aber schon die 'huge_mem' Funktionen, oder? Sind die wirklich 
so umständlich?

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

@ Matthias Sch. (Firma: Matzetronics) (mschoeldgen)

>Du benutzt aber schon die 'huge_mem' Funktionen, oder?

Welche? Im avr gcc gibt es die nicht. Ich hab aber sowas in den Headern 
von Atmel gesehen, die waren aber für den IAR Compiler.

Siehe Anhang. Das ist ein Header aus der App Note AVR1312 "Using the 
XMEGA external bus interface"

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Ich würde das höchste Adressbit nutzen um das highbyte des sechzehnbit 
Datenwortes über einen 8 bit Mux zu selektieren, damit sollte sich der 
Adressraum verdoppeln und das ungenutzte Highbyte nutzen lassen. Stehen 
zu wenig Adressleitungen zur Verfügung so sollte man die high Bits des 
adressbusses zum Mappen verwenden, so bleibt der refreshzyklus 
unbehelligt. Bei 4 bit Datenbus würde ich erst latschen und dann mappen.
 Namaste

von Falk B. (falk)


Lesenswert?

@ Winfried J. (Firma: Nisch-Aufzüge) (winne)

>Ich würde das höchste Adressbit nutzen um das highbyte des sechzehnbit
>Datenwortes über einen 8 bit Mux zu selektieren, damit sollte sich der
>Adressraum verdoppeln und das ungenutzte Highbyte nutzen lassen.

Schaltplan angeschaut? Beitrag gelesen? Beitrag verstanden?
Es WIRD bereits der GESAMTE SDRAM genutzt. Aber nicht über ein Adressbit 
(weil das bei SDRAM nicht wirklich geht) sondern über die beiden Signale 
UDQM und LDQM.

> Stehen
>zu wenig Adressleitungen zur Verfügung so sollte man die high Bits des
>adressbusses zum Mappen verwenden, so bleibt der refreshzyklus
>unbehelligt.

Jaja, graue Theroie. Schon mal REAL sowas aufgebaut? Mit SDRAM? Nicht 
nur mit 08/15 SRAM, wie es jeder 8051 Bastler macht?

> Bei 4 bit Datenbus würde ich erst latschen und dann mappen.

Was du mit deinen Latschem machst ist mir egal ;-)
Ausserdem ist das mit dem Latschen bei 65 Mhz nicht mehr ganz so 
einfach.
Anyway, es funktioniert bereits vollständig und sehr gut.
Nichts für ungut.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Falk Brunner schrieb:
> Welche? Im avr gcc gibt es die nicht.

Zumindest in ASF sind sie aber drin:
1
#include <ebi.h>
2
#include <ebi_port.h>
3
#include <hugemem.h>
4
// global pointers to SDRAM
5
hugemem_ptr_t writeptr;
6
hugemem_ptr_t readptr;
7
8
// write a dataset with time and accel values to SDRAM on the XPlained A1
9
static void WriteSet(uint16_t x, uint16_t y , uint16_t z){
10
uint32_t time = ((days * 16777216) + (hours * 65536) + (minutes * 256) + seconds);
11
  if (writeptr > (BOARD_EBI_SDRAM_SIZE + BOARD_EBI_SDRAM_BASE)) writeptr = BOARD_EBI_SDRAM_BASE;
12
  hugemem_write32(writeptr ,time);
13
  writeptr +=4;
14
  hugemem_write16(writeptr ,x);
15
  writeptr +=2;
16
  hugemem_write16(writeptr ,y);
17
  writeptr +=2;
18
  hugemem_write16(writeptr ,z);
19
  writeptr +=2;
20
}
21
// dump memory from SDRAM at arg1
22
void DumpMem(uint32_t arg1) {
23
unit32_t time;
24
  readptr = (arg1 * DATASET_LENGTH) + BOARD_EBI_SDRAM_BASE;
25
  time = hugemem_read32(readptr);
26
  readptr += 4;
27
// stuff omitted for demo
28
  printnum(hugemem_read16(readptr));
29
  readptr += 2;
30
  if (readptr > (BOARD_EBI_SDRAM_BASE + BOARD_EBI_SDRAM_SIZE)) {
31
      readptr = BOARD_EBI_SDRAM_BASE ; 
32
   }          
33
}

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

@ Matthias Sch. (Firma: Matzetronics) (mschoeldgen)

>Zumindest in ASF sind sie aber drin:

Das ist der gleiche Workaround mittels Funktionen.
Da hat man nix gewonnen.

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.