Shared PSRAM memory

[caco3]

This is a new approach to optimize the shared PSRAM memory.
The main focus is on allocating a large region and then manage it by itself to avoid fragmentation issues.

How does it work?

Early at the startup, it allocates a large memory block in PSRAM. This shared memory never gets freed again, thus fragmentation is no longer an issue. The block is large enough to provide space for the larges model (1.2 MB) and the Tensor Arena (820 KB) at the same time.
The memory is re-used depending on the step:

• Take Image: Use it for all STBI allocations > 100 KB. This is mainly:
  • 1x extracted image, 920 KB
  • 3x medium sized helper blocks (2x 150 KB, 1x 300 KB), total ca. 620 KB
• Aligning: The block is used for the temporary image (tmpImage, 920 KB, formerly referred to as imageTMP)
• Digitization (Digits or analog): Tensor Arena (820 KB) and Model File (max 1.1 MB).

Notes

• Because the rawImage only gets allocated later, there are some smaller fragmented blocks between it and the shared memory. Allocating the rawImage also early in startup, should solve this, but did not get it working stable. It should not be too hard, but I keep it aside for this PR.
• If we also put the smaller STBI blocks into the shared part, we get artifacts on the alg.jpg and alg_roi.jpg. It is jet unclear why this happens, but when we only but the larger blocks (>100 KB) into the shared memory, we don't hate this issue.
• It also moves the Wifi LWIP STack and BSS Segment back to PSRAM to free internal memory
• And MQTT Outbox also is in the PSRAM again.

Test Runs

Models (where not stated differently): dig-cont_0611_s3.tflite (1.1 MB), ana-class100_0157_s1_q.tflite (130 KB)

Old situation (v15.1.1)

Min Heap after 5 rounds: 12495

Using shared memory

Min Heap after 9 rounds: 26807

Using shared memory and additionally moved MQTT Outbox, Wifi and BSS to PSRAM.

CONFIG_SPIRAM_TRY_ALLOCATE_WIFI_LWIP=y
CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY=y
CONFIG_MQTT_CUSTOM_OUTBOX=y

Min Heap after 220 rounds: 60195 !!!!!!

Zoomed:

[caco3]

Feedback von @Slider0007:

Folgende Fragen/Anmerkungen hätte ich dazu:

• Das würde bedeuten, wir müssen in Zukunft alles was wir im PSRAM allokieren über diesen Weg abfahren, da nur dann fragmentfrei realisierbar. Korrekt?
• Es wäre wünschenswert, wenn alles was von den Flowklassen angelegt wird (rawimage, alg_roi, ROIs, ...) und bisher fragmentfrei im PSRAM lag, auch wieder fragmentfrei wäre (Voraussetzung für das Parameternachladen ohne Neustart, da dort die Klassen und deren Variablen wie rawimage, alg_roi,... zur Laufzeit gelöscht und wieder mit dem Standard-Init und den neuen Parametern angelegt werden. Dies geht geht jedoch nur, wenn wir die Elemente fragmentfrei anlegen können.)
• Das I-Tüpfelchen (aber ggf. nice to have): Bekommen wir es mit deinem Ansatz hin, auf die zwImage, in deiner Nennung die 920kB extracted image von STBI zu verzichten? (Voraussetzung für Modelfiles im Speicher halten. Dies ist aber voraussichtlich nur durch das Patchen der STBI möglich -> Sonderfall: Kein eigenständiges Allok von 920kB extracted image gewünscht, sondern nur Pointer-Übergabe des bereits vorhandenen vorallokieren Speicher von rawimage. So gemacht in meinen Tecdemo PR zum Models im Speicher halten). Vielleicht fällt dir dazu auch noch ein schönerer Ansatz ein, wie für diesen Sonderfall der Allok von STBI vermieden werden könnte und dafür der Speicher von rawimage übergeben werden könnte, um direkt dort zu schreiben. Das spart im Schritt Take Image die 920kB von zwImage ein.

[caco3]

Das würde bedeuten, wir müssen in Zukunft alles was wir im PSRAM allokieren über diesen Weg abfahren, da nur dann fragmentfrei realisierbar. Korrekt?

Nein, ich reserviere ja einen grossen Block für das sharing. Der Rest des PSRAM kann wie bisher verwendet werden.

Es wäre wünschenswert, wenn alles was von den Flowklassen angelegt wird (rawimage, alg_roi, ROIs, ...) und bisher fragmentfrei im PSRAM lag, auch wieder fragmentfrei wäre (Voraussetzung für das Parameternachladen ohne Neustart, da dort die Klassen und deren Variablen wie rawimage, alg_roi,... zur Laufzeit gelöscht und wieder mit dem Standard-Init und den neuen Parametern angelegt werden. Dies geht geht jedoch nur, wenn wir die Elemente fragmentfrei anlegen können.)

