Добрый день, уважаемые читатели!

В данной статье попробуем разобраться, как подключать сторонние компоненты (библиотеки) к проекту ESP-IDF (то есть не входящие в состав основного ядра ESP-IDF). Во второй части статьи весьма кратко рассказано о реестре компонентов ESP-IDF. Статья предназначена для тех, кто хочет разобраться в программировании ESP32 с использованием фреймворка ESP-IDF и Arduino core в режиме ESP-IDF плюс Arduino as component.

Компоненты в ESP-IDF и с чем их едят

Компонент в системе сборки ESP-IDF — это независимый и переиспользуемый пакет кода, который является базовым строительным блоком для создания приложений. Основная идея компонентов — реализовать модульность кода. Это как конструктор Lego: вы собираете своё приложение из отдельных «кирпичиков» (компонентов), каждый из которых отвечает за свою задачу. Такой подход позволяет реализовать повторное использование кода в разных проектах, делает структуру проекта более понятной, что упрощает разработку и дельнейшую поддержку.

Компоненты ESP-IDF по своему общему смыслу очень похожи на библиотеки Arduino IDE, но есть и принципиальные отличия. Компоненты в ESP-IDF — это более «продвинутая» и строгая версия, если сравнивать их с библиотеками из Arduino IDE.

С одной стороны цель компонента ESP-IDF и библиотеки Arduino одна и та же: это способ повторно использовать готовый код — Вы не пишете драйвер для дисплея или датчика каждый раз с нуля, а берете готовую «библиотеку/компонент» и подключаете к проекту. И там, и там есть файлы .c/.cpp (исходники) и .h (заголовочные файлы). Вы можете скачать готовый компонент из интернета (например, из реестра ESP или с GitHub) так же, как вы скачиваете библиотеку через менеджер библиотек Arduino или с GitHub.

Но есть и принципиальное отличие. Компонент в ESP-IDF — это «библиотека на стероидах», то есть более профессиональный инструмент для профессиональной сборки с системой зависимостей, а библиотека в Arduino — это чаще всего просто «папка с кодом». Компонент умеет управлять своими версиями, зависимостями от других компонентов и параметрами сборки, и делает это не через «авось скомпилируется», а через строгую систему CMake.

Управление зависимостями. Допустим, у нас есть некая библиотека A, которая использует для своей работы другую библиотеку B. В этом случае:

В Arduino IDE вы должны будете сами найти и установить в систему библиотеку B. Если версии библиотек не совпадают — проект падает с сотнями ошибок.
В ESP-IDF управление зависимостями автоматическое. Компонент четко прописывает в файлах idf_component.yml и CMakeLists.txt, какие составные компоненты ему нужны и каких версий. Система сборки сама скачает и подключит их к проекту – вам не нужно об этом заботится.

Настройка (конфигурация) библиотек. Иногда требуется изменить параметры какой-то библиотеки – например выбрать частоту SPI или пин GPIO. Как правило, это делается путем определения #define в коде или через параметры в конструкторе.

В Arduino IDE вам придется делать это либо через параметры командной строки или редактировать исходный код библиотеки.
В CMake легко и удобно задавать параметры через систему menuconfig (текстовое или графическое меню, с помощью которого можно задать параметры для всего проекта целиком, включая все подключенные компоненты). Вы сможете зайти в настройки компонента (если они предусмотрены разработчиком компонента, разумеется) и изменить их, не залезая в исходники компонента.

Правила сборки.

Arduino IDE сама решает, какие файлы компилировать, а какие нет. Обычно компилируется всё подряд в папке src библиотеки. В связи с этим иногда возникают проблемы.
У компонента есть специальный файл CMakeLists.txt – в нем разработчик сам указывает: какие файлы компилировать, какие папки с заголовками показывать наружу, а какие скрывать. Это дает полный контроль над процессом сборки компонента и включения его в проект.

Какие компоненты можно использовать в проекте ESP-IDF

В экосистеме ESP-IDF компоненты можно получить из нескольких основных источников, ниже приведен исчерпывающий список всех возможных способов подключить сторонний код к вашему проекту.

