Простая, но неразрешимая (?) проблема сишной отладки на мк

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

update
Зачеркнул - двусмысленная была фраза ) Вопрос не в том, как надо программировать, чтобы меньше отлаживаться, а всего лишь в том, как изменить программу, не выходя из сеанса отладки.

0

Сообщение от flomdger Но если выдержан принцип декомпозиции, то не бывает "светодиод загорелся - реактор взорвался, другой светодиод загорелся - дверь отвалилась".

тоже теоретик?:) никакой принцип от этого не защитит кроме принципа "не используем указатели" (в т.ч. в библиотеках, в т.ч. не в ваших). разжевывать не буду.

0

тоже теоретик?:) никакой принцип от этого не защитит кроме принципа "не используем указатели" (в т.ч. в библиотеках, в т.ч. не в ваших). разжевывать не буду.

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

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

Так не получится, я писал об этом на первой странице -

Извините, а когда вы тестируете софт под ПК(или не тестируете?) вы тоже последовательно нажимаете на кнопки чтобы попасть в нужную функцию и оттестировать её? Всё же более распространено (а главное эффективнее и имеет большее кпд) модульное тестирование, собственно поэтому сама проблема надумана. Конечно под ПК куда больше различных инструментов(каких только франкеншейнов не нарожали большие и не очень компании), найдётся монстр на любой изысканный вкус. Затраты на edit&continue просто не стоят того (если идёт речь о затратах времени одного человека), однако я не отказался бы от подобной фичи, если бы кто-то её внедрил :)

0

Сообщение от flomdger ... собственно поэтому сама проблема надумана.

Вы там ссылочку давали, я прочитал этот снобский рассказик ))

Чтобы решить проблему, Навичак решил воспользоваться форумом по программированию. Вы думаете он создал там тему вида: "Я хочу получить X. Пытаюсь сделать 111, получаю 222. Как сделать X?"? Нет! Навичак решил (ошибочно, т.к. Навичак пока не обладает достаточным знанием), что если он сумеет сделать Y, то с помощью Y он получит и X. Поэтому он написал: "Делаю 111, получаю 222. Как получить Y?" (ещё бывает, что Навичак задаёт только "Как сделать Y?"). ... Чаще всего, Y бывает невозможным, некорректным, сложным или вообще страшно извращённым и нелогичным действием. У всех Понимающих людей вопрос "как сделать Y?" вызывает недоумение: зачем это нужно? Это же бессмысленно. Всеми силами (иногда с привлечением утюга!) пытаются выпытать у Новичка Понимающие, что же ему на самом деле нужно. Но не сдаётся Навичак: он же хочет узнать, как сделать Y. Каких только Слонов не рождали глубокие умы, пытаясь постичь неисповедимые пути Новичка! Иногда даже бывает так, что Понимающие знают ответ на вопрос "как сделать Y?", но специально его не говорят, потому что эти действия лишены смысла. Они ещё надеются наставить Новичка на путь истинный.

Однако там есть один интересный коммент к нему ;)

Часто бывает совсем по-другому. Не Очень Навичак задает вопрос "мне нужно сделать X, я решил для этого сделать Y. Как мне сделать Y?", умалчивая множество деталей почему был выбран Y, т.к. если их приводить все - начальный пост окажется размером со средневековую библию со всеми комментариями. После этого толпы Не Особо Понимающих в предметной области сообщают своё экспертное мнение "Вам не нужен Y для получения X, это слишком сложно. Почему бы вам не сделать Z1...Zn?". После чего Не Очень Новичёк на каждое такое предложение вынужден объяснять почему не подходит Z1..Zn, вступать в споры и жалеть какого же его чёрт дёрнул вообще упомнуть про X в первом посте...

0

Сообщение от Mykysoft Что даст в вопросе промышленной и непромышленной электроники, программирования и эмбеддинга - обладание группой допуска к работе под напряжением?

Странно, и как это ты до сих пор выжил? (шутка)

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

0

Сообщение от vt340 Однако там есть один интересный коммент к нему ;)

Да, мне он тоже понравился. Бывает и такое. Очень часто грешат этим америкосские форумы, различные stackoverflow и прочие, когда задаёшь конкретный вопрос, а тебе 100500 ответов "а нафига тебе, возможно ты имел в виду <какая-нибудь ересь>?" Причём все слизанные друг у друга под копирку.

0

Сообщение от trymktor ... на отношении к электричеству в целом.

и можно ещё слово Электричество с большой буквы )) Убедительно прошу всех гуру пром автоматики не испытывать моё терпение второй раз )

0

Сообщение от vt340 Вы там ссылочку давали, я прочитал этот снобский рассказик ))

vt340, бывает и довольно часто. И если бы пациент выкладывал не свое видение процесса а суть реализации - подобного бы не происходило...

Сообщение от trymktor Т.е. ты хочешь сказать, что обладание группой допуска никак не сказывается на отношении обладателя (как в период аттестованности, так и в дальнейшем) на отношении к электричеству в целом.

Достаточно ответить себе - какое отношение группа допуска имела к теме срача , кроме попытки возвысить свое ЧСВ...

0

dosykus_2, я забыл ответить про библиотеки в rom - да, я знаю эту техасскую нигию ) но в стелларисваре (или теперь наверно тиваваре?) не было методов как их делать, были только - как их использовать, а использовать надо было, кажется, тупо по абсолютным адресам точек входа, въявную забитых в хидерах стандартной библиотеки

0

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

