LPC40xx header, обнаружил что нету Опции

[KRS]

у меня В IAR 7.4 обнаружилось отсутствие файла inc/nxp/iolpc4074.h
вернее там вообще по 40xx ничего нету

[zltigo]

у меня В IAR 7.4 обнаружилось отсутствие файла inc/nxp/iolpc4074.h
вернее там вообще по 40xx ничего нету

Ну ядро поддерживается, а остальное можно написать, или пользовать всякую всячину с LPCWARE
https://www.lpcware.com/content/nxpfile/lpc...er-library-keil

[KRS]

Ну ядро поддерживается,

да не только ядро IAR знает этот чип "в лицо"

просто похоже начали выталкивать на CMSIS, но все равно странно что для хидеров надо examples скачивать там есть LPC4000CMSIS

А вот для 43xx хидеры есть.

[zltigo]

А вот для 43xx хидеры есть.

Лично я хидеры от производителя компиляторов использую разве только в качестве болванки. Не устраивают проталкиваемые ими "внутрифирменные" навороты и нередки и отступления в аббревиатурах от того, что в документации производителя. Так-что как правило сам спокойно, вдумчиво по мере изучения чипа. Иногда использую и собственные альтернативные алиасики - для совместимости с предыдущими вариантами. А то и производитель часто фигней страдает меняя аббревиатуры от семейства к семейству.

да не только ядро IAR знает этот чип "в лицо"

Типа еще скрипт-болванка линкера есть? Так все равно его писать/менять для чего-либо кроме "Hello World!".

[jcxz]

Лично я хидеры от производителя компиляторов использую разве только в качестве болванки. Не устраивают проталкиваемые ими "внутрифирменные" навороты и нередки и отступления в аббревиатурах от того, что в документации производителя. Так-что как правило сам спокойно, вдумчиво по мере изучения чипа. Иногда использую и собственные альтернативные алиасики - для совместимости с предыдущими вариантами. А то и производитель часто фигней страдает меняя аббревиатуры от семейства к семейству.

Аналогично!
Я оттуда максимум - таблицу распределения входов для NVIC вытаскиваю.
Всё остальное - описываю сам, структурами, дефайнами по даташиту.
Может и используемых мной МК нету в хидерах IAR - я и не знаю даже
Поддержка контроллера IAR-ом мне нужна только чтобы JTAG-ом к нему коннектиться, ибо свои файлы конфигурации отладчика писать ещё не научился

[zltigo]

Поддержка контроллера IAR-ом мне нужна только чтобы JTAG-ом к нему коннектиться, ибо свои файлы конфигурации отладчика писать ещё не научился

Раз уж пошел такой разговор, а когда по Вашему мнению, отладчик именно необходим? Ну и как отладчик Вам помогает, когда надо вылавливать РЕАЛЬНЫЕ ошибки возникающие а РЕАЛЬНЫХ условиях эксплуатации в реальном окружении?

[jcxz]

Раз уж пошел такой разговор, а когда по Вашему мнению, отладчик именно необходим? Ну и как отладчик Вам помогает, когда надо вылавливать РЕАЛЬНЫЕ ошибки возникающие а РЕАЛЬНЫХ условиях эксплуатации в реальном окружении?

Думаю Вы знаете как работает отладчик и что он позволяет. Поэтому Ваш вопрос не понятен.

[zltigo]

Думаю Вы знаете как работает отладчик и что он позволяет. Поэтому Ваш вопрос не понятен.

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

[jcxz]

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

Всегда можно обойтись без, и обходились мы раньше, но сложность ПО растёт, соответственно и время поиска багов в нём увеличивается. JTAG позволяет во многих случаях (не всегда конечно) хоть сколько-то сократить это время. А время - деньги. И если это время можно сократить, то почему этого не сделать?

[zltigo]

Всегда можно обойтись без, и обходились мы раньше, но сложность ПО растёт, соответственно и время поиска багов в нём увеличивается. JTAG позволяет во многих случаях (не всегда конечно) хоть сколько-то сократить это время. А время - деньги. И если это время можно сократить, то почему этого не сделать?

В том-то и проблема, что именно с ростом СЛОЖНОСТИ изделия, растет и слжность ошибок в нем, и полезность отладчика резко стремится к нулю. Для изделия, условно, "нажал кнопку- загорелась лампочка" все изумительно - берем отладчик, повторяем нажатие кнопки 100500 раз и находим почему (например "программист" думал, что 2+2=5 ) не загорелась. Для изделия, котрое взаимодействует по каким-то интрефейсам и протоколам с изделиями других производителей (а именно таого типа изделие похоже на сложное), полезность отладчика равна ровно 0. Ну не поможет он никак найти ошибку в какой-нибудь ветке отрабатывающей ошибки протокола взаимодействия с неведомым чужим изделием, которая вылезает на объекте несколько раз в год. Для поиска такого, нужны другие механизмы, и, если они построены, то и для поиска ошибки в "нажал кнопку - загорелась лампочка" они тоже годятся. Тем более, если уже человек умеет делать сложные вещи, то в "нажал кнопку" он вообще ошибок не сделает, а если еще и в школе учился, а не сразу стал "программистом", то и ошибок "2+2=5" не сделает, а если и сделает, то опечатку и сооответственно просто ее увидит глазами.

[jcxz]

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

Странные какие-то рассуждения....
Следуя Вашей логике, если скажем имеем например какой-нить светильник, то мультиметр вполне поможет в его ремонте, но с увеличением количества лампочек - он всё менее полезен в ремонте, а если это уже гирлянда со всякими эффектами - то пользы от мультиметра почти никакой, а для контроллера, который ей управляет так и совсем 0. С чего бы это??? Даже в самом сложном, самом микропроцессорном контроллере управления гирляндой, вполне себе можно прозвонить какие-то контакты, проверить питающие напряжения. Это не говорит о том, что он полносстью заменяет осциллограф, но всему своё место.
Так же и с отладчиками. Почему Вы решили, что если кто-то пользуется эмулятором, то он не использует другие средства отладки???

Тем более, если уже человек умеет делать сложные вещи, то в "нажал кнопку" он вообще ошибок не сделает, а если еще и в школе учился, а не сразу стал "программистом", то и ошибок "2+2=5" не сделает, а если и сделает, то опечатку и сооответственно просто ее увидит глазами.

Да ну!!!? Правда что-ли?? И в нескольких тысячах строках текста сразу увидите?? А почему не увидели ошибку уже в первом предложении, которое написали?
А Вы всегда АБСОЛЮТНО внимательны когда пишете ПО? Вас АБСОЛЮТНО никто и ничто не может отвлечь?
Имхо, по моему опыту, большинство ошибок, которые делаются, делаются не потому что плохо учились, а потому что когда писал эту строчку, кто-то к тебе подошёл и отвлёк или что-то отвлекло.
И например у меня, это ~ 95% всех ошибок.
И эмулятор как раз очень хорошо помогает в быстром поиске большинства таких ошибок.

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

PS: Если Вы вдруг обнаруживаете, что какая-то из десятка задач в Вашем устройстве портит некую Вашу переменную, то, чтобы обнаружить виновника, можно конечно вынести её в отдельную область памяти и закрыть эту область встроенной в процессор защитой памяти, чтобы отловить исключение; можно написать ISR от высокочастотного прерывания таймера, в котором контролировать эту переменную и момент её модификации.
А можно просто поставить watchpoint в отладчике, это сэкономит массу времени, хотя и не гарантированно сработает (как впрочем и другие способы).

[zltigo]

Следуя Вашей логике, если скажем имеем например какой-нить светильник, то мультиметр вполне поможет в его ремонте, но с увеличением количества лампочек

Прнятно. Уровень сложности может измеряться, только количеством лампочек. Ладно, попробую обьяснить "в лампочках". Лампочек в светильнике стало так много, что они не поместились в один светильник и даже на один континет. Пришлось думать, как организовать управление.

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

Читайте ВНИМАТЕЛЬНЕЕ. В Вашей терминологии, для решения всех пробоем требуется "осциллограф" и он соответственно сделан. Зачем поосле этого "лампочка с батарейкой"?

Почему Вы решили, что если кто-то пользуется эмулятором, то он не использует другие средства отладки???

Про эмулятор я вообше ничего ни думал, ни решал, ни писал.

Да ну!!!? Правда что-ли?? И в нескольких тысячах строках текста сразу увидите??

Не пишите несколько тысяч строк зараз и не придется искать ошибки в нескольких тысячах. Пишите десятками строк и, уверен, что смодете и прочитать и найти ошибку и улучшить.

А почему не увидели ошибку уже в первом предложении, которое написали?

Потому, что это:
1) опечатка, а не ошибка
2) текст не компилировался
3) и даже не перечитывался, поскольку на русском языке я пишу раз в 100 быстрее, чем на Си.

А Вы всегда АБСОЛЮТНО внимательны когда пишете ПО? Вас АБСОЛЮТНО никто и ничто не может отвлечь?

Может.

Имхо, по моему опыту, большинство ошибок, которые делаются, делаются не потому что плохо учились, а потому что когда писал эту строчку, кто-то к тебе подошёл и отвлёк или что-то отвлекло.
И например у меня, это ~ 95% всех ошибок.

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

И эмулятор как раз очень хорошо помогает в быстром поиске большинства таких ошибок.

А перечитать написанное не помогает

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

Могу Вас заверить, что для действительно сложных систем, а не для торшеров с лампочками, тесты в тысячи раз сложнее тестируемого объекта. Я большую часть жизни занимался телекомуникационным оборудованим. Посмотрите, например, что такое SS7. Потом буду готов буду выслушать, что Вы беретесь написать протоколтестер. Кстати, никакого колхоза в работе не бвло - протокол тестеры покупались, использовались, поддерживалась подписка, ВЫЛАВЛИВАЛИСЬ ИХ ОШИБКИ. Но все не покрывали и НЕ ПОКРОЮТ никогда. Просто сложность фантастическая получается.

или когда разработчик не считает нужным продумывать все возможные ветви алгоритма при всех возможных вх. аргументах и т.д.

Продумывать - считает. И писать считает нужным. Проверить сложно. И такой проверке никакой отладчик не поможет, ибо дело в многообразии воздействий. А отладчик для явных, поыторяющихся хоть 100500 раз неправильных ситуаций.
Так-что для очень большого количества всяких ошибочных веток, рецепт хорошей работы - ТОЛЬКО хорошо писать и понимать написанное, а не смотреть а результат отладчиками.

Если Вы вдруг обнаруживаете, что какая-то из десятка задач в Вашем устройстве портит некую Вашу переменную

Изумительно. Если я уже узнал, что проблема в том, что именно эта переменная портится, то это уже финиш решения проблемы поиска ошибки, а не ее начало. Ну ладно, пусть мне было божье проведение об этом факте

, то, чтобы обнаружить виновника, можно конечно вынести её в отдельную область памяти и закрыть эту область встроенной в процессор защитой памяти, чтобы отловить исключение; можно написать ISR от высокочастотного прерывания таймера, в котором контролировать эту переменную и момент её модификации.
А можно просто поставить watchpoint в отладчике, это сэкономит массу времени

Значит к каждому устройству находящемуся в эксплуатации, надо приложить компьютер, одладчик, софт отладчика, проект, исходники и обученого человека. Про условия эксплуатации, где все это принципиально невозможно вообще не говорю.
Значит таки должен быть механизм отлавливания ошибок в процессе экспуатации БЕЗ всего это счастья и САМОЕ ГЛАВНОЕ без божественного провидения дарующего свыше знание, что именно за этой переменной надо следить.
Если такой механизм и умение им владеть, есть, то роль отладчика стремится к нулю.
Проблема только в том , что уметь пользоваться тяжелее, чем мышкой c кнопкой. Но и возможности другие .

[jcxz]

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

И в чём финиш заключается? Вы удалите весь проект и начнёте его заново??
Финиш обычно случается когда находится виновник, который портит эту переменную.
Вот скажите, со всем Вашим опытом в супер-пупер навороченных отладочных средствах - как Вы будете искать источник такого поведения??
И не надо баек про внимательное изучение строк кода. Может быть в Ваших проектах состоящих из десятка строк это возможно, но, поверьте, бывают другие проекты, в несколько тысяч и десятков тысяч строк, которые к тому же написаны (и правлены) несколькими людьми.