Встроенные компоненты ESP-IDF
Это библиотеки, которые уже идут в основном составе самого фреймворка ESP-IDF. Они находятся в папке $IDF_PATH/components и являются основой для работы с системой, встроенными контроллерами, периферийными устройствами.
Примеры: freertos (операционная система), esp_driver_gpio (работа с цифровыми выводами), esp_http (HTTP-клиент) и многие другие.
Использование: Чтобы их подключить к проекту, вам достаточно добавить соответствующий заголовочный файл #include в код – больше ничего не требуется. Добавлять зависимость от компонента в CMakeLists.txt в секции REQUIRES в этом случае не нужно! Эти компоненты нужны практически в любом проекте, и разработчики ESP-IDF сделали их доступными “из коробки”, чтобы не загромождать файлы сборки повторяющимися строчками.
Локальные компоненты проекта
Это компоненты, которые вы создаете сами и храните непосредственно внутри папки вашего проекта – это могут быть различные составные части большого проекта. Обычно их размещают в каталоге components/ в корне проекта.
Когда использовать: Этот метод хорошо подходит для кода, который необходимо вынести из основного файла проекта для удобства, но который не планируется повторно использовать в других проектах, либо для прототипов и кастомизированных вариантов системных компонентов.
Особенность: Компоненты из папки components/ имеют наивысший приоритет при сборке и могут переопределять компоненты с тем же именем из managed_components/. Это удобно, если нужно модифицировать какой-либо стандартный компонент без правки его исходников.
Локальные общие компоненты (вне папки проекта)
Если у вас есть набор собственных компонентов, которые вы одновременно используете в разных проектах, вы можете хранить (и редактировать) их в отдельной общей папке (например это может быть каталог $MY_LIBS/my_common_components/). В этом случае компоненты подключаются к системе сборки CMake напрямую, минуя менеджер компонентов.
Использование: Укажите путь к этой папке в главном CMakeLists.txt вашего проекта с помощью переменной EXTRA_COMPONENT_DIRS
Пример: set(EXTRA_COMPONENT_DIRS "$ENV{MY_LIBS}/my_common_components").
Управляемые компоненты
Их поиском и установкой занимается менеджер компонентов. Менеджер компонентов интегрируется с системой сборки ESP-IDF для загрузки и управления компонентами из реестра компонентов и других источников – локальных папок, GitHub и т.д. Это стандартный способ подключения библиотек из реестра (но не только) к проекту ESP-IDF. Как правило, менеджер компонентов скачивает или копирует подключаемые библиотеки в каталог в managed_components/ вашего проекта. Но это не точно.

При сборке компоненты ищутся в определенном порядке, который выглядит так:

Локальные компоненты проекта — из папки components/ в корне вашего проекта.
Компоненты из EXTRA_COMPONENT_DIRS — папки с компонентами, которые вы указали в CMakeLists.txt.
Управляемые компоненты — их поиском и установкой занимается менеджер компонентов.
Встроенные компоненты ESP-IDF — системные компоненты из папки установки ESP-IDF.

Если в нескольких источниках окажутся компоненты с одинаковыми именами, будет использован тот, который найден в источнике с более высоким приоритетом (т.е. из components/ вашего проекта перекроет системный компонент из IDF_PATH/components). Это удобно, если вам нужно модифицировать стандартный драйвер.

Менеджер компонентов (IDF Component Manager)

Это основной инструмент для управления зависимостями вашего проекта на ESP-IDF, который автоматически скачивает и подключает нужные компоненты (библиотеки) заданной версии. Он использует файл idf_component.yml в вашем проекте, находит все указанные в нем зависимости от сторонних компонентов и скачивает их в папку managed_components. Это избавляет вас от ручного поиска и копирования нужных библиотек. Особенно если вы открыли чужой проект из интернета – скачали проект, открыли его – а все библиотеки-компоненты подтянулись “волшебным образом”.

Менеджер компонентов может получать компоненты из:

ESP Component Registry – центрального реестра компонентов Espressif (его мы обсудим ниже)
из Git-репозитория
из локальной папки.

Например: вы хотите добавить в проект фреймворк Arduino core как компонент ESP-IDF, вы просто выполняете команду idf.py add-dependency "espressif/arduino-esp32^3.3.10", и при сборке проекта менеджер компонентов сам скачает и Arduino core и все вложенные зависимости. При этом в папке managed_components появляются копии для всех компонентов, готовые к компиляции вместе с вашим проектом (в том числе локальных).

По умолчанию диспетчер компонентов загружает компоненты из реестра компонентов ESP через интернет во время сборки. Если вы работаете в изолированной среде, в сети с ограниченным доступом или просто хотите получать воспроизводимые сборки без сетевых зависимостей, вы можете указать решателю версий локальный репозиторий.

Официальная документация IDF Component Manager: https://docs.espressif.com/projects/idf-component-manager/
Документация в составе ESP-IDF Programming Guide: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/API-guides/tools/idf-component-manager.html

Файл манифеста idf_component.yml

Файл манифеста — это цифровой список “покупок” для вашего проекта. В нём вы пишете: “Для моего проекта мне нужен компонент А, версии не ниже 2.0”. Когда вы запускаете сборку (нажимаете кнопку “Скомпилировать”), менеджер компонентов читает этот список и автоматически скачивает все эти компоненты из интернета прямо в ваш проект. Как курьер, который привозит продукты по вашему списку.

Файл idf_component.yml лежит в папке вашего проекта (обычно рядом с main). Выглядит он так:

dependencies:
  espressif/led_strip: >=2.0.0   # Мне нужна библиотека для управления светодиодами
  espressif/button: ^3.0.0       # И библиотека для работы с кнопками

Что здесь написано:

dependencies — раздел “зависимости” (то, что менеджер документов должен скачать).
- espressif/led_strip — имя компонента (как название библиотеки в Arduino, но с указанием автора).
- >=2.0.0 — версия (скачай версию 2.0.0 или новее).

А теперь магия, которой в Arduino нет.

Допустим, вы добавили компонент led_strip. А для этого компонента внутри него программист написал (в своём собственном файле манифеста idf_component.yml): “Для моей работы мне нужен компонент driver“. Вы ничего не знаете про этот компонент driver – вы даже не подозреваете, что он нужен. Но менеджер компонентов сам зайдёт внутрь скачанного компонента, прочитает его манифест, увидит там зависимость от компонента driver и автоматически скачает его тоже. Вам не нужно ничего искать, скачивать и разбираться с ошибками “не найден такой-то файл”. Всё происходит само.

