SPI-FRAM Speichererweiterung für XMEGA

Eine Frage noch hinterher:
Macht es bei Ankopplung von sagen wir mal 8 Stück 128KB ICs 
schaltungs/softwaretechnisch mehr Sinn diese mit 8 Chipselects und 
jeweils parallel an MISO/MOSI einzeln anzusprechen oder ist es schlauer 
die Daten IOs gleich in Reihe zu schalten mit nur noch einem notwendigen 
Chipselect (bzw. CS gleich ganz auf Masse)?

Maxim B. schrieb:
> Zwei CY15B104Q-SXI FRAM-Speicher 4Mbit, 512K x 8 bit, sind vielleicht
> praktischer

Ja sehr schön, war nur ein Beispiel, mir gehts ums Prinzip.

Sonst noch jemand sachdienliche Bemerkungen und Hinweise?

Nöö...

Gibt ja schon länger serielles SRAM mit SPI Schnittstelle. Solltest 
versuchen herauszufinden, warum sich diese Chips nicht durchgesetzt 
haben.

Frank K. schrieb:
> Da lässt sich dann auch RAM in größeren
> Mengen einfach anschließen, oder paralleles NAND oder NOR-Flash, wenn
> man will.

Dieser Anschluss dürfte auch nicht einfacher sein als der hier 
anvisierte. Davon abgesehen soll FRAM und kein langsames 
schreibbegrenztes Flash zum Einsatz kommen.

Mag vielleicht jemand mal auf die ursprünglichen Fragen eingehen?

Welche Frage?

Diese?
Clemens M. schrieb:
> oder ist es schlauer
> die Daten IOs gleich in Reihe zu schalten

Aus meiner Sicht ist diese Frage irgendwie irre.
Da ich keine Ahnung habe, was daran schau sein soll, oder was du dir da 
überhaupt vorstellst...

Nein, keine Antwort!
No.

Arduino Fanboy D. schrieb:
> Welche Frage?
>
> Diese?
> Clemens M. schrieb:
> oder ist es schlauer
> die Daten IOs gleich in Reihe zu schalten
>
> Aus meiner Sicht ist diese Frage irgendwie irre.
> Da ich keine Ahnung habe, was daran schau sein soll, oder was du dir da
> überhaupt vorstellst...
>
> Nein, keine Antwort!
> No.

Wenn Du hier nicht mehr Ahnung als ich hast halt Dich einfach an Deinen 
Vorsatz nicht zu antworten...

Maxim B. schrieb:
> Wenn im Prinzip... Seit dem FRAM nennenswerte Kapazitäten hat, kann
> Benutzung von EEPROM nur aus Kostengründen rechtfertigt werden.

Nicht unbedingt.

FRAM hat auch Nachteile:
Jeder Lesevorgang kostet einen Schreibzyklus, weil der Inhalt beim lesen 
gelöscht wird. Bei Flash ist das nicht so. Jetzt hat FRAM zwar sehr 
viele, aber endliche Schreibzyklen.

Wenn man beispielsweise Code vom FRAM ausführt, kann die Lebensdauer 
problematisch sein, obwohl FRAM enorm viele Schreibzyklen hat.

Die Problematik gibts beim MSP430:
http://www.ti.com/lit/an/slaa526a/slaa526a.pdf

Der Preis ist natürlich auch höher. Es ist auch langsamer, weil lesen 
einen Schreibvorgang bedeutet.

Ich will NICHT sagen, dass FRAM Mist ist, sondern nur, dass es nicht der 
"ideale" Speicher ist, für den viele Leute es halten.

jemand schrieb:
> FRAM hat auch Nachteile:

Das ist nicht sein Problem!
Ihm möchte alle /CS, von ihm seinen ganzen Fram, zusammenklemmen und 
alle IO in Reihe schalten.

Wie ihm sich das vorstellt, bleibt geheim.

Daisy Chain mit Fram?

... aber ich habe ja keine Ahnung ...
Ein schlechter Mensch halt...
Und bin jetzt auch ruhig.

jemand schrieb:
> Wenn man beispielsweise Code vom FRAM ausführt,

Vom angeschlossenen FRAM kann/soll der XMega keinen Code ausführen 
sondern nur Daten lesen und schreiben.

> Die Problematik gibts beim MSP430:
> http://www.ti.com/lit/an/slaa526a/slaa526a.pdf
>
> Es ist auch langsamer, weil lesen
> einen Schreibvorgang bedeutet.

