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

так причина лежит в стеке при входе в обработчик исключения: выводите из обработчика 4 байта, открываете листинг и видите, с какой команды улетели. ровно то, что и при отладке, но уже без отладчика. думаю, 3 секунды разницы во времени достижения результата не повлияют на производительность команды из трех ваших коллег... или нет?

Добавлено after 1 minute 50 seconds:
по моему скромному разумению, обработчик исключения именно для этого и нужен! на компьютере так, по крайней мере.

Какого еще тестировщика? Вы вообще о чем?
Отладка кода возможна только в симуляторе МК. Симулятор МК мало того, что тормозной, так он еще и предполагает ДЕТЕРМИНИРОВАННЫЕ входные сигналы. То есть ровно такие сигналы, которые НЕ ВЫЗЫВАЮТ сбойных ситуаций. Это я еще не говорю о проблеме синтеза сигнала для симулятора. Поскольку сигналы у меня далеки от синусоидальных или вообще простых. Ну и в симуляторах далеко не вся периферия имеет место быть моделирована.
Вы в качестве альтернативы нативному железному дебагу предлагаете какие то перректальные методы, которые мало того, что не дают ничего нового против него, так еще и требуют ресурсов как от МК, так и от разработчика.

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

Добавлено after 1 minute 6 seconds:
возможно я от недомыслия предположил, что у вас есть отсемплированные тестовые сигналы, на которых вы баги и ловите... или как вы повторяемость и сходимость результатов гарантируете? я бы поступал именно так.

То есть вы полагаете, что копание в многостраничном листинге вам даст ответ?
Вы попадете только в точку ДЕТЕКЦИИ ошибки. А причину вы не узнаете. Стек испортился совсем в другом месте.

Добавлено after 5 minutes 4 seconds:
Иногда общаются, а иногда нет. А если общаются, то совсем для других целей и в специфичном формате. Зачем делать то, что уже есть и работает без этих извращений?


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

с ДМА не работал, но как-то не верится, что часть кода, ответственную за это нельзя отладить без реальных сигналов "по даташиту". ЦОС отработать без симулятора прямо в винде, из файла читать семплы о обрабатывать алгоритмом. потом отлаженные модули слить воедино и, по моему скромному разумению отладчик НЕОБХОДИМЫМ уже не будет, и разработка медленней не станет...

в чем я заблуждаюсь?

Добавлено after 1 minute 46 seconds:
а зондирующий сигнал, отклик и помехи вы откуда берете? вы отладку делаете в "боевых условиях" или на столе? что-то я совсем не понимаю вашу технологию разработки...

Откуда я возьму эти "семплы"? Из реального массива? Так эти массивы меняются с частотой 150 Гц. И они все время разные.
Мне на каждом отдельно отлаживать код на ПК?
И зачем мне писать код на ПК? У меня есть реальное железо. И почти всегда код обработки взаимодействует с железом в реальном времени. И именно это вызывает проблемы. Отлаживать алгоритм обработки мне не нужно. Там все прозрачно и не вызывает никаких вопросов. Даже если я применяю что то новое, то, тем более, мне нужен реальный сигнал, а не отдельные семплы.
Вы продолжаете плодить ненужные сущности.

Добавлено after 2 minutes 5 seconds:

Из реальной работающей аппаратуры. Зондирующий сигнал создает этот же МК, отклик создает зондируемый объект, помехи я генерирую разными внешними устройствами, коих зоопарк.

однако, очень специфические у вас задачи. а заказчик вам на слово верит, что на вашем зоопарке все работает или у него условия точно такие же, как у вас? по идее должны быть "стандартные" тестовые сигналы, которые и должны убедить, что все работает, как надо...

но если ваши алгоритмы могут упасть в исключение из-за "странного" отклика входного сигнала - что-то не то у вас в консерватории... имхо

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

Задачи не у меня специфические. Специфическим является ваше представление об эмбедде.
Вы программист для ПК и пытаетесь учить жить разработчиков железа и кода для него. Это достаточно смешно выглядит.

В ваших руках видимо - да.
И на этом можно закрыть тему.

Добавлено after 1 minute 50 seconds:
У меня дворник во дворе тоже работает без неё. И чо?

Добавлено after 4 minutes 40 seconds:
Более того: нормально сделанное железо контроллера управления электродвигателем, тоже позволяет останавливать МК без гибели чего-либо.

Добавлено after 7 minutes 18 seconds:
......и видим, что в этом месте (из которого улетели) никакого кода в принципе быть не может. Так как место это находится за пределами любых существующих регионов памяти. А произошло так потому, что исключение - вторичная ошибка, вызванная например переполнением стека и возвратом из п/п по левому адресу. По которому уже и было получено исключение. Или CPU пролетел ещё несколько МБ адресов от адреса возврата, а потом случилось это исключение.
И остановив CPU отладчиком, можно просмотреть все стеки всех задач (и прочие критичные переменные) и найти таким образом причину "улёта".

В общем, подводя итог: те, кто яростно топят за внутрисхемную отладку и говорят, что без нее невозможно жить, просто нагло врут!

А кто говорил что "без неё невозможно жить"? Жить то можно.
...так же, как можно жить в пентхаусе, а можно и на телескопе скамеечке в парке.

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

так это мне простительно, т.к. я вашей темой не владею и делаю только предположения о том, как оно все происходит. а вот почему на мои предположения вы так реагируете - не понятно.
даже и не программист - я любитель полностью и бесповоротно, всё, что я умею, я достиг методом личного самобразования, никто ничему меня не учил (если не считать лекций по бейсику в ВУЗе).
ну, лично я себе это представляю так: берется некое АЦП, записывается РЕАЛЬНЫЙ сигнал с шумами, помехами, искажениями и т.п., если надо - 100500 таких разных записей делается, а потом многократно они воспроизводятся и скармливаются девайсу. в результате проблемы становятся повторяющимися (если они "случайно" возникли на каком-то семпле, повторить можно сколько угодно раз). демонстрация прибора, верно реагирующего на эти записи убедит любого клиента в работоспособности прибора. наличие таких тестовых записей позволит отлаживать комфортнее и т.д.
это вот такое мое дилетантское понимание.

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

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