Три минуты могу держать в голове. Если больше трех минут то подошедший посылается подальше, либо я спокойно перечитываю написанное.
А перечитать написанное не помогает

Вы счастливый человек, раз у Вас только такие простые задачи, что чтобы восстановить ход мыслей, достаточно несколько строк перечитать!
Я когда такие простые вещи пишу, тоже поверите-ли, отладчиком практически не пользуюсь. Даже если несколько сот строк кода - всё обычно практически сразу начинает работать как надо.
А представьте, если для написания кода Вам надо держать в голове несколько определений сложных типов данных (структур), распределения и алгоритма работы структур хранения данных в нескольких чипах, если процесс, который сейчас описываете, состоит из взаимодействия нескольких задач и ISR-ов (временные соотношения между которыми нужно держать в голове), с несколькими десятками рабочих переменных и когда пишешь текущую строку исходника, ещё держишь в голове, что нужно будет внести такие-то и такие-то модификации в такое-то и такое-то место, поправить ту структуру и убавить кол-во элементов массива в другой, изменить значение того enum-а и увеличить размерность этой переменной.
Когда в голове целый комплексный ворох информации. И чтобы потом это восстановить надо много чего просмотреть и многое ещё вспомнить ибо пока нигде не записано, а только в планах, в голове.
И поверьте - по кусочкам такой процесс бывает невозможно отладить, чтобы хоть что-то заработало надо сначала много написать.
А к вам в отдел набрали кучку студентов с глупыми вопросами или рядом сидящим коллегам, лень самим разбираться в чём-то и они считают что гораздо проще отвлечь тебя. И так каждые 15-20 минут.
После такого бывает такие ошибки вылавливаешь, самому поверить трудно как такое мог написать.

Развели тут срач ну пустом месте. Выяснилось, что системы сильно разные бывают (кто бы мог подумать?!). Соответственно, подходящие методы разработки тоже разные! Капитан Очевидность нервно курит в сторонке.

Согласен с Вами.
Уважаемый zltigo пытается доказать, что пользоваться отладчиком - моветон. И что те, кто им пользуется только от него полностью зависят как наркоманы и ничего другого не умеют делать и сами думать не умеют. Не понимаю почему, если не хочешь пользоваться - не пользуйся на здоровье.

[zltigo]

И в чём финиш заключается? Вы удалите весь проект и начнёте его заново??

Дураком не прикидывайтесь. Четко написано и даже выделено шрифом.

Вот скажите, со всем Вашим опытом в супер-пупер навороченных отладочных средствах - как Вы будете искать источник такого поведения??

В основом головой. Чудес не бывает.

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

Сразу, простите, видно, что именно Ваши проекты "из десяток строчек" , но щеки надувать хочется . Для описаной Вами ситуации БОЛЬШОГО ПРОЕКТА в которой Вы явно сами ни разу не бывали, иначе-бы понимали, что даже узнав чудесным образом "переменную" которую кто-то портит и воспользовавшись чудесным отладчиком и узнав адрес команды, которая портит, Вы на самом деле должны сделать самое сложное - исправить ошибку в большом чужом коде. Исправить так, что-бы это было именно исправление, а не заплатка, которая вылезет боком в другом месте. Отладчики, кстати, очень многих начинаюих провоцируют на заплаточный стиль написания - ой! нолик получился, сейчас сделаем +1 и будет хорошо.

А представьте, если для написания кода Вам надо держать в голове несколько определений сложных типов данных (структур), распределения и алгоритма работы структур хранения данных в нескольких чипах, если процесс, который сейчас описываете, состоит из взаимодействия нескольких задач и ISR-ов (временные соотношения между которыми нужно держать в голове), с несколькими десятками рабочих переменных и когда пишешь текущую строку исходника, ещё держишь в голове, что нужно будет внести такие-то и такие-то модификации в такое-то и такое-то место, поправить ту структуру и убавить кол-во элементов массива в другой, изменить значение того enum-а и увеличить размерность этой переменной.
Когда в голове целый комплексный ворох информации. И чтобы потом это восстановить надо много чего просмотреть и многое ещё вспомнить ибо пока нигде не записано, а только в планах, в голове.

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