Файл idf_component.yml может содержать два основных раздела:

dependencies – зависимости вашего проекта от компонентов
targets – цели, то есть семейства SoC

Раздел dependencies по своей сути является обязательным. Этот раздел представляет собой список (словарь), где каждый элемент — это название зависимости от какой-то библиотеки. Менеджер компонентов поддерживает следующие типы источников зависимостей:

Поддерживаются условные зависимости, в том числе и от опций системы KConfig. В рамках данной статьи у меня нет цели подробно описывать все элементы файла idf_component.yml, подробнее про формат файла манифеста вы можете почитать самостоятельно тута.

Официальная документация: https://docs.espressif.com/projects/idf-component-manager/en/latest/reference/manifest_file.html

Подключение библиотек через IDF Component Manager

Подключить к проекту необходимый компонент можно двумя основными способами:

с помощью команды add-dependency для командной строки
или через создание файла манифеста вручную – в любом текстовом редакторе

Также есть вариант подключения компонентов через графический интерфейс в ESP-IDF Eclipse Plugin.

⚙️ Способ 1: Командная строка (idf.py add-dependency)

Если вы ничего не знаете про файл манифеста, да и не хотите знать – то это ваш способ. Команда idf.py add-dependency автоматически создаст или обновит нужный файл манифеста для вашего проекта. Для библиотек из реестра компонентов это самый быстрый и рекомендуемый способ.

idf.py add-dependency "namespace/name^version"

Например, чтобы добавить компонент для “драйвера” кнопки espressif/button версии 4.1.3 (или выше) выполните следующую команду в VSCode: > ESP-IDF: Open ESP-IDF Terminal:

$ idf.py add-dependency "espressif/button^4.1.3"

После этого вы должны получить примерно следующее сообщение:

Executing action: add-dependency
NOTICE: Successfully added dependency "espressif/button": "^4.1.3" to component "main"
NOTICE: If you want to make additional changes to the manifest file at path <user_path>/blink/main/idf_component.yml manually, please refer to the documentation: https://docs.espressif.com/projects/idf-component-manager/en/latest/reference/manifest_file.html

Этой командой в вашем проекте будет создан новый файл idf_component.yml со следующим содержимым:

dependencies:
  espressif/button: ^4.1.3

Этот файл заставит менеджер компонентов скачать компонент и все его зависимости в папку managed_components вашего проекта. Для выполнения этого необходимо запустить сборку проекта или выполнить команду реконфигурации проекта idf.py reconfigure.

Далее, чтобы использовать компонент в вашем коде, необходимо подключить соответствующий заголовочный файл #include "бла-бла-бла" и вызвать функции, указанные в документации и папке компонента.

Чтобы подключить компонент напрямую из Git-репо, укажите опцию --git и, при необходимости, --git-path и --git-ref:

$ idf.py add-dependency my_component --git https://github.com/<org>/<repo>.git --git-path components/my_component --git-ref v1.2.3

✍️ Способ 2: Ручное создание манифеста (файл idf_component.yml)

Однако никто не запрещает вам создать или редактировать файл манифеста idf_component.yml вручную. Этот способ дает больше гибкости, так как позволяет подключать не только компоненты из реестра компонентов, но и из локальных папок.

Файл манифеста idf_component.yml должен находиться в корне вашего компонента (по умолчанию — в папке main вашего проекта). Вы можете создать этот файл в любом текстовом редакторе (plain text UTF-8) или просто выполните команду:

idf.py create-manifest

Примеры содержимого файла idf_component.yml:

Зависимость от библиотек из реестра компонентов:

dependencies:
  espressif/led_strip: ^2.4.1
  espressif/button: ^4.1.3

Зависимость от компонента из Git-репозитория:

dependencies:
  test_component:
    path: test_component
    git: ssh://git@gitlab.com/user/components.git

Локальная зависимость:

dependencies:
  some_local_component:
    path: ../../my_libs/component

Систему версионирования компонентов мы кратко обсудим ниже.

🛠️ Подключение библиотек “по ссылке”

Иногда стандартное поведение менеджера компонентов — копировать локальный компонент в папку managed_components — не удобно. Например когда вы ведете разработку собственно самого компонента в другой папке. В этом случае код компонента должен оставаться в исходной локальной папке, без копирования в папку проекта.

Для решения этой задачи в ESP-IDF существует несколько официальных способов, которые позволяют использовать компонент при сборке прямо из его исходной директории без копирования.

🛠️ Способ 1: Использование override_path

Этот метод специально создан для описанного выше случая — разработки уже опубликованного компонента “на месте”. Он описан в официальной документации idf_component.yml как способ “временно переопределить компонент, который существует в реестре, локальной версией“.

В файле idf_component.yml вы указываете зависимость от компонента из реестра, а затем добавляете поле override_path, которое указывает на локальную папку с вашим разрабатываемым компонентом:

dependencies:
  # Предположим, компонент опубликован в реестре как namespace/component_with_example
  namespace/component_with_example:
    version: "~1.0.0"
    override_path: "../../" # Менеджер использует компонент из этой папки, а не скачивает из реестра

