Перейти до змісту

Приклади, з яких можна почати

Я сподіваюсь, середовище вже встановлене, і cargo не свариться на відсутній Xtensa тулчейн. Якщо ще ні — спочатку підготовка середовища, а потім створення проєкту.

Тут вже буде код, який щось робить на самій Лілці. Не обов'язково одразу тягнути радіо, async та купу задач, щоби вивести текст або перевірити кнопку.

Що є в цій теці

  • Дисплей та кнопки — найпростіший приклад: текст на дисплеї й лічильник натискань.
  • Async — лічильник на дисплеї та окрема задача Embassy, без BLE.
  • microSD та файли — монтування FAT та читання HELLO.TXT стандартним файловим API.
  • Час від KeiraOS — необов'язковий feature для успадкування RTC після MultiBoot.
  • Готові прошивки — окремі застосунки, що використовують SDK.

Як запустити приклад

Якщо працюєте з цим репозиторієм, переходьте в теку потрібного прикладу:

cd examples/basics
cargo +esp build --release --locked

Це важливо, адже локальна .cargo/config.toml задає xtensa-esp32s3-none-elf, build-std та параметри лінкера. Просто запустити Cargo з іншої теки й сподіватись на магію не вийде.

Для прямого прошивання через налаштований probe-rs:

cargo +esp run --release --locked

Це вже прошивання

cargo run використовує runner з конфігурації та записує програму на пристрій. Якщо хочете запустити її з Keira, спочатку зробіть .bin, як показано нижче.

А якщо через KeiraOS?

З тієї ж теки прикладу, якщо встановлений cargo-espflash:

cargo +esp espflash save-image --release --chip esp32s3 basics.bin

Скопіюйте basics.bin на microSD та відкрийте його в Keira. Це самостійна прошивка: Keira записує її в OTA-розділ і перезапускає пристрій.

Без --merge

Для MultiBoot потрібен application .bin, без завантажувача та таблиці розділів. save-image тільки створює файл на комп'ютері й нічого сам не прошиває.

Що з пам'яттю

У навчальних прикладах є allocator esp-alloc і heap на 16 КіБ для простого старту. Це вибір прикладів, а не мінімальна вимога SD, FAT, дисплея чи RTC.

Є нюанс поточної залежності SDK: async-embedded-sdmmc 0.3.1 безумовно підключає extern crate alloc, навіть без default features. Через це кінцева прошивка потребує глобального allocator під час компонування. Саме підключення alloc не означає, що драйвер реально виділяє пам'ять. Окрема FAT-бібліотека embedded-sdmmc 0.9.0 працює з фіксованими буферами й не потребує heap.

Для роботи без heap можна використати статичні буфери та allocator, який відмовляє в алокаціях. Але тоді кожна залежність має обходитися без динамічної пам'яті. Детальніше — про пам'ять.

Як підправити ці сторінки

З кореня репозиторію:

python3 -m venv .venv-docs
.venv-docs/bin/pip install -r requirements-docs.txt
.venv-docs/bin/mkdocs serve

Відкрийте адресу з термінала: після збереження Markdown сторінка оновиться сама. Перед публікацією перевірте .venv-docs/bin/mkdocs build --strict.

Код на сторінках про дисплей, async, microSD та RTC підтягується прямо з examples/, тому спочатку редагуйте сам приклад, а потім збирайте документацію.