Время от времени слышатся просьбы о помощи в отладке программы. Ниже предлагается простой способ отладки через уарт путём внесения отладочной информации в отлаживаемую программу, т.е. по мере необходимости в исследуемые ветви отлаживаемого кода вставляются две строчки с определённым текстом, например, таким

Код

         rcall     debug
         .db       "some datum to be sent",0

или таким

Код

         rcall     debug
         .db       "первая точка пройдена",0

Программа вывода отладочной информации имеет следующий вид

Код

debug:   pop       zh
         pop       zl
         lsl       zl
         rol       zh
deb1:    lpm       temp,z+
         tst       temp
         brne      deb2
         lsr       zh
         ror       zl
         ijmp
deb2:    sbis      ucsr0a,udre0
         rjmp      deb2
         out       udr0,temp
         rjmp      deb1

и занимает всего 14 слов кода.

Интересно бы пообсуждать данный метод и узнать заодно, кто-нибудь пользуется подобным способом отладки?

Я, например, только таким способом и пользуюсь

Приведенный фрагмент компактен и симпатичен, но не обеспечивает сохранение регистров, да и UART UARTу рознь, так что предпочитаю все сохранить, пусть даже код существенно более раздутый получается, и воспользоваться "полноценной" программой передачи (которая используется и другими компонентами). Плюс к отладочной пропечатке по точкам практически всегда использую hex-пропечатку того, чего надо, на уровне байтов, регистров, а то и блока данных в формате hex/ascii.

Приведенный пример с вызовом и параметрами в виде констант вслед за ним еще очень удобен при систематической загрузке регистров какой-нибудь периферии или собственных аккумуляторов или еще чего, не надо кучи ldi и lpm, результат компактнее и нагляднее (и пусть в меня не бросают камнями апологеты ЯВУ).

А еще для отладки оказалось весьма удобным использовать бутер, который принимает через UART непосредственно .hex, и перепрограммирует программную память прямо в терминале, по простому копированию. Но тут надо использовать либо xon/xoff, либо (что особенно удобно в случае USB/COM) аппаратное управление потоком. 921600 и "со свистом"... Заодно упрощается жизнь на ноутбуках, где кроме USB и нет ничего. Один раз бутер хоть чем зашить и все... Но, понятное дело, это для более-менее "объемистых" камешков, хоть восьмая мега нужна...

Код можете показать? Интересует как вы сохраняете регистры, и где.

Что касается "полноценной" программы передачи, то тут вопрос, к примеру, вот вы начинающий и как раз хотите освоить приём-передачу "полноценной" программы с кольцевыми буферами и т.п. Что-то не срастается, глаз замылился, вы не видите очевидных вещей...значит, самое время воспользоваться более-менее автономным механизмом отладки.
Тут как-то не врубился, что это - hex-пропечатка?

