Ускорение ли вашей стратегии драйвера времени выхода на рынок?

Для большинства команд ответ-нет. Неоптимизированная стратегия водителя-это скрытое узкое место. Эта неэффективность проявляется через несколько симптомов:

• Команды борются с раздутыми SDK поставщиков.
• Код приложения слишком сильно зависит от конкретного оборудования.
• Процесс разработки застоя, поскольку команды ждут функциональных драйверов.

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

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

Ключевые выходы

• Медленная стратегия драйвера вредит срокам проекта и успеху на рынке.
• Общие SDK поставщиков создают проблемы, такие как длительное время сборки и трудная отладка.
• Плотно связанный код затрудняет изменение программного обеспечения дляНовое оборудование.
• Помогает трехэтапный план: создать lean SDK, использовать сильный HAL и стандартизировать работу с драйверами.
• Этот план помогает командам работать быстрее иСоздавайте лучшие товары.

ДИАГНОСТИКА ВАШЕЙ БУТНИНКА HISILICON

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

СИМПТОМ 1: КЛАЗИРОВАННЫЕ SDKS ПОСТАВЩИКА

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

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

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

• Более длительное время сборки:Компиляция ненужного кода и связывание неиспользуемых библиотек тратит драгоценное время разработчика с каждой сборкой.
• Сложная отладка:Большая кодовая площадка увеличивает область поиска ошибок. Разработчики должны перемещаться неактуальноДрайверы поставщикаИ зависимости, чтобы найти источник проблемы.
• Отложенная интеграция элементов:Добавление новых функций требует от разработчиков понимания того, как они взаимодействуют с огромной базой существующих драйверов поставщиков, замедляя процесс разработки.

Эти общие SDK заставляют вашу команду управлять сложностью, которая не представляет ценности для вашего конечного продукта.

СИМПТОМ 2: ТЯГКО СВАРЕННЫЙ КОД

Распространенным анти-паттерном является написание логики приложения, которая напрямую вызывает аппаратные регистры низкого уровня. Эта практика плотно связывает программное обеспечение с конкретным HiSilicon SoC, делая кодовую базу хрупкой и трудной в обслуживании. Любая аппаратная ревизия или переход на новый чип требует болезненной, строчной проверки кода и перезаписи.

Эта плотная связь часто является результатом:

• Нестандартные расширения компилятора:Код может использовать синтаксис какЛетучий uint8 _ t REG @ 0x1234;Для доступаПамять. Это не переносится на разные цепочки инструментов.
• Карты регистров, специфичные для компилятора:Предопределенные карты регистров от производителя кремния часто полагаются на нестандартные функции языка C, блокируя код на одном компиляторе.

Проект grbl, например, концентрирует свой аппаратно-зависимый код вStepper.c, Что делает этот конкретный модуль чрезвычайно трудным для порта.Решение состоит в том, чтобы обеспечить строгое разделение проблем с использованием уровней аппаратной абстракции (HAL).HAL предоставляет стандартизированный интерфейс для взаимодействия приложения с оборудованием. Он скрывает сложные, специфичные для чипа детали драйверов поставщика.

Хорошо разработанный HAL определяет общий интерфейс, часто используя структуру указателей функций. Это позволяет приложению выполнять такие действия, какI2C _ Write()Не зная конкретных битов регистра базовых драйверов поставщика.

/* Пример интерфейса I2C HAL */
Структура typedef
{
Bool (* Init)(void);
Bool (* Write)(uint16 _ t const TargetAddress, uint8 _ t const * const Data, uint32 _ t const DataLength);
Bool (* Read)(uint16 _ t const TargetAddress, uint8 _ t * Data, uint32 _ t const DataLength);
} I2С _ t;

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

СИМПТОМ 3: ПОСЛЕДСТВЕННОЕ РАЗВИТИЕ

Многие проекты следуют жесткому, последовательному рабочему процессу. Команда приложений не может начать значимую работу до тех пор, пока группа оборудования не обеспечит полностью функциональные драйверы. Это создает классическое узкое место зависимости.

Типичный неэффективность рабочего потока:

Команда водителя Разрабатывает➡️ Команда приложения ждет➡️ Интеграция начинается поздно 🚶‍♂️ .....................................💻

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

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

• Параллельные рабочие потоки:Разработка приложений и драйверов протекают одновременно, что значительно сокращает общие сроки.
• Раннее обнаружение ошибок:Команды могут выявлять и устранять проблемы интеграции в моделируемой среде задолго до того, как окончательное оборудование будет готово.
• Улучшение сотрудничества: Этот процесс с самого начала обеспечивает четкую коммуникацию и согласование интерфейсов, выравнивание команд и сокращение конфликтов на поздних стадиях.

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

СТРАТЕГИЯ ПО УСКОРЕНИЮ ВРЕМЕНИ НА РЫНКЕ

Диагностика узких мест-это только первый шаг. Следующим шагом является реализация продуманной, трехуровневой стратегии. Такой подход трансформирует то, как командаУправляет драйверами HiSilicon, Превращая источник задержки в инструмент для ускорения времени выхода на рынок. Каждый уровень опирается на последний, чтобы создать упорядоченный и эффективный рабочий процесс.

TIER 1: СОЗДАЙТЕ LEAN SDK

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

Создание и поддержание Lean SDK требует дисциплинированного подхода.Передовая практика включает:

