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

Развитие идей по упрощенной отладке. Оставим пока в покое ОСи. Вот есть у нас модуль, который надо оттестировать. Натравливаем на него ctag - получаем файл с именами всех сущностей. Вручную "парсим" его (Ctl-Y), оставляя только то, что надо для тестирования. После парсинга должны остаться: * список include для тестовой main * список имен переменных (элементы структур приводятся с полными именами) * шаблон для обращения к тестируемому модулю (надо придумать, как сюда засунуть данные о типе переменной - пока можно и руками) Запускаем специальный скрипт, в качестве параметра ему - этот файл. Скрипт автоматически генерит при помощи COG тестовый main. Перво-наперво разбираемся с переменными: составляем массив структур вида (для каждого элемента списка переменных) const char name = "имя переменной №1 из списка по порядку" * address = имя переменной №1 из списка по порядку // указатель на переменную size = sizeof (имя переменной №1 из списка по порядку) // длина переменнной Далее по шаблону обработка команд - RUN, STOP, DUMP, ну и прочее. Также вставляем в тело собственно сам код для тестования модуля :) Компиляция, сборка, загрузка, запуск, ждем команды на входе в тестовый кусок. Вначале просим list переменных. В этом листе как имя, так и emun для переменной - чтобы потом было проще к ним обращаться. Нам отправляют блок данных, мы проверяем - то ли мы вообще тестируем :) Далее формируем пакет на установку переменных в нужное нам состояние. Выдаем его, команду установить и т.д. Запускаем тест. Сами слушаем сокет (или другой интерфейс) - ага, вышли из теста. Скачиваем к себе переменные, анализируем. Повторяем по новой с новым набором данных или пересбока для другого теста. После файла сущностей мы пишем тестировочный скрипт. Типа чего задавать, чего анализировать, как принимать решения. Этот скрипт вызывается некоей "большой сущностью" test suite для полной автоматизации процесса. При некоторых ограничениях (типы переменных) выглядит очень здорово, согласитесь. Если все сделать правильно в плане автоматизации, то можно вообще оптимизировать "нипадеццки" Например, мы отлаживаем блок DSP, надо (кроме правильности) выжать еще и скорость. И тут возникает ковеер, кеш, и много чего - что на симуляторе очень трудно отсимулировать (и всегда есть вероятность того, что симулятор не то симулирует). В тестовый main добавляем работу с таймером, запоминаем таймер перед входом в тестирование и после выхода. Пишем несколько вариантов кода, и после завершения работы всех скриптов (пусть они хоть час крутятся!!!) мы получаем аккуратую табличку - время выполнения в зависимости от варианта и опций компилятора. За время тестирования мы написали следующйи кусок кода, и процесс отлично конвейризуется!!! Заодно становится понятны временные характеристики кусков системы (причем, затем, до того, как собрана вся система!!!). Можно по ходу менять структуру системы, приоритеты и пр. Т.е. результат разработки становится все более и более предсказуемым. Эту идею можно несколько расширить для "отладочной печати". Т.е. вот отлаживаем кусок кода - а он нифига на идет! Ставим в него debug_printf (), debug_scanf (), , автоматически собираем вокрух этого куска тестовый main, и запускаем все это на исполнение. Скрипт автоматически из нашего "разрабатываемого файла" делает тестовый файл, дополняет его внешними прогами и пр. make - рулез!!!!! Вообще, делатели JTAG в моем понимании должны как огня бояться идеологии мониторов. Ибо при помощи простейшего монитора, который может принять прогу извне и запустить ее на исполнение, получается абсолютно универсальная среда разработки для embedded систем (с учетом описанной выше скрпитовой идеологии от монитора большого ума не требуется - он может быть примитивен). И нет необходимости платить несколько k$ за JTAG (я говорю о "взрослых" JTAG) за каждую архитектуру и каждое рабочее место. Остается еще много тонких вещей, связанных со стеком и пр. !!!! Эту идеологию отладки можно расширить и до низкого уровня. Как отладочная печать (приведено выше), ставим COG кусок - задампить регистры процессора (и периферии - если надо). COG вставлят нам кусок кода, который это делает. Опять же при помощи скрипта можно обработать эти дампы - чтобы не искать нужные данные в куче экранов или длинных файлах логов. Я изобрел "Unix". :))) Над всем процессом разработки и отладки приложения есть верхний уровень - скриптовое управление. И если разработчик научится при помощи скриптов управлять всем этим, то его возможности резко повышаются. О вреде стереотипов мышления. :)) Когда-то я сам заводил Радио-86РК. И идеология мониторов для меня не новинка. Потом были 51 и мелкие AVR, там тяжело сменить программу без перепрошивки чипа, и это все как-то забылось. Кстати, заметим, при помощи Avreal эта идеология вполне будет и на AVR работать - только контроллеры нужно признать "расходным материалом" по причине протирания дырки во флеше. :) Потом ARM, и JTAG как нечто доступное только "взрослым пацанам". Тепепь я понимаю, что если "разуть мозги", то все это условности. Самое главное для высококлассного разработчика - мыслить обобщенными категориями. Прописная истина, но увы, про нее так легко забыть. И скатиться на уровень мышления "а в IAR это делается так". Понятие скрпитового объектно ориентированного языка становится главенствующим. Будет это Python, или какой-нибудь REXX - это же дело вкуса. Все сводится к: * редактор - универсальный редуктор для работы со всеми видами текста * компилятор и прочий тулчейн - это нечто, что при помощи скриптовой оболочки приведено к удобному и единообразному виду * интерактивный шелл. Тут сказать особо нечего - желающие смотрят http://ipython.scipy.org/ И стиль мышления должен быть такой. Надо мне нечто откомпилировать. Я не вспоминаю F что мне надо нажать в IDE. Или в какую менюшку слазить. Я просто в интерактивной консоли задаю compile (ну ли в каком-нибудь конструкторе графических интерфейсов рисую безумно красивую кнопку compile - если мне делать больше нефиг). И оно все само должно сделать! Разумеется, нет никакой необходимости задавать все эти горы параметров командной строки. Нужно в каждый момент времени думать только над одной задачей. Есть понятие обобщенного компилятора. Делаем объект в питоне. Берем конкретный компилятор - и встраиваем его в нашу систему, задавая все необходимые опции. Все, отложили доку по компилеру в сторону - начали с исходниками работать. Настроили рабочую среду - работаем с таким-то компилером, такой-то вариант конфиграции, репозиторий кода там-то, директория проекта вот здесь, либы, хидеры - тута. comlipe - и все само срабатывает. Открывается редактор и показывает, где кто обматерился. test - и описанная выще процедра автоматического тестирования понеслась. ****************** Выводы **************** 1. Все истинно профессиональное должно быть с командной строкой. GUI - на любителя, но оно не должно быть определяющим. 2. Мышление должно быть структурированным. В каждый момент времени количество сущностей по вертикали (различная степень детализации) и горизонтали (над которыми размышляешь одновременно) должно быть минимально. Так сказать, "объем мышления" должен быть минимален. Нужно натренировать мозги, чтобы очень быстро переключаться между "точками зрения". 3. Учить скриптовые языки. Они должны стать "продолжением мысли". И основным "рабочим местом" должен быть не IDE, а окно шелла и окно редактора. 4. Выработать практику "конвейризации работы". Т.е. думаешь над одним, в это время в фоне собирается что-то другое, автоматически тестируется третье и т.д. В каждый момент времени ты не отвлекаешься, а затем по командам внутренного шедулера переключашься между задачами. 5. Надо следить за собой, отдыхать и отвлекаться, чтобы в результате бесконечной работы над собой не оказаться в дурдоме.