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

Embedded TDD (Test Driven Development): отладка реентерабельных модулей ========== Предыдущие посты по теме ========== TDD (Test-driven Development) применительно к embedded системам: похоже, я догнал, как это должно быть устроено. http://www.caxapa. …echo/arm.html?id=63285 http://electronix. …ex.php?showtopic=18859 Развитие идей по упрощенной отладке. http://www.caxapa. …echo/arm.html?id=63474 http://electronix. …s=&showtopic=18859 Дальнейшее развитие идей по Embedded TDD (test driven development). Самый экономичный вариант по памяти и процу. http://www.caxapa. …echo/arm.html?id=65892 http://electronix. …ex.php?showtopic=20099 ========== 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 framework (по одной изобсужденных или иной технологии) и вкомпилли его в реальное приложение. Запустили. При помощи __FILE__, __LINE__ (большой респект Алексей Мусин:: Caxapa - до меня только сейчас дошла вся красота использования этих классических "шняг" !!!) мы идентифицировали, кому принадлежит отладочный вывод. Но остается вопрос - а какому инстансу нашей функции принадлежит этот вывод? Как это отловить? Как там насчет PID в простых осях? Нда, это уже "GDB вручную" получается.... С другой стороны, я просто чую, что вырисовывается совершенно фантастическая картина. Если не заморачиваться на JTAG и специфические отладочные функции среды (например, CrossWorks умеет программно из программы на таргете открывать файлы на хосте по JTAG!), то пожно построить полностью портабильную систему тестирования софта. JTAG пусть остается для начальной "заводки" незнакомой платформы да для отладки дров. А грамотное использование COG (или другой подобной кодогенерации) позволит свести ручную работу к минимуму. ========== Отладка с минимальным уровнем вмешательства в отлаживаемую программу ========== При использовании prinf и других "стандартых отладочных шняг" есть опасность внести сильные изменения в работу многозадачной системы. Ибо шняги не просто жрут память, они еще и стек жрут. И может полчить так, что их работа со стеком внесет существенное "возмущение" в систему (отлаживать с большим стеком на задачу, а затем при переходе в release стек уменьшать просто глупо, ибо отлов ошибок по стеку и есть одна из целей отладки). Есть идея! Резервируем некую область памяти для отладки. Делаем из нее систему кольцевых буферов с дескрипторами. Есть прерывание - "выводилка" - читает эти буфера и загоняет их в отладочный интерфес - COM, Ethernet,... module_under_test(); // задать список переменных для отладочного вывода // комананда для COG - сгенерировать отладочный кусок для переменных их списка // COG генерирует кусок кода, который без вызовов чего бы то ни было заталкивает необходимую информацию в буфер // __FILE__, __LINE__ используются для идентификации места, откуда прошел вывод // PID тоже как-то надо учитывать В результате: * мы не нагружаем стеки задач - у нас не происходит вызовов функций * мы не делаем "лишних" вызовов malloc, и, таким образом, ничего не нарушаем в системе * мы только немного увеличиваем размера кода * "отладочный" кусок памяти живет сам по себе, и на систему влияния не оказывает * затраты процессорного времени на обработчик прерывания будут небольшими при грамотном подходе. Поскольу обработчик работает только с дебуг интерфейсом и свой областью памяти, то он тоже ничего не сможет нарушить. * переход debug -> release: -- ставим флаг запрете генерации отладочного кода * организация файлов проекта -- my_file_proto.c - тут живут исходники верхнего увровня - с командами для COG -- my_file.c - это получается после обработки proto COG. Именно эти файлы идут на компиляцию. COG позволит вставлять достаточно большие "параметризированные" куски кода, задав всего лишь несколько параметров. Такой кусок кода один раз отлаживается - и все, на все случаи жизни. С реентерабельностью вроде как тоже все получется - просто памяти поболее в дебуг область. YES!!!