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
>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.
http://www.nxp.com/products/microcontrollers/cortex_m3/lpc1800/#products Die können SDRAM ansteuern. Oder LPC177x/178x. fchk
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
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
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.
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
>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.
@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.
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. |
Du kannst auch den AT32UC3C0 nehmen (von 64K-512K flash) Preise gehen bei Digikey mit 6$ los und immer noch überschaubares 144pin Package.
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
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.
Hier gibt es den: http://de.farnell.com/integrated-silicon-solution-issi/is42s16400j-7tli/sdram-sdr-64mbit-3-3v-54tsopii/dp/2253831?ost=is42s16400j
@ 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
@ 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
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
@ 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.
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
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
@ 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
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
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...
Angehängte Dateien:
-
SDRAM.png
6,4 KB
>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.
@ 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.
@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.
>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.
@ 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!
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.
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.
@ 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.
@ 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!
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.
> 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.
@ 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 ;-)
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
@ 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.
@ Frank K. (fchk)
>oder AVR32, da gibts auch etliche mit SDRAM Interface.
Ist mir zu exotisch, da bin ich eher ein Mainstreamer.
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.
@ 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.
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
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
@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.
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 ;-)
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.
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?
@ 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"
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
@ 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.
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
@ Matthias Sch. (Firma: Matzetronics) (mschoeldgen)
>Zumindest in ASF sind sie aber drin:
Das ist der gleiche Workaround mittels Funktionen.
Da hat man nix gewonnen.
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.