Такой подход часто используется в примерах внутри самого компонента, чтобы пример всегда использовал актуальную версию кода по указанному пути, а не из реестра.

📂 Способ 2: Использование локального пути (path)

Этот метод подходит для использования компонентов, которые еще не опубликованы или полностью локальны. Он более простой, но менее гибкий в плане переключения между локальной и опубликованной версией. Вы просто указываете поле path с относительным или абсолютным путем до директории компонента .

dependencies:
  some_local_component:
    path: ../../projects/component # Менеджер будет использовать компонент по этому пути

⚙️ Способ 3: Через систему сборки CMakeLists.txt

Можно вообще не создавать никаких idf_component.yml, а вместо этого воспользоваться стандартным инструментарием системы сборки. В корневом файле CMakeLists.txt вашего проекта для этого предназначена переменная EXTRA_COMPONENT_DIRS. Вы просто перечисляете в ней пути к папкам, где лежат ваши компоненты.

# В корневом CMakeLists.txt вашего проекта
set(EXTRA_COMPONENT_DIRS
    ../shared_components/    # Путь к компонентам из соседней папки
    custom_lib/              # Путь к папке с вашим локальным компонентом
)

Этот способ лучше всего подходит, когда вы разрабатываете компонент самостоятельно и хотите, чтобы он использовался при сборке непосредственно из его текущей папки, без копирования.

📐 Схема версионирования компонентов

Вы, наверное, заметили, что при подключении библиотеки можно (но не обязательно) указывать версию библиотеки или диапазон версий. Указание версии компонента позволяет устранить (либо существенно снизить) риск того, что Ваш проект может внезапно перестать собираться, когда в новой версии какого-либо компонента произошли несовместимые изменения.

Все компоненты должны обязательно следовать строгой схеме управления версиями, похожей на Semantic Versioning. Поэтому, если вы создаете свой компонент, то также должны следовать этим правилам. Подробное описание системы версионирования ESP-IDF в оригинале вы можете найти здесь.

Полный номер версии выглядит так:

major.minor.patch~revision-prerelease+build

где поля означают следующее:

major (Основная): Увеличивается при несовместимых изменениях в API. Переход на новую мажорную версию может потребовать изменений в вашем коде.
minor (Минорная): Увеличивается при добавлении нового функционала, который обратно совместим с прежними версиями.
patch (Патч): Увеличивается, когда в данной версии выходят только исправления ошибок, без изменения API.
~revision (Ревизия): Это опциональное поле. Оно используется, когда компонент зависит от другого пакета, и в нём есть изменения, не затрагивающие основной код. Например, в версии 0.1.2~3 ревизия равна 3.
-prerelease (Пре-релиз): Опциональное поле для обозначения нестабильных версий (alpha, beta, rc). Версия с этим суффиксом считается ниже, чем версия без него. Пример: 1.0.0-beta1.
+build (Сборка): Ещё одно опциональное поле для метаданных сборки. Оно игнорируется при определении старшинства версии.

Приоритет версий определяется сравнением полей слева направо. Например, 1.0.0 всегда новее, чем 0.9.0.

📝 Как задать версию компонента

В файле манифеста idf_component.yml вы можете указать не только конкретную версию компонента, но и гибкий диапазон версий. Это делается с помощью специальных операторов сравнения: >=, >, ==, <, <=, !=, ~=, ~, ^.

Как задать конкретную версию компонента – Вы наверное уже поняли – просто ~~добавьте воды~~ укажите её espressif/button: ==4.1.3. Чисто технически, можно опустить оператор сравнения == (согласно правилам синтаксиса, если оператор не указан, он по умолчанию интерпретируется как ==), но делать так не рекомендуется.
Можно указать несколько условий, перечислив их через запятую: >=1.0.0,<2.0.0 – это означает, что означает “любая версия с мажорной единицей”.
В сравнении версий можно использовать символ подстановки * – он означает “любое значение” в поле major, minor или patch. Например, ==1.* означает “любая версия с мажорной единицей”, что эквивалентно приведенному выше выражению >=1.0.0,<2.0.0.
Совместимый релиз ~= – это выражение разрешает обновления компонентов в пределах указанной минорной версии, ~=1.2.3 эквивалентно выражению >=1.2.3, <2.0.0.
Совместимый минорный релиз ~ – позволяет обновления на уровне патчей, ~1.2.3 эквивалентно выражению >=1.2.3,==1.2.*.
Совместимый мажорный релиз ^– самый популярный подход. Позволяет обновления в пределах крайнего левого ненулевого разряда. Выражение ^1.2.3 означает “любая версия с мажорной единицей” (>=1.2.3,<2.0.0), а ^0.2.3 — “любая версия с минорной двойкой” (>=0.2.3,<0.3.0).

Подробное описание системы версионирования ESP-IDF в оригинале вы можете найти здесь.

📝 Можно не указывать версию компонента?

Можно! А зачем? Версию можно не указывать, для этого просто укажите имя компонента без указания версии:

idf.py add-dependency example/cmp

Эта команда добавит в проект зависимость от компонента example/cmp последней доступной версии.

В файле манифеста idf_component.yml вы можете просто указать имя компонента, например, как это сделано для компонента espressif/esp32_display_panel:

dependencies:
  # Зависимость без указания версии
  espressif/esp32_display_panel:

Другой вариант – указать * (звездочку) в качестве версии. Это означает буквально “любая версия”:

dependencies: 
  espressif/esp32_display_panel:
    version: "*"

Но такой подход имеет риск: проект может внезапно перестать собираться, если в новой версии компонента произошли несовместимые изменения. Поэтому использование этого подхода требует внимательности. Если вам нужен более предсказуемый и контролируемый процесс, лучше всё же явно указывать версию или диапазон версий – это гарантирует, что обновления компонентов не сломают сборку вашего проект.

⚙️ Как обновить зависимости?

Для того, чтобы обновить версии компонентов в пределах заданных диапазонов, выполните команду:

$ idf.py update-dependencies

Эта команда запускает разрешение зависимостей и обновляет dependencies.lock при изменении разрешенного набора. Если файл манифеста не изменился, а существующие заблокированные версии по-прежнему удовлетворяют ограничениям, решатель версий может оставить текущие версии. Если ограничения изменились (или ранее выбранные версии им не удовлетворяют), решатель версий выбирает новый согласованный набор и загружает новые версии.

Реестр компонентов

Когда то ~~давным-давно~~ одним из наиболее существенных недостатков разработки на ESP-IDF считалось отсутствие сторонних библиотек для различных сенсоров, экранов и других устройств. Что, безусловно, создавало определенные трудности в освоении этого фреймворка и отталкивало многих программистов. Однако в настоящее время ситуация радикально изменилась. C выходом ESP-IDF 5.0 стал активно развиваться и пополняться реестр компонентов ESP-IDF – ESP Component Registry, который представляет собой централизованное хранилище компонентов (библиотек) для ESP-IDF и решает проблему “велосипедостроения”.

Что такое реестр компонентов ESP и когда он появился?

Это официальный каталог библиотек для фреймворка ESP-IDF, где можно найти и скачать и (или опубликовать ваши собственные) готовые компоненты и примеры для ESP-IDF. Процесс его активного наполнения начался с выхода версии ESP-IDF v5.0 (самый конец 2022 года). В этом релизе компания Espressif приняла стратегическое решение: некоторый компоненты, которые раньше были частью ядра фреймворка, были из него удалены и перенесены в этот реестр. Это было сделано для того, чтобы основная часть ESP-IDF стала более легкой, а все вспомогательные библиотеки были опциональными и легко подключаемыми через менеджер пакетов. Например на тот момент были “вынесены” в реестр LibSodium, mDNS, FreeModbus и некоторые другие. На этом этот процесс не закончился, в последних версиях ESP-IDF из ядра исключен ESP-MQTT и некоторые другие библиотеки.

Однако не стоит ошибочно полагать, что в реестре компонентов содержаться только исключенные из ядра компоненты. Судя по всему, в Espressif очень серьезно озаботились проблемой отсутствия прикладных библиотек и активно работают над наполнением реестра дополнительными компонентами. На момент написания статьи в реестре уже находится около 1000 библиотек для самых разных программистских нужд. Большинство из них “официальные” компоненты, то есть созданы самой Espressif, но есть и достаточно большое количество компонентов сторонних разработчиков, например LVGL, Waveshare. Вы также можете при желании опубликовать в реестре и ваши собственные компоненты.

Небольшой кусочек реестра компонентов

Реестр компонентов даже на текущий момент довольно большой, а будет еще больше. В таблице ниже вы можете найти некоторые компоненты, представленные в реестре на текущий момент. Разумеется, в этой таблице присутствует очень малая часть списка – я физически не смогу дублировать весь реестр сюда. Тогда зачем все это? Цель данного списка – только продемонстрировать, что сейчас в реестре компонентов почти наверняка можно найти готовый компонент для вашей задачи или драйвер для вашего устройства. Например драйверов LCD дисплеев в реестре компонентов аж на 10 страниц поисковой выдачи. Я также поместил некоторые компоненты, которые лично мне интересны.

Большая часть представленных ниже компонентов разработана в Espressif. На мой взгляд, это очень даже неплохо – так как гарантирует, что при создании компонента применялся унифицированный подход (обратите внимание на драйверы LCD – почти все они созданы на базе другого компонента) и максимально использовались аппаратные возможности микроконтроллера (вместо программной эмуляции). А не “кто во что горазд”, как это часто бывает с библиотеками Arduino. Но и библиотеки сторонних производителей также присутствуют в данной таблице.

