Zephyr что это за программа
ZERG — что за зверь?
Когда мы говорим о CI&CD, мы часто углубляемся в базовые инструменты автоматизации сборки, тестирования и доставки приложения — фокусируемся на инструментах, но забываем осветить процессы, которые протекают во время отрезания и стабилизации релизов. Однако, не все готовые инструменты одинаково полезны, а какие-то кастомные процессы не укладываются в их покрытие. Приходится исследовать процессы и находить пути автоматизации для их оптимизации.
В нашей компании QA-инженеры используют Zephyr для отслеживания хода регресса, так как ручное и исследовательское тестирование нам не заменить автотестами. Но несмотря на это, автотесты у нас гоняются часто и в больших количествах, поэтому хочется иметь возможность опустить какие-то банальные проверки, которые были автоматизированы и дать тестировщикам заниматься более производительной и полезной работой.
У нас есть ночные прогоны, когда гоняются полные наборы тестов. Но на самой заре освоения Zephyr, нашим тестировщикам во время регресса приходилось скачивать xcresult, или ещё ранее plist, или junit xml, а затем проставлять соответствия зелёных и красных тестов в зефире руками. Это довольно рутинная операция, да и занимает она много времени, чтобы руками пройти 500-600 тестов. Такие вещи хочется отдать на откуп бездушной машине. Так родился ZERG.
Рождение зерга
Zephyr Enterprise Report Generator — небольшая утилита, которая изначально умела только искать соответствия в отчёте тестов и отправлять в Zephyr их актуальные статусы. Позже утилита получила новые функции, но сегодня мы остановимся на поиске и отправке отчётов.
В Zephyr нам предлагается оперировать версиями, циклами и проходами (execution) тест кейсов. Каждая версия содержит произвольное количество циклов, а каждый цикл содержит в себе проходы кейсов. Такие проходы содержат в себе информацию о задаче (zephyr прекрасно интегрируется с jira и тест кейс — это, по сути, задачка в jira), авторе, о статусе кейса, а также о том, кто занимается этим кейсом и о других необходимых деталях.
Для автоматизации проблемы, которую мы обозначили выше, нам важно разобраться в проставлении статуса кейса.
Работа с кодом
Но как соотнести тест в коде и тест в зефире? Здесь мы выбрали довольно простой и прямолинейный подход: для каждого теста мы добавляем в секцию комментариев ссылки на задачи в jira.
В комментариях также могут размещаться дополнительные параметры, но об этом позже.
Так, один тест в коде может покрывать несколько задач. Но работает и обратная логика. Для одной задачи может быть написано несколько тестов в коде. Их статусы будут учитываться при составлении отчёта.
Нам надо пройти по исходникам, извлечь все тест-классы и тесты, слинковать задачи с методами и соотнести это с отчётом о прохождении тестов ( xcresult или junit ).
Работать с самим кодом можно разными путями:
— просто читать файлы и через регулярные выражения извлекать информацию
— использовать SourceKit
Как бы то ни было, даже при использовании SourceKit мы не обойдёмся без регулярных выражений для извлечения идентификаторов задач из ссылок в комментариях.
На данном этапе нас не интересуют детали, поэтому отгородимся от них протоколом:
Нам надо получить тесты. Для этого опишем структуры:
Затем нам надо прочитать отчёт о прохождении тестов. ZERG был рождён ещё до переезда на xcresult, и поэтому умеет парсить plist и junit. Детали в этой статье нас всё ещё не интересуют, они будут приложены в коде. Поэтому отгородимся протоколами:
Остается только слинковать тесты в коде с результатами тестов из отчетов.
Проверяем соответствие по имени класса и имени теста (в разных классах могут быть методы с одинаковыми именами) и нужен ли рефакторинг для теста. Если он нужен, то считаем, что он ненадёжный и выкидываем из статистики.
Работаем с зефиром
Теперь, когда мы прочитали отчёты о тестировании, нам надо их перевести в контекст zephyr. Для этого надо получить список версий проекта, соотнести с версией приложения (чтобы это так работало, необходимо, чтобы версия в зефире совпадала с версией в Info.plist вашего приложения, например, 2.56), выкачать циклы и проходы. А дальше соотнести проходы с нашими уже имеющимися отчётами.
Для этого нам надо реализовать в ZephyrAPI следующие методы:
Cпецификацию можно увидеть здесь: getzephyr.docs.apiary.io, а реализацию клиента в нашем репозитории.
Общий алгоритм довольно простой:
На этапе сопоставления проходов с отчётами есть тонкий момент, который необходимо учитывать: в zephyr api обновление execution отправлять удобнее всего пачками, где передаётся общий статус и список идентификаторов проходов. Нам нужно развернуть наши отчёты относительно тикетов и учесть n-m соотношение. Для одного кейса в зефире может быть несколько тестов в коде. Один тест в коде может покрывать несколько кейсов. Если для одного кейса есть n тестов в коде и один из них красный, то для такого кейса общий статус — красный, однако если один из таких тестов покрывает m кейсов и он зелёный, то остальные кейсы не должны стать красными.
Поэтому мы оперируем сетами и ищем пересечение красных и зелёных. Всё, что попадает в пересечение, мы отнимаем из зелёных результатов и отправляем отредактированные сведения в zephyr.
Здесь ещё нужно отметить, что внутри команды мы договорились, что zerg не будет менять статус прохода, если:
1. Текущий статус blocked или failed (раньше для failed мы меняли статус, но сейчас отказались от практики, потому что хотим, чтобы тестировщики обращали внимание на красные автотесты во время регресса).
2. Если текущий статус pass и его поставил человек, а не zerg.
3. Если тест помечен как флакающий.
Интересности Zephyr API
При запросе циклов нам приходит json, который с первого взгляда невозможно систематизировать для десериализации. Всё дело в том, что запрос на получение циклов для версии, хотя по смыслу и должен возвращать массив циклов, на самом деле возвращает один объект, где каждое поле уникально и называется идентификатором цикла, который лежит в значении. Чтобы такое обработать, мы применяем несложные хаки:
Статусы прохождения тестов приходят в одном из запросов рядом с объектом запроса. Но их можно вынести заранее в enum:
При запросе циклов нужно передавать в параметры запроса версию и целочисленный идентификатор проекта. Но в запросе проходов для цикла надо этот же идентификатор проекта передавать в формате строки.
Вместо заключения
Если есть много рутинной работы, то, скорее всего, что-то можно автоматизировать. Синхронизация прохождения автотестов с системой ведения тестов — один из таких кейсов.
Таким образом, каждую ночь у нас проходит полный прогон тестов, а во время регресса отчёт отправляется QA-инженерам. Это снижает время регресса и даёт время на исследовательское тестирование.
Если правильно реализовать парсер андроид-исходников, то его можно с тем же успехом применять и для второй платформы.
Наш Zerg помимо сопоставления тестов ещё умеет в начальный импакт анализ, но об этом, возможно, в следующий раз.
Прочесть большую статью — сложно… Тестировать сложный продукт – легко
В современной IT индустрии многие до сих пор удивляются: «зачем вообще нужен отдельный тестовый отдел?».
Лирическое вступление
Что такое петербургская осень? Дожди, Розенбаум, меланхолия… Разве всё?! Нет, ещё это новый учебный год, который во многих регионах нашей страны начался именно с Дневник.ру. За лето мы успели достичь определенных успехов: число пользователей проекта перевалило отметку в 7 000 000, мы стали единственной российской компанией, вошедшей в список «World Economic Forum Technology Pioneers 2014», а Республика Северная Осетия-Алания полностью перешла на электронные журналы с Дневник.ру. На этом лирическое вступление окончим и перейдем к сути данного поста.
Вступление по теме
В современной IT индустрии многие до сих пор удивляются: «зачем вообще нужен отдельный тестовый отдел?». Как один из участников тестовой команды нашего проекта, ответственно заявляю: это ошибочное мнение. Организовать отдел QA – дело нелегкое, но оно того стоит.
В этом случае для себя надо четко понимать:
— что считать критерием качества?
— какие метрики использовать?
— с помощью какого инструментария проводить тестирование?
— как строить взаимодействие с разработчиками/аналитиками и т.д.
По большому счету изобретать велосипед не стоит – данные практики описаны на миллионах интернет-страниц, успешно применяются во многих корпорациях, чей опыт можно перенять. Однако не нужно забывать простую истину – везде есть своя специфика. Например, в Дневник.ру это сильно-связанные между собой компоненты и CI (Continuous Integration), а попросту – высокий уровень интеграции связанных областей. Как лучше тестировать в этом случае?
Начнем с простого: любая информация никогда не сможет на 100% автоматически «всплывать» в вашей (бесспорно, очень умной) голове. QA-шникам в первую очередь необходимо запоминать и в дальнейшем прогонять тестовые сценарии, которые проверяются от релиза к релизу – «а не сломалось ли что?». Как мы все знаем – регрессионное тестирование. Но сейчас не об этом, про виды – welcome to protesting.ru (хороший, кстати говоря, ресурс).
Так вот, для написания и хранения тест-кейсов («Тест-кейс — артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части») можно использовать массу инструментов: Excel, блокнот, google-docs, листы бумаги, в конце концов. Но разве это эффективно и удобно? Для одного человека – может быть. Для команды, где статус проекта «надо было знать уже вчера» – определенно нет. 
Подготовительные работы
Суммируя всё вышесказанное, требования к тулу были такими:
Итак, что рассматривали:
PS: предупреждая вопросы – HP Quality Center мы не рассматривали, потому что 1) неоправданно дорого 2) не очень он и «приветливый», особенно к тем, кто никогда не работал с тест-тулами, а писать свой – ресурсные затраты и нехватка времени…
Постараюсь уложиться в пару-тройку основных тезисов:
Microsoft Test Lab
Zephyr
Test Link
Testia Tarantula
Test Rail
На мой взгляд – один из самых легких, но в то же время очень масштабных существующих тулов. Главный плюс – кастомизация возможна практически во всём. Начиная от дизайна, заканчивая логикой. Прямая интеграция с JIRA. Эффективное занесение тест-кейсов и разбиение их по нужным сьютам. Как один из минусов – до недавнего времени у Test Rail была слабо реализована система отчетности: скудные результаты по тест-ранам, отсутствие кастомизации репортов и т.д. Однако Gurock & Co взялись за это дело и к 3-ей версии инструмента ребята сделали работу над ошибками. Отчетность заиграла новыми красками: хочешь – отчет по майлстоуну, хочешь – только по дефектам, хочешь – настроим регулярный е-мейл с посылкой отчета по тестированию строго определенного функционала и т.д. Молодцы! Итог – данный тул удовлетворял всем (!) моим требованиям, перечисленным немного выше.
Итого: наш выбор – внедрение Test Rail. Собственно говоря, что такое Test Rail?
• Это эффективное управление тест-кейсами, планами и тестовыми циклами (создание/хранение/редактирование тестовых сценариев, управление тестовыми планами, запуск тестовых циклов, занесение результатов тестирования)
• Это значительное повышение качества тестирования (четкое описание тестовых сценариев, их ревью, соотношение с требованиями, разделение на области — всё это позволяет оценить как полноту покрытия тестами функционала, так и является необходимым материалом для всей проектной команды)
• Это получение тестовых результатов в реальном времени (создание отчетов по совершенно разным критериям: Defect Summary, Comparison for Cases, тестовые результаты по проектам/компонентам/майлстоунам и т.д.)
• Это легкая организация и удобное отслеживание загрузки отдела тестирования (возможности для полной кастомизации «рабочего dashboard», а также удобное получение статуса работы QA отдела)
Внедрение
1. Поставили ТестРейл на виртуалку Windows Server 2008 R2 с базой MSSQL
2. Настроили AD аутентификацию
3. Настроили полноценную связь с JIRA
[connection]
address=http://jira/***
user=%jira_user%
password=%jira_password%
Ура. Теперь у каждого пользователя есть возможность в My Settings выставить логин/пароль от JIRA.
Далее в JIRA_Rest прописываем как связь непосредственно с установленной JIRA, так и впоследствии связи всех существующих у Вас JIRA fields: будь то основные поля, или кастомные (welcome to: docs.gurock.com/testrail-integration/tools-jira-rest).
Связи с основными полями (пример):
[push.fields]
summary=on
project=on
issuetype=on
component=on
assignee=on
priority=on
affects_version=on
fix_version=off
estimate=off
labels=off
environment=off
description=on
Связи с кастомными полями (пример):
[push.fields]
customfield_XXXXX=on
[push.field.customfield_XXXXX]
label=Customer
size=compact
type=dropdown
required=true
Как итог – при заведении бага можно смело воспользоваться инструментарием Test Rail, и при этом не тратить время на переход в соседнее окно с JIRA. Плюс ли? Вы знаете, при прогоне больших тестовых циклов и выставлении результатов тестирования – это несомненный плюс, так как те самые десятки секунд финально складываются в драгоценные минуты и просто-напросто удобство работы, что немаловажно.
И ещё: При генерации тестового репорта обычно мы выводим после результатов список известных дефектов, которые блокируют прохождение тест-кейса. Так вот, представьте себе такой список, и при наведении курсора на дефект в этом отчете всплывает попап с JIRA информацией о тикете – Summary, Description и т.д. Просто гениально! Всё сделано за вас.
4. После основных тех. настроек можно смело создавать проекты, привязанные к майлстоунам и тестовые сьюты, содержащие всевозможные секции с тест-кейсами, а также настраивать dashboard исключительно по вашим желаниям и критериям
Все мы знаем, что при создании тест-кейсов на какой-либо функционал для начала желательно составить тест-план, где четко будут описаны классы эквивалентности, секции и разбиение как минимум на позитивные-негативные сценарии. TestRail позволяет максимально эффективно составить такой план и впоследствии расширить его до полноценных сценариев.
Немного поподробнее: создаем тестовый сьют. Затем внутри него имеем возможность добавлять как секции, так и тест-кейсы внутри этих секций. Мы имеем возможность, не переходя к внутренней сущности кейса, составить шаблоны (= чек-лист/тест-план), вводя только Summary и нажимая Enter после ввода. Выглядит это так:
Это поле можно исправить на No, только написав сам тест-кейс в форме редактирования (необходимо просто поставить галочку «Only Title» = No).
Любые кастомные поля, которые Вы вводите, можно также вынести на дашборд как и все остальные, выбрав их в отображаемых колонках (нажатие «таблички» на основной странице написания тест-кейсов в строке с перечислением названий полей: ID, Title an so on).
5. Все внутренние поля тест-кейса также кастомизируемы
В изначальной конфигурации Test Rail представлен классический и безусловно необходимый набор внутренних полей тестового сценария: ID, Приоритет, Начальные Условия, Вид, Шаги, Ожидаемый Результат, Ссылка на требования или задачу Implementation в JIRA и т.д. Вы имеете право добавить любое поле и настроить его как вы хотите: будь то string, checkbox, dropdown – не важно. Всё в Ваших руках и головах! Что сделали мы:
— Добавили поле Data for test-case, в котором для теста из одного класса эквивалентности просто-напросто перечисляем какие-либо данные, с которыми тест должен быть выполнен. Это может быть все что угодно: начиная от ролей выполняющего, заканчивая перечислением строк ввода.
— Добавили поля ID Auto и Auto. ID Auto – уникальный ID для авто-теста. Auto – чекбокс Yes/No, который показывает автоматизирован ли тест-кейс или нет.
Сделано это для того, чтобы в дальнейшем при настраивании Test Rail для автоматизации можно было сразу использовать эти параметры для запуска необходимых авто-тестов и генерации по ним нужного отчета (http://www.gurock.com/testrail/tour/5/ — Automated tests and API).
6. Для любого test run можно выбрать абсолютно любой набор тест-кейсов
Test Rail позволяет создавать тестовые циклы по любым критериям. Это очень важная особенность инструмента, так как зачастую необходимо прогнать строго определенные сценарии (выбранные по приоритетам, по майлстоунам, по названию, по части названия, да как угодно на самом деле – все зависит от поставленных целей). Так вот, при назначении Test Run мы имеем возможность выбрать «свой» сьют по фильтру. Общий вид таков:
А вот, допустим, выбираем по названию, которое «равно или содержит что-то»:
При всем этом тестовый сьют может быть выбран для прогона полностью.
7. Настраиваемая репортинговая система
Любой тестовый прогон может быть представлен в виде четкого отчета: «что-где-когда-почему». Возможно выбрать любые критерии, точно так же, как и при создании тестового цикла. Кроме прочего, рассылку всевозможных отчетов имеет смысл настроить на необходимое время и заинтересованных адресатов.
Заключение
Чек-листы, ad-hoc тестинг – это хорошо, однако, без четких процедур зачастую у продукта выявляются слабые места, которые со временем усиливаются и тянут компанию вниз. Имея как набор тест-кейсов, так и матрицу покрытия (хотя бы покомпонентно) – этого можно избежать.
Я перечислил далеко не все возможности TestRail и привел в пример лишь несколько вариантов его использования. Тем не менее, очевидно, что такая гибкая кастомизируемость позволит многим настроить данный инструмент под свой процесс разработки. Кроме прочего, тул позволяет совершенно прозрачно наблюдать за QA отделом, что, во-первых, избавляет всех от недосказанности «а что же они тестируют», а, во-вторых, налаживает четкое взаимодействие между командами и даёт понимание «зачем и как тестировать».
Выбирайте свой тул, тестируйте, контролируйте процесс! Удачи во всех начинаниях! 
Автор статьи: Василий Петухов, руководитель отдела анализа и управления качеством Дневник.ру
Zephyr в embedded: опыт использования на STM32F7-Discovery
История о моем опыте использования операционной системы реального времени (ОСРВ) Zephyr для устройства на базе микроконтроллера STM32F7-Discovery.
Привет, Хабр, меня зовут Илья. Я студент выпускного курса университета и параллельно прохожу стажировку на позицию embedded-разработчика в компании Третий пин. Мой приход совпал с началом изучения операционной системы реального времени Zephyr. Чтобы не делать исследование на пустом месте, мне и другим стажерам предложили придумать небольшой проект, где можно использовать эту операционную систему. Мы остановились на идее устройства для отладки оборудования, когда отсутствует возможность подключения к компьютеру. Устройство позволяет считывать, хранить и отображать логи тестируемого устройства на дисплее или передавать их на компьютер по Ethernet. Проект получил внутренне название Logovoz. Прототип решили делать на STM32F7-Discovery. О том, что получилось планирую рассказать в следующих статьях. Сегодня – про сам Zephyr.
Что еще за Zephyr?
Zephyr — это сравнительно новая операционная система реального времени с прицелом на embedded и устройства интернета вещей. Она была разработана в 2015 году компанией Wind River Systems, автора другой популярной в авиационной и космической отраслях ОС — VxWorks.
Операционная система реального времени – это такая операционная система, ключевым критерием которой, наравне с корректной работой, является время выполнения операций. Так, если в Windows программа отработает на милисекунду позже, пользователь может даже не обратить внимания, а в ОСРВ эта ситуация является недопустимой. Например, представьте, что будет, если контроллер подушки безопасности автомобиля отработает на пару секунд позже, чем нужно?
Система не лишена минусов. В основном, они связаны с её относительной молодостью. Например, проблемы с документацией в разных версиях системы. Несмотря на это, система имеет активное комьюнити и активно развивается.
Как устроен Zephyr?
Система во многом схожа с Linux. Как и Linux, Zephyr содержит menuconfig или guiconfig (то же самое, но с отдельным GUI, а не в консоли), которые конфигурируют программные части системы на основе файлов Kconfig. Это могут быть различные драйверы, поддержка сетевых функций и т.д. Для описания же аппаратной части используется структура device tree. С помощью неё конфигурируются диапазоны адресов регистров в памяти, периферия, линии прерываний и др.
В качестве системы сборки Zephyr иcпользует CMake. Поэтому каждое приложение должно иметь CMakeList.txt в качестве точки входа системы сборки. Сборка проекта осуществляется с помощью West. Команды west упрощают настройку приложения. Например, написав программу, собрать её под STM32F746G-Discovery надо командой:
Не меняя исходный код, программа под NUCLEO-F207ZG собирается командой:
Подробнее про доступные команды можно узнать, вызвав подсказку:
Для использования определенной версии Zephyr и подключения сторонних модулей используется файл манифеста west.yml.
Запуск Zephyr
Если у вас есть отладочная плата и она поддерживается Zephyr — открываем статью Getting Started Guide на официальном сайте и проделываем 8 нехитрых пунктов для вашей ОС. Для выполнения 7 пункта придётся найти файл Kconfig.defconfig и в нём посмотреть название отладки в параметре BOARD.
И, voila, вы гордый обладатель отладки с мигающим светодиодом.
Если вашей платы нет в списке, то вам открывается дополнительный уровень сложности в игре «запусти зефир», где нужно описывать собственную борду, либо пользоваться возможностью эмуляции плат в QEMU.
Что попробовать сделать
Zephyr содержит большую базу примеров с описаниями, где можно посмотреть реализованные в системе возможности вашей отладки.
Если ваша плата поддерживает периферию из примера — запускайте его. После чего, основываясь на нём, можно собрать свой проект, который будет делать очень важные и полезные вещи или просто радовать глаз, мигая светодиодами.
Отладка
Для отладки приложения я пользовался связкой VSCode + marus25.cortexdebug. В документации приведена инструкция для использования Eclipse в
качестве IDE.
Работа с драйверами
Для хранения логов в проекте планировалось реализовать файловую систему на SD-карте. Смотрю в щедро предлагаемые мне системой возможности, но не обнаруживаю там поддержки SD.
Zephyr на момент версии 2.1 умеет работать с SD-картами SDHC от 2 до 32 Гб ёмкости через SPI. Для работы с ними есть примеры, инструкция, всё замечательно. Хорошо, тогда почему же моя отладка не поддерживает работу с SD в Zephyr? Смотрю reference manual на stm32f7 и в разделе SDMMC нахожу строку.
Одно из преимуществ Zephyr – это активное комьюнити. Гугл в помощь, и вот найдены братья по несчастью, один из которых даже написал свой драйвер работы с SD. Написанный драйвер — отлично, но есть нюанс.
На рисунке представлена модель драйверов в Zephyr. Для использования конкретной реализации к ней надо обратиться через обобщенный API. Конечная цель работы с SD картой – взаимодействовать с ней, как с файловой системой. Такой интерфейс предоставляется через подсистему disk. Директория с этой подсистемой содержит как обобщенный API, так и API, предоставляющие доступ к файловой системе в ОЗУ, во флеше или на SD картах через SPI. Соответственно, надо добавить сюда свой интерфейс, который будет обращаться к реализации драйвера работы с SD.
Берём готовые реализации интерфейсов, смотрим, как там всё сделано, и пишем что-то подобное. При написании драйверов и интерфейсов рекомендуется использовать язык Си, а также макросы, которые применяются в подобных файлах Zephyr. В конце создания API не забываем вписать о нём информацию в файлы CMakeList.txt и Kconfig, чтобы драйвер можно было собрать и включить в системе. В итоге, на карточку памяти гордо записан текстовый файл с приветствием миру.
Работа с любыми новыми возможностями Zephyr заключается в том, что ты смотришь документацию на них и примеры. Потом пытаешься запустить сэмпл или повторить его. То же самое я пытался проделать и с файловой системой, но столкнулся с отсутствием файлов при сборке проекта. В результате поиска проблемы оказалось, что часть файлов есть в каталоге Zephyr с подсистемами, а часть файлов берётся из стороннего репозитория и подключается в качестве модуля в файле манифеста. Это касается случаев, когда вы сами записываете требуемые модули, а не пользуйтесь готовым файлом со всеми доступными сторонними репозиториями.
Версионирование
В поисках определенной функциональности можно наткнуться на ссылки более старых версий Zephyr, а при переходе в документации на свежий релиз, оказывается, что этого описания уже нет или оно полностью поменяло расположение. При работе возникало ощущение, что авторы сами не до конца понимают, где должен быть тот или иной раздел документации, поэтому он сменяет местоположение от версии к версии.
Бывают и другие досадные моменты. В мажорном обновлении с Zephyr 1.14 до 2.0 сменилась такая незначительная деталь, как спецификация device tree.
В итоге поменялся формат статуса в файлах .dts c «ok» на «okay». Вроде бы мелочь, но при создании собственной платы и переходе на другую версию, проект не будет собираться. Поэтому если вы работаете на определенном релизе Zephyr, внимательно следите и за версией документации.
Работа с RTC
В попытках запустить RTC (Real Time Clock) на плате, я находил, что драйвер часов реального времени был, но потом его не стало. Неприятная ситуация. Позже оказалось, что его функциональность осталась, но была переименована и получила интерфейс Counter.
Воспользовавшись примерами, запустить RTC оказалось несложно. И он даже работал. До первого reset-а. А вот потом обнулился, хотя суть часов реального времени и заключается в том, чтобы не сбрасываться во время reset-а. Это могло произойти из-за того, что в отладку нельзя подключить батарейку и проверить работу часов с ней, а в Zephyr всё на самом деле прекрасно работает. Помогла возможность подсмотреть реализацию RTC в HAL. Те драйверы, которые удалось пощупать, были написаны с применением LL. Не найдя чего-то в нужном драйвере, можно узнать реализацию в HAL и дописать это. Выяснилось, что при инициализации часов в системе, сбрасываются регистры RCC. Не делая этого при reset-е можно оставить нетронутыми значения RTC и он будет работать, как и должен.
Вторым найденным недостатком в реализации RTC оказалось отсутствие функций выставления времени и даты. Их можно считать, но каждый раз отсчитывать время от 2000 года оказалось как-то неудобно. Поэтому снова смотрим в HAL, вдохновляемся и добавляем реализацию сеттеров вместе с требуемым интерфейсом.
Выводы
Стоит ли пробовать Zephyr? Кратко – да. Zephyr действительно поддерживает много фишек «из коробки». Достаточно сделать пару кликов в guiconfig и вот в проекте появляется поддержка UART, SPI, Ethernet. Посмотрел пример, повторил, изменил, оно ещё и работать будет. Возможность не переписывать исходный код при переезде на другую плату тоже подкупает.
Однако, я работал с отладкой, изначально поддерживаемой в системе, и рассказать про процесс самостоятельного описания платы, с какими сложностями можно столкнуться в этом случае, не могу. Что касается встреченных мною трудностей, большинство из них вытекают из того факта, что система новая и поддержка некоторых функций ещё просто не сделана.
Если у вас был опыт работы с Zephyr, поделитесь им в комментариях.