Wieviel externes SRAM ist möglich

[Markus M. (mmax)]

Hallo,

Ich bin gerade dabei, mich zum Thema externer Datenspeicher einzulesen, 
da ich große Daten (array von großem, im moment 150Byte, structs) 
ablegen muss. Da mir flüchtiger Speicher genügt und ich mir keine Sorgen 
über die max Anzahl der Lese-/Schreibzugriffe machen will, wird wohl ein 
SRAM die beste Wahl sein.

Unter der Artikelsammlung bin ich auf das XMEM-Interface gekommen.

Dazu folgende Fragen:
Welchen MC soll ich dafür nehmen ... ATmega, ATXmega, 32-Bit AVR UC3?. 
Finde leider keine Übersicht welche Typen denn das XMEM Interface on 
Board haben.

Wieviel Speicher kann ich denn maximal adressieren? Sollte ja von der 
Anzahl der Bits abhängig sein, oder? Kann ich die vollen 8Mb von [1] 
nutzen?

Wie schauts mit der Speicherverwaltung aus. Optimal wäre natürlich wenn 
ich mich nicht drum kümmern müsste, das also der MC macht. Also einfach 
Variablen definieren und benutzen (avr-gcc). Geht das so oder muss ich 
den Speicher manuell lesen/schrieb.

Oder gibts eine bessere/einfachere Lösung für externen Speicher, wenn 
Geschwindigkeit kein großes Thema ist?

Links zu Schaltungs- und Codebeispielen wären auch sehr hilfreich.

[1] 
http://de.mouser.com/ProductDetail/ISSI/IS66WV51216DBLL-55TLI/?qs=sGAEpiMZZMt9mBA6nIyysNjym0K16YsKs3e5dkjL1Pc%3d

Danke,
Max

[Falk B. (falk)]

@ Markus Manninger (mmax)


>Welchen MC soll ich dafür nehmen ... ATmega, ATXmega, 32-Bit AVR UC3?.

Kommt drauf an, wieviel Speicher man braucht und wie schnell es sein 
soll.

>Finde leider keine Übersicht welche Typen denn das XMEM Interface on
>Board haben.

Einige AVRs, fast alles ATXmegas (?)?, viele AMRs.

>Wieviel Speicher kann ich denn maximal adressieren?

Theoretisch unendlich. Praktisch deutlich weniger. AVRs können direkt 
~60kiBi (kilo Byte)

> Sollte ja von der
>Anzahl der Bits abhängig sein, oder? Kann ich die vollen 8Mb von [1]
>nutzen?

Mit ATXmega sicher, AVR eher nicht, da muss man basteln 
(Bankumschaltung).
Ausserdem sind sowohl AVR als auch ATXmega auf 8 Bit Speicherbreite 
ausgelegt, 16 Bit sind da wieder ein ziemlicher Zusatzaufwand.

>Wie schauts mit der Speicherverwaltung aus. Optimal wäre natürlich wenn
>ich mich nicht drum kümmern müsste, das also der MC macht. Also einfach
>Variablen definieren und benutzen (avr-gcc). Geht das so

Ja. Je nach (einmaligem) Aufwand direkt oder über Pointer.

>oder muss ich
>den Speicher manuell lesen/schrieb.

Nein, das sind nur Basellösungen.

>Oder gibts eine bessere/einfachere Lösung für externen Speicher, wenn
>Geschwindigkeit kein großes Thema ist?

Serielles FRAM. Musst du denn immer Schreiben? Oder nur wenig Schreiben 
und viel Lesen. Dann ist vielleicht ein serielles Flash besser.

[Eumel (Gast)]

Von Microchip gibts auch serielle SRAMs, vielleicht reicht dir das 
schon.

[lala (Gast)]

ist es ein Privatprojekt oder was für eine Firma?

Ich kann dir aus Erfahrung sagen dass ein externes Standard-SRAM z.B. an 
Infineon Mikrocontroller der XE166-Familie angeschlossen werden können.
Diese 16Bit-uCs haben ein Externes Bus-Interface mit bis zu 24 
Adresspins und natürlich 8 oder 16 Datenpins.

Allerdings ist das externe Bus-Interface wohl auch bei Infineon 
"deprecated", also evtl. bei zukünftigen C166-uCs in Zukunft irgendwann 
nicht mehr unterstützt. Die XE166-Familie ist aber nicht besonders alt 
und wird sicherlich noch sehr lange hergestellt.

[Markus M. (mmax)]

Falk Brunner schrieb:
> Kommt drauf an, wieviel Speicher man braucht und wie schnell es sein
> soll.