Компонент	Автор	Описание
Системные компоненты и протоколы, исключенные из ядра ESP-IDF
ESP32 MQTT Library	Espressif	Поддержка MQTT через TCP, SSL, MQTT over Websocket, MQTT over Websocket Secure. Ссылка: espressif/mqtt
ESP-Modbus Library	Espressif	Библиотека для связи по протоколу Modbus в сетях, основанных на интерфейсах RS485, WiFi, Ethernet. Ссылка: espressif/esp-modbus
ESP Modem	Espressif	Библиотека для связи с сотовыми модемами GSM/LTE, поддерживающими AT-команды и протокол PPP в качестве сетевого интерфейса. Ссылка: espressif/esp_modem
Исполнительные устройства и периферия
Servo	Espressif	Компонент для управления сервоприводами. Использует аппаратный контроллер LED PWM. Ссылка: espressif/servo
DC Motor	Espressif	Драйвер управления коллекторным двигателем постоянного тока. Ссылка: espressif/bdc_motor
LoRa LR1121	Waveshare	Драйвер приемопередатчика LR1121 – многодиапазонный радиочастотный приемопередатчик сверхмалой мощности. Ссылка: waveshare/esp_lora_1121
PID	Espressif	Пропорциональный интегрально-дифференцирующий регулятор (PID). Ссылка: espressif/pid_ctrl
Open Therm	Sazanof	Протокол Open Therm для управления водогрейными и отопительными котлами Ссылка: sazanof/opentherm
PCF85063A	Waveshare	Драйвер RTC PCF85063A для шины I2C Ссылка: waveshare/pcf85063a
Экраны и дисплеи (components?q=esp_lcd)
ESP Display Panel	Espressif	Универсальный драйвер LCD-дисплеев, поддерживающий большое количество контроллеров разных производителей. Ссылка: espressif/esp32_display_panel
ESP LVGL Port	Espressif	Адаптация LVGL8 и LVGL9 для фреймворка ESP-IDF Ссылка: espressif/esp_lvgl_port
ESP LVGL Adapter	Espressif	Многопоточная интеграция LVGL в ESP-IDF Ссылка: espressif/esp_lvgl_adapter
LCD AXS15260D	Waveshare	Реализация контроллера LCD-дисплея AXS15260D с помощью компонента esp_lcd. Ссылка: waveshare/esp_lcd_axs15260d
LCD CO5300	Espressif	Реализация контроллера LCD-дисплея CO5300 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_co5300
LCD EK79007	Espressif	Реализация контроллера LCD-дисплея EK79007 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_ek79007
LCD HX8394	Waveshare	Реализация контроллера LCD-дисплея HX8394 с помощью компонента esp_lcd. Ссылка: waveshare/esp_lcd_hx8394
LCD ILI9341	Espressif	Реализация контроллера LCD-дисплея ILI9341 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_ili9341
LCD ILI9881C	Espressif	Реализация контроллера LCD-дисплея ILI9881C с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_ili9881c
LCD ILI9881C	Waveshare	Драйвер Waveshare 7-DSI-TOUCH-A, разрешение 720*1280. Ссылка: waveshare/esp_lcd_ili9881c
LCD JD9165	Espressif	Реализация контроллера LCD-дисплея JD9165 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_jd9165
LCD JD9165	Waveshare	Реализация контроллера LCD-дисплея JD9165 с помощью компонента esp_lcd. Ссылка: waveshare/esp_lcd_jd9165
LCD JD9365	Espressif	Реализация контроллера LCD-дисплея JD9365 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_jd9365
LCD JD9365	Waveshare	Реализация контроллера LCD-дисплея JD9365 Waveshare 10.1 дюйма. Ссылка: waveshare/esp_lcd_jd9365_10_1
LCD GC9A01	Espressif	Реализация контроллера LCD-дисплея GC9A01 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_gc9a01
LCD LT8912B	Espressif	Реализация моста LT8912B MIPI-DSI-HDMI с компонентом esp_lcd. Ссылка: espressif/esp_lcd_lt8912b
LCD NT35510	Espressif	Реализация контроллера LCD-дисплея NT35510 с помощью компонента esp_lcd. Интерфейс 8080. Ссылка: espressif/esp_lcd_nt35510
LCD OTA7290B	Waveshare	Реализация моста OTA7290B с компонентом esp_lcd. Ссылка: waveshare/esp_lcd_ota7290b
LCD SD5207	Waveshare	Реализация моста SD5207 с компонентом esp_lcd. Ссылка: waveshare/esp_lcd_sd5207
LCD SH1107	Espressif	Реализация контроллера LCD-дисплея SH1107 с помощью компонента esp_lcd. Интерфейс I2C. Ссылка: espressif/esp_lcd_sh1107
LCD SH8601	Espressif	Реализация контроллера LCD-дисплея SH8601 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_sh8601
LCD SPD2010	Espressif	Реализация контроллера LCD-дисплея SPD2010 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_spd2010
LCD ST7701(S)	Espressif	Реализация контроллера LCD-дисплея ST7701(S) с помощью компонента esp_lcd. Интерфейсы 3-wire SPI + RGB / MIPI-DSI Ссылка: espressif/esp_lcd_st7701
LCD ST7703	Waveshare	Реализация контроллера LCD-дисплея ST7703 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_st7703
LCD ST7735	Waveshare	Реализация контроллера LCD-дисплея ST7735 с помощью компонента esp_lcd. Ссылка: waveshare/esp_lcd_st7735
LCD ST7796	Espressif	Реализация контроллера LCD-дисплея ST7796 с помощью компонента esp_lcd. Ссылка: espressif/esp_lcd_st7796
LCD ST77916	Espressif	Реализация контроллера LCD-дисплея ST77916 с помощью компонента esp_lcd. Интерфейсы SPI/QSPI/MIPI-DSI Ссылка: espressif/esp_lcd_st77916
LCD ST77922	Espressif	Реализация контроллера LCD-дисплея ST77922 с помощью компонента esp_lcd. Интерфейсы SPI/QSPI/MIPI-DSI Ссылка: espressif/esp_lcd_st77922
Touch-панели (components?q=esp_lcd_touch)
ESP LCD Touch	Espressif	ESP LCD Touch — основной компонент для использования контроллеров с сенсорным экраном. Ссылка: espressif/esp_lv_decoder
LCD Touch AXS15260D	Waveshare	Реализация сенсорного контроллера AXS15260D с помощью компонента esp_lcd_touch. Ссылка: waveshare/esp_lcd_touch_axs15260d
LCD Touch CST3530	Waveshare	Реализация сенсорного контроллера CST3530 с помощью компонента esp_lcd_touch. Ссылка: waveshare/esp_lcd_touch_cst3530
LCD Touch CST816S	Espressif	Реализация сенсорного контроллера CST816S с помощью компонента esp_lcd_touch. Ссылка: espressif/esp_lcd_touch_cst816s
LCD Touch CST9217	Waveshare	Реализация сенсорного контроллера CST9217 с помощью компонента esp_lcd_touch. Ссылка: waveshare/esp_lcd_touch_cst9217
LCD Touch FT5x06	Espressif	Реализация сенсорного контроллера FT5x06 с помощью компонента esp_lcd_touch. Ссылка: espressif/esp_lcd_touch_ft5x06
LCD Touch GT911	Espressif	Реализация сенсорного контроллера GT911 с помощью компонента esp_lcd_touch. Ссылка: espressif/esp_lcd_touch_gt911
LCD Touch GT1151	Espressif	Реализация сенсорного контроллера GT1151 с помощью компонента esp_lcd_touch. Ссылка: espressif/esp_lcd_touch_gt1151
LCD Touch HI8561	Waveshare	Реализация сенсорного контроллера HI8561 с помощью компонента esp_lcd_touch. Ссылка: waveshare/esp_lcd_hi8561
LCD Touch ST7123	Espressif	Реализация сенсорного контроллера ST7123 с помощью компонента esp_lcd_touch. Ссылка: espressif/esp_lcd_touch_st7123
LCD Touch STMPE610	Espressif	Реализация сенсорного контроллера STMPE610 с помощью компонента esp_lcd_touch. Ссылка: espressif/esp_lcd_touch_stmpe610
LCD Touch TT21100	Espressif	Реализация сенсорного контроллера TT21100 с помощью компонента esp_lcd_touch. Ссылка: espressif/esp_lcd_touch_tt21100
Платы
ESP32-S3-Touch-AMOLED-1.8	Waveshare	LCD-дисплей на базе SH8601 для платы Waveshare ESP32-S3-Touch-AMOLED-1.8 Ссылка: waveshare/esp_lcd_sh8601
ESP32-S3-Touch-AMOLED-2.06	Waveshare	Пакет поддержки платы (BSP) для Waveshare ESP32-S3-Touch-AMOLED-2.06 Ссылка: waveshare/esp32_s3_touch_amoled_2_06
ESP32-S3-Touch-LCD-4	Waveshare	Пакет поддержки платы (BSP) для Waveshare ESP32-S3-Touch-LCD-4 Ссылка: waveshare/esp32_s3_touch_lcd_4
ESP32-S3-CAM-OVxxxx	Waveshare	Пакет поддержки платы (BSP) для Waveshare ESP32-S3-CAM-OVxxxx Ссылка: waveshare/esp32_s3_cam_ovxxxx
ESP32-S3-LR1121-OLED-0.96	Waveshare	Драйвер дисплея Waveshare ESP32-S3-LR1121-OLED-0.96 Display для шины I2C Ссылка: waveshare/esp_oled_ssd1315
Сенсоры и датчики
ESP32-CAMERA	Espressif	Совместимый с ESP32 драйвер для датчиков изображения OV2640, OV3660, OV5640, OV7670 и OV7725. Ссылка: espressif/esp32-camera
NTC	Espressif	Драйвер для различных NTC-термисторов на основе одного канала АЦП. Ссылка: espressif/ntc_driver
Dallas 1-Wire BUS	Espressif	Драйвер шины Dallas 1-Wire для различных периферийных устройств. Работает на основе аппаратных контроллеров RMT или UART. Ссылка: espressif/onewire_bus
DS18B20	Espressif	Драйвер для 1-Wire датчика температуры Dallas / Maxim DS18B20. Используется шина Dallas 1-Wire BUS на основе RMT. Ссылка: espressif/ds18b20
AHT20	Espressif	Драйвер для I2C датчиков температуры и влажности Asair AHT20, AHT21, AHT30. Ссылка: espressif/aht20
AHT30	Espressif	Драйвер для I2C датчиков температуры и влажности Asair AHT30. Ссылка: espressif/aht30
BME280	Espressif	Драйвер для I2C датчика давления, температуры и влажности Bosch BME280. Ссылка: espressif/bme280
BME690	Espressif	Драйвер для I2C датчиков серии Bosch BME69x с использованием BME69X SensorAPI. Ссылка: espressif/bme690
SHT3x	Espressif	Драйвер для I2C датчиков температуры и влажности Sensirion третьей серии (SHT30, SHT31, SHT35). Ссылка: espressif/sht3x
HTS221	Espressif	Драйвер I2C для датчика влажности и температуры HTS221. Ссылка: espressif/hts221
AT581X	Espressif	Драйвер I2C для радарного датчика AT581X. Ссылка: espressif/at581x
AS5600	Espressif	AS5600 — это 12-битный магнитный датчик угла от компании AMS OSRAM Ссылка: espressif/as5600
MPU6050	Espressif	Драйвер I2C для 6-осевого гироскопа и акселерометра Invensense MPU6050. Ссылка: espressif/mpu6050
QMA6100P	Espressif	Драйвер для 3-осевого акселерометра QST QMA6100P на основе интерфейса I2C. Ссылка: espressif/qma6100p
QMI8658	Waveshare	Драйвер датчика QMI8658, предназначенный для высокоточного обнаружения движения и определения положения. Ссылка: waveshare/qmi8658
BH1750	Espressif	Драйвер для I2C датчиков освещенности BH1750. Ссылка: espressif/bh1750
VEML6040	Espressif	Драйвер цветового сенсор VEML6040. Ссылка: espressif/veml6040
VEML7700	Esp-Idf-Lib	Драйвер для датчика внешней освещенности VEML7700. Ссылка: esp-idf-lib/veml7700

