Externer nichtvolatiler Speicher zur Zwischenspeicherung von Daten

Bei Zwischenpufferung von Daten und Log-Informationen auf SD-Karte sowie Zwischenpufferung von Daten und Log-Informationen im RTC slow memory des ESP32 wird das Thema breitgetreten. Hier schauen wir uns nach weiteren Alternativen um, wie man Daten über mehrere Schlafzyklen hinweg optimal zwischenspeichern kann, ohne z.B. spezielle Features des ESP32 zu nutzen, durchaus aber gerne mit fix und foxi Unterstützung für MicroPython.

EEPROM

Eine naheliegende Möglichkeit wäre ein EEprom. Das ist dann aber wieder ein zusätzliches Bauteil, Kabel usw. was ich vermeiden wollen würde, falls möglich. Die Beelogger-Kollegen machen das seit kurzem:

FRAM

Maybe.

FE-Ram oder FRAM sind genau fuer sowas gedacht. @weef hat sowas in einem andren projekt mal benutzt.

ich zitiere hier mal die wp:
[Ferroelectric RAM - Wikipedia]

FeRAM’s advantages over Flash include: lower power usage, faster write performance and a much greater maximum read/write endurance (about 10^10 to 10^14 cycles). FeRAMs have data retention times of more than 10 years at +85 °C (up to many decades at lower temperatures). Market disadvantages of FeRAM are much lower storage densities than flash devices, storage capacity limitations and higher cost. Like DRAM, FeRAM read process is destructive, necessitating a write-after-read architecture.

das ganze gibts fuer 2-3 euros in 8kbyte mit i2c und ‘controller’ z.b. https://www.reichelt.de/fram-64-kb-8-k-x-8-4-5-5-5-v-so-8-fm-24c64b-g-p146570.html

https://eu.mouser.com/Semiconductors/Integrated-Circuits-ICs/Memory-ICs/F-RAM/_/N-98x7s

1 Like

Für das Adafruit I2C Non-Volatile FRAM Breakout - 256Kbit / 32KByte gibt es bereits entsprechende MicroPython-Unterstützung.

Wer noch weiter in medias res gehen will, findet hier noch mehr Lektüre.

jo, ein Detail des digital parts eines alten kommerziellen Loggers aus meiner Feder von vor zehn Jahren (noch mit 0,6er Bohrungen für die vias ;) ):

Auf acht Stück 25PE16 (datasheet) (16Mbit flash mem; einer davon rechts im Bild) pufferte ein FM25CL64 (datasheet) -FRAM (links zu sehen) deren Schreibzugriffe.

  • im FRAM wurde ein nicht-flüchtiges flag (explizit geschützte Speicheradresse, ohne Partitionssystem oder sowas) verwendet (es reicht ein bit oder ein byte - egal) für den Status, ob das Gerät gerade im firmware-update-Modus ist. Denn wenn dabei etwas schiefgeht, muß das Ding nach dem reboot anhand dieses flags entscheiden, das failsafe-Betriebssystem-Image anzustarten (denn der update scheint ja nicht geklappt zu haben, sonst wäre das flag ja als dessen Bestätigung gelöscht).

  • Zusätzliche wurde ein reset controller / voltage detector (MAX63xx) verwendet, um die write protect-Leitung aller neun Speicher-ICs zu ziehen, wenn die Spannung unter 3,0 V absinken sollte:
    image

Bei jenen kleinen FRAMs dieser Serien ist die von @roh erwähnte Variante 25C64 für 5V-Systeme, während die 25CL64 für 3V3-Systeme geeignet ist. Diese FRAMs sind pinkompatibel zu SPI flash mems wie 25P- oder 25PE-Serien und damit einfach per SPI anzusteuern.

Derartige Überlegungen sind auch geeignet, bei Problemfelder bei der automatischen Strom-Abschaltung - #3 by weef bedacht zu werden.

2 Likes

FRAM

Das hört sich doch solide an mit dem FRAM – vielen Dank!

Um noch einmal Adafruit dazu zu zitieren…

PSRAM

Nur so zur Gaudi… Wäre die hier beschriebene PSRAM Technologie auch geeignet, um volatilere Einsatzszenarien abzudecken oder ist das Quatsch, weil FRAM ohnehin “far superior” ist und man sich daher nicht weiter den Kopf über Alternativen zu zerbrechen braucht?

eh. na der psram wird doch vom mpy schon benutzt… dachte der fipi hat da einen onboard …oder?