Das schon genannte CY15B103Q 4M FRAM kann bis 40MHz SPI Takt unverzögert 
ausgelesen und beschrieben werden- und zwar 100 Trillionen Mal. Die 
Haltbarkeit wird mit 150 Jahren angegeben.
Alle diese Daten erreicht das ältere MSP430 FRAM nicht annähernd 
woraus man folgern kann, daß der Speicher sehr zum Positiven 
weiterentwickelt wurde.

Korrektur: 100 Billionen Mal (10^14).

>Ich weiß nicht, welches konkrete Problem damit gelöst werden soll.

So einen prähistorischen Prozessor mit futuristischer 
Speichertechnologie verbinden - damit bist du der Star auf jedem 
Steampunk Festival.

Nur so eine Idee schrieb:
> Ich weiß nicht, welches konkrete Problem damit gelöst werden soll.
>
> So einen prähistorischen Prozessor mit futuristischer
> Speichertechnologie verbinden - damit bist du der Star auf jedem
> Steampunk Festival.

Prähistorisch sind solche Kommentare.

Maxim B. schrieb:p
> Allerdings ist von TO erwüschte Daisy Chain mit beiden IC nicht möglich:
> es gibt entweder Schreiben oder Lesen. Geschriebene in SI Daten
> erscheinen auf SO nicht.

Ja danke, endlich mal eine konkrete Antwort auf eine der gestellten 
Fragen.  Also gehts nicht ohne separate Chipselects.

Irre!
Unglaublich irre.


> Maxim B
Nix gegen dich....

Wieso werden die Datenblätter ignoriert, die sich daraus ergebene Logik 
ignoriert, meine Aussage als "keine Ahnung" tituliert, aber DIR 
geglaubt?

Irre.

Arduino Fanboy D. schrieb:
> Irre!
> Unglaublich irre.

Das charakterisiert Deine "Beiträge" ziemlich treffend.

Clemens M. schrieb:
> Das charakterisiert Deine "Beiträge" ziemlich treffend.

Von  Arduino Fanboy habe ich hier auf uC.net schon jede Menge
sachlicher und qualifizierter Beiträge gesehen.

Von dir noch keinen einzigen (qualifizierten).
Eher nur Gelabere.

Uwe D. schrieb:
> FRAM ist teurer, oder ich habe die falsche Quelle...
> (sRAM 23LC1024 für 2,30)

Du hast nicht die falsche Quelle, sondern die falsche Technologie.
FRAM ist nicht-flüchtiger Speicher.
SRAM ist flüchtiger Speicher.
Das Eine ersetzt das Andere nicht.

void schrieb:
> Das Eine ersetzt das Andere nicht.

Siehe dazu: 23LCV1024 (nicht 23LC1024)

Arduino Fanboy D. schrieb:
> Siehe dazu: 23LCV1024

Arduino Fanboy D. schrieb:
> Siehe dazu: 23LCV1024 (nicht 23LC1024)

Dann war es die falsche Quelle. Denn Uwe D. hat die SRAM Variante ohne 
'V' (w/o Battery Backup) genannt. Und die Batterie kostet doch auch, 
oder nicht?

P.S.: Sorry, zu schnell geklickt.

Mag sich noch jemand zur eingangs gestellten Frage äußern?
Bislang noch keine fachkundige Antwort hier...

Musst halt akzeptieren - die einzig mögliche fachkundige Antwort ist: 
Deine Idee ist nicht so genial wie du denkst. Dieses Problem musst du 
anders anpacken.

Uwe D. schrieb:
> Diese seriellen sRAMs setze ich zum Puffern von Messdaten ein oder
> zum visualisieren von Messwerten an Außensensoren. Ein serielles
> Verketten geht nicht. Haupeinsatzzweck der seriellen Speicher ist
> mitnichten der (mögliche) Ersatz von Parallel-sRAM.

Ja danke, das war bereits geklärt.
Nun hätte ich nur noch gern gewusst ob sich das Ein/Auslesen via XMega 
DMA problemlos gestalten lässt. Siehe Eingangsposting.

Nur so eine Idee schrieb:
> Dieses Problem musst
> du anders anpacken.

Na welches Problem wie denn? Was laberst Du da?

Clemens M. schrieb:
> Nun hätte ich nur noch gern gewusst ob sich das Ein/Auslesen via XMega
> DMA problemlos gestalten lässt. Siehe Eingangsposting.

Bei Datenblöcken ist das sicher möglich und auch soweit sinnvoll. Hat 
Falk schon beantwortet.
CPU schickt 1 byte read command/opcode per SPI.
CPU schickt 3 byte dummy(7bit) und adresse(17bit) per SPI.
CPU bittet DMA 4096 byte von SPI zu lesen und nach RAM zu schreiben.
CPU wartet[1] auf DMA ready interrupt.  [1] Hier kann die CPU was anders 
nützliches machen.

Clemens M. schrieb:
> SPI Speicher effizient am Core vorbei via DMA ansteuern lässt.
> Wie seht ihr das? Hat die Idee irgendwelche Haken?

Du fragtest nach Haken bzw. wie effizient das ist. Der Haken ist 
Random-Access.
Wenn du keine Blöcke lesen oder schreiben möchtest, sondern nur kurze 
lineare Speicher-Abschnitte oder schlimmstenfalls nur Bytes, dann ist 
der DMA keine Hilfe mehr. Warum sollte die CPU in einem solchen Fall den 
DMA benutzten um ein Byte zu kopieren, dass kann sie auch schneller 
selbst.
CPU schickt 1 byte read command/opcode per SPI.
CPU schickt 3 byte dummy(7bit) und adresse(17bit) per SPI.
CPU bittet DMA 1 byte von SPI zu lesen und nach RAM zu schreiben.
CPU wartet[2] auf DMA ready interrupt.  [2] Hier lohnt es sich für die 
CPU nicht was anders zu tun.

Mit einem Modul was den seriellen Speicher memory mapped im Adressraum 
abbildet, wie es das auch für paralleles NAND/NOR Flash (sagte Frank K. 
schon) oder auch für S(D)RAM gibt, könnte der DMA effizienter arbeiten.
Der XMEGA[3] hat so ein Modul für seriellen Speicher aber nicht. Mit dem 
'external bus interface' gehen halt nur kleine "parallele" SRAM und 
SDRAM Speicher.
[3] Weil es im Eingangsposting keine Daten dazu gibt, ich gehe mal vom 
Datenblatt des ATxmega128A1U/ATxmega64A1U aus.

Falk B. schrieb:
> Sicher kann man das machen

Prima.

void schrieb:
> Bei Datenblöcken ist das sicher möglich und auch soweit sinnvoll.

So wäre das auch gedacht. Einzelne Variablen-Bytes siedle ich lieber im 
SRAM bzw. EEPROM des Controllers an :)

void schrieb:
> Mit einem Modul was den seriellen Speicher memory mapped im Adressraum
> abbildet ... könnte der DMA effizienter arbeiten.

Das finde ich ja mal interessant. Kann jemand zu dieser Art Modul nähere 
Angaben machen? Wo findet sich das? Auf welche Weise wird hier welche 
Menge Speicher in den Adressraum eingeblendet?

Grundsätzlich gehts mir um die einfache Speicher-Erweiterung eines 
XMega-(128A4U) Projekts fürs Speichern von Messwerten. Mit zwei 
CY15B104Q SOICs sind da via 5 Pins SPI-Bus inklusive zweier Chipselects 
ruckzuck 1MB nichtflüchtiger Speicher angeflanscht.

> Na welches Problem wie denn? Was laberst Du da?

Bei der Frage, ob es eine "clevere Idee" ist, gibt es 2 
Betrachtungsweisen.
- Interresante Technologie, das sollten wir mal ausprobieren!
- Mit welcher Technologie können wir am einfachsten die Anforderungen 
erfüllen?

Bei meinem ersten Job hatten wir ein Echtzeitbetriebssystem auf PCs mit 
386er. Um Speicherverwaltung brauchten wir uns nicht kümmern. Mein 
zweiter Job war dann für DOS Rechner TSRs  entwicklen, die mit extended 
und expanded Memory jonglierten. Auf DOS mehr als 649kB benutzen - da 
brauchte es nicht nur "clevere Ideen". Dafür brauchte es geniale Ideen. 
Trotzdem was das ganze Konzegt gehirnamputierter Unfug.

