Процесс разработки для встроенного проекта со значительными изменениями оборудования - PullRequest
Новая
       35

Процесс разработки для встроенного проекта со значительными изменениями оборудования

4 голосов
/ 15 марта 2010

У меня есть хорошее представление о процессе разработки Agile, но я не знаю, как сопоставить это со встроенным проектом со значительными изменениями в оборудовании.

Я опишу ниже, что мы в настоящее время делаем (Ad-hoc, пока не определен процесс). Изменения разделены на три категории, и для каждой из них используются разные процессы:

  1. полная замена оборудования

    пример: используйте другой видеокодек IP

    а) Изучите новый IP

    b) моделирование RTL / FPGA

    в) Реализовать устаревший интерфейс - перейдите к б)

    d) Дождаться, пока аппаратное обеспечение (лента) будет готово

    е) Тест на реальном оборудовании

  2. улучшение аппаратного обеспечения

    пример: улучшение качества отображения изображения путем улучшения базового алгоритма

    a) RTL / FPGA моделирование

    b) Дождитесь аппаратного обеспечения и проведите тестирование на аппаратном обеспечении

  3. Незначительное изменение

    пример: изменить только отображение аппаратного регистра

    a) Подождите, пока аппаратное обеспечение и проведет тестирование аппаратного обеспечения

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

Как вам удалось сменить аппаратное обеспечение? Вы решили это с помощью уровня аппаратной абстракции (HAL)? Был ли у вас автоматический тест для слоя HAL? HAL работает для зрелого продукта, но он может не работать хорошо для потребительского продукта, который быстро меняется. Как вы тестировали, когда аппаратная платформа даже не готова? У вас есть хорошо документированные процессы для такого рода изменений?

1 Ответ

3 голосов
/ 16 марта 2010

Добавление уровня аппаратной абстракции (HAL) необходимо, если вы ожидаете, что базовое оборудование изменится в течение срока службы продукта.Если все сделано правильно, вы можете создать модульные тесты для обеих сторон HAL.

Например, HAL - это просто API от вашего GUI до реального аппаратного обеспечения дисплея.Вы можете написать поддельный аппаратный драйвер, который не управляет физическим устройством, но реагирует по-разному, чтобы убедиться, что ваши верхние уровни API обрабатывают все возможные коды ответов из HAL.Может быть, он создает в памяти растровое изображение (вместо управления внешним вводом-выводом), которое можно сравнить с ожидаемым растровым изображением, чтобы убедиться в правильности его рендеринга.

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

Вернемся к вашему примеру.Насколько отличается переход на другой видео кодек?Вы все еще просто толкаете байты на верхних уровнях.Если вы реализуете известный кодек, было бы полезно иметь исходные файлы, которые действуют как модульный тест (охватывающий весь спектр возможных форматов данных), чтобы гарантировать, что ваш кодек декодирует и отображает их правильно (без сбоев!).Декодирование в растровое изображение в памяти делает хороший модульный тест - вы можете просто сравнить память с необработанным распакованным кадром.

Надеюсь, это поможет.Если нет, задавайте больше вопросов.

...