Lua na ESP: Kompletní průvodce podporou pro ESP8266, ESP32 a RISC-V čipy

Kdo chce programovat ESP čipy v Lua, narazí zpravidla na jediné jméno: NodeMCU. Není to jen název oblíbené vývojové desky - je to především komunitní firmware, který do těchto čipů vdechuje interaktivní Lua interpret místo kompilovaného C/C++ kódu. Problém je, že NodeMCU vznikl v roce 2014 výhradně pro ESP8266²², a od té doby Espressif vypustil do světa desítky odvozenin - od dvoujádrového ESP32 po jednojádrové RISC-V čipy ESP32-C3, C6 a H2. Tento článek mapuje, na kterém z těchto čipů je Lua podpora vyzrálá, na kterém experimentální a na kterém prakticky neexistuje, a k tomu přidává kompletní postup, jak si Lua na vybraném čipu skutečně rozchodit.

Zdroj: Popolon, „ESP32-C3 RISC-V NodeMCU board" — Wikimedia Commons, CC BY-SA 4.0

Co je NodeMCU a proč to není obyčejná Lua

NodeMCU firmware vznikl jako port projektu eLua nad tehdejším Espressif Non-OS SDK pro ESP8266²². Prvotní commit má na svědomí vývojář vystupující pod přezdívkou Hong, a to 13. října 2014, jen pár měsíců po tom, co Espressif začal ESP8266 vyrábět²². Původní autoři projekt opustili v létě 2015, od té doby ho drží nad vodou komunita - a firmware mezitím nabobtnal na desítky modulů²².

Klíčová věc, kterou je potřeba pochopit hned na začátku: Lua na ESP není plnohodnotná Lua, jakou znáte z počítače. Firmware implementuje Lua 5.1.4, nebo volitelně Lua 5.3, ale bez knihoven debug, io, os a bez většiny modulu math¹. Důvod je prostý - na mikrokontroléru bez souborového systému v tradičním smyslu a bez operačního systému nemá os.execute() ani io.popen() co dělat. Místo toho firmware nabízí vlastní sadu globálních modulů (gpio, wifi, net, file, tmr a další), které fungují jako runtime knihovna napojená přímo na hardware čipu. Kdo přichází z desktopové Lua a čeká standardní ekosystém balíčků přes LuaRocks, bude zklamaný - NodeMCU žije ve vlastním, uzavřenějším světě.

Dvě větve, dva světy

Repozitář nodemcu/nodemcu-firmware na GitHubu se dělí na dvě zásadně odlišné linie vývoje, a tohle rozdělení je klíčové pro pochopení toho, který čip má jakou podporu:

• release/dev - stabilní a vývojová větev cílená výhradně na ESP8266 a ESP8285. Do release se merguje z dev zhruba jednou za dva měsíce, po pěti až šesti týdnech přijímání změn a dvou až třech týdnech stabilizace¹.
• dev-esp32 - samostatná větev, která cílí na ESP32 a jeho novější sourozence. Je to jiná kódová základna postavená nad Espressif ESP-IDF, ne nad Non-OS SDK, a nikdy nebyla mergnuta zpátky do hlavní release větve^{1 2}.

Jinými slovy: NodeMCU pro ESP8266 a NodeMCU pro ESP32+ jsou dva různé projekty, které sdílí jméno, filozofii a částečně kód, ale ne vydávací cyklus, ne stabilitu a ne úroveň testování.

Podpora Lua podle konkrétního čipu

ESP8266 a ESP8285: domovská platforma, kde je vše vyladěné

ESP8266 (a jeho odlehčená varianta ESP8285 s vestavěnou flash pamětí) je čip, pro který NodeMCU vznikl, a je to jediná platforma, kde má projekt oficiální, pravidelně vydávanou stabilní větev¹. Všechny moduly popsané dál v tomto článku (GPIO, PWM, I2C, SPI, UART, ADC, WS2812, časovače) jsou zdokumentované primárně pro tento čip a v praxi na něm nejlépe otestované.