Jede "fachkundige Person" ist zu der Einschätzung gekommen: Diese Art 
von "cleveren Ideen" ergeben nur irrsinnigen Aufwand, aber es kommt 
nichts bei raus. Natürlch klappt SPI mit DMA problemlos. Aber danach 
handelst du dir mit dieser Technologier tonnenweise überflüssige 
Probleme ein.

Uwe D. schrieb:
> Du könntest versuchen den FRAM über den USART mit Hilfe des DMA zu
> bespielen, denn der USART kann im SPI-Modus arbeiten.

Waschechtes SPI ist verfügbar, das nehm ich natürlich.

Nur so eine Idee schrieb:
> Jede "fachkundige Person" ist zu der Einschätzung gekommen: Diese Art
> von "cleveren Ideen" ergeben nur irrsinnigen Aufwand, aber es kommt
> nichts bei raus.

Wie kommst Du zu dieser Aussage? Worin besteht der irrsinnige Aufwand? 
Warum kommt nichts dabei heraus?

> Aber danach
> handelst du dir mit dieser Technologier tonnenweise überflüssige
> Probleme ein.

Na dann führ doch mal genauer aus.
Bis dahin bleibt mein Vorwurf der Laberei bestehen.
Ist Dir langweilig?

Clemens M. schrieb:
> Grundsätzlich gehts mir um die einfache Speicher-Erweiterung eines
> XMega-(128A4U) Projekts fürs Speichern von Messwerten. (...)

Dann bleib bei der Methode größere Blöcke am Stück vom XMega (mit DMA 
oder ohne) in den ext. FRAM Speicher zu kopieren.


Clemens M. schrieb:
> void schrieb:
>> Mit einem Modul was den seriellen Speicher memory mapped im Adressraum
>> abbildet ... könnte der DMA effizienter arbeiten.
>
> Das finde ich ja mal interessant. Kann jemand zu dieser Art Modul nähere
> Angaben machen? Wo findet sich das? Auf welche Weise wird hier welche
> Menge Speicher in den Adressraum eingeblendet?

Solche Module finden sich eher in größeren Mikrocontrollern. Unten 
findest du zwei Beispiele.
Das einblenden in den Adressraum geschieht genau so wie beim 'external 
bus interface' des XMega für S(D)RAM. Beim Zugriff auf die passene 
Adresse im Speicherbereich liest das Modul selbstständig den 
angeschlossnen Speicher aus und reicht die Daten weiter.
Diese Module gibt es für serielles Flash, für serielles RAM auch aber 
das ist noch eher selten.

SPI Multi I/O Bus Controller modul
aus dem RZ/A1H (R7S721000)
siehe Seite 789 im Reference Manual 'R01UH0403EJ0400 Rev.4.00'
"External Address Space Read Mode
A maximum of 8-Gbyte address space is supported (when two serial flash 
memories are connected)
Efficient data reception due to built-in read cache (64-bit line × 16 
entries)."

QSPI modul
aus dem STM32 (STM32F446)
siehe Seite 337 im Reference Manual 'RM0390'
"Memory-mapped mode
In memory-mapped mode, the external Flash memory is seen as internal 
memory but with some latency during accesses. Only read operations are 
allowed to the external Flash memory in this mode. (...)"

void schrieb:
> Solche Module finden sich eher in größeren Mikrocontrollern.

OK, die haben dann auch meist mehr eingebauten Speicher und da sind 
Erweiterungen dieser Art sicher oft überflüssig (vom 
Nichtflüchtigkeits-Aspekt mal abgesehen bzw. dann unpraktischerweise mit 
Backup-Batterie). Inwieweit diese Module mit den durchaus vorhandenen 
Eigenarten serieller Speichertypen klarkommen steht möglicherweise auf 
einem anderen Blatt, auch ist

> Only read operations are
> allowed to the external Flash memory in this mode

nicht gerade attraktiv. Aber interessant was es alles gibt, danke für 
den Beitrag.

Clemens M. schrieb:
> auch ist
>
>> Only read operations are
>> allowed to the external Flash memory in this mode
>
> nicht gerade attraktiv.

Die beiden Beispiele waren Module für serielles NOR Flash.
Wie gesagt, so etwas gibt es auch für serielles RAM. Die können dann 
auch schreiben. Aber es ist eine Nische.
Wenn man einen grösseren Kontroller und Bandbreite benötigt, dann greift 
man notwendigerweise zum DRAM.

>Aber interessant was es alles gibt, danke für den Beitrag.

Gern geschehen.