Уважаемый zltigo пытается доказать, что пользоваться отладчиком - моветон.

Отнюдь нет. Как последний шанс, котороый должен быть - обязательно. Как средство разборки с новой платформой - тоже потенциально весьма желателен. По этой причине все средства отладки имею. Хотя есть интересный момент - уже много лет на готовом железе интерфейс для отладчика не выводится (если заливка фирмвари возможна без него). То есть использование отладчика де-факто ограничивается демобордой.

И что те, кто им пользуется только от него полностью зависят как наркоманы и ничего другого не умеют делать и сами думать не умеют.

Не все, так однозначно. Чаще более мягкий случай - типа нормальный человек, но выпил и начал гнать код из под отладчика . Протрезвеет и опять нормальный . Хотя даже не так - памперсы это хорошо, сухо и комфортно, но не всегда удобно, прилично и возможно их носить. Но самое ГЛАВНОЕ, что его использование решает только часть проблем, причем достаточно небольшую в действительно больших проектах. Отчего, наблюдаю, что если вырабатывается привычка "ни шагу без отладчика", то при росте сложности программ доходит до шокового эффекта - отладчик не помог, что ни правится, все ведет к новым проблемам... Остановится и подумать уже невозможно - только "трясти надо" .

Не понимаю почему, если не хочешь пользоваться - не пользуйся на здоровье.

Я и не пользуюсь и перечислил почему. Если все это не Ваш случай, то тогда и не должно Вас все это волновать. Не читайте и пользуйтесь.

[jcxz]

Дураком не прикидывайтесь. Четко написано и даже выделено шрифом.

Опять ушли от конкретного ответа, скрывшись за кучей демагогии.
Так и не ответили как именно знание, что данная переменная портится поможет в устранении проблемы.
Как найдёте причину кто её портит???? Вы вообще отлаживали когда-нить что-то, если не можете ответить на конкретный вопрос или только теоретизируете?

Отладчики, кстати, очень многих начинаюих провоцируют на заплаточный стиль написания - ой! нолик получился, сейчас сделаем +1 и будет хорошо.

Фантазии - вещь хорошая при написании книг.

Много лет назад я писал и отлаживал без отладчика. И это было на TMS320VC5502 почти полностью на ассемблере (это очень далеко не простейшая ARM-архитектура). Только светодиоды и вывод в лог (UART).
И ничего - доводил до конечного продукта и не раз. Только времени на это тратилась уйма. Тогда было можно, сейчас - жалко времени.
А стиль программирование и факт пользования отладчиком - не имеют никакой связи сколько не утверждайте обратное.

[zltigo]

Опять ушли от конкретного ответа, скрывшись за кучей демагогии.
Так и не ответили как именно знание, что данная переменная портится поможет в устранении проблемы.
Как найдёте причину кто её портит???? Вы вообще отлаживали когда-нить что-то, если не можете ответить на конкретный вопрос или только теоретизируете?

Вообще-то отвечал. Только видимо ответ показался Вам общим . На самом деле вопрос Вами поставлен, о чем уже писал, абсолютно некорректно, для реальной системы - ну НЕ известно, что портится именно эта переменная. Поиск моих ошибок в РЕАЛЬНОЙ жизни, начинался обычно так - что-то изменилось в окружающем мире и Вы, набрав телефонный номер в Гондурасе не смогли дозвоиться до желаемого абонента. Вопрос куда втыкать отладчик в телефонную станцию с оборудованим размещенном в нескольких стативах и где искать "переменную которую испортили" ? Так-что все начинается с трассирвки вызова, с просмотра логов, активизации дополнительных уровней отладочной печати. Все это закладывается уже на этапе разработки и служит и средстовом пошагово поднимать систему.
А "кто-то портит переменную" это уже много много позже, не говоря уже о том, что сама ситуация с "портит переменную" практически нереальная с тех пор, как программирование в кодах умерло, а в АSM минимизировалось. На чужие пременные залезть уже можно только специально, ну или при грубейшей ошибке перпахав много памяти. Ну выяснили Вы отладчиком, что у Вас перепахан стек (что явно стант ясным и без отдадчика по вылету), а не какой-то вырожденно-ПАРКЕТНЫЙ случай аккуратно измения одной переменной. Ну и?