edit: jo… ist drauf…


der chip oben in der mitte ist das psram.
drunter der flash.
rechts der esp32.
links das lora/sigfox radio

jedenfalls is der inhalt von psram auch weg sobald der strom fehlt.

1 Like

Der Zweck wäre hier bei uns ja Zwischenspeicherung über mehrere deep sleep-Zyklen, nicht als Backup auf einer SD. Wird denn der Speicher auch mit Strom versorgt, wenn der FiPy im deep sleep ist? Für was wird der Baustein beim FiPy genutzt (OTA?) und wie groß ist der??

ich weiss es nicht, ich denke 4-8mb und wird schon vom mpy gefressen… zumindest gibt es fuer die diversen forks(pycom, loboris) da support fuer, wuerd mich wundern wenn pycom das verbaut und nicht nutzt

erwaehnt das da 4mb sind bei lopy4 und nicht beim 1er…

Aus manchen Dokumentationen kann man ableiten, dass der Baustein als RAM nutzbar ist. Vielleicht vertu ich mich aber auch – probieren geht über studieren und wir sind ja innerhalb mancher Perspektiven auf das Espressif/Pycom Universum schon oft auf nicht ganz richtige Erwartungen reingefallen.


Allgemein

Sowohl die ESP32-WROOM als auch die ESP32-WROVER Modelle haben

520 KB of on-chip SRAM for data and instructions

ESP32-WROOM

Je nach Einsatzzweck war beim WROOM der RAM damit oft knapp, daher hat Espressif die Möglichkeit geschaffen, ihn mit einem externen SPI PSRAM Baustein erweitern zu können.

ESP32-WROVER

Die ESP32-WROVER Modelle (ESP32-D0WDQ6) haben nun neben den 4MB Flash noch 8MB PSRAM integriert.

Ich glaube die Maschinen der zweiten Gerätegeneration von Pycom haben alle ausnahmslos WROVER Module an Bord.

Wird ja immer mehr on-chip SRAM, der externe!

Das verlinkte posting von roh: RAM | Pycom user forum

I assum that you use the 1st model LOPY. No, there is no way to increase the RAM size. Even if you open the RF shield and attach a PSRAM chip, you have to modify the firmware to make it use that chip. In order to overcome the memory problem, you have two choices.

a) Buy a LoPy4 model. This has 4 MB of RAM
b) Put your Python code into flash memory. That requires to build the firmware yourself, starting with downloading the repository at GitHub - pycom/pycom-micropython-sigfox: A fork of MicroPython with the ESP32 port customized to run on Pycom's IoT multi-network modules. and seeting up the tool chain as told in the README.md. Once you are able to build the image, you can put your python code into esp32/frozen and re-build.

Python code in flash does not need the RAM for compiling and resulting code, so the RAM is used for the dynamic data only. If that us still too much, you have to re-consider your code.

Mit RAM meint robert-hh wohl das PSRAM? 4 MB Der LoPy1 funktioniert wohl auch ohne weil er das nicht hat!

oh und eigene bugs hat natuerlich alles… auch psram auf esp32 ESP32 RAM cache issue when using both cores | Pycom user forum

1 Like

Weil die Diskussion um ein RTC-Modul drüben bei Daten auf SD schreiben und als bulk senden - #23 by MKO gerade aufkam und @MKO die Frage nach einem geeigneten Modul stellte,

wollte ich zurückfragen: »Meinst Du z.B. so etwas wie das DS3231/AT24C32-Kombimodul [1] [2]?

Ich frage nur, weil wir dann ja neben dem MicroPython-Treiber für die DS3231 auch nach einer entsprechenden Unterstützung z.B. des AT24C32 EEPROM Ausschau halten sollten.

Mit der entsprechenden Implementierung at24c32n.py von Mike Causer sollten wir ohne weiteres auch ein DS3231/AT24C32-Tandem ansteuern können.


  1. https://protosupplies.com/product/ds3231-rtc-with-eeprom-module/ ↩︎

  2. https://www.elecrow.com/rtc-eeprom-module-ds3231-at24c32-p-863.html ↩︎

Können wir - gerade getestet. Die Adresse des AT24C32N ist bei mir allerdings 0x57 und nicht 0x50.

Danke fürs Testen! Der MicroPython I2C EEPROM driver von Peter Hinch würde mir zwar besser gefallen, weil er mehrere Chips unterstützt, aber ob from bdevice import BlockDevice auf Pycom MicroPython klappt?