Комментарии 42
Было бы неплохо сделать сравнение с другими RTOS, а то после прочтения все ещё непонятно, чем оно лучше
Методология разработки под Zephyr это не сколько про "писать нормальный структурированный код" сколько про "накладывание бесчисленных overlay(ев) (заплаток/костылей) на существующий default(товый) код".
Overlay на .conf файлы, overlay на файлы дерева устройств.
https://www.youtube.com/watch?v=2bVMHAK-Isw
Вам оно надо?
Для NuttX минимальную систему и простое приложение обновляющее прошивку для STM32F105 можно уместить в следующий объем:
32 162 bytes of readonly code memory
358 bytes of readonly data memory
1 349 bytes of readwrite data memory
Это включает в себя: приложение, урезанное ядро, драйвера SPI, драйвера внешней NOR FLASH, драйвера внутренней FLASH, FAT, VFS, AES и прочее по мелочи
Все руки чешутся. Да, выглядит приятно. Мне понравилось, что для экономии памяти они кастомные секции линковщику делали. И собирают стрктурки на этапе линковки. Вместо runtime регистраторов обработчиков событий/структур. Драйвера так подключаются.
Еще нравится, что POSIX прослойка есть. Как на esp sdk. Тесты писать удобнее так как отдельные модули можно на Linux пускать. А на Linux уже подключить
санитайзеров побольше.
Смотрел их исходники много раз. Еще вроде Nordic semiconductor их поддерживает.
Какой путь проходят исходники с момента написания до загрузки во Flash при сборке из-под Zephyr?
GCC->LD->Binutils->Прошивальщик
Кто (какая утилита) поедает *.yaml файлы? *.yaml это тоже исходник.
https://docs.zephyrproject.org/latest/build/cmake/index.html#build-configuration-phase
Дальше сами справитесь?
Спасибо, но все же не совсем понятно какая конкретно утилита в Zephyr project читает и обрабатывает файлы Kconfig?
Kconfig это же тоже исходник.
Кто (какая утилита) поедает *.yml файлы? *.yml это тоже исходник.
Zephyr project продолжает удивлять своей глубочайшей ущербностью.
Оказывается Zephyr выдумал свой собственный диалект/новояз CMake(а)
Вот справка Zephyr(овского) сленга:
include_directories -> zephyr_library_include_directories
add_compile_definitions ->zephyr_compile_definitions
include_directories->zephyr_include_directories
include_directories->zephyr_library_include_directories
add_library->zephyr_library_sources
Так что если вы уже написали систему сборки под CMake, то вы очень "обрадуетесь", что при переходе на Zephyr project вы будете писать систему сборки для своего репозитория заново.
Кто (какая утилита) поедает *.conf файлы? *.conf это тоже исходник.
Какая утилита поедает файлы с расширением *.zephyr?
*.zephyr файлы это тоже исходники.
Крайне не советую использовать Zephyr project. Это маркетинговая хохма.
Там очень запутанная система сборки и очень много непонятных конфигов. Собирать проекты можно только из-под их SDK.
1) Вынесешь пример из SDK (out-of-tree) в свой компанейский репозиторий, пропишешь переменные окружения и west его откажется собирать.
https://devzone.nordicsemi.com/f/nordic-q-a/80126/unable-to-build-blinky-project-outside-sdk-folder
2) В Zephyr сначала собираются конфиги затем артефакты.
На этапе сборки конфигов через west очень много возможных вариантов ошибок.
Вам придется разбираться с конфигами west(а) больше чем со своим кодом.
Вывод
Собирайте лучше из самописных makefile(ов).
В этом нет ничего сложного. Вся спека make всего 242 станицы.
Zephyr можно разве что использовать как дойную корову. Взять какой-н драйвер для своего проекта и собрать его в своем ToolChain(е).
У них система сборки имеет большое количество наворотов, однако оно того стоит. И инструментов они много взяли популярных готовых.
Некоторые вещи взяли из linux. Например, Kconfig, DeviceTree. Это было вполне разумно с учётом того, что из SDK очень большой.
Cmake тоже уже почти стандарт. Причем генерируют Ninja, который быстрее make работает.
Допом они overlay концепцию красиво реализовали, в моем проекте смог поддержать несколько разных плат.
На счет прошивки - вроде у них раннер там был на питоне написан который дёргает тулы от производителя. Вполне не сложно было разобраться. И мемори мап они автоматом генерят, тут я почитывал подольше.
Думаю подобного большого размера система без автоматизаций на мейкфайлах рассыпалась бы или вникать было бы гораздо сложнее. Однако по опыту написания проектов - дело шло очень быстро. И драйвера подключались/отключались быстро. Но сначала пришлось повникать в DeviceTree.
Мой личный опыт был - очень быстро раскатался не самый простой проект. Потому, что драйвера были готовые. Файловая система итд. В том числе помогла либа для обмена сообщениями между чипами. В сравнении с другими sdk гораздо быстрее. Меньше велосипедов и не надо было "свои очереди сообщений" делать, примитивы синхронизации или портировать из раза в раз тонну инструментов... Тестовый фреймворк тоже вложен. Можно некоторые тесты хоть на борде раскатать хоть на рабочем компе с эмуляцией драйверов.
Минусы Zephyr
--Zephyr не позволяет экспортировать артефакты сборки в папку за пределами SDK.
Буквально прописываешь другой BUILD_DIR и
cmake -S %PROJECT_DIR% -B %BUILD_DIR% -DBOARD=nrf5340_audio_dk_nrf5340_cpuapp -G Ninja
ninja -C %BUILD_DIR%не собирается
--Zephyr также не позволяет собирать проекты в папках за пределами SDK.
Если у вас в компании есть свой репозиторий, то при переходе на Zephyr вы можете с ним благополучно попрощаться
1) артефакты можно в ci/cd указывать в любую папку. И ничего не мешает в своем cmakelists добавить команду переноса куда хочешь на postbuild. Или при вызове cmake указать не только сурс, но и билд фолдер, чтобы именно туда собирать hex-ы.
2) в любой папке за пределами sdk можно свои проекты делать. Только zephyr_base надо определить свой
3) был свой репозиторий и не прощались
Возможно тут поможет внимательное чтение документации и чтение внимательное ошибок в консоли. Ибо у меня собиралось в разные папки, и проект с sdk хранил отдельно. И разнообразие было выбора куда собирать (debug, release отдельно в разные папки). И артефакты вытаскивать не было проблем. Ну и с git никаких проблем.
Hidden text
[1/431] Generating include/generated/version.h
-- Zephyr version: 3.1.99 (C:/ncs/v2.1.0/zephyr), build: v3.1.99-ncs1
[236/431] Building C object zephyr/boards/boards/arm/nrf5340_audio_dk_nrf5340_cpuapp...nrf__boards__arm__nrf5340_audio_dk_nrf5340.dir/nrf5340_audio_dk_cpunet_reset.c.obj FAILED: zephyr/boards/boards/arm/nrf5340_audio_dk_nrf5340_cpuapp/CMakeFiles/..nrf__boards__arm__nrf5340_audio_dk_nrf5340.dir/nrf5340_audio_dk_cpunet_reset.c.obj ccache C:\ncs\toolchains\v2.1.0\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DARM_ALL_FAST_TABLES -DARM_DSP_CONFIG_TABLES -DARM_FAST_ALLOW_TABLES -DARM_FFT_ALLOW_TABLES -DARM_TABLE_RECIP_Q15 -DARM_TABLE_RECIP_Q31 -DARM_TABLE_SIN_F32 -DARM_TABLE_SIN_Q15 -DARM_TABLE_SIN_Q31 -DGATEWAY=2 -DHEADSET=1 -DKERNEL -DNRF5340_XXAA_APPLICATION -DNRF_SKIP_FICR_NS_COPY_TO_RAM -DUSE_PARTITION_MANAGER=0 -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS -D__PROGRAM_START -D__ZEPHYR=1 -IC:/ncs/v2.1.0/zephyr/include/zephyr -IC:/ncs/v2.1.0/zephyr/include -Izephyr/include/generated -IC:/ncs/v2.1.0/zephyr/soc/arm/nordic_nrf/nrf53 -IC:/ncs/v2.1.0/zephyr/lib/libc/newlib/include -IC:/ncs/v2.1.0/zephyr/soc/arm/nordic_nrf/common/. -IC:/ncs/v2.1.0/zephyr/subsys/bluetooth -IC:/ncs/v2.1.0/zephyr/subsys/usb/device -IC:/ncs/v2.1.0/zephyr/subsys/settings/include -IC:/ncs/v2.1.0/nrf/include -IC:/ncs/v2.1.0/modules/hal/cirrus-logic -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/common -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/common/bridge -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/common/platform_bsp -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/cs47l63 -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/cs47l63/bsp -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/cs47l63/config -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/cs47l63/fw_pt -IC:/ncs/v2.1.0/modules/hal/cirrus-logic/cs47l63/generated -IC:/ncs/v2.1.0/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/v2.1.0/modules/hal/cmsis/CMSIS/DSP/Include -IC:/ncs/v2.1.0/modules/hal/nordic/nrfx -IC:/ncs/v2.1.0/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/v2.1.0/modules/hal/nordic/nrfx/mdk -IC:/ncs/v2.1.0/zephyr/modules/hal_nordic/nrfx/. -Imodules/libmetal/libmetal/lib/include -IC:/ncs/v2.1.0/modules/lib/open-amp/open-amp/lib/include -IC:/ncs/v2.1.0/modules/debug/segger/SEGGER -IC:/ncs/v2.1.0/modules/debug/segger/Config -IC:/ncs/v2.1.0/zephyr/modules/segger/. -IC:/ncs/v2.1.0/modules/crypto/tinycrypt/lib/include -IC:/ncs/v2.1.0/nrfxlib/lc3/codec/inc -IC:/ncs/v2.1.0/nrfxlib/lc3/platform/os/inc -IC:/ncs/v2.1.0/nrfxlib/lc3/platform/os/baremetal/inc -IC:/ncs/v2.1.0/nrfxlib/lc3/include -IC:/ncs/v2.1.0/nrfxlib/softdevice_controller/include -isystem C:/ncs/v2.1.0/nrfxlib/crypto/nrf_cc312_platform/include -Og -imacros C:/1_job/0_NPP_IT_ELMA/code_base_workspace/code_base_firmware/source/projects/nrf5340_adk_gateway_app_cmake/artefacts/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mfp16-format=ieee --sysroot=C:/ncs/toolchains/v2.1.0/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/v2.1.0/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-reorder-functions -fno-defer-pop -fstack-usage -fmacro-prefix-map=C:/ncs/v2.1.0/nrf/applications/nrf5340_audio=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/v2.1.0/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs/v2.1.0=WEST_TOPDIR -ffunction-sections -fdata-sections -specs=nano.specs -std=c99 -MD -MT zephyr/boards/boards/arm/nrf5340_audio_dk_nrf5340_cpuapp/CMakeFiles/..__nrf__boards__arm__nrf5340_audio_dk_nrf5340.dir/nrf5340_audio_dk_cpunet_reset.c.obj -MF zephyr\boards\boards\arm\nrf5340_audio_dk_nrf5340_cpuapp\CMakeFiles..__nrf__boards__arm__nrf5340_audio_dk_nrf5340.dir\nrf5340_audio_dk_cpunet_reset.c.obj.d -o zephyr/boards/boards/arm/nrf5340_audio_dk_nrf5340_cpuapp/CMakeFiles/..__nrf__boards__arm__nrf5340_audio_dk_nrf5340.dir/nrf5340_audio_dk_cpunet_reset.c.obj -c C:/ncs/v2.1.0/nrf/boards/arm/nrf5340_audio_dk_nrf5340/nrf5340_audio_dk_cpunet_reset.c
C:/ncs/v2.1.0/nrf/boards/arm/nrf5340_audio_dk_nrf5340/nrf5340_audio_dk_cpunet_reset.c:1: fatal error: cannot open zephyr/boards/boards/arm/nrf5340_audio_dk_nrf5340_cpuapp/CMakeFiles/..__nrf__boards__arm__nrf5340_audio_dk_nrf5340.dir/nrf5340_audio_dk_cpunet_reset.c.su for writing: No such file or directory
1 | /*
|
compilation terminated.
[245/431] Building C object zephyr/subsys/bluetooth/host/CMakeFiles/subsys__bluetooth__host.dir/settings.c.obj
ninja: build stopped: subcommand failed.
Вот типичная ошибка Zephyr при смене директории сохранения артефактов (freestanding application)
Zephyr выдумывает калейдоскоп непонятных своих собственных расширений файлов, которые с одной стороны являются исходниками, а с другой стороны совершено не ясно какая утилита с этими расширениями работает.
Например файлы с расширением *.с.in
Вы не устали? Имеет смысл сходить на курсы "аджайл гуглинг инженер". Тогда можно минут за 30 будет выяснить что за расширения файлов. Например, тогда не будет казаться странным что есть файлы *.cmake и они используются внезапно cmake-утилитой. Или что её можно заставить генерировать из шаблона (внезапно файлы с расширением *.in) настройки или код.
Вы потратили на комментарии на хабре минимум пару дней за которые можно было документацию прочитать всю. Найти nrf connect плагин в vscode который сам всё делает. Или элементарно погуглить.
Ну или если удивляют эти инструменты, возможно имеет смысл начать с чего-то попроще и потихоньку компетенции наращивать вместо невнятной критики в стиле "не понимаю - значит отстой".
Посмотрите на ядро Linux и с удивлением половину инструментов можно найти. nRF SDK для ble mesh когда-то был, там тоже был cmake.
P.S. под nrf нордик выпустили несколько тулов которые снимают с программиста необходимости знаний тулов. Для использования в сыром виде без ncs sdk, для STM или др. чипов они вообще поставляют докер контейнер который можно и в ci использовать или в vscode через remote development (docker) плагин... Только юзера нерутового добавить и за полчаса готово всё.
PS2: не надо хабр комменты использовать как stack overflow. Для технической поддержки можно прямо в zephyr создать issue или написать на форуме Nordic semiconductor.
Как в Zephyr через механизм Kconfig передать существующему Legacy коду макро определение произвольного имени?
Например не CONFIG_XXX а HAS_XXX?
Чтобы в авто cгенерёном файле autoconf.h была строчка
#include HAS_XXX 1
Кстати, я west не пользовал. Он всё равно тот же самый cmake дрыгает. Сразу брал cmake и надо было пару переменный в environment выставить. Вид тулчейна и еще что-то. Так как-то быстро раскаталось. И в cmakelists свой надо было заинклудить уже их sdk. Сам SDK сабмодулем в папку external добавил.
ZEPHYR_BASE не помню, толи в своём cmakelists. Толи в environment.
В Zephyr SDK очень много файлов с расширением *.cmake (2612 штук).
Какая утилита поедает файлы с расширением *.cmake?
Существует ли утилита, которая преобразует финальное дерево устройств *.dts в Graphviz граф на языке *.dot?
Это сильно помогло бы анализировать описание аппаратуры.
Что значит оператор & в синтаксиcе и семантике деревьев устройств *.dts?
Zephyr не перестает "удивлять".
Вот каким образом в Zephyr project определить глобальный макрос препроцессора на стадии отработки Cmake кода?
Написание add_compile_definitions(HAS_XXXX) не приводит к появлению HAS_XXXX в другом *.с файле.
Одновременно заталкивать десятки макросов HAS_XXXX в аргументы cmake -DHAS_XXXX ... совсем не здорово.
Zephyr project неудобен еще и тем, что наделал целую кучу способов передавать конфигурации для сборок
1--переменные окружения
2--аргументы west или аргументы сmake
3--Kconfig (prj.conf) +.conf overlay
4--Деревья устройств +DT overlay
5--menuconfig
6--guiconfig
За всем этим трудно уследить
При классической сборке конфиги передавались
1--*.mk
2--.[ch]
И всё было более чем нормально
Zephyr еще тем плох, что у него очень слабые драйверы периферии.
Тот же Zephyr(овский) I2S даже не позволяет добавить Custom код в обработчик прерываний по I2S.
https://docs.zephyrproject.org/3.0.0/reference/audio/i2s.html
Все это делает Zephyr очередной разновидностью Adruino.
Примеры работают, а шаг право, шаг влево невозможен.
Zephyr продолжает парад бессилия своих драйверов
оказывается функция gpio_pin_get_config возвращает
#define ENOSYS 88 /**< Function not implemented */
на nrf5340
До чего же тупой этот Zephyr.
Zephyr UART не принимает больше чем 7 байт за раз.
Надо выгребать раньше чем успеет переполниться RxFIFO.
Размер RxFIFO массива просто изменить нельзя.
https://devzone.nordicsemi.com/f/nordic-q-a/87453/ncs-uart-can-t-to-receive-data-continuously
Zephyr продолжает пробивать очередное дно.
Оказывается при сборке в Zephyr не работает функция sin() из <math.h> даже если подключить опцию -lm к компоновщику.
В прошивке NoRTOS функция sin работает.
Деревья устройств в Zephyr активно используют много вложенные макрофункции.
А это, вообще говоря, запрещено правилами MISRA.
Поэтому Zephyr сборки нельзя считать надежными.
Существует ли standalone Kconfig для использования в произвольных проектах на Windows?
Zephyr в embedded: опыт использования на STM32F7-Discovery