Wie gesagt, muss nicht schnell sein aber die 8MB vom verlinkten Baustein 
wären schon super, wobei 2MB oder 4MB auch ausreichend sein. Man weiss 
aber nie was die Zukunft bringt.

> Einige AVRs, fast alles ATXmegas (?)?, viele AMRs.

ARM ist mir dann doch etwas overkill aber ATXmega wär schon in Ordnung. 
In der XMEGA-A3 Doku steht im Kaptitel 8 (Direct Memory Access 
Controller) was von bis zu 16M(Bit?) ... ist das die XMEM Schnittstelle 
nur anders bezeichnet?

> Theoretisch unendlich. Praktisch deutlich weniger. AVRs können direkt
> ~60kiBi (kilo Byte)
>
>> Sollte ja von der
>>Anzahl der Bits abhängig sein, oder? Kann ich die vollen 8Mb von [1]
>>nutzen?
>
> Mit ATXmega sicher, AVR eher nicht, da muss man basteln
> (Bankumschaltung).
> Ausserdem sind sowohl AVR als auch ATXmega auf 8 Bit Speicherbreite
> ausgelegt, 16 Bit sind da wieder ein ziemlicher Zusatzaufwand.

Es gibt aber anscheinend auch 16-Bit'er der XMEGA Serie.

>>Wie schauts mit der Speicherverwaltung aus. Optimal wäre natürlich wenn
>>ich mich nicht drum kümmern müsste, das also der MC macht. Also einfach
>>Variablen definieren und benutzen (avr-gcc). Geht das so
>
> Ja. Je nach (einmaligem) Aufwand direkt oder über Pointer.

Kann man das im Makefile konfigurieren oder wie kann ich mir das 
vorstellen?

>>Oder gibts eine bessere/einfachere Lösung für externen Speicher, wenn
>>Geschwindigkeit kein großes Thema ist?
>
> Serielles FRAM. Musst du denn immer Schreiben? Oder nur wenig Schreiben
> und viel Lesen. Dann ist vielleicht ein serielles Flash besser.

Schreiben und lesen. UDP Telegramm sollen in einem Ringbuffer für 
nochmaliges Senden gespeichert werden.

[Markus M. (mmax)]

Das XMEGA Board [1] scheint ein 8MB externes SRAM zu haben. Hat das 
schon jemand in verwendung und kann was darüber berichten?

[1] 
http://store.atmel.com/PartDetail.aspx?q=p:10500183;c:100113#tc:description

Danke,
Max

[Markus M. (mmax)]

lala schrieb:
> ist es ein Privatprojekt oder was für eine Firma?
>
> Ich kann dir aus Erfahrung sagen dass ein externes Standard-SRAM z.B. an
> Infineon Mikrocontroller der XE166-Familie angeschlossen werden können.
> Diese 16Bit-uCs haben ein Externes Bus-Interface mit bis zu 24
> Adresspins und natürlich 8 oder 16 Datenpins.
>
> Allerdings ist das externe Bus-Interface wohl auch bei Infineon
> "deprecated", also evtl. bei zukünftigen C166-uCs in Zukunft irgendwann
> nicht mehr unterstützt. Die XE166-Familie ist aber nicht besonders alt
> und wird sicherlich noch sehr lange hergestellt.

Es soll ein kommerzielles Projekt werden. Ich will aber bei Atmel 
bleiben, da hab ich schon Erfahrungen.

[Markus M. (mmax)]

Eumel schrieb:
> Von Microchip gibts auch serielle SRAMs, vielleicht reicht dir das
> schon.

Ja, das [1] schaut auch nicht schlecht aus.

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en559066

[Eumel (Gast)]

Markus Manninger schrieb:
> Ja, das [1] schaut auch nicht schlecht aus.
>
> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en559066

Schön, die sind auch wirklich einfach zu benutzen. Einfacher z.b. als 
ein externes EEPROM.

[gq3agh44 (Gast)]

-> Es soll ein kommerzielles Produkt werden.
-> Der XMega soll es in 16-Bit geben.
-> ARM ist mir dann doch etwas overkill.


Merkste was? :-)

[Falk B. (falk)]

@ Markus Manninger (mmax)

>In der XMEGA-A3 Doku steht im Kaptitel 8 (Direct Memory Access
>Controller) was von bis zu 16M(Bit?) ... ist das die XMEM Schnittstelle
>nur anders bezeichnet?

Nein, das ist ein DMA Controller, der innerhlab des uC Daten 
transportieren kann.

