Мне известны две распространенные стратегии:
Убедитесь, что у вас хорошая архитектура SW-компонента, включая четко определенный интерфейс для компонентов HAL / драйвера, которые только позаботьтесь о доступе к регистрам портов HW. Разработайте отдельный метод проверки для низкоуровневых компонентов HW-доступа, который исключает инструменты модульного тестирования. Чтобы установить sh такую концепцию проверки, убедитесь, что
- , чтобы по возможности избегать любых логов обработки c в компонентах HAL / драйвера.
- , чтобы избежать любых зависимостей HW и любой непереносимый код в остальных частях вашего ПО.
Теперь вы можете перенести свободные от кода части кода в некоторую архитектуру P C (x86 или любую другую) и выполнить все Ваше модульное тестирование с помощью обычных инструментов UT. Конечно, ваш UT будет пропускать любые ошибки, связанные с различиями между STM32 и вашим P C. Обратите внимание, что обычно это не слишком большая проблема, потому что функции HW-специфицированные c были «вытолкнуты» в HAL, а в других частях кода вы ищете только логические ошибки, которые не имеют ничего общего с HW / архитектура.
Я знаю, что эта часть ответа обсуждает вашу тему, а не предоставляет решение, которое вы запрашивали. Тем не менее, это то, что делают многие проекты.
(Разработайте себе интеграцию STM32 для своей среды модульного тестирования или) купите коммерческий инструмент модульного тестирования, поддерживающий вашу архитектуру HW. STM32 очень популярен в наши дни, поэтому многие коммерческие инструменты (Tessy, VectorCast et c.) Обеспечивают интеграцию, которая может соответствовать вашей системе. Обратите внимание, что вы также должны выбрать свою цепочку инструментов сборки (и, возможно, адаптер отладки) в соответствии с этим выбором инструмента, поэтому вам нужно проверить некоторые дополнительные ограничения.
Чтобы получить некоторую ориентацию для ваше решение между этими двумя стратегиями, вы должны рассмотреть вопрос, для какой цели вы проводите модульное тестирование:
Какие ошибки вы обнаружите таким образом? Какие другие методы проверки вы уже используете? Какой степени устойчивости ваше приложение должно достичь / гарантировать - насколько критично ваше приложение?
Обычно определенный вид / уровень критичности соответствует определенному количеству усилий, чтобы уменьшить вероятность остаточного ошибки в вашем программном обеспечении / системе настолько низки, насколько это практически возможно ( ALARP ). Вы должны убедиться, что «потратили» эти усилия сбалансированным образом, чтобы вы нашли как можно больше ошибок при каждой дополнительной проверке. Модульное тестирование низкоуровневого кода более утомительно и часто находит меньше ошибок (за тестовый случай или за рабочий час), чем другие виды тестирования.
Вам нужно доказать определенный уровень охвата UT для выполнения таких критериев процесса, как стандарты безопасности (например, IEC 61508-3 и производные стандарты), внутренние стандарты компании и т. д. c.? Затем вы должны проверить, что эти стандарты требуют для вашего приложения, и обсудить вашу стратегию с соответствующими оценщиками.
Если такие требования применимы к вашей ситуации, вам придется убедить оценщиков в том, что меры проверки применяется достаточно. Для профессиональной эффективности крайне важно, чтобы вы решили (и начали обсуждение), какой стратегии следовать в начале проекта.
Edit : Я только что наткнулся на хорошее обсуждение этой темы c на SoftwareEngineeringStackExchange . Взгляните туда.