Привязанность к отладчикам Опции

[GetSmart]

А чего было то?

[zltigo]

А чего было то?

Можно предположу?
Не смотря на несомненную многоопытность имеет место быть болезненная привязанность к отладчику . В результате вместо просмотра глазами куска исходника с опиской, или обдумывания алгоритма были получены обильные листинги (да еще и с непонятным ARM ASM) да окошечки c цифирками в которых все проблемы прекрасно замаскировались. То, что было привычным для исходников на ASM для AVR положило свинью.

[Rst7]

Да не имеет это отношение к принципу отладки. Симулятор, эмулятор, монитор... Он впёр бы эту ошибку всё равно. Это ошибка человека писавшего программу, а не отладчика.

Разве я что-то другое утверждал? Видимо, Вы меня не совсем верно поняли. Конечно, ошибка внесена человеком. Как на это повлиял отладчик? Неужели Вы никогда не видели кода, который пестрит костылями типа "if (a>(b+2))"? Костыль - это именно "+2", это явно сделано по результатам шагания в отладчике.

Зря.

И не уговаривайте. Я сторонник подхода господина zltigo - вдумчивое чтение кода и результатов kprintf - куда более правильное занятие.

[SasaVitebsk]

Разве я что-то другое утверждал? Видимо, Вы меня не совсем верно поняли. Конечно, ошибка внесена человеком. Как на это повлиял отладчик? Неужели Вы никогда не видели кода, который пестрит костылями типа "if (a>(b+2))"? Костыль - это именно "+2", это явно сделано по результатам шагания в отладчике.

Ну это уж чересчур. Мне даже представить себе сложно. Всётаки видимо разные задачи. Я не представляю что можно внести в код, по результатам отладки отладчиком. Обычно - исправляются ошибки.
Я костыли по другому себе представляю. Вот у меня несколько пока живых проектов осталось на асме. Просят переделать. К примеру вместо датчика аналогового ввести датчик частотный. Или увеличить демпфирование. А структура проекта, изначально на это расчитана не была. Написано всё было 5 лет назад и вылизывалось в деталях - год. Ну и начинаются вставки в готовую прогу.
Это конечно никому не нравится. Особенно мне, естественно.
С переходом на Си - таких ситуаций практически не возникает.

И не уговаривайте. Я сторонник подхода господина zltigo - вдумчивое чтение кода и результатов kprintf - куда более правильное занятие.

Я не уговариваю. Кроме того вдумчивое чтение исходников никто не отменял.

Для примера скажу, что последний перенос проекта, а он достаточно значительный (под AVR занимал 60к). Было много ковыряний с переферией, разборок с аппаратурой ARM. Одна ошибка переноса. Из-за небрежности при переносе констант из внутренней EEPROM AVR в спец блок 24c512, с соответствующими процедурами на ARM. Плюс в двух местах выравнивание. В одном просто изменил объявление, а в другом (упакованная структура шла с внешнего источника) пришлось изменить объявление, и при приёме вставить нули (распаковать). И всё заработало. И это при полной оптимизации под 8-ми битовик со множеством указателей.
Конечно - главное спасибо IAR, но в тоже время я удовлетворён, так как считаю, что и я корректно прогу написал. Иначе вылизываний было бы много (я этого и ожидал, если честно).
Теперь я перепишу RS232. Потом затестирую рост производительности за счёт производительности проца (именно по этому сохранил 8-ми битовую направленность проекта) потом буду переписывать на 32 битную платформу. Чтобы оценить рост производительности за счёт архитектуры.
Люблю переписывать проекты. Так как в конце, на проект смотришь несколько по-другому.

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