Локальное зеркало реестра компонентов

Реестр компонентов – это, конечно же, очень хорошо и удобно. Но менеджер компонентов каждый раз лезет в интернет, и каждый раз скачивает исходники с GitHub-а. Для автономных систем без доступа к сети интернет это неприемлемо. Для подобных случаев разработчики предусмотрели режим создания частичного локального зеркала.

Основная идея заключается в том, чтобы один раз скачать необходимые компоненты из официального реестра в специальную папку на вашем компьютере или внутреннем сервере, а затем перенастроить инструмент управления компонентами так, чтобы он обращался к этой локальной копии в первую очередь.

Это достигается в два этапа:

Создание зеркала. Для этого используется утилита compote. Она может синхронизировать как отдельные компоненты, так и все зависимости, необходимые для конкретного проекта. Например, команда linux для синхронизации всех компонентов, нужных вашему проекту, выглядит так:
```
compote registry sync --project-dir /path/to/your/project /path/to/your/local/mirror
```
или
```
compote registry sync --project-dir D:/my_project C:/my_components_mirror/storage
```
Можно также синхронизировать только последние версии или компоненты в определенном диапазоне версий, чтобы сэкономить место на диске.
Настройка менеджера компонентов на использование зеркала. Чтобы система знала о вашем локальном зеркале, его нужно указать в конфигурационном файле idf_component_manager.yml. Этот файл обычно находится в папке .espressif в вашей домашней директории. В нем нужно добавить или изменить параметр local_storage_url:
```
profiles:
  default:
    local_storage_url:
      - file:///path/to/your/local/mirror  # Путь к вашему зеркалу
```
Система будет проверять компоненты в локальном зеркале в первую очередь, и только если их там нет, обратится к официальному онлайн-реестру.
Важное правило для Windows: используйте префикс file:// и прямые слэши / (не обратные \)
```
profiles:
  default:
    local_storage_url:
      - file://C:/my_components_mirror/storage/
```

