Zephyr Project защищает использование поставщиков HAL в проектах с открытым исходным кодом

На конференции Embedded Linux Conference Europe разработчик NXP и участник проекта Zephyr Морин Хельм предложили перевесить преимущества HAL-решений вендоров.

Использование предоставляемых вендором HAL (Уровни аппаратной абстракции) в проектах с открытым исходным кодом является предметом постоянных дискуссий.
На октябрьской конференции ELC Europe в Праге Морин Хелм, архитектор программного обеспечения MCU в NXP, обсудила плюсы и минусы этой практики.
В конечном счете, она утверждала, что выгоды намного перевешивают компромиссы.
Эта точка зрения была расширена в недавнем сообщении в блоге Zephyr Project Хелмом и Фрэнком Олхорстом.


Maureen Helm от NXP исследует основные HAL, используемые в Zephyr

(щелкните изображение, чтобы увеличить)

Основная причина использования предоставляемых поставщиком HAL заключается в сокращении времени на кодирование и тестирование, сказал Хельм участникам ELCE в разделе «Использование HAL SoC Vendor в проекте Zephyr». Проект Zephyr поддерживает и разрабатывает облегченную ОС Zephyr для блоков микроконтроллеров (MCU). , количество и разнообразие которых выросли в последние годы.

«Многие из этих SoC имеют тысячи различных полей регистрации и регистрации», - сказал Хельм, член Технического руководящего комитета проекта Zephyr.
«Поставщики HAL предоставляют нам основные и периферийные определения реестра, поэтому нам не нужно создавать их самостоятельно.
Это очень скучный код, который трудно проверить, поэтому, если мы сможем использовать его повторно, мы определенно заинтересованы ».

Хелм отметил, что есть основания полагаться на код, разработанный и обновленный поставщиками SoC.
Если разработчики Zephyr обнаружат новую ошибку, «гораздо сложнее обновить исходный код», - сказал Хельм.
Тем не менее, большинство поставщиков SoC обычно довольно хорошо умеют находить и исправлять ошибки и отправлять обновления, добавила она.
«Это экономит бесчисленные часы, которые потребуются для поддержания их в проекте Zephyr».

Лицензионные несоответствия являются еще одной проблемой.
«Иногда мы видим лицензии, которые не обязательно совместимы, и в этом случае мы должны попросить совет управляющих определить, является ли лицензия приемлемой», - сказал Хелм.
«Однако обычно это просто новая лицензия с открытым исходным кодом, которая оказывается совместимой с разрешительной лицензией Apache 2.0 Zephyr.
Обычно это BSD с 3 пунктами ».

Другая сложность заключается в том, что HAL используются другими продуктами и проектами в разных контекстах, и эти сценарии использования возвращаются в код.
Например, «вы можете найти API, которые не совместимы с Zephyr, поэтому сложно использовать драйвер», - говорит Хельм.
«Иногда функция, доступная на уровне API в Zephyr, не реализована в драйвере HAL более низкого уровня».

С другой стороны, вклад нескольких проектов также помогает HAL развиваться быстрее.
«Вы можете получить дополнительную зрелость за счет внешнего использования», сказал Хельм.
«HAL были протестированы в других контекстах, поэтому драйверы, как правило, проходили больше тестов QA».

Отвечая на вопрос о том, что использование HAL поставщиков может противоречить процессу с открытым исходным кодом, передавая его коммерческим поставщикам, она отметила, что «у нас много сотрудничества с разными компаниями и поставщиками». Действительно, HAL от Zephyr вендоров происходят из Arm, Atmel, Intel, Nordic, NXP, SiLabs, STMicroelectronics и Texas Instruments (см. Основное изображение выше).

Большинство крупных поставщиков MCU поддерживают Zephyr вместе с двумя другими беспроводными ОСРВ с открытым исходным кодом: FreeRTOS и Arm's Mbed.
Можно утверждать, что Zephyr более независим от поставщиков, чем Mbed и FreeRTOS.

Три вкуса поставщиков HAL

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

Транзакционные HAL обеспечивают высочайший уровень абстракции и, следовательно, наибольшее повторное использование кода.
К ним относятся CMSIS от Arm (стандарт системного интерфейса микроконтроллеров Cortex), MCUXpresso от NXP (ранее Kinetis SDK) и QMSI от Intel (программный интерфейс Quark для микроконтроллеров).
«Транзакционные HAL идеальны, потому что гораздо меньше настраиваемого кода для написания», - сказал Хельм.
«Мы можем использовать то, что уже было проверено.
Это самый тонкий тип драйвера с точки зрения специфичного для Zephyr кода для включения периферийных устройств или API ».

HAL многих поставщиков также предоставляют низкоуровневые периферийные драйверы без сохранения состояния, которые ограничивают повторное использование кода, но обеспечивают больший контроль.
«Они основаны на том, как вы устанавливаете скорость передачи данных при общении с UART», - пояснил Хельм.
«Нет состояния, поэтому для управления этим требуется драйвер или приложение более высокого уровня». Некоторые низкоуровневые драйверы без сохранения состояния - это транзакционные драйверы с «голым железом», которые управляют некоторыми периферийными состояниями, но им не хватает ОСРВ или понимания потоков.
«Мы используем их для создания чуть большего размера шайбы Zephyr, которая является обычной для деталей STM32».

Наконец, есть драйверы, которые ограничены определениями регистров.
«Они предлагают самый низкий уровень абстракции с наименьшим повторным использованием», - сказал Хельм.
«В этом случае драйвер Zephyr является практически родным драйвером.
Это видно у водителей Atmel и Nordic ».

Затем Хелм глубже погрузился в CMSIS и MCUXpresso и рассказал о том, как Zephyr Project хранит поддерживаемый извне код в папке ext /, чтобы отличить его от нативного кода Zephyr.
«Мы стараемся не изменять ничего, что мы добавляем в ext / - или изменять это как можно меньше», - добавила она.

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

Хелм намекает на то, что сопротивление поставщикам HAL может быть обусловлено скорее происхождением HAL, чем сегодняшней реальностью.
«Идеология, лежащая в основе разработки и внедрения HAL-систем, возникла в области закрытых и закрытых проектов, где контроль над поставщиками господствует, а идеологии с открытым исходным кодом могут игнорироваться или игнорироваться», - пишут Хелм и Охлхорст в своем блоге.

Тем не менее, многие поставщики SoC привыкли работать с проектами с открытым исходным кодом и стали более отзывчивыми в обновлении и обновлении.
Хелм и Олхорст утверждают, что эти позитивные тенденции в сочетании с гибким трехслойным подходом Zephyr и строгим новым процессом импорта делают интеграцию HAL решающей для успеха Zephyr.
Как отмечается в их блоге: «Никто не может отрицать силу HAL, когда дело доходит до ускорения разработки».

Вы можете посмотреть полное видео презентации ELCE ниже:

«Использование HAL SoC Vendor в проекте Zephyr»

Эта статья защищена авторским правом © 2017 Linux.com и была первоначально опубликована здесь .
Он был воспроизведен этим сайтом с разрешения его владельца.
Пожалуйста, посетите Linux.com для получения последних новостей и статей о Linux и open source.