Pro ESP8266 navíc existuje pohodlná cesta k vlastnímu firmwaru bez nutnosti cokoliv kompilovat lokálně - cloudová build služba na nodemcu-build.com, kam si uživatel zaškrtne požadované moduly a verzi Lua a po chvíli mu na e-mail přijdou odkazy ke stažení hotových .bin souborů⁵. Tahle služba je ale výhradně pro ESP8266 - pokus přidat jí podporu ESP32 zůstal v GitHub issue jako neimplementovaný požadavek⁴.

Pokud tedy chcete Lua na ESP s nejmenším počtem překvapení a nejlépe zdokumentovanou sadou periferií, ESP8266 je stále nejjistější volba - i když jde o čip z roku 2014, komerčně už dosluhující.

ESP32 (Xtensa, dvoujádrový): funguje, ale je to pořád vývojová větev

Původní ESP32 s dvoujádrovým Xtensa LX6 má v NodeMCU zastoupení přes větev dev-esp32². Tahle větev je vůči vydávacímu cyklu ESP8266 v roli chudšího příbuzného: nemá pravidelné číslované vydání, nemá cloud builder a nemá binárky ke stažení. Kdo chce NodeMCU na ESP32, musí si firmware sám zkompilovat pomocí Espressif ESP-IDF.

Dobrá zpráva je, že větev je pořád živá - poslední commit (přidání mDNS modulu) byl v srpnu 2025², takže se stále něco děje, jen výrazně pomaleji a s menší komunitou kolem sebe než u ESP8266. Firmware na dev-esp32 je navíc stavěný přímo nad ESP-IDF, takže dědí jeho stabilitu a bezpečnostní záplaty - není to tedy experiment stavěný na zelené louce.

ESP32-S2 a ESP32-S3: stejná větev, méně prošlapaná cesta

ESP32-S2 (jednojádrový, s nativním USB) a ESP32-S3 (dvoujádrový, s AI instrukcemi a USB OTG) jsou v dev-esp32 větvi podporované na úrovni buildovacího systému - continuous integration projektu je explicitně sestavuje jako samostatné cíle vedle klasického ESP32³. To znamená, že firmware se pro tyto čipy prokazatelně kompiluje a prochází základním sestavením při každém pushi do repozitáře.

Co to ale neznamená, je stejná úroveň komunitního ověření jako u ESP8266 - dokumentace modulů se v drtivé většině stále popisuje na příkladech ESP8266 a u okrajovějších funkcí (třeba přesných hardwarových detailů ADC nebo počtu dostupných periferních jednotek na S2/S3) je třeba počítat s tím, že narazíte na chování, které dokumentace nezachycuje a budete si ho ověřovat experimentálně.

ESP32-C3, C6 a H2: RISC-V a Lua funguje - ale hraje se to na tenkém ledě

Tady je nejčastější mýtus, který je potřeba vyvrátit: na internetu koluje řada starších diskuzí a článků (typicky z let 2021-2022, z doby uvedení ESP32-C3 na trh) tvrdících, že NodeMCU RISC-V čipy nepodporuje. Realita v repozitáři je jiná. Lua VM je napsaná čistě v přenositelném C, takže na rozdíl od některých starších assembly optimalizací pro Xtensa jí architektura procesoru (Xtensa vs. RISC-V) sama o sobě nevadí - kompiluje se přes ESP-IDF stejně jako zbytek firmwaru.

Continuous integration dev-esp32 větve to potvrzuje přímo: buildovací matice explicitně obsahuje cíle esp32c3, esp32c6 i esp32h2 vedle Xtensa čipů, a to jak pro Lua 5.1, tak pro Lua 5.3³. Firmware se tedy pro tyhle RISC-V čipy prokazatelně staví a produkuje funkční binárku.

Realita pro běžného uživatele je ale střízlivější než pro vývojáře v CI: neexistuje hotová binárka ke stažení, neexistuje cloud builder, a komunitní zkušenosti (fóra, návody, hotové projekty) jsou na těchto čipech řádově tenčí než u ESP8266 nebo klasického ESP32. Kdo sáhne po C3/C6/H2, bude si muset firmware sestavit sám a počítat s tím, že bude často první, kdo na dané kombinaci desky a modulu něco takového zkouší.

ESP32-P4 a další nové čipy: mimo hru

Nejnovější čip ESP32-P4 (výkonný RISC-V bez Wi-Fi/Bluetooth, cílený na HMI a strojové vidění) se v dev-esp32 buildovací matici k datu psaní tohoto článku neobjevuje³ - Espressif tyto čipy vypouští rychleji, než je komunitní projekt jako NodeMCU stíhá zařazovat. Kdo plánuje projekt na úplně nejnovějším křemíku, měl by před nákupem vždy zkontrolovat aktuální buildovací matici přímo v repozitáři, protože se může (a pravděpodobně bude) měnit rychleji, než jak často vychází články jako tento.

Přehledová tabulka

Alternativy k NodeMCU: proč je lepší se jim vyhnout

Pro ESP32 kdysi existovala konkurenční Lua platforma Lua RTOS od projektu Whitecat, která šla dál než NodeMCU - nabízela plnohodnotnější RTOS vrstvu a vlastní sadu nástrojů. Poslední commit do hlavní větve repozitáře whitecatboard/Lua-RTOS-ESP32 je ale z prosince 2022¹⁷, projekt je tedy fakticky opuštěný. Odvozený fork loboris/Lua-RTOS-ESP32-lobo je na tom ještě hůř - jeho poslední commit je z roku 2017²¹. Pro nový projekt v roce 2026 nedává smysl stavět na žádné z těchto dvou variant; NodeMCU zůstává jedinou reálně živou volbou pro Lua na ESP čipech.

Jazyk samotný: co v Lua na ESP funguje a co ne

Než se pustíte do psaní kódu, je dobré vědět přesně, s jakou verzí jazyka pracujete a čeho se nedočkáte:

• Verze jazyka: volitelně Lua 5.1.4 (výchozí, blíže klasické NodeMCU dokumentaci) nebo Lua 5.3 (novější syntaxe, celočíselná aritmetika, bitové operátory)¹. Volba se dělá při kompilaci firmwaru přes konfigurační přepínač, ne za běhu.
• Chybějící standardní knihovny: debug, io, os a většina math modulu v embedded firmwaru chybí úplně¹ - typické volání jako os.time(), io.write() nebo os.execute() nefungují, protože pro ně na mikrokontroléru bez OS a bez klasického souborového systému není ekvivalent. Místo os.time() se používá modul rtctime, místo io operace se soubory modul file.
• Číselný typ: u Lua 5.3 lze zvolit variantu s 64bitovými celými čísly a doubly (alternate), nebo defaultní konfiguraci - volba ovlivňuje paměťovou náročnost i přesnost výpočtů³.
• Moduly a require: klasický souborový require() z desktopové Lua tu nahrazuje kombinace nahrávání skriptů do flash a mechanismu LFS (viz níže) - require() sice existuje, ale hledá moduly primárně v LFS oblasti, ne v libovolné cestě na disku.

Úložiště skriptů: SPIFFS a Lua Flash Store (LFS)

ESP8266 má k dispozici jen desítky kilobajtů RAM (typicky kolem 44 KB volného heapu), zatímco flash paměť bývá řádově větší - stovky kilobajtů až jednotky megabajtů⁶. Standardní Lua počítá s tím, že kód i data leží v RAM, což je na takhle malém čipu problém.

NodeMCU řeší tohle omezení dvěma mechanismy:

• SPIFFS - flash souborový systém, kam se ukládají .lua skripty jako běžné soubory. Skript se ale musí při každém spuštění zkompilovat za běhu, což stojí čas i RAM.
• LFS (Lua Flash Store) - novější a efektivnější přístup. Skripty se zkompilují předem, mimo zařízení, nástrojem luac.cross, a výsledný obraz se nahraje do vyhrazené oblasti flash paměti. Kód se pak spouští přímo z flash bez nutnosti znovu kompilovat, což je 5-10× rychlejší než klasické dofile() nad SPIFFS⁶.

Praktický důsledek pro začátek: soubor init.lua uložený v SPIFFS je vždy to první, co firmware po startu spustí - typicky se v něm připojuje Wi-Fi a pak se předá řízení modulu z LFS. Dokumentace výslovně doporučuje, aby init.lua nikdy nepředpokládal, že LFS obsahuje platná data (třeba po neúspěšném nahrání), a ošetřoval načtení modulů přes pcall(node.flashindex("_init"))⁶.

Podpora periferií: co s Lua na ESP skutečně zprovozníte

Tahle sekce mapuje moduly, které jako vývojář elektroniky budete potřebovat nejčastěji. Dokumentace, ze které vychází, je psaná primárně pro ESP8266 - u ESP32 řady je API modulů koncepčně stejné, ale míra otestování a dolaďování detailů je nižší, protože jde o mladší a méně používanou větev.

GPIO a přerušení

Základní čtení a zápis pinu zajišťují gpio.read(pin) (vrací 0 nebo 1) a gpio.write(pin, gpio.HIGH/gpio.LOW)⁷. Pozor na časté zdroje chyby: číslo, které tyhle funkce očekávají, je IO index NodeMCU firmwaru, ne číslo GPIO vytištěné na desce. Index 4 odpovídá GPIO2 (na většině desek popsanému jako D4), index 5 odpovídá GPIO14 (D5) atd. - mapování je pevně dané firmwarem a při psaní kódu podle cizích schémat se vždy vyplatí ho ověřit v dokumentaci, ne odhadovat podle sítotisku na desce.

Pro hardwarová přerušení slouží gpio.trig(), který lze nastavit na pinech 1 až 12 (pin 0 přerušení nepodporuje)⁷. Podporované režimy hrany jsou:

• "up" - náběžná hrana
• "down" - sestupná hrana
• "both" - obě hrany
• "low" / "high" - úrovňové spouštění

Callback funkce dostává aktuální úroveň pinu, časovou značku v mikrosekundách a počet přerušení, která byla od posledního zavolání „slita" dohromady, pokud přišla rychleji, než je firmware stihl zpracovat⁷. Tohle je důležitý detail - při velmi rychlých sekvencích pulzů může dojít ke ztrátě jednotlivých událostí, callback vás jen informuje, kolik jich chybí.

PWM

PWM modul umožňuje současně řídit maximálně 6 pinů, s frekvencí v rozsahu 1 až 1000 Hz a rozlišením 10 bitů (hodnota střídy 0 až 1023)⁸. Zásadní omezení, na které často narazí lidé zvyklí na PWM z Arduina: všechny aktivní PWM kanály sdílejí jedinou frekvenci pro celý systém⁸ - nelze mít jeden pin blikat na 200 Hz a druhý na 800 Hz současně, protože generátor frekvence je pro celý čip jen jeden.

I2C

ESP8266 nemá hardwarovou I2C sběrnici, takže NodeMCU implementuje softwarové bit-banging I2C na libovolné dvojici GPIO pinů⁹. Podporované rychlosti jsou standardní 100 kHz, rychlý mód 400 kHz, a FastPlus mód 1 MHz (ten ale vyžaduje běh CPU na 160 MHz)⁹. Firmware umí obsluhovat až 10 nezávislých sběrnic současně, včetně sdílení SDA linky mezi nimi kvůli úspoře pinů, a podporuje clock stretching pro pomalejší periferie⁹.

SPI

