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

[Advanced тестирование "боевых" прошивок] Идея. http://cs.swan.ac.uk/~csoliver/ok-sat-library/internet_html/doc/doc/Gcc/4.6.4/html/gccint/LTO.html
Есть у нас прошивка, которую собрали в "полном хардкоре": -- один файл исходника -- 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), а также абсурдные данные из сектора -- поведение на наборе данных от контролируемого объекта. -- многое другое. Это не панацея, но, на первый взгляд, мощный инструмент для тестирования. Критика?