Много лет назад я писал и отлаживал без отладчика. И это было на TMS320VC5502 почти полностью на ассемблере (это очень далеко не простейшая ARM-архитектура). Только светодиоды и вывод в лог (UART).

А я начинал еще на первых советских, наших рижских, "ренатах" c ошибками в ядре. DSP это на самом деле несколько другая жизнь (натягивие линуксов на все, что попало не рассматриваем), то, что для них пишется это на 90% процентов работа с математическими моделями и симуляторами. Ума не приложу к чему-бы мне был отладчик для разбирательсва с алгоритмом фильтра или кодека. Ну а остальное можно и через UART.

А стиль программирование и факт пользования отладчиком - не имеют никакой связи сколько не утверждайте обратное.

Увы, имеют. Для embedded это как-бы еще немножко замазано, тем более если Вы на свой личный опыт опираетесь, а оглянитесь на PC писателей во всяких "студиях" на которых уже не одно поколение выросло. Ну чисто дети уверенные, что без отладчика вообще программирования не бывает. Ну и результат такого массового похода в программирование виден сразу, даже не читая кода .

[jcxz]

А "кто-то портит переменную" это уже много много позже, не говоря уже о том, что сама ситуация с "портит переменную" практически нереальная с тех пор, как программирование в кодах умерло, а в АSM минимизировалось. На чужие пременные залезть уже можно только специально, ну или при грубейшей ошибке перпахав много памяти. Ну выяснили Вы отладчиком, что у Вас перепахан стек (что явно стант ясным и без отдадчика по вылету), а не какой-то вырожденно-ПАРКЕТНЫЙ случай аккуратно измения одной переменной. Ну и?

Нереальная??? А указатели уже отменили? А приведение типов? А массивы, с индексами выходящими за границы? Да хотя-бы то же самое переполнение стека?
Это всё паркетные случаи? Или Вы всё-таки на яве пишете, а не на си?
И как станет ясно по вылету? Вылет произошёл в одном месте системы (из-за разрушения переменной, а переполнение - совсем в другом, где в переполненном стеке попортился лежавший там указатель, запись по которому и разрушила чужую переменную).
И Ваше "писать по 10 строк, потом отлаживать написанное" здесь не пройдёт, так как когда этот кривой кусок писался и отлаживался, эта запись по случайному адресу не попадала на важные данные, а после добавления кода через N месяцев, она стала портить важные данные.

DSP это на самом деле несколько другая жизнь (натягивие линуксов на все, что попало не рассматриваем), то, что для них пишется это на 90% процентов работа с математическими моделями и симуляторами. Ума не приложу к чему-бы мне был отладчик для разбирательсва с алгоритмом фильтра или кодека. Ну а остальное можно и через UART.

Например: какие-то команды процессора описаны в доке поверхностно, так что трудно понять нюансы исполнения (а у C55xx очень богатая и сложная система команд); либо неполное или запутанное описание периферии (это касательно любого МК) - в таких случаях JTAG очень часто помогает быстро разобраться, быстро глянув на поведение какого-либо бита при определённом воздействии. И воздействие это можно прямо в отладчике применить (меняя данные в отладчике), быстро, не перекомпиляя каждый раз код и не перезаливая его.
И это тоже никакой не паркетный случай, а вполне жизненный. Если конечно сидеть всё время на одном МК, обсосанном вдоль и поперёк, а не осваивать новый МК под каждый новый проект, то тогда это менее актуально.
Не спорю - всё можно отладить и через UART, можно даже одним светодиодом. Но многие вещи гораздо быстрее удобнее - JTAG-ом.
И не вижу смысла так не делать, а заниматься мазохизмом.