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

TDD (Test-driven Development) применительно к embedded системам: похоже, я догнал, как это должно быть устроено. =================== Книги по теории XP (Extreme Programming) =================== http://rapidshare. …_Kent_Bek.pdf.rar.html 9.84 MB Кент Бек Экстремальное программирование: разработка через тестирование Test-driven Development by Example Серия: Библиотека программиста Издательство: Питер, 2003 г. Мягкая обложка, 224 стр. ISBN 5-8046-0051-6, 0-321-14653-0 http://rapidshare. …e_programming.rar.html 2.19 MB Экстремальное программирование Extreme Programming Explained Кент Бек Мягкая обложка 224 стр., 2003 г. Издательство: Питер. Серия: Библиотека программиста. ISBN 5-94723-032-1 Все взято с сайта http://www.natahaus.ru/. =================== Предыдущие обсуждения по теме =================== eCos на ARM симуляторе SID, автоматическое тестирование при помощи DejaGNU - очень интересно!!! http://www.caxapa. …echo/arm.html?id=62769 http://electronix. …ex.php?showtopic=18602 PowerPC (AMCC PPC405-GPr) для embedded устройств: наш выбор (после кидалова со стороны AMD & Intel)? http://www.caxapa. …echo/arm.html?id=62678 http://electronix. …ex.php?showtopic=18556 =================== Классические тулзы для TDD =================== ##### CUnit ##### http://cunit.sourceforge.net/index.html CUnit is a lightweight system for writing, administering, and running unit tests in C. It provides C programmers a basic testing functionality with a flexible variety of user interfaces. CUnit is built as a static library which is linked with the user's testing code. It uses a simple framework for building test structures, and provides a rich set of assertions for testing common data types. In addition, several different interfaces are provided for running tests and reporting results. ##### Check ##### http://check.sourceforge.net/ Check: A unit test framework for C Check is a unit test framework for C. It features a simple interface for defining unit tests, putting little in the way of the developer. Tests are run in a separate address space, so Check can catch both assertion failures and code errors that cause segmentation faults or other signals. The output from unit tests can be used within source code editors and IDEs.. Check was inspired by similar frameworks that currently exist for most programming languages; the most famous example being JUnit for Java (www.junit.org). There is a list of unit test frameworks for multiple languages at www.xprogramming.com/software.htm . Unit testing has a long history as part of formal quality assurance methodologies, but has recently been associated with the lightweight methodology called Extreme Programming. In that methodology, the characteristic practice involves interspersing unit test writing with coding (" test a little, code a little"). While the incremental unit test/code approach is indispensable to Extreme Programming, it is also applicable, and perhaps indispensable, outside of that methodology. The incremental test/code approach provides three main benefits to the developer: * Because the unit tests use the interface to the unit being tested, they allow the developer to think about how the interface should be designed for usage early in the coding process. * They help the developer think early about aberrant cases, and code accordingly. * By providing a documented level of correctness, they allow the developer to refactor (see www.refactoring.com ) aggressively. * That third reason is the one that turns people into unit testing addicts. There is nothing so satisfying as doing a wholesale replacement of an implementation, and having the unit tests reassure you at each step of that change that all is well. It is like the difference between exploring the wilderness with and without a good map and compass: without the proper gear, you are more likely to proceed cautiously and stick to the marked trails; with it, you can take the most direct path to where you want to go. ##### Все здорово, но применительно к embedded вещам надо: * тестировать реальный код реального компилятора, с использованием реальных библиотек * тестировать все это на реальном проце (либо на полноценном симуляторе оного) * измерять временные характертистики кода * не зависить (или слабо зависить) от embedded ОСи * иметь предсказуемой поведение системы при полном креще тестируемого кода Обе вышеописанные системы неплохи, но этим требованиям они не удовлетворяют. Хочется вместо тестирования plain C (которое, строго говоря, можно проводить на любой платформе) перейти сразу к целевому тестированию. Понятно, что писать тестирование для С программ на самом С (пусть даже с использованием достаточной удобной либы как в CUnit) - это самоубийство. Нужен некий ОО скриптовый язык, который резко сократил бы количество писанины. При этом скорость работы tets engine волнует умеренно - все равно он будет выполняться на быстром пЫсюке. =================== Мои идеи =================== ##### Тестирование одиночной функции ##### Есть функция test_func (). Ее надо протестить. Юзаем GDB. Пишем test framework: декларация всего необходимого для test_func (); a=0; for (;;a == 0){ пустрой оператор 1; test_func (); пустрой оператор 2; } Сама функция живет в отдельном файле. Framework живет в своем файле. Собируем, запускаем. Ставим break points на пустые операторы (в идеале пользуемся аппаратным break points). Дошли до 1. Через GDB задали значения для всего, что нужно для данного сеанса тестирования test_func. Go. Остановились на втором операторе. Задампили все значения переменных, задали новые. Надо завершить тест - задаем a=1. Go. Первый брейк-поинт может отсутствовать. Основной кайф GDB состоит в том, что он позволит иметь _ОДИНАКОВЫЙ_ интерфейс к нашей тестируемой функции во всех случаях: GDB -> виртуальный симулятор ядра (пример: PSIM) GDB -(COM | Ethernet)-> GDB Stubs на виртуальном симуляторе ядра + периферии (пример: SID, skyeye.org, ) GDB -(COM | Ethernet)-> GDB Stubs на реальном железе GDB -(JTAG)-> реальное железо Еще один кайф состоит в том, что не надо "упаковывать" данные в printf (), а затем распаковывать их. Количество отадочного кода тоже резко уменьшается, и хотя он будет жить под #ifdef - все равно, чем меньше кода в боевом приложении, тем лучше. Вместо кода в основном приложении получаем код в тестовых скриптах, что гораздо правильнее. ##### Тестирование модуля - совокупности функций ##### То же самое, но test framework будет поразвесистее. ##### Тестирование драйвера ##### Аналогично тестированию функции (но не все дрова можно так протестить). Например, для COM порта делаем hardwarer loopback и пишем тест: отправить пакет - принять пакет. Ну и контроль целостности. ##### Тестирование в реальном времени ##### Собираем тестровую систему: * embedded ОСь * Dhrystone тест как отдельную задачу для контроля производительности * драйвер; софтовый модуль * test framework Идея test framework: a=0; for (;;a == 0){ interrupt disable (); timer_freeze (); пустрой оператор 1; interrupt enable (); timer_release (); test_func (); interrupt disable (); timer_freeze (); пустрой оператор 2; interrupt enable (); timer_release (); } timer_freeze (); timer_release (); нужны для того, чтобы у ОСи крышу не сносило, пока мы по регистрам и по памяти проца лазим. Иначе таеймер тикает, и после "отпускаяния" ОСь попадент в неизвестное состояние. Тестирование в части реального времени потребует free running timer (timer_test) нужной разрядности и выглядит примерно так: * измерили Dhrystone на "чистом" проце - только ОСь и одна задача под ее управлением * настроили все для тестирования * запустили timer_test * запустили процесс Dhrystone * запустили test framework * вернулись из test framework * остановили процесс Dhrystone * остановили timer_test * посмотрели, какую производительность показал Dhrystone * проверили результаты test framework Очевидно, что при помощи test framework мы можем задать максимально возможную нагрузку на дрова системы, а затем оценить "запас по процессору". Понятно, что автоматизировав процесс, мы можем проводить длительные тесты для обнаружения тонких аппаратных глюков. =================== Автоматизация тестирования, или зачем нам DejaGNU =================== Все описанные выше процедуры можно проводить вручную - но это для hardcore мазохистов. Любому нормальному человеку становиться понятно, что все это надо автоматизировать. DejaGNU для этого и создана. Она: * обеспечивает инвариантность взаимодействия с девайсом независимо от канала связи * удобный механизм генерации тестровых воздействий * такой же удобный механизм анализа отклика * автоматизация ведения логов Ручная же отладка потребуется только в случае неожидаемого провала теста - чтобы понять, что к чему. Думаю, если сильно извратиться, то можно полностью автоматизировать процесс тестирования. Т.е. из репозитория собирать фнкцию, ее test framework, запускать, запускать соотсвтуюзий скрит GejaGNU и т.д. Конечно, попотеть придется, но оно того стоит. =================== Замечание по средам и процессу отладки =================== Вот, собственно, и приплыли. Начиная с этого момента GNU форЁвА! Ибо коммерческие тулзы такого класса, вероятно, существуют, но разденут даже богатую контору - в этом даже и не сомневаюсь, ибо это уже "взрослые" технологии разаработки (это Вам не в ИАРе недопатченном код дебажить). Наличие исходников тоже становится стратегически важным - ибо такая система внутри фирмы создает один раз на многие годы (десятилетия), и зависимость от кого бы то ни было стратегически не допустима!!! Я не знаю, какая скорость прогона тестов в итоге получится - но меня это даже и не волнует. Ибо тут во всей красе предстает юниксовая идеология скриптов. Немного напрягли голову, нарисовали скрпиты - и все, дальше нас ничего не волнует. Пусть тесты идут хоть несколько часов, хоть несколько дней - все равно есть чем другим заняться. Иногда переключаешься в окошко теста и смотришь - а какой там % выполнения, и не закрешилось ли все. =================== Взаимоотношения с аутсорсерами =================== Сильно упрощаются. Перед написанием каждой фукции пишется тест для нее. Также тесты для модулей. If тест неполный - $--, ибо это уже нарушение договора. If мухлеж с тестами - "асфальтная болезнь" в хронической форме. Причем работы полностью автоматизирован: прошли тесты - получил бабло; не прошли - получил по шее. Тесты для функций пишут авторы функуцйи. Тесты для важных модулей пишут други люди (не разработчики). =================== Выбор контроллера =================== С топовым контроллером все понятно - PPC. Вопрос в мелких контроллерах для lite вариантов. Базовые требоваия к такому контроллеру: Ethernet, много памяти. ##### FLASH ##### Если каждый раз тестовый код прошивать по FLASH - дырка там протрется очень быстро. Отпадает. ##### FLASH + SRAM ##### STR91 + внешний SRAM был бы идеальным вариантом, если бы не медленная работа с внешним SRAM. ##### FLASH + SDRAM ##### Это и есть идеальный выбор контроллера. FLASH хорошо бы внутренний, но можно без него, а вот SDRAM контроллер + Ethernet необходим. Варианты: * AT91RM9200 - контроллер на все времена. Ему бы еще Public порт eCos... * EP930xx - как-то недолюбливаю я Cirrus. * LH7952(4 |5) - замечательные контроллеры, но на них нет порта eCos, RTEMS, что печально. * Samsung S3C4510B, S3C4530A - отлично, есть eCos, но нет -40, производительности может не хватить * ColsdFire - замечательная вещь для данной идеологии. По сотношению цена/ресурсы им трудно найти конкуренцию. Например, 100 Мгц Coldfire c внешней шиной, DMA, MAC 32 бита, 64 к SRAM на кристалле, 8К универсального кеша, много, много всего MCF5270AB100 (PQFP!) в партии 25 штук на http://www.digikey.com стоит 12$ - почувствуйте разницу... Кстати, BGA у ColdFire на редкость продуманные - 1 мм, 4 ряда - так что на 4-х слоке 4 класса разведется без вопросов (образцы до 5 кв. дм при заказе в PCB Technology будут стоить 250$ - можно пережить). Свинцовые корпуса также досупны - а при таком раскладе запаять его на плату сможет квалифицированный ремонтник сотиков Например, на MCF5282 есть полный порт RTEMS с GDB Stubs. На eCos полный порт есть только от eCoscentric. Но зато на eCos есть порт для MCF5272 (но без Ethernet) - тоже отличный камень. Более подробно о ColdFire: FreeScale (Motorola) ColdFire - наши мольбы о !BGA услышаны? http://www.caxapa. …echo/arm.html?id=63110 http://electronix. …ex.php?showtopic=18754 Собственно, вначале я осознал все описанные тут идеи, потом стал шерстить по контроллерам, нашел много интересного в ColdFire - поэтому и появился пост про ColdFire. :)