• Модульная архитектура:Проектирование SDK в модулях. Это позволяет командам разработчиков включать только необходимые части для их конкретных функций.
• Семантическое версионирование:Используйте систему управления версиями MAJOR.MINOR.PATCH. Это четко передает влияние обновлений, различая изменения, новые функции и исправления ошибок.
• Очистить документацию:Предоставьте полную документацию для каждой версии. Сюда входят руководства по миграции и изменения, помогающие разработчикам плавно адаптироваться к новым релизам.
• Автоматизированное тестирование:Внедрение набора автоматизированных тестов для каждой версии. Это обеспечивает обратную совместимость и предотвращает регрессии, сохраняя надежность пользовательских sdks.

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

TIER 2: ОСУЩЕСТВЛЕНИЕ РОБЮСТА HAL

При наличии бережливого SDK следующий уровень-это архитектура надежного уровня абстракции оборудования (HAL). HAL-это программный уровень, который создает буфер между логикой приложения и аппаратно-специфическими драйверами. Он отделит приложение от базовой SoC HiSilicon, делая код переносимым и простым в обслуживании.

Хорошо продуманный HAL определяет стандартный набор функций для взаимодействия с периферийными устройствами. Для такого компонента, как GPIO, основные функции включают в себя:

• Инициализация
• Операции записи и чтения
• Настройка контактного мультиплексора (SetMux)

Эта абстракция не позволяет коду приложения делать прямые, низкоуровневые аппаратные вызовы. Вместо привязки к конкретным регистрам, приложение использует стандартизированный интерфейс HAL.

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

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

• Изолированное тестирование: Разработчики могут использовать макет объектов для модульная проверка бизнес-логики в изоляции. Это устраняет аппаратные зависимости и позволяет проводить быстрое тестирование на машине разработки.
• Раннее обнаружение ошибок:Оберточная аппаратная связь в модуле HAL позволяет командам отлавливать ошибки интеграции раньше, задолго до того, как будет доступно конечное оборудование.
• Снижение риска:Изменения в коде более высокого уровня с меньшей вероятностью приведут к нарушению аппаратного интерфейса, поскольку HAL рассматривается как стабильный и проверенный компонент.

TIER 3: РАЗРАБОТКА СТАНДАРТИЗА ВОДИТЕЛЯ

Последний уровень объединяет весь процесс, устанавливая четкие стандарты для развития водителя. Стандартизация гарантирует, что все драйверы надежны, ремонтопригодны и последовательны. Это начинается с принятия строгого стандарта кодирования.

Для систем с высокой надежностью необходимы такие стандарты, как MISRA C. MISRA предоставляет руководящие принципы для C и CЭто поможет разработчикам:

• Повышение безопасности:Он не разрешает небезопасные языковые конструкции, такие как непроверенные арифметические указатели, что имеет решающее значение в системах, где сбой не является опцией.
• Улучшение ремонтопригодности:Это способствует четкости и переносимости кода, упрощая обновление программного обеспечения и управление им в течение его жизненного цикла.
• Обеспечьте соответствие:Он обеспечивает основу для соблюдения строгих отраслевых стандартов безопасности, таких как ISO 26262 для автомобильных систем.

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

Для автоматического применения этих стандартов командам следует внедрить конвейер непрерывной интеграции (CI).Сервер CI может быть настроен для выполнения последовательности заданий каждый раз, когда код совершается, ускоряя время выхода на рынок за счет обеспечения быстрой обратной связи.Типичный конвейер CI для встроенных драйверов включает следующие этапы:

1. Сборка:Трубопровод компилирует прошивку и генерирует двоичные файлы выпуска.
2. Анализ: Инструменты статического анализа, такие как PVS-Studio, Coverity или Polyspace, автоматически проверяют код на наличие ошибок и соответствие стандартам MISRA.
3. Тестирование:Трубопровод выполняет все модульные, интеграционные и системные тесты.
4. Отчетность:Он собирает результаты всех предыдущих этапов для отчета об успехе сборки, качестве кода и покрытии тестирования.
5. Объединить:Новая функция объединяется с основной веткой только в том случае, если все предыдущие задания успешны.

Этот автоматизированный стандартизированный процесс гарантирует, что каждый фрагмент кода будет построен, протестирован и проверен, что приведет к более качественным драйверам и более предсказуемой временной шкале проекта.

---

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

Эти инвестиции в процесс и навыки дают значительную отдачу:

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

Прекратите позволять неэффективным водителям создавать задержки. Внедрите эти изменения для улучшения продуктов и ускорения времени выхода на рынок.

Часто задаваемые вопросы

Что такое уровень абстракции оборудования (HAL)?

Уровень аппаратной абстракции (HAL)-это программный уровень, который отделяет код приложения от аппаратных драйверов. Этот уровень обеспечивает параллельную разработку и делает программное обеспечение переносимым на разные микросхемы. Это ключевой инструмент для ускорения времени выхода на рынок.

Сложно ли создать Lean SDK?

Создание Lean SDK требует дисциплины. Команды должны идентифицировать и удалить неиспользованный код из пакета поставщика. Эти первоначальные усилия окупаются за счет сокращения времени сборки, упрощения отладки и повышения безопасности.

Что такое МИСРА С?

MISRA C-это набор руководящих принципов разработки программного обеспечения для языка программирования C. Это помогает командам писать более безопасный и портативный код. Привержение имеет решающее значение для систем с высокой надежностью. Ключевые преимущества включают:

• Повышенная безопасность🛡️
• Улучшенная ремонтопригодность
• Гарантированное соответствие

Как эта стратегия помогает с новыми чипами HiSilicon?

Надежный HAL делает портирование наНовые HiSilicon SoCНамного быстрее. Код приложения остается неизменным. Разработчикам нужно только обновить базовую реализацию драйвера HAL для нового чипа, экономя значительное время и усилия.