Na rozdíl od I2C je SPI implementované hardwarově. ESP8266 nabízí dvě hardwarové sběrnice - SPI (ID 0, typicky obsazená interní flash pamětí) a HSPI (ID 1, doporučená pro vlastní periferie) s pevně danými piny: CLK na GPIO14, /CS na GPIO15, MOSI na GPIO13, MISO na GPIO12¹⁰. Základní frekvence je 80 MHz, dělená konfigurovatelným děličem - lze tedy volit prakticky libovolnou rychlost od 80 MHz směrem dolů¹⁰.

UART

K dispozici jsou dvě sériové linky - UART0 obousměrná, UART1 jen pro odesílání, přijímat na ní nelze¹¹. Výchozí rychlost konzole je 115200 baud, přičemž prvních cca dvě minuty po startu firmware automaticky detekuje rychlost, na jaké s ním terminál komunikuje¹¹. Piny UART0 lze přesměrovat na GPIO13/GPIO15 pomocí uart.alt(), což se hodí, pokud potřebujete primární piny uvolnit pro něco jiného¹¹.

ADC

Tohle je časté zklamání pro lidi přicházející z jiných platforem: ESP8266 má jediný ADC kanál, navíc sdílený s měřením napájecího napětí modulu¹². Firmware musí být nakonfigurován buď pro čtení externího napětí na pinu (adc.read()), nebo pro čtení systémového napětí (adc.readvdd33()) - přepnutí mezi režimy vyžaduje restart čipu, a funkce nepoužitá pro daný režim vrací hodnotu 65535 jako indikaci, že daný způsob čtení není v aktuální konfiguraci k dispozici¹². Novější ESP32 čipy mají v hardwaru ADC kanálů podstatně víc, ale kompletní zdokumentování odpovídajícího rozhraní modulu adc pro dev-esp32 větev zatím není na úrovni ESP8266 dokumentace - před nasazením v ostrém projektu si chování na konkrétním čipu ověřte experimentálně.

WS2812 (adresovatelné RGB LED)

Modul ws2812 umí poslat data na jeden nebo dva LED pásky v jejich nativním formátu (obvykle GRB pro RGB, GRBW pro RGBW pásky)¹⁴. Zajímavý implementační detail: modul k přesnému časování signálu zneužívá hardwarový UART, což znamená, že po odeslání dat se funkce může vrátit až 300 mikrosekund předtím, než odesílání skutečně doběhne - pokud potřebujete navazující akci provést synchronně, dokumentace doporučuje počkat těch 300 µs pomocí tmr.delay()¹⁴. Praktický důsledek: dokud běží odesílání na WS2812, nelze spolehlivě používat příslušný hardwarový UART port k něčemu jinému.

Časování a proč tmr není vhodný pro sonar

Tohle je bod, který si zaslouží zvláštní pozornost, protože je to nejčastější zdroj zklamání u lidí přicházejících z Arduina nebo MicroPythonu a chtějících si na ESP s Lua postavit ultrazvukový dálkoměr typu HC-SR04.

Modul tmr pracuje na úrovni milisekund pro běžné callbacky, tmr.now() sice vrací čítač v mikrosekundách, ale dokumentace k němu výslovně uvádí, že „přesnost je omezená a kumulující se chyby vedou k poměrně nepřesnému měření času"¹³. Funkce tmr.delay(), která by teoreticky šla použít k busy-loop čekání na echo pulz, je podle dokumentace „obecně špatný nápad, protože nic jiného nedostane šanci běžet a síťový zásobník (a další věci) může spadnout"¹³.