теоретик. когда пишешь один сам небольшую программку - да, ок, сильно не накосячишь. когда программа большая, когда ее писали много людей - всё совсем не так просто. да, это говнокод, но он будет. такова практика в отличие от теории.

Сообщение от flomdger По библиотекам могу сказать одно, если работа с библиотекой херачит весь проект, то надо либо пересматривать работу с этой библиотекой, либо переписывать, либо выкидывать её.

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

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

0

Сообщение от vt340 но в стелларисваре (или теперь наверно тиваваре?) не было методов как их делать,

Угу, счас они раскрыли все свои плюшки. Зато какое раздолье хомячкам - и никто не обвинит что либы тухлыепухлые. :))))

0

теоретик. когда пишешь один сам небольшую программку - да, ок, сильно не накосячишь. когда программа большая, когда ее писали много людей - всё совсем не так просто. да, это говнокод, но он будет. такова практика в отличие от теории.

Вы решили уподобиться demiurgу аля "сама придумала - сама обиделась"? Он также себе в свою задницу вбил что я ПКшный программист с потоковым "мышлением".

На практике говнокод будет всегда, но это не означает что "весь мир гавно". Да и разный он бывает.

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

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

Каждый сам кузнец собственного щасья, как говорится.

0

Сообщение от oomomstir vt340, не-не-не. На PC было то же самое поколение (вы досовский debug помните?), но и более совершенные инструменты появились, и другие языки. Было бы кому те же средства для МК сделать - приняли бы на ура.

Эх... появился бы сейчас 8086 в виде мк, хоть с каким то кол-вом встроенного рам и флэша, и за разумные деньги, махнул бы с кортексов не глядя, только из-за ПО - мой любимый TopSpeed идеально подошёл бы для мк, без всех этих gcc-извратов )

0

Сообщение от vt340 Сообщение от oomomstir vt340, не-не-не. На PC было то же самое поколение (вы досовский debug помните?), но и более совершенные инструменты появились, и другие языки. Было бы кому те же средства для МК сделать - приняли бы на ура.

Эх... появился бы сейчас 8086 в виде мк, хоть с каким то кол-вом встроенного рам и флэша, и за разумные деньги, махнул бы с кортексов не глядя, только из-за ПО ))
У армов разве нет всех фишек тех же самых? VisualGDB в своё время для меня сделало прекрасную нигию в Visual Studyo, когда я какой то арм дебажил.

0

Сообщение от flomdger У армов разве нет всех фишек тех же самых?

Да я шучу ) и 8086 нужен с jtag-ом, конечно ) Если серъёзно - досовские компиляторы были специально заточены для нижнего уровня, вот например объявление массива векторов прерываний в topspeed modula-2 сразу с явной привязкой к физ адресу -
IntTab[0:0] : ARRAY [0..255] OF FarADDRESS;
И последующее заталкивание в вектор процедуры обработчика прерывания -
IntTab[11] := FarADR(IntProc);
И это всё - никаких доп defyme, volatile, ассемблерных stortup-ов, ld-скриптов и т.п. )

0

Сообщение от flomdger На практике говнокод будет всегда, но это не означает что "весь мир гавно".

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

Сообщение от flomdger Я не знаю как там у вас конечно, но я такой херни стараюсь не допускать среди подчинённых.

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

кроме того, не верите мне - почитайте статьи про проверку разных проектов pvs-studyo, в т.ч. тех проектов, которые тоже проверяются анализаторами кода. все равно там ошибки есть. или взгляните на любой большой массовый продукт, firefox, chrome, whatever... в каждом есть ошибки несмотря на то, что пишут это всё далеко не дураки, но везде есть порча памяти и прочее. вот практика.

Сообщение от flomdger но если я знаю что этот кусок кода будет сопровождаться, он войдёт в библиотеку и будет использоваться дальше то хрен я его пропущу в таком виде.

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

0

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

На ПК то есть куча средств чтобы отследить утечки памяти, корректность её освобождения. Тот же PVS.

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

0

да вот было, использовал и rtos, и malloc в мк. а зачем в компиляторах для мк реализуют malloc? значит надо. но это всего лишь один из примеров. гораздо проще пример с sprymtf, str* и прочими, там тоже указатели, тоже бывает портят что-то не то. так что пофиг, мк или пк, всё одинаково. везде можно взорвать реактор.

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

0

Сообщение от Ymk да вот было, использовал и rtos, и malloc в мк. а зачем в компиляторах для мк реализуют malloc? значит надо. но это всего лишь один из примеров. гораздо проще пример с sprymtf, str* и прочими, там тоже указатели, тоже бывает портят что-то не то. так что пофиг, мк или пк, всё одинаково. везде можно взорвать реактор. для промавтоматики захотели сделать более надежную систему, придумали языки, в которых нет указателей. и сразу там систему нельзя убить.

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

0

Сообщение от flomdger Я как то со строками недавно тоже напоролся, в одном из весьма безобидных случаев, всего лишь на strcpy. Теперь не доверяю нуль-терминированным строкам, использую только защищённые от переполнения функции. Тоже не пролезло на тестах, выяснилось в процессе эксплуатации когда БД слетела(всю внешнюю еепромку снесло). Всякое бывает.

хех, ну т.е. реактор-таки взорвал:) зачем тогда было сказано это?

Сообщение от flomdger Но если выдержан принцип декомпозиции, то не бывает "светодиод загорелся - реактор взорвался, другой светодиод загорелся - дверь отвалилась".

0

Сообщение от Ymk хех, ну т.е. реактор-таки взорвал:) зачем тогда было сказано это?

Несколько неверно выразился, бывает намного реже.

0