>Es gibt aber anscheinend auch 16-Bit'er der XMEGA Serie.

Nein. Die Xmegas haben einen normalen AVR CPU-Kern, nur die Peripherie 
ist aufgebohrt. Warum aber 16 Bit Busbreite, wenn Geschwindigkeit keine 
Rolle spielt? Nimm einen SRAM mit 8 Bit Datenbus und fertig.

>Kann man das im Makefile konfigurieren oder wie kann ich mir das
>vorstellen?

http://www.mikrocontroller.net/search?query=avr+xmem&forums[]=1&forums[]=19&forums[]=9&forums[]=10&forums[]=2&forums[]=4&forums[]=3&forums[]=6&forums[]=31&forums[]=17&forums[]=11&forums[]=8&forums[]=14&forums[]=12&forums[]=7&forums[]=5&forums[]=15&forums[]=13&forums[]=18&forums[]=16&max_age=-&sort_by_date=1

Einfachste Möglichkeit. SRAM im main einschalten, Zugriff auf SRAM über 
manuell initialisierte Pointer.

Schwieriger. SRAM in einer der vielen_.init() sections im Compiler 
einschalten und per Kommandozeile dem Linke mitteilen, dann kann man die 
Variablenverwaltung und das Anlegen voll dem Compiler überlassen, so wie 
bei normaler AVR Programmierung.

Beitrag "Re: Atmega64 und XMEM"

>Schreiben und lesen. UDP Telegramm sollen in einem Ringbuffer für
>nochmaliges Senden gespeichert werden.

Und dafür brauchst du 1 Megabyte?

Man könnte einen 1 MByte SRAM an einen AVR ala ATmgea64 mit XMEM 
klemmen. Dann muss man halt die oberen 5 Adressbits mit einem extra Port 
steuern und den Speicher in 32 Bänke a 32 kB teilen, wie zu guten, alten 
DOS-Zeiten ;-)

[Peter D. (peda)]

Der AVR-GCC kann nur max 64kB adressieren, da die Pointer 16Bit sind.
Ob es für die Xmega eine neue Version mit 32Bit far Pointer gibt, weiß 
ich nicht.

Für >64kB würde ich schon einen ARM-Cortex empfehlen, macht auf 8Bittern 
einfach keinen Spaß mehr.

[Markus M. (mmax)]

gq3agh44 schrieb:
> -> Es soll ein kommerzielles Produkt werden.
> -> Der XMega soll es in 16-Bit geben.
> -> ARM ist mir dann doch etwas overkill.
>
>
> Merkste was? :-)

Nein?

[Mirco C. (Firma: s@Td) (mcontroller)]

Auch Atmel hat ARMs im Angebot wenn du schon mit dem ASF arbeitest macht 
es keinen so großen Unterschied ob du für einen CortexM4 oder ein XMega 
programmierst. Es gibt auch Testboards für wenig Geld die schon ein SRAM 
mit 8 Mbit drauf haben (z.B. das Sam4 Xplained).

[Falk B. (falk)]

Naja, wenn er schon mit AVR fit ist, ist ATXmega doch das naheliegenste. 
Identischer CPU-Kern, gleiche Entwicklungsumgebung, ähnliche Peripherie. 
UNd der kann 16 MByte S(D)RAM direkt ansteuern.

[Markus M. (mmax)]

Falk Brunner schrieb:
> Naja, wenn er schon mit AVR fit ist, ist ATXmega doch das naheliegenste.
> Identischer CPU-Kern, gleiche Entwicklungsumgebung, ähnliche Peripherie.
> UNd der kann 16 MByte S(D)RAM direkt ansteuern.

Jop, das dachte ich mir eben auch und für meine Anwendung brauch ich 
wirklich keinen ARM. Eigentlich reicht mir der Atmega (im Moment ein 
ATMega328P), nur der Speicher ist mir zu knapp bemessen.

Im Moment entwickle ich auf Linux mit avr-gcc und Netbeans IDE ... würde 
auch gerne dabei bleiben - die Macht der Gewohnheit.

[Peter D. (peda)]

Falk Brunner schrieb:
> UNd der kann 16 MByte S(D)RAM direkt ansteuern.

Der Knackpunkt ist aber, der Compiler muß es auch unterstützen.

[(prx) A. K. (prx)]

Peter Dannegger schrieb:
> Der Knackpunkt ist aber, der Compiler muß es auch unterstützen.

Nur wenn man normale C Daten dort deponieren will. Nicht wenn man den 
Speicher separat anspricht. Freilich: 32-Bitter haben es einfacher.

[Falk B. (falk)]