Důvod je architektonický: NodeMCU běží na kooperativním, událostmi řízeném modelu (podobně jako Node.js), ne na jednoduchém blokujícím while cyklu jako Arduino. Modul tmr je dokumentací popsaný jako nástroj „pro nastavování pravidelně se opakujících úloh, časové limity operací a nízko-rozlišené odhady času" - ne pro deterministické měření šířky pulzu na mikrosekundy přesně¹³. Klasický postup měření vzdálenosti u HC-SR04 (odešli trigger pulz, čekej na náběžnou hranu echo, změř čas do sestupné hrany) je tedy v čisté Lua na NodeMCU podstatně méně spolehlivý než ve srovnatelném MicroPython nebo Arduino kódu - přesnost bude kolísat kvůli tomu, že Wi-Fi zásobník a další interní úlohy firmwaru mohou měření kdykoliv na pár mikrosekund přerušit. V praxi se to řeší buď kombinací gpio.trig() (zachytí náběžnou i sestupnou hranu echo pinu jako přerušení s časovou značkou místo busy-loopu), nebo přesunem přesného měření pulzu do C modulu firmwaru, pokud si firmware sami kompilujete a umíte si takový modul dopsat.

Jak zprovoznit první Lua kód na ESP

Krok 1: získání firmwaru

Postup se zásadně liší podle toho, jaký čip máte na desce:

• ESP8266 / ESP8285: nejrychlejší cesta je cloud builder na nodemcu-build.com - zvolíte větev, moduly (třeba gpio, i2c, pwm, ws2812, tmr, file) a verzi Lua, zadáte e-mail a za pár minut dorazí odkaz na hotový .bin soubor⁵. Alternativou je lokální build podle oficiálního návodu v repozitáři, který funguje na Linuxu, macOS i přes Docker²⁰.
• ESP32 a novější (S2, S3, C3, C6, H2): žádný cloud builder ani hotové binárky nejsou k dispozici. Musíte si nainstalovat Espressif ESP-IDF (instalační skripty install.sh pro Linux/macOS, install.bat/install.ps1 pro Windows, oficiálně podporované na všech třech systémech)², naklonovat větev dev-esp32 a spustit make IDF_TARGET=esp32 (nebo esp32s3, esp32c3 atd. podle konkrétního čipu)³. Je to o krok náročnější než u ESP8266, ale postup je stejný jako u kteréhokoliv jiného ESP-IDF projektu, takže se hodí i jako první seznámení s oficiálními nástroji Espressifu.

Krok 2: flashování na Linuxu, Windows i macOS

Univerzálním nástrojem napříč všemi třemi systémy je esptool.py - oficiální nástroj od Espressif, jediný, který firma sama doporučuje¹⁹. Typické volání vypadá takto:

esptool.py --port <port> write_flash -fm <mód> 0x00000 nodemcu-firmware.bin

kde <mód> je qio u starších ESP-01/07 modulů s 512 KB flash, nebo dio u novějších modulů ESP-12 a u ESP32 s 4 MB a více.

Kdo nechce pracovat s příkazovou řádkou, může sáhnout po grafickém nástroji NodeMCU PyFlasher - je to esptool.py zabalený do jednoduchého okna postaveného na wxPython. Vydání obsahují samostatně spustitelný .exe pro Windows a od verze 3.0 také .dmg pro macOS, na Linuxu se spouští přímo z Pythonu¹⁵.

Bez ohledu na nástroj a operační systém je potřeba dvou věcí:

• Ovladač USB-sériového čipu. Levnější desky (typicky s čipem CH340, jako na fotce výše) i dražší (s CP2102/CP2104) potřebují na Windows a starším macOS instalaci ovladače výrobce čipu - na aktuálních verzích Linuxu a macOS bývá ovladač už součástí systému.
• Správný název portu. Na Linuxu to bývá /dev/ttyUSB0 (nebo /dev/ttyACM0 u některých desek s nativním USB), na macOS /dev/cu.usbserial-XXXX (nikdy /dev/tty.usbserial-* pro programové ovládání), na Windows COM3, COM4 a podobně - přesné číslo najdete ve Správci zařízení.

Krok 3: komunikace a nahrávání skriptů

Po naflashování firmwaru čip odpovídá na sériové lince na Lua REPL - v podstatě interaktivní konzoli, do které lze psát Lua příkazy přímo. Pro pohodlnější práci existují dva hlavní nástroje:

• ESPlorer - multiplatformní IDE napsané v Javě (potřebuje Javu 8+), běží na Windows, Linuxu, macOS i Solarisu¹⁶. Kromě NodeMCU Lua umí i MicroPython a AT příkazy, má zvýrazňování syntaxe a hlavně „chytré" nahrávání skriptů, které po každém řádku ověřuje odpověď od zařízení¹⁶.
• NodeMCU-Tool - jednodušší CLI nástroj postavený na Node.js, instaluje se přes npm. Nahrání souboru vypadá jednoduše: nodemcu-tool upload --port=/dev/ttyUSB0 skript.lua, s volbou --compile lze rovnou nahrát zkompilovanou bajtkódovou verzi místo zdrojového textu¹⁸.

Oba nástroje fungují stejně na Linuxu, Windows i macOS - jde jen o to, zda dáte přednost grafické Javě, nebo terminálovému JavaScriptu.

Krok 4: první kód

Ukázka, která zkombinuje blikání LED přes GPIO s reakcí na tlačítko pomocí přerušení - typický „hello world" pro ověření, že firmware i nahrávání fungují:

-- init.lua
led = 4    -- GPIO2 na vetsine NodeMCU desek (D4 v Arduino znaceni)
button = 5 -- GPIO14 (D5)

gpio.mode(led, gpio.OUTPUT)
gpio.mode(button, gpio.INPUT, gpio.PULLUP)

state = gpio.LOW

blinker = tmr.create()
blinker:register(500, tmr.ALARM_AUTO, function()
    state = (state == gpio.LOW) and gpio.HIGH or gpio.LOW
    gpio.write(led, state)
end)
blinker:start()

gpio.trig(button, "down", function(level, when, eventcount)
    print("Tlacitko stisknuto, cas: " .. when .. " us, pocet udalosti: " .. eventcount)
end)

print("Firmware bezi, LED blika, cekam na tlacitko.")

Skript se nahraje například přes nodemcu-tool upload init.lua, a protože se jmenuje init.lua, firmware ho automaticky spustí při každém startu.

Jakou desku zvolit, když chcete v Lua opravdu programovat

Pro čtenáře, který má v ruce konkrétní desku (nebo si ji teprve chystá koupit) a chce vědět, po čem sáhnout:

• Nejlepší a nejméně bolestivá volba zůstává ESP8266 - navzdory tomu, že je to technologicky nejstarší čip v tomto přehledu. Má stabilní vydávanou větev, cloud builder bez nutnosti cokoliv kompilovat, nejlépe zdokumentované moduly a největší množství existujících návodů a hotových projektů.
• ESP32 (klasický, Xtensa) je solidní druhá volba, pokud potřebujete Bluetooth nebo víc výpočetního výkonu než ESP8266 nabízí - počítejte ale s tím, že si firmware musíte sami zkompilovat přes ESP-IDF, protože hotové binárky nejsou.
• ESP32-S2/S3 dává smysl, pokud potřebujete nativní USB nebo (u S3) víc výkonu a AI instrukce - Lua na nich funguje, ale jste o krok dál od vyšlapané cesty než u klasického ESP32.
• RISC-V čipy ESP32-C3/C6/H2 doporučuji vyloženě jen těm, kdo si chtějí sami experimentovat a nevadí jim být na okraji komunity - firmware se pro ně staví, ale hotové návody, ověřené postupy a odpovědi na specifické dotazy budete hledat mnohem hůř než u zbytku rodiny.
• Vyhněte se hledání „hotového" Lua RTOS firmwaru pro ESP32 jako alternativě k NodeMCU - projekt je od konce roku 2022 fakticky mrtvý.

Kdo zvládne postavit první blikající LED a čtení tlačítka na kterémkoliv z těchto čipů, má základ, na kterém lze stavět dál - ať už jde o čtení I2C senzorů, generování PWM signálu pro servo, nebo ovládání pásku adresovatelných LED.

Citovaná díla