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

Догнал - II: все то же самое, но гораздо проще :) Пишем функцию или кучку функций. На нашем специальном макроязыке описываем, какие у всего этого хозяйства входные и выходные переменные. При помощи COG http://www.nedbatc …code/cog/index_ru.html http://www.onembed …m/articles/cog-n-make/ http://www.onembed …og-n-make/examples.htm автоматически (по заранее разработанной универсальной программе) генерим test unit, который: * принимает по внешнему каналу связи от пЫсюка данные, запихивает их во входные переменные * тестирует код с этим набором данных * выгружает переменные во внешний пЫсюк. * повторяет, если надо Вся эта загрузка-разгрузка данных может быть довольно геморройной (пример - структуры, они могут быть по разному упакованы; индейцы), но в общем это конечной сложности задача. Тогда задача для тестировочного скрипта на пЫсюке выглядит так: * генерация кода test unit * сборка тестового проекта (make и пр.) * обресетить плату * длождаться загрузки монитора * по TFTP загрузить модуль, запустить * по заданному каналу связи установить связь с test unit * передать/принять данные * анализ, новые данные. Работа с данными тестирования производится "подскриптом", который разработан в процессе разработки тестируемого модуля. Основной кайф такого подхода состоит в том, что он не зависит ни от чего: ни от отладчиков, ни от ОСей, ни от компилеров. Гавное, чтобы на целевой плате были: * Ethernet * памяти побольше * монитор, который TFTP понимает. Что касается работы с Ethernet из тестируемого приложения, то либо использовать функции монитора, либо прикрутить LwIP - не так уж он страшен. В результате можно создать совершенно монстровую тестовую конструкцию без обращения к тяжелым ОСям (eCos, RTEMS). В качестве скриптового языка для автоматизации всего этого процесса Python подходит просто идеально. При некотором усердии, полагаю, можно полностью автоматизировать тестирование целого проекта. Есть списком модулей, далее автоматически запускаются и собираются тесты.... "Нас не догонят...!"