Scheint mir eine clevere Idee zu sein da sich (nichtflüchtiger FRAM) SPI Speicher effizient am Core vorbei via DMA ansteuern lässt. Wie seht ihr das? Hat die Idee irgendwelche Haken?
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)?
Angehängte Dateien:
-
Untitled-2.png
76 KB
Clemens M. schrieb: > oder ist es schlauer > die Daten IOs gleich in Reihe zu schalten mit nur noch einem notwendigen > Chipselect Na, wenn du das schaffen kannst... Ich nicht. Datenblatt hilft. > sagen wir mal 8 Stück 128KB ICs Zwei CY15B104Q-SXI FRAM-Speicher 4Mbit, 512K x 8 bit, sind vielleicht praktischer
:
Bearbeitet durch User
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.
Clemens M. schrieb: > mir gehts ums Prinzip. Wenn im Prinzip... Seit dem FRAM nennenswerte Kapazitäten hat, kann Benutzung von EEPROM nur aus Kostengründen rechtfertigt werden.
Sonst noch jemand sachdienliche Bemerkungen und Hinweise?
Gibt ja schon länger serielles SRAM mit SPI Schnittstelle. Solltest versuchen herauszufinden, warum sich diese Chips nicht durchgesetzt haben.
Clemens M. schrieb: > 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)? Ich weiß nicht, welches konkrete Problem damit gelöst werden soll. Irgendwie sieht das ganze nach Frickelei aus, bei der der gesamte Aufwand nur deswegen getrieben wird, um nicht die Architektur wechseln zu müssen. Linearer 32 Bit Adressraum ist auch bei Mikrocontrollern inzwischen nichts ungewöhnliches mehr, egal ob ARM, MIPS, PPC, 68k, RiscV oder was auch immer. Da lässt sich dann auch RAM in größeren Mengen einfach anschließen, oder paralleles NAND oder NOR-Flash, wenn man will. fchk
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.
Beitrag #5922014 wurde von einem Moderator gelöscht.
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.
>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.
jemand schrieb: > 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. Laut Datenblatt hat FM25V10 High-endurance 100 trillion (1014) read/writes. Das bedeutet: wenn MK nichts anderes macht als nur immer das gleiche Byte liest, und zwar mit 10 MHz, auch dann lebt FRAM 127 Jahre lang. Das ist das Gleiche wie ewig, da weder ein Mensch noch welche Technik so lange lebt. Zum Vergleich: manche CD- und DVD-Rohlinge verlieren Daten schon nach ein paar Jahren (bei Verbatim habe ich das festgestellt)... Ich sehe zwischen FRAM FM25V10 und SRAM 23LCV1024 nur kleine Unterschiede: SRAM braucht Batterie oder Kondensator, und FRAM kann mit Vcc von 2,0 bis 3,6 V arbeiten, während SRAM 2.5-5.5 V braucht. Zugang zu Daten ist identisch, man braucht nichts im Programm ändern. Ich habe gute Erfahrung mit 23LCV1024. Wenn ich einmal keine Uhr-IC in Gerät einbaue, dann wäre vielleicht sinnvoll, statt 23LCV1024 FM25V10 zu löten und somit ohne Vbat auskommen.. 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.
:
Bearbeitet durch User
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.
FRAM ist teurer, oder ich habe die falsche Quelle... (sRAM 23LC1024 für 2,30)
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.
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...
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.
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: > 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. Sicher kann man das machen, Schließlich ist es nur einfach einen dummen Datenblock schaufeln. Ob das nun die CPU selber macht oder der DMA-Controller ist nebensächlich.
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.
Du könntest versuchen den FRAM über den USART mit Hilfe des DMA zu bespielen, denn der USART kann im SPI-Modus arbeiten. Das geht aber wohl nicht bei XMEGA A & D. Guck mal ins Nachbarforum: https://www.avrfreaks.net/forum/xmega128a1-dma-and-spi
> 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.
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.