16+
Среда
20 февраля
Вход |Карта сайта | |Upload |codebook | PARTS

 О смысле всего сущего 0xFF

 Средства и методы разработки

 Мобильная и беспроводная связь

 Блошиный рынок Объявления

caxapa

Микроконтроллеры ARM 

AVR PIC MSP PLD,FPGA,DSP 

Кибернетика Технологии 

Схемы, платы, компоненты 

Средства и методы разработки

 
   Новая тема Правила Регистрация Поиск »» Архив
Вернуться в конференциюТопик полностью
Evgeny_CD  (05.02.2019 18:12, ссылка, просмотров: 1966)
[Advanced тестирование "боевых" прошивок] Идея. 
Есть у нас прошивка, которую собрали в "полном хардкоре": -- один файл исходника -- LTO -> -- прочая Надо бы ее протестировать, перед тем как пускать в продакшн... Но для части кода тестовый и боевой код сильно разные. Например, вместо драйвера UART нам надо заглушку, которая будет взаимодействовать с внешним ПК, где будет крутиться упрощенный эмулятор модема. Но если мы будем собрать боевое ядро с тестовым кодом - это будет совсем другая прошивка. Делаем так. 1. Заранее готовим data set для тестирования со 100% покрытием кода основного модуля. 2. Дрова тестируем со специальным кодом без основного модуля. 3. Исходники основного модуля пишем правильно. Вместо init как последовательности операторов в main пишем int init (); 4. Готовим исходники заглушек в отдельных файлах. Чтобы интерфейс вызова из основного модуля был одинаков. 5. Собираем отдельно боевой комплектный модуль, начиная с какого-то адреса 6. Собираем отдельно модуль заглушек. 7. Пишем/патчим срипт линкера, чтоб получить загрузочный образ, и чтобы линкер скомпоновал бинарник из тестового и основного модуля, заменив адреса части боевых функций вызовами тех же функций в тестовом варианте. 8. Берем либо тот же камень, либо из того же семейства с большим объемом ОЗУ/FLASH 9. Пишем на ПК тестовые модели 10. Натягиваем "почти боевую" прошивку во все дыры. Есть тонкости в эмуляции прерываний, от архитектуры зависит, но решить можно. Не всякий боевой код можно так протестировать, но если изначально затачиваться на такой метод, то все будет ок, и оверхеды будут микроскопические. Жестко синхронные вещи, типа когда код знает и учитывает это, сколько тактов он исполняется, так не отладить - но так ответственные сложные вещи не стоит писать. Можно, конечно, создать железный эмулятор SD карты, Serial NAND, но кто и в рамках какого бюджета будет их делать? В моем варианте трудоемкость сильно меньше. В отличие от просто тестирования, и тестирования в синтетических портах (их никто не отменяет, это дополнение), можно эффективно тестировать не только ошибки ТЗ и кодера, но и ошибки компилятора. "Эмуляторы сущностей" удобно писать на ПК под SystemC - там хорошо поведенческие вещи описывать. ПО машин состояний тоже будет очень кстати для эмуляторов. Можно бенчмаркить целевой код и подбирать опции компилятора - это дело муторное, без полной автоматизации не обойтись. Подаем на вход стека несколько IP пакетов и смотрим время обработки. Подбираем оптимизацию под нашу конкретную задачу, а не вообще. Часть глюков останется, но в тонком слое между драйверами и боевым кодом. Что тестируем: -- подаем на вход стека все варианты битых и кривых пакетов, смотрим, что все переходы выполнены верно. -- FLASH - прогоняем все варианты битых секторов (проверка ECC), а также абсурдные данные из сектора -- поведение на наборе данных от контролируемого объекта. -- многое другое. Это не панацея, но, на первый взгляд, мощный инструмент для тестирования. Критика?
 [x][x][x][x][x][x] [x][x][x][x][x][x][x][x]

Тема выделяется по переводу строки или автоматом

 

Имя


Регистрация позволит вам редактировать и перемещать ваши сообщения и прикреплять к ним файлы.
 
Символы: á é ó ú ý « »
Главная | Карта сайта | О проекте | Проекты | Файлообменник | Регистрация | Вебмастер | RSS
Лето 7527 от сотворения мира. При использовании материалов сайта ссылка на caxapу обязательна.
MMI © MMXIX