Отладка программ для AVR, как это лучше делать? Опции

[ivainc1789]

Появилась возможность приобрести AVR Dragon и STK500, но есть некоторые сомнения. Конечно, хорошо иметь параллельный программатор, но давайте пока про это забудем и рассмотрим только работу AVR Dragon и только в качестве отладчика по JTAG и dWIRE. Есть следующие возможности:

1. Использовать для отладки внутр EEPROM. Достаточно иметь тестовый пин и буфер в EEPROM например на 50 ячеек. Я пользуюсь этим методом и вообщем-то он кажется удобным. Отлаживается всегда реально прошитая программа, результаты с большей надежностью достоверны, т. к. для отладки используются ресурсы самого MCU.

2. Использовать для отладки AVR Dragon. Опыта естественно пока нет как и самого Дракона. Все проекты я делаю в IAR EWAVR. На выходе получаем файл "пожатой/оптимизированной" прошивки. Однако Студия не может работать с таким файлом и, возможно, остается только использовать debug firmware. Налицо проигрыш при отладке, т. к. получается что отлаживаем одно, а окончательно прошиваем другое. Поправьте, если я не прав.
С другой стороны, как отлаживать с Драконом? Расставляем точки останова и смотрим содержимое переменных? Насколько я представляю, любое изменение точек приводит к необх перепрошивки кристалла... Но наблюдать ресурсы таким образом можно и способом 1.
Как-то с трудом представляю себе преимущества отладчика. Если есть опыт и желание поделиться, милости прошу.

И еще попутно вопрос по Студии. Есть ли возможность при старте заставить ее СРАЗУ располагать панели инструментов в одну строку? Сейчас у меня это происходит только при загрузке конкретного DBG файла.

[zhevak]

Я обычно по старинке отлаживаю -- вывожу в ЮАРТ все, что меня интересует, и смотрю это на компе.
Отладочную инфу кладу в небольшой буфер, несколько десятков байт, откуда ее ЮАРТ вынимает и передает в комп. Поскольку ЮАРТ работает по прерываниям, то процесс передачи инфы практически не требует времени, т.е почти никак не сказывается на работе софта.

Понятно, что для того, что бы получить вывод отладочной инфы нужно написать соответствующий кусок проги. Дак ведь и это тоже не проблема! Этот кусок уже написан. Написан один раз и реально кочует с одного контроллера на другой с минимальными переделками. В процессе отладки, в нужной точке программы, я просто вызываю функцию debug() с аргуметом того, что хотелось бы увидеть. Понятно что каждый раз приходится переносить debug() в новое место. Но ведь время прошивки во флэшь новой версии занимает секунды. Ресурс флеши, конечно, вырабатывается... но, господа! Поделите стоимость микроконтроллера на гарантированное количество циклов стирания/записи, и вы поймете, что разговор-то ни о чем!

Это была преамбула. А амбула -- вот она. Ну есть у меня этот Драгон, ну и что с того? Лежит он сейчас на столе, и лапки к верху. (Не потому, что он издох. Хотя и это было, как многих. Там мелкосхему нужно выпаять, да проводок вместо нее запаять -- вот и весь ремонт!) Я сейчас занимаюсь одним проектом на меге256-ой. А драгон, оказывается, не умеет работать с такими кристаллами: ни запрограммировать, ни отдебажить.

Но самое-то печальное, я кажись понял, почему он стоит так дешево! С одной стороны его использование ограничено 32 КБайтами флеша в АВРах, а с другой -- самими-же микроконтроллерами, т.е. не все АВРки поддерживают ЖИТАГ. Иначе говоря, разнообразие поддерживаемых Драгоном типов не очень большое.

Вот и получается, что таньку2313 я дебажу по ЮАРТУ, мегу8 -- опять по ЮАРТУ, и мегу256... уже говорил. А других типов АВР я как-то в последнее время не использовал. Не доводилось. Т.е. как-то он (драгон) у меня не попер. Но может только у меня А может это временное явление. Не знаю, не знаю. По крайней мере, я честно сказал какая тенденция у меня наблюдается.

А за идею сохранять отладочную инфу в ЕЕПРОМе -- спасибо. Как это я сам не догадался!? Идея лежала вообще на поверхности. Сохранил, а потом программатором обратно считал... хм