Jak zjistit volnou RAM Controlleru

Praktický postup, jak ve Studiu přes USB serial zjistit velikost TNGL projektu a kolik volné RAM ještě zbývá v ESP Controlleru.

Co tento postup ukáže

Při diagnostice sledujete dvě různé informace:

Parsed TNGL Bytes length = velikost zkompilovaného TNGL bytecode, který Studio posílá do Controlleru
HEAP = kolik volné interní RAM má Controller právě teď k dispozici

Tyto dvě hodnoty spolu souvisejí, ale nejsou to totéž:

TNGL bytes říkají, jak velký je výsledný projektový bytecode
HEAP říká, kolik paměťové rezervy Controlleru zbývá za běhu

Pokud tedy chcete znát jen velikost projektu, sledujte Parsed TNGL Bytes length. Pokud chcete vědět, jestli se Controller blíží paměťovému limitu, sledujte hlavně HEAP, WM a LB.

Zásadní praktické pravidlo:

z hodnoty Parsed TNGL Bytes length nelze přímo odvodit, kolik RAM Controller spotřebuje na HEAPu

Jedno číslo říká velikost výsledného bytecode, druhé ukazuje aktuální volnou runtime paměť. Mezi nimi není jednoduchý převod 1:1.

Doporučené nastavení Controller Configu

Pro diagnostiku stačí v praxi zapnout debug a ponechat běžný serial workflow:

{
  "console": {
    "debug": 3
  },
  "serial": {
    "debug": true,
    "baudrate": 1500000
  }
}

Praktický význam těchto polí:

console.debug: 3 zapne INFO log level
serial.debug: true pustí debug výstup do serial workflow
serial.baudrate: 1500000 je aktuální prakticky ověřená rychlost, na které jsme tenhle postup smoke-testovali
serial.enable není potřeba explicitně nastavovat, protože ve standardním výchozím nastavení bývá serial workflow zapnuté už defaultně

Postup krok za krokem

Připojte Controller k počítači přes USB.
Otevřete Spectoda Studio v prohlížeči, který podporuje Web Serial.
Otevřete vývojářskou konzoli prohlížeče (DevTools -> Console).
Připojte se ke Controlleru přes serial konektor.
Nahrajte projekt nebo nechte Controller několik sekund běžet připojený.
Sledujte logy v browser konzoli.

Co uvidíte v konzoli

Při zápisu projektu typicky uvidíte například:

> Preprocessing TNGL code...
> Parsed TNGL Bytes length: 13938
> Reading TNGL fingerprint from Controller...

Po připojení přes serial debug pak Controller periodicky vypisuje stav paměti, například:

[Spectoda_ESP32] HEAP: 183456, WM: 175920, LB: 124688

Firmware tento HEAP log vypisuje přibližně každých 10 sekund během běžného provozu. Během OTA update se tento periodický výpis dočasně nevypisuje.

Jak číst `HEAP`, `WM` a `LB`

Hodnota	Co znamená	Jak ji číst v praxi
`HEAP`	aktuálně volná interní RAM	základní informace, kolik rezervy má Controller právě teď
`WM`	minimum volné RAM od posledního bootu	důležitější bezpečnostní indikátor, ukazuje nejnižší dosaženou rezervu
`LB`	největší souvislý volný blok paměti	pomáhá odhalit fragmentaci, i když celkový `HEAP` ještě nevypadá špatně

Prakticky:

pokud roste Parsed TNGL Bytes length, roste velikost projektu
pokud po uploadu nebo při běhu scénáře výrazně padá HEAP, projekt nebo runtime logika jsou paměťově náročné
pokud padá hlavně WM, znamená to, že Controller už během běhu naráží na výrazně nižší rezervu, než jaká je vidět jen v aktuálním HEAP
pokud je LB výrazně menší než HEAP, může být problém spíš ve fragmentaci paměti než v samotném součtu volných bytů

Jak poznat, že jste blízko limitu

Neexistuje jedno univerzální magické číslo, které by platilo pro všechny projekty. Záleží na firmware, použitém hardware, pluginách i tom, co dělá Berry za běhu.

Varovné signály jsou hlavně tyto:

Parsed TNGL Bytes length dlouhodobě roste a po každé další úpravě projektu ubývá rezerva
HEAP po nahrání projektu klesne příliš nízko nebo dál padá při běhu
WM se při běhu stále zhoršuje a nestabilizuje se
LB je nápadně malé vůči celkovému HEAP
Controller začíná padat, restartovat se nebo se objevují chyby při běhu Berry logiky

Doporučený diagnostický postup

Pokud chcete zjistit, jestli je projekt ještě bezpečně v limitu:

zapište si Parsed TNGL Bytes length po uploadu
sledujte několik cyklů výpisu HEAP
spusťte typický scénář, který projekt v praxi zatěžuje
porovnejte, jak se změnily HEAP, WM a LB

Pokud hodnoty po krátkém ustálení drží rezervu a dál se nepropadají, projekt je pravděpodobně v rozumném provozním prostoru. Pokud se naopak dál zhoršují, je čas zjednodušit Berry logiku, omezit alokace nebo projekt rozdělit.

Po dokončení diagnostiky

Debug režim doporučujeme nechat zapnutý jen po dobu měření a diagnostiky. Pro běžný provoz je lepší vrátit logování na nižší úroveň, aby serial workflow zůstalo čisté a bez zbytečného debug šumu.