Это должен был бы быть мой следующий пост(:-(. Похоже, не один я такой прыткий...Покажите кусочек кода, если можно.
А смысл 921600, если пишется 5 мс? Насчёт загрузчика я пока думаю, не решил до конца вопрос. Заманчиво использовать тот-же усап, в принципе, можно всю рам задействовать, но вот что делать, если программа больше объёма рамы?

Я использую похожий метод, когда идет отладка более высокоуровневых функций прибора, и нужно анализировать события и переход между состояниями прибора. Причем передача информации остается и в серийном приборе.
Но для низкоуровневой отладки использую JTAG - на первом этапе (при отладке железа), и потом, при поиске сложных глюков.

Что вы имеете в виду под низкоуровневой отладкой?

Я отлаживаюсь только линейными фрагментами, с известными входными и выходными данными. Если надо - проводится расчёт вручную, но это раз в год или реже.

Не претендуя на оптимальность и компактность:

;----------------------------------------------------------------------
; Программа выдачи сообщений
; Текст сообщения описывается директивами .db непосредственно после
; команды rcall Msg, признаком конца текста является байт 00.
; После выполнения программы управление возвращается на следующую за
; байтом 00 команду. Программа не портит регистры. Для выдачи текста
; используется команда rcall Print.
; Эта версия программы может использоваться только для микроконтроллеров
; с 16-разрядным счетчиком PC !!!
;----------------------------------------------------------------------

Msg:
push temp
push YH ; сохраним
push YL ; рабочие
push ZH ; регистры
push ZL
in YH,SPH ; адрес текущей
in YL,SPL ; позиции стека
ldd ZH,Y+6
ldd ZL,Y+7 ; адрес операнда в памяти
lsl ZL ; адрес для команды lpm
rol ZH
Msg1:
lpm temp,Z+ ; очередной байт
tst temp ; контроль на терминатор
breq Msg2 ; текст закончился
rcall Print ; вывод байта
rjmp Msg1
Msg2:
sbrc ZL,0
adiw ZL,1 ; коррекция для нечетного адреса
lsr ZH ; новый адрес возврата
ror ZL
std Y+6,ZH
std Y+7,ZL ; меняем адрес в стеке
pop ZL
pop ZH
pop YL
pop YH
pop temp
ret



Но передачу-то в первую очередь надо отладить, потому как мало пихать байты в UDR, надо ведь и делители настроить, да и готовность приемника (в случае управления потоком) проверить. Для передачи часто можно и без кольцевых буферов обойтись.


В смысле, вывести на экран hex-значение байта.

Меньше накладные расходы на пересылку. И 5 mS это ведь страница пишется. 64 байта даже в бинарном виде на 115200 передаются столько же, в .hex вдвое дольше. А страницы-то бывают и 128 (лениво смотреть, в старших камнях ведь и того больше, наверное ?) 12 кило кода в mega168 сейчас загружаются две секунды...

А при чем тут объем RAM ? Ну да, если не управлять потоком, то да, надо проглотить все сразу. Но ведь можно и тормознуть (я останавливаюсь после каждой строчки, т.е. нужен буфер на строку).

Это аналог printf() в Си

Странные вы какие-то...

Отладка отладке -- рознь. Одно дело отлаживать код в мелкиих АВРках (tiny13, 15, 26), у которых нет uart, другое дело отлаживать код в крупных АВРках, где полно всяких "вводов/выводов".

Я лично так делаю. Когда код небольшой по размерам или код дожен работать в реальном времени, -- выделяю под отладку 2-3-4 вывода какого-нибудь порта. "Прохождение" проги контролирую изменением состояния соответствующей ноги. Можно ЛЭДом, можно осциллографом. Это так называемый, первый уровень отладки. Он годится лишь для маленьких АВРок и маленьких программ.

Если прога болшая и процессорное время позволяет, то организую отладочный канал на основе uart'а. С частотой особо не заморачиваюсь, делаю 115200. Такую частоту все компы поддерживают, поэтому проблем нет. На вывод организую буфер, не кольцевой, объемом от 10 до 64 байт (когда как). Этого вполне достаточно для того, чтобы вывести изнутри АВРки несколько байт перемненных. По этим байтам можно судить о том, что делает прога. Это -- второй уровень отладки. Обычно я использую этот подход для программ 500-4000 байт для средних АВРок (от tiny2313 до mega8).

Третий уровень. Это отладка с помощью JTAG-отладчитков. Сюда можно также отнести и 1d-отладку, но я с ней не "игрался", поэтому ничего не могу сказать. Итак, этот уровень позволяет не только посмотреть некоторые переменные, но и пройтись по шагам. Понятно, что не всякая АВРка имеет JTAG-интерфейс. Поэтому этот метод подходит только для больших АВРок и больших программ.

Все, что я сказал выше, это не есть какое-то незыблемое правило. Способ отладки зависит от типа АВРки и объема программного кода, от наличия под руками отладочных средств (JTAG-отладчика, конвертора uart -> RS232, -> USB) и желания что-то делать.


Два, маленьких примера. Я сейчас рожаю один проект на mega2561: два uart'а, графический LCD, тетя клава на 20 кнопулек (мышки только вот нет!). Система управления основанная на событиях, реальное время, ... ладно, не буду все рассказывать. Короче, достаточно солидный проект. Так вот, отлаживать его с помощью LED'ов -- невозможно, по моему тут даже и говорить не о чем. Если отладку производить с помощью uart'ов, то они оба заняты самой прогой. Поэтому, быстро и безупречно -- не получится. На других интерфейсах (I2C, SPI) тоже сидя не по одному устройству. Значит, оставется только JTAG. Что я и делаю.

Второй пример, для отладки модуля, упомянутого в первом примере, мне понадобилось сделать маленькую плату на tiny2313. Плата должна была принимать определенные пакеты и отсылать на них ответные. Типа эмулятор периферийного устройства (объекта). Я не умею писать проги без ошибок, поэтому отладка здесь тоже была нужна. Эту плату я отлаживал с помощью "лапко-дерганий" и вывода инфы в uart.

Могу поделиться кодом терминалки примерно на столько же строк ,для полного комплекта.

Я допустим не только вывожу и и через кнопки ,но и решаю ,проезжать или останавливаться ,если остановились куда дальше движемся ,ну между делом заливаю прогу через боотлоадер ,рестартую ,питание отключаю ,короче все в одном флаконе не перетыкая разьем
Вообще это давний способ отладки ,и на мой взгляд наиболее оптимальный для отлова динамических ошибок.

ИМХО вывод длинных строк для отладки - непозволительная роскошь если отлаживается какой-то быстрый алгоритм.

Я в таких случаях использую буфер - массив байт на 50, который заполняю отладочной информацией в критических к времени выполнения участках кода, а потом, когда этот участок кончится выстреливаю в ком-порт все данные из этого буфера.

Я тоже УАРТом отлаживаюсь. Вывод в фоновой программе, обычный 115200. Пользуюсь кольцевым буфером, а уж туда подпрограммы скидывают то, что надо. Все это вывожу на самопальный терминал в виде осциллографа, с прокручиваемым буфером. Скажем, на 1-й канал вывожу флаги, на второй метки или адреса - и сразу видно, куда свалился. Даже не всегда требуется пошаговая прокрутка.
Так же сигналы через фильтры гоняю - принимаю отладочные данные от компа, укладываю их в ячейки ОЗУ фильтра, флагом разрешаю шаг фильтра. Фильтр выкладывает данные в буфер - и на осциллограф. Не знаю, кому как, а мне удобно - сразу отклик видно, шум и помехи можно добавлять всяческие. Главное - сигнал свой и реакция предсказуема. Ну и в конце - проверка реальным сигналом.
Для пользователя УАРТ отключаю, хотя далеко в меню есть флажок для включения.
Тут главное - не запутаться в версиях терминалов-осциллографов...

Подскажите пожалуйста что я делаю не так?
в свою программу вставляю в "нужном" месте код:

далее в пп обработки седующее:

Проверяю в АВРстудии. Как я понимаю в регистр "temp" должны последовательно по команде "lpm" загружатся "1,2,3,4..". На деле же совершенно другие цифры. В чем "неправильность"?!
зы: Mega8515

Самые досадные ошибки - в макросах, которые дергают выводы. Глаз видит, а мозг не понимает.
Низкий уровень - это все, что до запуска ЖКИ, кнопок, интерфейсов, поддержки фоновых процессов.

.include "m8515def.inc"
ldi r16, low(RAMEND)
out SPL,r16
ldi r16, high(RAMEND)
out SPH,r16

rcall debug
.db 1,2,3,4,5,0

nop
nop

debug:
pop zh
pop zl
lsl zl
rol zh
deb1:
lpm r16,z+
tst r16
brne deb1
ijmp

ae_ пасиба! Я писал что "..в свою программу вставляю в "нужном" месте код..." т.е. Инициализация стека уже сделана.
а вот со сдвигом правильно, в точку! только правильней так:

Странно, почему ув. =GM= не написал такой код сразу?! (с добавлением lsr,ror и т.д.) или это подразумеевалось само сабой?!

Не, я забыл вставить, извините, писал по памяти. Для LPM нужна байтовая адресация, а для IJMP - словная.

Для удобства использования поправил в исходном посте (добавил недостающие lsr, ror, lsl, rol). Не ругайте меня сильно(:-).

Несомненно.

Один из возможных вариантов, весьма удобен. В крайнем случае туде можно и после сброса "заглянуть", посмертное вскрытие, так сказать. В реалтаймовых вещах иногда полезно и просто махание лапками, чтобы скопом или логическим пробником посмотреть, светодиод "на борту" тоже может серьезно облегчить работу.

Вставлю и свои 5 коп

Тоже uart, но с прерываниями. В памяти формируется строка, но не ASCIIZ а первый байт = кол-во байтов. Ещё нужен счётчик адреса (1 байт), если нет желания получать строку задом наперёд. Строка формируется в программе, где надо. Когда можно начать отправку, жду UDRE и пишу байт в UDR, например, '@' - "начало сообщения". Дальше оно самО: по прерыванию UDRIE если счётчик+1=длине то выходим; иначе UDR = байт с адреса строки+счётчик. В прерывании TXCIE обнуляем счётчик (на будущее). Здесь не надо ждать, программа выполняется в фоне, прерывания происходят 1 раз на байт и занимают немного времени.

To rx3apf Посмотрел ваш код, неплохо написано, все используемые регистры сохраняются, только немного тяжеловесно из-за этого. А вот эти две инструкции

по большому счёту не нужны, поскольку при чётном числе байт asciz-строки делать ничего не нужно, а при нечётном числе байт в последнем слове asciz-строки будет 0х0000, а это код команды nop. Поэтому в моём варианте и нет коррекции нечётного адреса.

Ещё одно соображение по поводу сохранения регистров. Мне кажется, в фоне должны быть доступны все регистры регистрового файла. Тут главное не дойти до абсурда, например сохранить два регистра, участвующих в сложении, сохранить результат, а затем восстановить оба регистра. Возможно, выбран не самый удачный пример, но смысл наглядно видно. Само собой разумеется, что многое зависит от задачи.

А зачем так долбаться, если можно тупо поставить брякпойнт и, тормознувшись, посмотреть содержимое кишечника впрямую, а не через замочную скажину.
Скажу прямо, я тоже отлаживался через терминалки. Но через ЖТАХ-дебугвирь как-то прямее. ИМХО.

Часто нужна натуральная "реалтаймовость". Для реализации которой сохраненная трасса удобнее. Пропечатка на терминале по ходу дела может помешать, а breakpoint - убить идею на корню.

Случаи, конечно, разные бывают, но на моё ИМХО, сброс строки о 20-30 символов и рилтайм...Хотя по 115200, да если РАМы для "трассы" нет...

Добавлю к тому, что сказал rx3apf. Не все аврки имеют джейтаг или дибагвайе. А если и имеют, то не всякий начинающий программер имеет соответствующий отладчик.

Хм... Я тоже использую вывод отладочной информации в терминал - уж очень это просто и удобно. Правда использую для этого стандартный сишный printf или его модификацию printf_P. Правда совершенно недопустимо делать такой вывод в прерываниях - убедился наступив неоднократно на грабли. Здесь верную мысль подал sla000:
Как я сам до этого не додумался...

Разного рода ICE-отладчикам я не доверяю, вернее не люблю их. Отладить вычислительный алгоритм можно и на комповской программе при помощи обычного сишного компилятора. Так недавно я писал сравнительно большой код для канального уровня ком-порта после чего его перенес на контроллер, внеся небольшие изменения в хидере исходника.

Тем не менее пару раз делал некое подобие пошаговой отладки через терминал:



Потом в нужном месте кода вставляю строчку
на которой исполнение останавливается, ожидая нажатия кнопки на клавиатуре.

Да, это можно делать, только когда код не загроможден другими задачами, и применимость такого метода его крайне узкая. Тем не менее, я так вполне успешно отлаживал генерацию JTAG сигнала с пошаговым его анализом.

Забыли упомянуть о еще одном извращенном туле:
глухо засаженная в 0 ножка INT0 с прерыванием от низкого уровня.
Честный бряк, нагружающий проц, конечно. Но иногда весьма полезно

Если я правильно понимаю, вы имеете в виду пошаговую отладку? А в прерывании выдавать наружу всю требуемую информацию (неважно в ком-порт, или юсб)?

Пошаговая - это по максимуму. Вряд ли кому-то нужна. А вот сравнить точку останова со значением PC в стеке и сделать выдачу - это оно.
P.S. А еще есть условные бряки, и их так обработать удобнее...

Ну понятно, прерывания-то будут на каждом шаге, а уж что выдавать, зависит от желания. А что вы имеете в виду под условными? Откуда брать условия и какие? Самому задавать в прерывании?

Так вот, пока уважаемый, но свирепый =AVR= учит нас выбирать велосипед , представим себе ситуацию, когда разбираться в отладчике невозможно ввиду огромного кода. А у Вас все ОК, кроме того, что где-то подленько сваливается STACK, или какая-л. ячейка памяти живет своей жизнью.
Таким методом пишете поллинг памяти или указателя стека. Обратите внимание на то,приоритет INT0 ISR наивысший. Если же надо залезть в другие ISR, ставите SEI при входе в прерывание.
Единственное неудобство - сохранение контекста.

Я отлаживаю так проги
1 в разных функциях с помощью флагов типа flag |= 1 << 3; выставляю флаги и запускаю программу с брек поинтом в нужной точке программы используя при этом JTAG 2 он пошустрее будит и чего то он мне больше нравится чем 1 ,
2 и в результате у меня идет еще и трассировка программного кода что в 8 разрядных контроллерах большая редкость выявляются сложные ошибки типа мерцающих неисправностей это типа на работе все работает у клиента поставили и раз в четыре дня сбои ну или что то вроде этого, вообще пользуюсь отладочными средствами Атмеля чего и вам желаю - удобно, быстро и с комфортом разработка на микроконтроллерах превращается не в работу а что то типа игры и если есть цифровой осциллограф (я использую veleman 500A генератор и разные считыватели интерфейсов которые вы используете в работе) то все должно быть прекрасно а одними руками головой и паяльником конечно можно сделать устройство на микроконтроллере но это может занять годы это мое мнение не более


Я отлаживаю так проги
1 в разных функциях с помощью флагов типа flag |= 1 << 3; выставляю флаги и запускаю программу с брек поинтом в нужной точке программы используя при этом JTAG 2 он пошустрее будит и чего то он мне больше нравится чем 1 ,
2 и в результате у меня идет еще и трассировка программного кода что в 8 разрядных контроллерах большая редкость выявляются сложные ошибки типа мерцающих неисправностей это типа на работе все работает у клиента поставили и раз в четыре дня сбои ну или что то вроде этого, вообще пользуюсь отладочными средствами Атмеля чего и вам желаю - удобно, быстро и с комфортом разработка на микроконтроллерах превращается не в работу а что то типа игры и если есть цифровой осциллограф (я использую veleman 500A генератор и разные считыватели интерфейсов которые вы используете в работе) то все должно быть прекрасно а одними руками головой и паяльником конечно можно сделать устройство на микроконтроллере но это может занять годы это мое мнение не более