Какая разница с какой скоростью выводятся данные в ПО? Хоть гигабит в секунду. На экране они появятся неизвестно когда. Просто потому, что ПО в винде или линуксе не является реальным временем. Но и это ерунда. Человек не в состоянии считать с экрана быстро меняющиеся данные. Ну бежит скролл по экрану и что с ним делать?
Похоже, вы не поняли принцип отладки.
Количество выбрасываемых в отладчик байтов ограничено. В принципе, максимальное число ограничено размером свободного места в памяти SRAM в МК отладчика, на практике достаточно 100 байт. После заполнения этого объёма приём прекращается, останавливается и скролл на экране компьютера. А дальше можно спокойно анализировать данные на экране компьютера.
Компьютер используется, фактически, в качестве дисплея.
JTAG просто сканирует заданные участки памяти с целью вывода на экран среды разработки. Есть желание наблюдать сечение - создавайте буфер в точке сечения и наблюдайте за ним.
При работе с JTAG мне неясно следующее.
Скажем, надо посмотреть несколько 4-байтных переменных. Пока JTAG выводит один байт первой переменной, остальные байты этой переменной и следующая переменная могут измениться, ведь МК не остановлен. Будут получены неправильные данные.
Можно приостановить МК или забросить переменные в буфер. Но это модификация кода и компиляция с прошивкой.
В моей отладке всё проще, на время вывода переменных МК останавливается.
Скорость вывода не имеет никакого значения, поскольку сам интерфейс при выводе работает автономно. Поэтому, что УАРТ, что SPI - без разницы. Любой интерфейс будет занят и будет требовать кусок кода.
В моей отладке USART и SPI не используются. При отладке лучше всего не использовать никакие периферийные устройства, поскольку они могут быть заняты основной программой.
Вывод байтов в отладчик делается программно, при этом МК останавливается. Чем меньше время остановки, тем лучше, меньше вероятность искажения работы программы.
Обычно для расчёта функции используется линейная аппроксимация, а при этом используется массив чисел.
Это чушь. Но дело даже не в этом. Один раз написав функцию, далее ее можно просто копипастить из проекта в проект.
Аппроксимация функции отрезками линий – это не чушь. Похоже, вы никогда не делали этого.
Запись во флеш - это достаточно длинный ассемблерный код. Причем с ограничениями. В подавляющем количестве платформ не симулируется.
Понятно, что запись во флеш – это не одна ассемблерная команда.
Но остальные команды точно симулируются, а вот симулируется ли команда SPM, скажем, в старых программах – вопрос. Я не вижу проблем с симуляцией этой команды, так что, вполне возможно, вашу ошибку можно было просто найти в хорошем симуляторе.
Ошибку нетрудно найти и с помощью дебаггера.
Но вы рассматриваете только ваш случай, а ситуация бывает разной. Скажем, отлаживаемая установка находится в цехе. А туда не всегда есть доступ, то сдача продукции, то ещё чего. В соседнем помещении могут включить испытательное грохочущее оборудование и т.д.
В тихом просторном кабинете отлаживать удобнее.
В симуляторе, которыми пользовался, нет моделей конкретного МК. Симулируются команды ассемблера. Симулятор просто идёт по командам ассемблера, поэтому можно смотреть любой МК.
Потому что на любой чих вам нужно писать хоть и небольшой, но код.
А для двусторонней "отладки" - еще больше кода. Который тоже надо отлаживать.
А для того, что бы остановить программу в любом месте без перекомпиляции проекта и вдумчиво просмотреть все регистры МК, область ОЗУ... еще код писать?
А сможете?
....
а КРАМу не надо ничего писать. Ему достаточно нажать паузу в IDE и смотреть все, что творится в МК. И даже поменять.
Написать строчку вывода переменной в отладчик – несколько секунд, представлять это проблемой несерьёзно.
Я не останавливаю МК, остановка – прощай реальный режим, всерьёз это не рассматриваю.
Я не смотрю, даже вдумчиво, на все регистры МК, зачем на них смотреть.
Точнее, когда начинал изучать МК, с интересом смотрел в симуляторе, как меняются регистры РОН, но это было в далёком прошлом.
Да и в программе почти отсутствуют в явном виде регистры РОН, есть переменные, вот их и смотрю, этого достаточно для быстрой отладки.
Ваше мнение об отладке «по двум проводкам» было бы объективным, если бы вы поработали с такой отладкой. Вспомнилось про мангустины…