я вам ранее писал о том, как отладку сигналами понимаю я. если вы записали недетерминированный сигнал, то его "симулятор" и прожуёт. притом что я говорил не о симуляторе, а о запуске вашего ембед-кода на PC под отладчиком винды в "песочнице", которая кормит его семплами из файла. думаю, компьютерная программа обработает ваши задачи раз в 10 быстрее, чем сам МК, а если код на Си написан корректно, разницы в его работе быть не должно. в теории.

угу. я фантастику очень люблю и уважаю.

а команда POP или RET разве не нужна для возврата? разве не ее адрес будет в стеке?

то есть вы утверждаете, что содержимому памяти можно будет доверять, если несколько мегабайт кода выполнилось "несанкционированно"? если вы посмотрите в отладчике на отпетрушенную таким кодом память, вам сразу станет все понятно?! если исполняемый код не является мусором, вы получите инфу о моменте исключения, откуда можно и понять, как туда попали.

а вот в attiny13 (512 команд программного кода, 64 байта ОЗУ) и даже attiny10 (кажется, и того меньше) дебаг есть. вы в самом деле считаете, что он там необходим и вот ни капельки не является маркетинговым крючком, на который ловятся простофили?

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


Как в том анекдоте:
— Батюшка! Ну вот я — не пью, не курю, работаю как вол, жене не изменяю! Отладчиком не пользуюсь! Неужели я неправильно живу?!
— Отчего же? Правильно, сын мой. Но зря

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

Я же писал - ковыряюсь с чипом не имеющим внутрисхемной отладки. Чувствую себя инвалидом. Задрался уже править и перепрошивать. Задрался изворачиваться из-за недостатка ног две из которых заняты уартом. Задрали строки с вызовом функции печати в терминал в тексте. Задрало их комментировать и раскомментировывать. Какие еще примеры нужны? Этих костылей недостаточно? Забег на длинную дистанцию на костылях.

Я когда-то монитор писал в шешнадцатеричных кодах на листке в клеточку, а забивалось все в память с пульта с тумблерами и светодиодами в двоичном представлении. И мне такого щастья на всю следующую жизнь хватит по самое нехочу. Кому не хватило, те могут не пользоваться дебагерами, и ide тоже им не надо. А я буду упрощать себе жизнь всеми возможными способами.

Ответ очевиден, ибо:

При этом одни идиоты создают отладочные сопроцессоры, разрабатывают инструменты и описывают методики их применения, а другие учатся быстро находить ошибки в своих программах, потому что время- это деньги, или потерянные, или не заработанные. И лишь 1% особо одарённых анально-огороженных умников, находящихся на государевом обеспечении, сидят месяцами без отладчиков. Они могут себе это позволить.

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

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

Абисняю. Из=за вашей самоуверенной позиции, которая основана на никаком опыте.

Хотелось бы узнать ЗАЧЕМ? Зачем весь этот перфоманс? Есть реальное железо, которое взаимодействует с реальным кодом и содержит реальный АЦП (мужского рода, к слову). Чем имитация лучше оригинала? Как в имитации узнать о проблемах взаимодействия аппаратной и софтовой части проекта?
Впрочем, обнаружение сигнала происходит далеко не за один кадр. Так, реально работающее на стенде устройство анализируется на устойчивость к помехам по нескольку часов, чтобы получить адекватную информацию. Какие еще семплы тут могут имитировать все это на ПК?
Так же, как и все - накапливаю опыт. Обработка сигналов - она такая, статистически не вполне определенная. И никем и ничем не нормированная. Мало того, развивающаяся во все более агрессивных внешних условиях, которые нужно периодически разруливать, совершенствуя изделие и в аппаратной и в программной части. Иногда ретроспективно перерабатывая код ранних версий изделий, решая возникающие на объектах проблемы на основании накопленного опыта.

Снова неправы. Если некий процесс затер стек, то узнать что либо по его содержимому уже невозможно. Но можно найти причину, анализируя другие переменные (например машину состояний или границы массивов).
Даже в теории это не так. Скорость обработки в DSP контроллере в разы быстрее, чем в прикладном софте на ПК. Виной тому - ОС общего назначения. Она исключает реальное время. Поэтому в сигнальных системах на кристалле делают отдельные ядра для сигнальных задач и отдельные для ОС общего назначения). Повторяю в 100500 раз. Проверять корректность работы например ДПФ нет никакой необходимости. Код ДПФ в true-DSP-контроллерах пишут на АСМе (даже если через встроенные функции), поскольку Си не поддерживает true-DSP-ядро. Основная проблема отладки - взаимодействие периферии с кодом. Поддержка реального времени плохо симулируется на ПК. Кроме того, код на Си плохо переносим с ПК на МК. Он плохо переносим даже в МК разных платформ. Если конечно этот код эффективен.

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

Какой смысл вы вкладываете в термины простофили и маркетинговый ход? Отсутствие дебага создает дополнительные затраты времени на отладку. Нужно делать инструменты, нужно писать отладочный код, нужно иметь периферию поддерживающую этот отладочный код, а так же свободные пины для этой отладки.
Да, я могу вести разработку и без встроенного дебага. Но при его наличии я не буду заниматься мазохизмом.

Добавлено after 5 minutes 30 seconds:

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