Ich habe versucht, rawImage direkt im startup anzulegen. Hatte jedoch Stabilitätsprobleme (siehe Beschreibung des PR. Ich würde das deshalb gerne mal aussen vorlassen, um die Komplexität möglichst minim zu halten. Es spricht nichts dagegen, dass wir das später nochmals angehen.

Das I-Tüpfelchen (aber ggf. nice to have): Bekommen wir es mit deinem Ansatz hin, auf die zwImage, in deiner Nennung die 920kB extracted image von STBI zu verzichten? (Voraussetzung für Modelfiles im Speicher halten. Dies ist aber voraussichtlich nur durch das Patchen der STBI möglich -> Sonderfall: Kein eigenständiges Allok von 920kB extracted image gewünscht, sondern nur Pointer-Übergabe des bereits vorhandenen vorallokieren Speicher von rawimage. So gemacht in meinen Tecdemo PR zum Models im Speicher halten). Vielleicht fällt dir dazu auch noch ein schönerer Ansatz ein, wie für diesen Sonderfall der Allok von STBI vermieden werden könnte und dafür der Speicher von rawimage übergeben werden könnte, um direkt dort zu schreiben. Das spart im Schritt Take Image die 920kB von zwImage ein.

Vom Speicher-Verbrauch her ist es zum jetzigen Stand (dieser PR) nicht nötig, zwImage wegzubringen, da das shared memory gross genug ist. Falls wir ohne das das dnyamische conflig laden nicht hinbekommen, können wir das gerne in einem separaten PR anschauen. Ich möchte diesen PR gerne minimal halten, damit wir allfällige Problem einfacher isolieren können.

[caco3]

Tested on 2 productive systems.
After 21h (630 rounds):

Heap Total: 661914 | SPI Free: 584171 | SPI Large Block: 573440 | SPI Min Free: 452419 | Int Free: 77743 | Int Large Block: 71680 | Int Min Free: 62811
Heap Total: 745946 | SPI Free: 668123 | SPI Large Block: 655360 | SPI Min Free: 534383 | Int Free: 77823 | Int Large Block: 71680 | Int Min Free: 67959

[caco3]

@Slider0007 I used the same error message again, is that ok for you?

BTW, I am not sure if we should call this heap. Isn't it just available PSRAM memory?

[Slider0007]

I did a quick test for a few rounds. It's working and yes we have more internal heap. That's great.

But I'm honest with you, I'm not totally happy about this hopefully intermiate state because it's blocking one of my planned features due to the new restrictions we have right now on PSRAM side.

I will postpone my larger upgrades until it's clear how this is developing.

[caco3]

You mean the persistent keeping of the models in RAM? That IMO anyway is not possible as you in worst case would need 2 MB of RAM for this!

Or do you mean the auto-reload of the config? How does it interfere there?

[Slider0007]

Or do you mean the auto-reload of the config? How does it interfere there?

This feature is running quite a while on all my devices.

Blocking reason:
Es wäre wünschenswert, wenn alles was von den Flowklassen angelegt wird (rawimage, alg_roi, ROIs, ...) und bisher fragmentfrei im PSRAM lag, auch wieder fragmentfrei wäre (Voraussetzung für das Parameternachladen ohne Neustart, da dort die Klassen und deren Variablen wie rawimage, alg_roi,... zur Laufzeit gelöscht und wieder mit dem Standard-Init und den neuen Parametern angelegt werden. Dies geht geht jedoch nur, wenn wir die Elemente fragmentfrei anlegen können.)

[caco3]

Ich finde dein Ansatz mit dem config reload sehr ehrgeizig, ich bin da recht skeptisch, ob wir uns da nicht ganz viele neue Probleme heraufbeschwören.
Bei einem Problem/Crash müssen wir ab dann jeweils fragen, ob ein restart stattgefunden hat! Auch wird das Nachvollziehen solcher Probleme noch komplexer!

Aus meiner Sicht hat das daher nicht wirklich Priorität. Das heist nicht, dass ich dich davon abhalten will. Aber ich denke, mit meinem PR hier können wir die aktuelle Situation massiv verbessern und haben eine gute Basis für die Zukunft.
Und ich denke, deinen Wunsch schliesst das nicht aus, da wir nun schon ein viel besseres Verständnis vom PSRAM haben.

Wir haben momentan recht viele Baustellen offen, z,.b. die offenen Bugs.
Auch haben einige Anwender mit HW rev3 Probleme. Ich versuche seit einigen Tagen, PlatformIO auf die neuste Version anzuheben (5.x -> 6.1). Für einige Anwender scheint das zu helfen. Das Upgrade klappt mit v15.0.3, führt aber bei v15.1.0 und neuer zu crashes. Nach mehreren Abenden mühsamen Portierens min ich nun soweit, dass die Erweiterungen in main.cpp etwas damit zu tun haben. Nehme ich nämlich wieder das main.cpp von v15.0.3, läuft es korrekt.
Ich denke wir sollten hier zuerst aufräumen und eine neue stable machen, bevor wir weiter gross umbauen!

[caco3]

@jomjol Was ist deine Ansicht dazu?