@ Peter Dannegger (peda)

>> UNd der kann 16 MByte S(D)RAM direkt ansteuern.

>Der Knackpunkt ist aber, der Compiler muß es auch unterstützen.

Ja, aber das kann der avr gcc leidlich, wenn auch nur über pointer.

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Variablenzugriff_.3E64kB

Achso, das ist ja in erster Linie für Flashfunktionen gedacht. Ob das 
auch für SRAM Zugriffe funktioniert? Hmmm?

Ok, es bleibt ein Workaround.

[Peter D. (peda)]

A. K. schrieb:
> Nicht wenn man den
> Speicher separat anspricht.

Dann sollten aber solche Zugriffe sämtlichst in Assembler und unter 
Interruptsperre erfolgen, sonst zieht man dem Compiler die Variabeln 
unterm Hintern weg.
Das wird also kein gut leserlicher, wartbarer und portabler C-Code.

Pseudocode:

  assembler{
    push r16
    push r17
    push r18
    push r19
    push r20
    lds r16, addr0
    lds r17, addr1
    lds r18, addr2
    lds r19, addr3
    lds r20, data
    sichere far pointer
    cli
    lade far pointer mit r19..r16
    far schreiben mit r20
    restore far pointer
    sei
    pop r20
    pop r19
    pop r18
    pop r17
    pop r16
  }

[(prx) A. K. (prx)]

Peter Dannegger schrieb:
> Dann sollten aber solche Zugriffe sämtlichst in Assembler und unter
> Interruptsperre erfolgen, sonst zieht man dem Compiler die Variabeln
> unterm Hintern weg.

GCC Doku sagt, dass die RAMPx Register in ISRs gesichert und genullt 
werden. CLI/SEI ist also unnötig. Dort wird auch ein 24-Bit Adressraum 
__memx erwähnt, mit dem sowohl Flash als auch RAM adressiert werden 
kann. Es dürfte also alles schon da sein.

[Kindergärtner (Gast)]

Die STM32F42/3x haben 256kB internen SRAM, können über den "FSMC" bis 
256MByte externen SRAM und über den FMC bis 512MByte externen SDRAM 
(billig!) ansteuern. Der RAM "integriert" sich direkt in den 
(virtuellen, 4GB großen) Adressraum, sodass man zum Programmieren nur 
das Linkerscript anpassen und ein paar Register setzen muss und sich 
dann keine weiteren Gedanken darüber machen braucht wo die Daten jetzt 
liegen. Diese Controller sind noch recht einfach ohne komplettes 
Betriebssystem zu programmieren (im Gegensatz zum z.B. Raspberry PI, der 
ja auch viel RAM hat) und da es sich um Cortex-M4F handelt kann man 
sogar noch besser zeitkritisch programmieren als mit AVR's.

[(prx) A. K. (prx)]

Dass 32er hier einfacher zu handhaben sind ist unstrittig. Er will 
freilich sein Entwicklungssystem nicht allein deshalb wechseln.

[Anigaver (Gast)]

Einmal mit den 32bittern gearbeitet will man nicht mehr zurück!

[MCUA (Gast)]

>Ich will aber bei Atmel bleiben, da hab ich schon Erfahrungen.
Wenn von Software her die einzelnen Mem-Pakete < bsp 32kB 
(zusammenhängend) machbar sind, wäre das (mit Bankswitch.) rel. einfach 
zu machen.
(ggfs könnte sogar die Bankgrösse an das 'Paket' angepasst werden)
Wenn nicht, kann es schon umständlich werden.

[Johann L. (gjlayde)]

Markus Manninger schrieb:
> Ich will aber bei Atmel bleiben, da hab ich schon Erfahrungen.

Atmel bietet auch 32-Bit Controller, etwa ARM oder AVR32.

[Frank K. (fchk)]

Markus Manninger schrieb:

> Jop, das dachte ich mir eben auch und für meine Anwendung brauch ich
> wirklich keinen ARM. Eigentlich reicht mir der Atmega (im Moment ein
> ATMega328P), nur der Speicher ist mir zu knapp bemessen.
>
> Im Moment entwickle ich auf Linux mit avr-gcc und Netbeans IDE ... würde
> auch gerne dabei bleiben - die Macht der Gewohnheit.

Ja und? Dann tauscht Du halt den avr-gcc gegen einen arm-gcc aus. Wo ist 
das Problem? Bist Du etwa zu alt, um noch etwas dazuzulernen?

