Hallo zusammen ! Ich möchte im Rahmen einer Produktentwicklung auf STM32-Basis ca. 60 Schaltzustände abspeichern - auch nach Aus- und Wiedereinschalten des Systems sollen diese Zustände verfügbar bleiben - für wen es interessiert, hier ein Link zu einem Thread zu Vorüberlegungen des Projektes: Beitrag "Mit 3.3V Mikrocontroller 5V schalten" Die Grundidee ist es, Schaltzustände über LED-beleuchtete Taster einer kabelgebundenen Remote (Zustand "ON" = LED im Taster auch AN als optische Referenz) anzusteuern. Dabei sollen die Taster über PISO-Schieberegister eingelesen und die LEDs (und zusätzlich jeweils ein Relais, aber das tut hier nichts zur Sache) über "Power-"Schieberegister Texas (TLC6C598-Q1) geschaltet werden. Es entsteht also ein im Grunde sehr simples "Schema" von ON/OFF-Zuständen, das in der Programmierung ständig aktualisiert/abgefragt und bei Betätigung eines Tasters entsprechend angepasst wird. Das aktuelle "Schema" (z.B. 01=ON, 02=ON, 03=OFF, 04=ON etc.,etc.) möchte ich dann gleichzeitig in einem Speicher ablegen, so dass mit diesem wie schon gesagt die ganzen Zustände auch nach Stromunterbrechung des Systems wiederhergestellt werden. Ich hatte letztes Jahr schon mit Arduino FRAM Speicher über I2C verwendet, und die entsprechende Routine erfolgreich programmiert. Meine Frage ist nun: Spricht für die werte Gemeinde hier etwas für oder gegen I2C vs. SPI ? Soweit ich als Anfänger das verstanden habe, wäre SPI schneller, aber das ist hier ja überhaupt nicht von Belang, da wir hier über ein Bedienfeld reden, wo ab und zu mal ein Taster gedrückt wird, um z.B. eine Funktion zu aktivieren. Als zeitkritische Anwendung kann man das wohl kaum bezeichnen...;-) Für mich stellt sich auch die Frage, ob SPI nicht grundsätzlich zu bevorzugen wäre, weil die entsprechenden Daten ja ohnehin schon für sie Schieberegister da durchgehen....? Im Gegenzug wäre ein Gedanke, ob es (vielleicht auch programmiertechnisch?) von Vorteil sein könnte, gerade durch Nutzung von I2C für den Speicher das Ganze als zwei unabhängige Systeme zu behandeln - a) Datenverkehr für die Abfrage und Ausgabe der Schieberegister und b) Speicherung....? Als nächster Schritt wäre auch die Verwaltung bestimmter "Schemata" als Presets interessant... Freue mich über Gedanken und Anregungen dazu - gerne auch für die programiertechnische Seite !
Der gesammtzweck ist mir nicht ganz deutlich... Erste Frage : Warum ein externes memory ? Warom nicht das EEPROM der uC benutzen ?
Moderne STM32 mit Octo-SPI können SPI-Flash transparent in den Adressraum einblenden. Du kannst den Flash dann wie interne Speicherzellen nutzen. Du brauchst also keine speziellen Routinen wie bei Standard-SPI oder I2C.
Hi, ich will irgendwann ein EERAM [1] verbauen. Das kann man beliebig häufig schreiben und wenn die Spannung flöten geht, hat man keine Probleme (oder wenige). Gruß Daniel [1] https://www.microchip.com/en-us/products/memory/serial-eeram#
Patrick C. schrieb: > Der gesammtzweck ist mir nicht ganz deutlich... Erste Frage : Warum ein > externes memory ? Warom nicht das EEPROM der uC benutzen ? Vielleicht, weil der uC kein EEprom hat.
John Doe schrieb: > Moderne STM32 mit Octo-SPI können SPI-Flash transparent in den > Adressraum einblenden. Du kannst den Flash dann wie interne > Speicherzellen nutzen. Hm.....das heißt, sobald der gewählte STM32 Flash an Bord hat (haben ja eigentlich so ziemlich alle), kann ich den nutzen ? Ist der denn frei verfügbar, ohne dass es irgendwelche Kollisionen mit Systemaufgaben des µC gibt ? Natürlich wäre es viel netter, wenn ich KEINEN externen Speicher anbinden müsste...
:
Bearbeitet durch User
John Doe schrieb: > Moderne STM32 mit Octo-SPI können SPI-Flash transparent in den > Adressraum einblenden. Kannst Du mir bitte erklären, was das bedeutet ?
Uli A. schrieb: > John Doe schrieb: >> Moderne STM32 mit Octo-SPI können SPI-Flash transparent in den >> Adressraum einblenden. > > Kannst Du mir bitte erklären, was das bedeutet ? Ich habe eben gegockelt: AN5050 Application note Octo-SPI interface on STM32 microcontrollers Eigentlich nicht so schwer. Klingt aber interessant. Auch PSRAM wie beim ESP32 kann man damit einblenden. Ein bisschen Linkerscript anpassen, den Octo-SPI konfigurieren und schon kann man den externen SPI-Speicher wie internen nutzen. Sogar XiP funktioniert damit!
Und noch eine schöne Powerpoint/PDF-Folie fürs Bullshit-Bingo: https://www.st.com/content/ccc/resource/training/technical/product_training/group0/fd/49/71/1b/2c/22/46/ba/STM32L4Plus_Peripheral_OctoSPI/files/STM32L4Plus_Peripheral_OctoSPI.pdf/jcr:content/translations/en.STM32L4Plus_Peripheral_OctoSPI.pdf
Uli A. schrieb: > Natürlich wäre es viel netter, wenn ich KEINEN externen Speicher > anbinden müsste... Auch das geht. Schau mal in das Datenblatt Deines STM32. Da wirst Du möglicherweise etwas finden, was BKPSRAM heißt. Das sind 4k RAM, die über VBAT versorgt werden. Wenn an VBAT eine Batterie hängt, wird zum einen die Uhr darüber versorgt, und zum anderen diese 4k SRAM. Die bleiben dann auch, wenn die restliche Stromversorgung weg geht. fchk
Frank K. schrieb: > Schau mal in das Datenblatt Deines STM32. Danke, Frank ! Hatte mich da zwar noch nicht endgültig entschieden bezüglich des STM32-Modells...u.a. weil ich noch nicht sicher bin, ob ich die Taster nicht doch einzeln über GPIOs abfrage statt über die PISO-Schieberegister, und sich dadurch die minimale Pinzahl natürlich entsprechend höher gestaltet als bei dem monentan angepeilten STM32G07...aber ich check das mal bei den bisherigen Kandidaten....! 4k reichen ja völlig aus für den Zweck....! John Doe schrieb: > Moderne STM32 mit Octo-SPI können SPI-Flash transparent in den > Adressraum einblenden. Du kannst den Flash dann wie interne > Speicherzellen nutzen. Ok. Verstanden hab ich das immer noch nicht ;-)))) Aber ich vermute mal, es geht darum, dass man da trotzdem einen externen Speicherbaustein hat, den aber über die Konfigurationsmöglichkeiten so adressiert als wäre es interner Speicher ? Also dem "Gesamtsystem" vorgaukelt, es hätte einen internen Speicher statt des externen ?
:
Bearbeitet durch User
Uli A. schrieb: > Ich hatte letztes Jahr schon mit Arduino FRAM Speicher über I2C > verwendet, und die entsprechende Routine erfolgreich programmiert. Dann bleib doch einfach beim IIC-Bus. EEPROM (24Cxx) kosten nur wenige ct (https://www.reichelt.de/ch/de/eeprom-2-kb-256-x-8-4-5-5-5-v-so-8-st-24c02-mn-p40062.html?&trstct=pos_0&nbc=1), FRAM ist eine elegante Alternative schnell und beliebig oft zu schreiben und andere IIC-Peripherie läuft über die gleichen zwei Drähte.
Lottomann schrieb: > Dann bleib doch einfach beim IIC-Bus. EEPROM (24Cxx) kosten nur wenige > ct > FRAM ist eine elegante Alternative schnell und beliebig oft zu schreiben > und andere IIC-Peripherie läuft über die gleichen zwei Drähte. Danke für Deinen Beitrag. Dann werde ich vermutlich bei der FRAM-Variante bleiben - der 1 Euro mehr im Gerät soll dann nicht das Problem sein ;-) Aber nochmal zu der Idee von Frank, wenn das denn so dann intern lösbar wäre: Wie sieht das denn mit dem internen SRAM aus bezüglich Robustheit bzw. Wiederbeschreibbarkeit in Zyklen ? Gibt es da Limits, die ggfs. deutlich unter denen von FRAM liegen ? Oder wäre der interne SRAM-Bereich da als gleichwertig zu sehen ?
:
Bearbeitet durch User
Uli A. schrieb: > Wie sieht das denn mit dem internen SRAM aus bezüglich Robustheit > bzw. Wiederbeschreibbarkeit in Zyklen ? Genauso wie mit jedem anderen RAM, quasi unbegrenzt.
Uli A. schrieb: > Aber nochmal zu der Idee von Frank, wenn das denn so dann intern lösbar > wäre: Wie sieht das denn mit dem internen SRAM aus bezüglich Robustheit > bzw. Wiederbeschreibbarkeit in Zyklen ? Gibt es da Limits, die ggfs. > deutlich unter denen von FRAM liegen ? Oder wäre der interne > SRAM-Bereich da als gleichwertig zu sehen ? SRAM ist SRAM, da gibts keinerlei Limits. Wenn Dein Prozessor kein Backup RAM hat, dann kannst Du immer noch 20 Bytes in der Echtzeituhr speichern. Das sind die sogenannten Backup Register. Schau ins Reference Manual zu Deinem Prozessor. Wenn Du die RTC nicht benutzt und keinen Uhrenquarz anschließt, kannst Du prinzipiell auch andere Register der Uhr für Deine Zwecke missbrauchen. Die Uhr darf dann halt nur nicht loslaufen. fchk
Danke für die Ergänzungen. War nur etwas ins Grübeln gekommen von der Info, dass bestimmte EEPROMs in AVRs offensichtlich eine "geringere Lebensdauer" haben sollen...wenn das für den SRAM nicht zutrifft, ist das ja fein...
Frank K. schrieb: > Wenn an VBAT eine Batterie hängt, wird zum > einen die Uhr darüber versorgt, und zum anderen diese 4k SRAM. Die > bleiben dann auch, wenn die restliche Stromversorgung weg geht. Sorry, hab das erst jetzt richtig verstanden beim nochmal Drüberlesen.... Das heißt ja, dass da dann trotzdem noch eine Batterie benötigt wird, die den Speicherinhalt "am Leben hält"....und das trifft laut STM32-Datenblatt auch auf die "stille Reserve" in der Uhr zu... Dann werde ich wohl doch eher mit dem FRAM arbeiten, was ja auch kein Ding ist....dachte nach Euren (dennoch erhellenden) Kommentaren nur, dass ich das auch ohne den externen Speicher realisieren könnte... Danke an alle !
Mitlesa schrieb: > Warum hat das hier noch keiner ins Gespräch gebracht? > > Beitrag "STM32: EEPROM Emulator im Flash" Hm....ist zwar interessant, allerdings wird auch dort der Aspekt angesprochen, dass Flash-Speicher nur 100k mal beschrieben werden könne....
Uli A. schrieb: > Wiederbeschreibbarkeit in Zyklen ? Gibt es da Limits, die ggfs. > deutlich unter denen von FRAM liegen ? Normales SRAM ist unendlich oft beschreibbar und lesbar. FRAM altert durch lesen genauso schnell, wie durch schreiben/löschen. Das Problem haben EEPROM und FLASH nicht, die altern nur beim schreiben/löschen
Arduino Fanboy D. schrieb: > FRAM altert beim lesen genauso schnell Okay....klingt schwach....;-) Aber im Datenblatt des FRAM steht 10^14 read/writes....ich glaube, das hält ne Weile....;o) (keineswegs klugscheißerisch gemeint!) Und da ich in meinem Fall ja sogar eher öfter schreibe als lese (schreiben andauernd bei Eingabe durch die Taster und lesen nur wenn Strom weg), ist das für mich rein formal auch kein Pro für EEPROM & Flash....
....aber ich kann ja auf Nummer sicher gehen und noch 40 cent für nen SPI-SRAM drauflegen...;o) Da brennt dann gar nix mehr an....
Arduino Fanboy D. schrieb: > FRAM altert beim lesen genauso schnell, wie beim schreiben. Und was stört Dich daran? Das Problem ist eher der Finger, der neue Werte eingibt. Der ist längst zu Staub zerfallen und auch die Taste ist längst verrottet. CY15B004J: - High-endurance 100 trillion (10^14) read/writes - 151-year data retention Das ergibt für das selbe Byte hintereinander zugreifen bei 400kHz >2000 Jahre.
Arduino Fanboy D. schrieb: > FRAM altert durch lesen genauso schnell, wie durch schreiben/löschen. Das mag stimmen; aber in absoluten Zahlen (in Zugriffen oder Jahren) ist das m.E. praktisch nicht relevant. Wir nutzen verschiedene Cypress (jetzt Infinion) FRAM Modelle schon länger (>8 Jahre) und nutzen die quasi im "Festplatten"-Betrieb. Aktuell die "Excelon" Serie. Das einzige was da merklich altert ist der Anwender (oder ich). ;) VG, Stephan
Uli A. schrieb: > (keineswegs klugscheißerisch gemeint!) Peter D. schrieb: > Und was stört Dich daran? Stephan schrieb: > Das mag stimmen; aber in absoluten Zahlen Mädels, ihr dürft gerne auf mir rumhacken, und meine Aussage negativ bewerten.... Aber bedenkt dabei: Es wurde nach genau solchen Unterschieden gefragt.
Uli A. schrieb: > Hm....ist zwar interessant, allerdings wird auch dort der Aspekt > angesprochen, dass Flash-Speicher nur 100k mal beschrieben werden > könne.... Das umgeht man in Profi-Bereich damit dass man nur einmal beim Ausschalten die Gerätezustände speichert. Solange das Gerät läuft bleiben die Daten im RAM erhalten. Das hält ewig.
Mitlesa schrieb: > Das umgeht man in Profi-Bereich damit dass man nur einmal beim > Ausschalten die Gerätezustände speichert. Solange das Gerät > läuft bleiben die Daten im RAM erhalten. Das hält ewig. Verstehe. Interessant zu wissen...! Aber mal blöd als Anfänger zum Verständnis gefragt: Wie macht man das in einem simplen Gerät, das man nicht "runterfährt" wie z.B. ein Betriebssystem ? Ich meine, Strom weg ist Strom weg, oder ? Da käme ja dann nur wieder irgendeine Routine in Frage, die eine Zwischenstromversorgung nutzt...also zumindest eine Art Kondensator, der noch solange Strom liefert, die zum Abspeichern gebraucht wird, oder ?
MCUA schrieb: > PowerFailInterrupt Könntest Du das genauer erläutern ? Klingt für mich nach ner softwareseitigen Lösung - das beantwortet aber nicht meine obige Frage nach der Stromversorgung...(ich möchte z.B. zusätzliche Batterien im System vermeiden)...
Uli A. schrieb: > Wie macht man das in > einem simplen Gerät, das man nicht "runterfährt" wie z.B. ein > Betriebssystem ? Uli A. schrieb: > Da käme ja dann nur wieder irgendeine Routine in Frage, die eine > Zwischenstromversorgung nutzt...also zumindest eine Art Kondensator, der > noch solange Strom liefert, die zum Abspeichern gebraucht wird, oder ? Das ist eine Methode. Es gibt andere Varianten bis zur Pufferbatterie. Alles in allem ist es durchaus nicht wenig Entwicklungsaufwand, das bei allen Temperaturen und Betriebszuständen betriebssicher zu bekommen bei möglichst kleinem Bauteileaufwand. Speicher-Zyklen zu sparen, indem man nur beim Ausschalten speichert, lohnt sich also nur bei großen Stückzahlen. Bei kleinen Stückzahlen nimmt man einfach einen größeren Speicherbaustein, betreibt Wear Leveling und schreibt dann, wenn es einem am besten passt.
Uli A. schrieb: > Ich meine, Strom weg ist Strom weg, oder ? > Da käme ja dann nur wieder irgendeine Routine in Frage, die eine > Zwischenstromversorgung nutzt...also zumindest eine Art Kondensator, der > noch solange Strom liefert, die zum Abspeichern gebraucht wird, oder ? Genau. Inzwischen gibts die Kondensatoren auch in etwas größer, z.B. https://www.kemet.com/en/us/capacitors/supercapacitors/product/FG0V155ZF.html 1.5 F. Das sind 15000000µF. Wenn Du den an Dein VBAT anschließt und über eine Diode (keine Schottky, die lecken zu viel) von VCC lädtst, dann hält der den Speicher und die Uhr etliche Wochen. fchk
Uli A. schrieb: > das beantwortet aber nicht meine obige Frage > nach der Stromversorgung...(ich möchte z.B. zusätzliche Batterien im > System vermeiden)... Was denkst du wie lange es dauert deine 8 Byte zu speichern?
Arduino Fanboy D. schrieb: > Aber bedenkt dabei: Es wurde nach genau solchen Unterschieden gefragt. Wie bitte? Peter D. schrieb: > Das ergibt für das selbe Byte hintereinander zugreifen bei 400kHz >2000 > Jahre. Ich rechne das jetzt nicht nach, ist aber doch ein sehr starkes Argument!
Uli A. schrieb: > Könntest Du das genauer erläutern ? Klingt für mich nach ner > softwareseitigen Lösung - das beantwortet aber nicht meine obige Frage > nach der Stromversorgung...(ich möchte z.B. zusätzliche Batterien im > System vermeiden)... Viele Netzteile haben ein PowerGood Ausgang. Das ist ein Komparator, der die Ausgangsspannung gegen eine Referenzspannung vergleicht, und wenn die Ausgangsspannung eine bestimmte Zeit lang stabil über der Schwelle liegt, dann geht das PowerGood an, und der Prozessor startet. Hast Du in jedem PC. Wenn das Gerät ausgeschaltet wird, dann geht PowerGood wieder weg. Der Prozessor kann aber noch eine kurze Zeit weiter laufen. Beispielsweise: Du hast ein Gerät, das mit 12V versorgt wird. PowerGood geht bei sagen wir mal 11V weg. Der Schaltregler für die 3.3V Versorgung geht aber noch bis 5V. Die Zeit, bis sich die Ausgangskondensatoren des Netzteils von 11V auf 5V entladen haben, hast Du noch Zeit, um Daten in Sicherheit zu bringen. Das können 10 oder 100ms sein. fchk
Man muss nicht riesige Cs haben, um für ein paar ms noch Spannung zu haben.
Frank K. schrieb: > > Viele Netzteile haben ein PowerGood Ausgang. Das ist ein Komparator, der > die Ausgangsspannung gegen eine Referenzspannung vergleicht, und wenn > die Ausgangsspannung eine bestimmte Zeit lang stabil über der Schwelle > liegt, dann geht das PowerGood an, und der Prozessor startet. Hast Du in > jedem PC. > > Wenn das Gerät ausgeschaltet wird, dann geht PowerGood wieder weg. Der > Prozessor kann aber noch eine kurze Zeit weiter laufen. Beispielsweise: > Du hast ein Gerät, das mit 12V versorgt wird. PowerGood geht bei sagen > wir mal 11V weg. Der Schaltregler für die 3.3V Versorgung geht aber noch > bis 5V. Die Zeit, bis sich die Ausgangskondensatoren des Netzteils von > 11V auf 5V entladen haben, hast Du noch Zeit, um Daten in Sicherheit zu > bringen. Das können 10 oder 100ms sein. Verstehe das Prinzip. Und klar kenne ich das von bestimmten Netzteilen.... Danke fürs Erklären, Frank ! Aber zum eigentlichen Thema verstehe ich nicht, warum wir gerade eine Frage wie Karl schrieb: > Was denkst du wie lange es dauert deine 8 Byte zu speichern? diskutieren..... Der eigentliche Aspekt (zumindest von meiner Seite aus) war ja nicht, wie lange das Speichern dauert, und ob dafür bei Strom AUS noch genug Zeit bleibt, sondern das längerfristige Liefern einer "Notspannung" wie z.B. die angesprochene VBAT oder ähnliche Konzepte, damit die internen Speicher nicht ihren Inhalt verlieren...keep it simple....da ist für mich der komplett nichtflüchtige Ansatz eines externen SRAM oder FRAM, der komplett OHNE solche Spannungserhaltungsvehikel auskommt, eindeutig attraktiver...
Arduino Fanboy D. schrieb: > > Aber bedenkt dabei: Es wurde nach genau solchen Unterschieden gefragt. Völlig richtig. Daher war auch mein Hinweis auf das NICHT klugscheißerische meinerseits genau so gemeint ;-)
Uli A. schrieb: > Speicher nicht ihren Inhalt verlieren...keep it simple....da ist für > mich der komplett nichtflüchtige Ansatz eines externen SRAM oder FRAM, > der komplett OHNE solche Spannungserhaltungsvehikel auskommt, eindeutig > attraktiver... Ein externes SRAM ist auch leer, wenn der Strom weg ist. Nur mal so zur Info... fchk
Frank K. schrieb: > Ein externes SRAM ist auch leer, wenn der Strom weg ist. Nur mal so zur > Info... Danke für die Klarstellung ! - dachte, diesbezüglich sind FRAM und SRAM gleichzusetzen....
Uli A. schrieb: > Danke für die Klarstellung ! - dachte, diesbezüglich sind FRAM und SRAM > gleichzusetzen.... Dann gäbe es keine Notwendigkeit für FRAM! Oder? Die Alternative, sowas wie: 23LCV1024 Gibt es auch in den verschiedensten Ausführungen.
Uli A. schrieb: > Hm....ist zwar interessant, allerdings wird auch dort der Aspekt > angesprochen, dass Flash-Speicher nur 100k mal beschrieben werden > könne.... Alterung bezieht sich rechnerisch auf die Löschvorgänge einer Page, nicht aber auf einzelne Programmiervorgänge von einem Teil einer Page. Man kann Pages inkrementell füllen, indem man neue Daten an die bisherigen Daten dranhängt. Erst wenn eine derart inkrementell gefüllte Page voll ist, und man zur nächsten übergehen muss, zählt die Page als einmal vollständig geschrieben (und muss gelöscht werden). Schreibt man also jedesmal 16 Bytes in eine 16kB grosse Page, kann man 1024 mal schreiben, bis ein einziger Vorgang von den 10000 oder 100000 mindestens möglichen abgeschlossen ist. Das reicht eine Weile.
:
Bearbeitet durch User
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.