Альтернатива: используйте компоненты из локальных папок

Если вам не нужно создавать полное зеркало реестра, а требуется просто подключить свою собственную библиотеку, которая лежит на диске, это делается еще проще. Вы можете просто разместить предварительно скаченный компонент из реестра в папке components вашего проекта, и сборщик ESP-IDF автоматически его подхватит без обращения к официальному реестру.

Либо, как вариант, в файле манифеста idf_component.yml можно указать путь к локальному компоненту, если он хранится отдельно от проекта.

dependencies:
  espressif/button:
    version: "^4.1.3"
    override_path: "../../" # Менеджер использует компонент из этой папки, а не скачивает из реестра

Команда compote

compote — это инструмент командной строки для диспетчера компонентов IDF. Он работает с реестром компонентов ESP, проектами ESP-IDF и компонентами. Команда compote входит в состав IDF Component Manager, который по умолчанию уже установлен в актуальных версиях ESP-IDF . Чтобы получить к нему доступ, нужно активировать окружение ESP-IDF. В ОС Windows для этого проще всего запустить ярлык “ESP-IDF PowerShell Environment” или “ESP-IDF Command Prompt (cmd.exe)“. После этого в открывшемся терминале команда compote будет доступна. Если по какой-то причине команда не работает, это может означать, что у вас установлена очень старая версия ESP-IDF.

С помощью этой команды можно загружать свои компоненты в реестр:

compote component upload --namespace имя_пространства --name имя_компонента

Управление зависимостями компонента:

compote manifest add-dependency example/cmp

Настройка конфигурации IDF Component Manager:

compote config set --local-storage-url file://C:/путь/к/вашему/зеркалу/

Ссылка на документацию: https://docs.espressif.com/projects/idf-component-manager/en/latest/reference/compote_cli.html

Ссылки

Пожалуйста, оцените статью:

[ 5 из 5, всего 1 оценок ]

-= Каталог статей (список по разделам) =- -= Архив статей (плитки, все подряд) =-

Небольшой анонимный опрос: какие статьи вы предпочитаете?

Подключение библиотек к проекту ESP-IDF