Irgendwo gibt es immer eine Grenze, wo das Verharren bei einer 
Architektur keinen Sinn mehr macht. Und in Deinem Fall wird Dein Produkt 
dadurch schlechter als nötig und teurer als nötig. Beispiel:
- Ethernet, 100 MBit/s eingebaut vs 10 MBit/s extern via SPI bei 
gleichen Kosten
- erhöhter Aufwand beim Bankswitching
- Möglichkeit, preiswertes SDRAM anstelle von SRAM zu verwenden, um dann 
richtig viel Speicher zu haben.

Für Dich wäre vielleicht ein Raspberry Pi das richtige. Selbermachen 
kommt deutlich teurer, auch mit AVR.

fchk

[gq3agh44 (Gast)]

Keine eindeutigen Anforderungen und auf der anderen Seite nicht genug 
Energie, sich in unbekannte Themen einzuarbeiten.

[Markus M. (mmax)]

@Frank K, @ gq3agh44:

Als Telematikstudent muss ich oft mehr als mir lieb ist dazulernen und 
auch mein Alter sollte dem keine Grenzen setzten. Grundsätzlich hab ich 
auch nix dagegen auf eine andere Architektur umzusteigen, wenn es Sinn 
macht. Aber grundsätzlich versuche ich es "keep it simple" zu halten und 
nicht mit Kanonen auf Spatzen zu schiessen.

Auch ein Raspberry ist mir da zu viel des Guten. Ausserdem ist das ein 
Spielzeug, nicht industrietauglich und keine weiss obs den in 5 Jahren 
noch gibt.

Laut [1] sollte das XMEM interface ja auch bei den AVRs verfügbar sein 
und der ATmega2560 hats definitiv, laut Doku (9. External Memory 
Interface). Und es gibt ja schon Projekte [2].

[1] http://www.mikrocontroller.net/articles/Speicher#Mit_XMEM-Interface
[2] 
http://andybrown.me.uk/wk/2011/08/28/512kb-sram-expansion-for-the-arduino-mega-software/

[Frank K. (fchk)]

Markus Manninger schrieb:
> @Frank K, @ gq3agh44:
>
> Als Telematikstudent muss ich oft mehr als mir lieb ist dazulernen und
> auch mein Alter sollte dem keine Grenzen setzten. Grundsätzlich hab ich
> auch nix dagegen auf eine andere Architektur umzusteigen, wenn es Sinn
> macht. Aber grundsätzlich versuche ich es "keep it simple" zu halten und
> nicht mit Kanonen auf Spatzen zu schiessen.

auch wenn die Kanonen billiger sind?

Wo Du den Mega 2560 erwähnst, habe ich einfach mal nachgeschaut, wie die 
Preise so sind. Beispiel Farnell:

ATMEGA2560-16AU #1288330 16.80€
STM32F107VCT6   #1737141 10.08€ (mal willkürlich ausgewählt)

beide TQFP100, 256k Flash, nur der STM32 hat 64k RAM intern statt 8k, 72 
MHz statt 16, einen 100 MBit Ethernet MAC gleich onchip, viel mehr 
Peripherie intern, größerer Adressraum, etc etc. Und trotzdem kostet der 
AVR 50% mehr bei nur 20% der Leistung (stark optimistisch gerechnet).

Die Welt hat sich weiter gedreht.

Gut, dass ich verglichen habe.

fchk

[Markus M. (mmax)]

Frank K. schrieb:
> auch wenn die Kanonen billiger sind?
>
> Wo Du den Mega 2560 erwähnst, habe ich einfach mal nachgeschaut, wie die
> Preise so sind. Beispiel Farnell:
>
> ATMEGA2560-16AU #1288330 16.80€
> STM32F107VCT6   #1737141 10.08€ (mal willkürlich ausgewählt)
>
> beide TQFP100, 256k Flash, nur der STM32 hat 64k RAM intern statt 8k, 72
> MHz statt 16, einen 100 MBit Ethernet MAC gleich onchip, viel mehr
> Peripherie intern, größerer Adressraum, etc etc. Und trotzdem kostet der
> AVR 50% mehr bei nur 20% der Leistung (stark optimistisch gerechnet).

Ich muss gestehen dass die Blattform schon nicht schlecht ist und die 
Entwicklerboards von Olimex sind preislich auch recht gut. Ich glaub die 
muss ich mir genauer anschauen, vorallem wies mit Entwicklungsumgebung 
(gcc) usw. ausschaut ... das wiki hier ist ja recht informativ.

[MCUA (Gast)]

> ATMEGA2560-16AU #1288330 16.80€
ATMEGA64A (mit ExtBusIF) gibts für paar eur.