Русский
Русский
English
Статистика
Реклама

Zephyr

Zephyr в embedded опыт использования на STM32F7-Discovery

15.06.2020 18:18:41 | Автор: admin
image

История о моем опыте использования операционной системы реального времени (ОСРВ) Zephyr для устройства на базе микроконтроллера STM32F7-Discovery.


В статье:


  • Что такое Zephyr и при чем тут Linux?
  • Запуск проекта на STM32. Интересные моменты по работе с драйверами.
  • Фишки этой ОС. Что понравилось, а что нет.

Привет, Хабр, меня зовут Илья. Я студент выпускного курса университета и параллельно прохожу стажировку на позицию embedded-разработчика в компании Третий пин. Мой приход совпал с началом изучения операционной системы реального времени Zephyr. Чтобы не делать исследование на пустом месте, мне и другим стажерам предложили придумать небольшой проект, где можно использовать эту операционную систему. Мы остановились на идее устройства для отладки оборудования, когда отсутствует возможность подключения к компьютеру. Устройство позволяет считывать, хранить и отображать логи тестируемого устройства на дисплее или передавать их на компьютер по Ethernet. Проект получил внутренне название Logovoz. Прототип решили делать на STM32F7-Discovery. О том, что получилось планирую рассказать в следующих статьях. Сегодня про сам Zephyr.


Что еще за Zephyr?


image

Zephyr это сравнительно новая операционная система реального времени с прицелом на embedded и устройства интернета вещей. Она была разработана в 2015 году компанией Wind River Systems, автора другой популярной в авиационной и космической отраслях ОС VxWorks.


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

Операционная система реального времени это такая операционная система, ключевым критерием которой, наравне с корректной работой, является время выполнения операций. Так, если в Windows программа отработает на милисекунду позже, пользователь может даже не обратить внимания, а в ОСРВ эта ситуация является недопустимой. Например, представьте, что будет, если контроллер подушки безопасности автомобиля отработает на пару секунд позже, чем нужно?


Чем хорош Zephyr:


  • Мощная архитектура. Системные вызовы, драйвера, потоки, файловая система, shell и так далее. Всё как во взрослых ОС.
  • Поддержка множества контроллеров от разных вендоров. STM, ESP, Atmel, NXP и т. д. Система позволяет запускать одно приложение на разных платах без переписывания кода.
  • Собственный инструмент командной строки West. Сами создатели называют его перочинным ножом для разработчика. Это одновременно система сборки, менеджер модулей, инструмент прошивки, конфигуратор.
  • Open-source. С 2017 года система поддерживается Linux Foundation и в ней используются наработки из кодовой базы Linux. Например, Kconfig и dts.

Система не лишена минусов. В основном, они связаны с её относительной молодостью. Например, проблемы с документацией в разных версиях системы. Несмотря на это, система имеет активное комьюнити и активно развивается.


Как устроен Zephyr?


Система во многом схожа с Linux. Как и Linux, Zephyr содержит menuconfig или guiconfig (то же самое, но с отдельным GUI, а не в консоли), которые конфигурируют программные части системы на основе файлов Kconfig. Это могут быть различные драйверы, поддержка сетевых функций и т.д. Для описания же аппаратной части используется структура device tree. С помощью неё конфигурируются диапазоны адресов регистров в памяти, периферия, линии прерываний и др.


image

В качестве системы сборки Zephyr иcпользует CMake. Поэтому каждое приложение должно иметь CMakeList.txt в качестве точки входа системы сборки. Сборка проекта осуществляется с помощью West. Команды west упрощают настройку приложения. Например, написав программу, собрать её под STM32F746G-Discovery надо командой:


west build b stm32f746g_disco

Не меняя исходный код, программа под NUCLEO-F207ZG собирается командой:


west build b nucleo_f207zg

Подробнее про доступные команды можно узнать, вызвав подсказку:


west --h

image

Для использования определенной версии Zephyr и подключения сторонних модулей используется файл манифеста west.yml.


Запуск Zephyr


Если у вас есть отладочная плата и она поддерживается Zephyr открываем статью Getting Started Guide на официальном сайте и проделываем 8 нехитрых пунктов для вашей ОС. Для выполнения 7 пункта придётся найти файл Kconfig.defconfig и в нём посмотреть название отладки в параметре BOARD.


image

Расположение для STM32F746G-Discovery:
zephyr/boards/arm/stm32f746g_disco/Kconfig.defconfig


И, voila, вы гордый обладатель отладки с мигающим светодиодом.


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


Что попробовать сделать


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


image

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


Отладка


Для отладки приложения я пользовался связкой VSCode + marus25.cortexdebug. В документации приведена инструкция для использования Eclipse в
качестве IDE.


Работа с драйверами


image

Для хранения логов в проекте планировалось реализовать файловую систему на SD-карте. Смотрю в щедро предлагаемые мне системой возможности, но не обнаруживаю там поддержки SD.
Zephyr на момент версии 2.1 умеет работать с SD-картами SDHC от 2 до 32 Гб ёмкости через SPI. Для работы с ними есть примеры, инструкция, всё замечательно. Хорошо, тогда почему же моя отладка не поддерживает работу с SD в Zephyr? Смотрю reference manual на stm32f7 и в разделе SDMMC нахожу строку.


image

Одно из преимуществ Zephyr это активное комьюнити. Гугл в помощь, и вот найдены братья по несчастью, один из которых даже написал свой драйвер работы с SD. Написанный драйвер отлично, но есть нюанс.


image

На рисунке представлена модель драйверов в Zephyr. Для использования конкретной реализации к ней надо обратиться через обобщенный API. Конечная цель работы с SD картой взаимодействовать с ней, как с файловой системой. Такой интерфейс предоставляется через подсистему disk. Директория с этой подсистемой содержит как обобщенный API, так и API, предоставляющие доступ к файловой системе в ОЗУ, во флеше или на SDкартах через SPI. Соответственно, надо добавить сюда свой интерфейс, который будет обращаться к реализации драйвера работы с SD.


Берём готовые реализации интерфейсов, смотрим, как там всё сделано, и пишем что-то подобное. При написании драйверов и интерфейсов рекомендуется использовать язык Си, а также макросы, которые применяются в подобных файлах Zephyr. В конце создания API не забываем вписать о нём информацию в файлы CMakeList.txt и Kconfig, чтобы драйвер можно было собрать и включить в системе. В итоге, на карточку памяти гордо записан текстовый файл с приветствием миру.


Работа с любыми новыми возможностями Zephyr заключается в том, что ты смотришь документацию на них и примеры. Потом пытаешься запустить сэмпл или повторить его. То же самое я пытался проделать и с файловой системой, но столкнулся с отсутствием файлов при сборке проекта. В результате поиска проблемы оказалось, что часть файлов есть в каталоге Zephyr с подсистемами, а часть файлов берётся из стороннего репозитория и подключается в качестве модуля в файле манифеста. Это касается случаев, когда вы сами записываете требуемые модули, а не пользуйтесь готовым файлом со всеми доступными сторонними репозиториями.


Версионирование


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


Бывают и другие досадные моменты. В мажорном обновлении с Zephyr 1.14 до 2.0 сменилась такая незначительная деталь, как спецификация device tree.


image

В итоге поменялся формат статуса в файлах .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, поделитесь им в комментариях.

Подробнее..

ZERG что за зверь?

19.02.2021 14:12:20 | Автор: admin


Когда мы говорим о 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 помимо сопоставления тестов ещё умеет в начальный импакт анализ, но об этом, возможно, в следующий раз.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru