Вот странная фигня выходит....
Те, кто пробовали мангустин, жаренный на петиаровом масле, утверждают, что это вкусный десерт.
А те, кто не пробовал - говорят, фигня эти ваши мангустины... Не нужны они нам, вот у нас есть вареная картоха - и она нажористая....
Хотя вареная картоха ни разу не десерт.
Как говорил МихалМихалыч - Давайте спорить о вкусе устриц и кокосовых орехов с теми кто их ел.
Прошу прощения за оффтоп.
Оба способа отладки - и внутрисхемная, и вывод отладочной информации в порт - имеют место быть.
Но они не заменяют друг друга. Скорее всего, дополняют и могут применяться в разных случаях.
Просто в большинстве случаев внутрисхемная отладка удобнее и информативнее.
Но к сожалению, в модный современный алгоритм-билдер внутрисхемную отладку, увы, не завезли... Только команду логарифма....
И, кстати, название современной программы для написания программ на ассемблере для AVR нам так и не сказали....
Мангустинов в петиаровом масле не пробовал, это точно. Как-то не задалось у меня с мангустинами…
А пошаговой отладкой пользовался, она ведь есть в симуляторе.
Программа запускается в режиме симулятора. В любом месте программы можно поставить точку старта, а затем шагать. Если интересующее место находится далеко от места старта, можно поставить точку финиша. Тогда одним кликом можно пройти до финиша и затем шагать.
Такая отладка удобна, вопросов нет, но только для процессов внутри МК.
По моим представлениям, это плохо подходит для реальной работы МК с внешними устройствами.
Кроме опасности аварии могут происходить ошибки из-за несоблюдения временных соотношений. Скажем, центральный МК начал обмен с периферийным МК какого-нибудь блока, например, измерителя. Вы шагаете медленно, измеритель не дождался ответа и ушёл.
Центральный МК тоже не получил правильного ответа и выдал сообщение, что измеритель неисправен. Можно впустую потратить много времени на поиски ошибки в измерителе, а она возникла из-за работы вашего отладчика.
В связи с такими проблемами решил, что реализация пошаговой отладки при реальной работе не имеет смысла.
С моим отладчиком тоже возникали такие ошибки, но крайне редко, ведь время задержки – несколько микросекунд. Да и они легко определялись. Запрограммировал с новыми командами отладки – возникла новая ошибка, убрал эти команды, ошибка исчезла. Всё ясно, влез туда, куда не надо.
В новых МК АВР через один вывод программирования МК можно просматривать и изменять SRAM. Тогда можно в интересующем месте выбросить переменную в SRAM, а в свободном окне считать её. Чтобы переменная не затёрлась, придётся, наверно, притормозить МК. Скорее всего, можно сделать вариант без «притормаживания», надо будет разбираться.
У меня программа никакого отношения к алгоритм-билдеру не имеет.
И в ней есть не только логарифм, хотя пока маловато для современной программы. Да и программирование, можно сказать, простое и стандартное, без «стрелочек».
Приведу пример.
Пусть не про AVR, но это не существенно.
В ARM-ах нет EEPROM-а. Его эмулируют в программном флеше…
Сделать это через порт, сами понимаете, принципиально невозможно, ибо ПРОГРАММА НЕ РАБОТОСПОСОБНА.
«ПРОГРАММА НЕ РАБОТОСПОСОБНА» - стало быть, нет выброса переменной в дебаггер, это существенная информация.
Насколько понял, в вашем примере все процессы происходят в МК без работы с внешними устройствами. Вообще-то в этом случае удобно использовать симулятор, у меня он тоже есть. Но можно и отладку в реальном времени.
Скажем, в начале каждой записи в EEPROM выбрасывать в дебаггер номер страницы или что ещё есть. Быстро выяснится, что МК зависает при записи последней страницы. Дальше найти ошибку несложно.
Могло случиться, что вы не знаете, отчего зависает МК. Включили – и через некоторое время он завис. Тогда можно расставить несколько команд отладчика по ходу программы. Далее видно, МК точку №4 прошёл, в точку №5 не пришёл, МК завис. Расставили новые команды после точки №4. Несколько итераций – и вы вышли на дефектную команду записи в EEPROM.
Можно сказать, это типовая ошибка, с помощью дебаггера легко отыскивается.