|
|
  |
Привязанность к отладчикам |
|
|
|
Jun 2 2009, 23:32
|
дятел
    
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065

|
Цитата(zltigo @ Jun 3 2009, 03:07)  Это когда Вы комануете "светодиодами" и "самый главный", ибо "светодиоды" сугубо беспрекословные твари. Ха-ха, у меня контроллер может быть далеко не главным и быть просто звеном длинной цепочки, могут быть много контроллеров "сверху" которые будут рулить им и много контроллеров "снизу" которыми будет рулить он. А светодиоды это конечно "тупые твари" но их тоже бывает много на наших девайсах(по количеству каналов например...) Цитата Теперь давайте Вами будут командовать во полне реальном времени железки сторнних производителей, протокольчики будут с подтверждениями, переповторами, уходами на резервные и обходные направоения... Реальное время это сколько ? Цитата Каналов тоже будет далеко не один. Ну а Вы постоите и поотлаживаетесь.... А кто сказал что он один ? все что я описал в ТТХ(кроме SPI) это каналы обмена с другими контроллерами, более того, часть этих каналов может переключаться в разные режимы работы на ходу, и вот сейчас стою на одном из промежуточных девайсов и легко отлаживаюсь.
|
|
|
|
|
Jun 3 2009, 00:52
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(zltigo @ Jun 3 2009, 02:07)  Вот именно обеспечением этого и занимается отладочный код верхнего уровня выдающий сообщения на консоль. Факты прихода внешних воздействий, ошибки их разборки, переходы состояний и отображение памяти конечных автоматов, ответные реакции..... Я уже вижу недостаток такого подхода - размер отладочного кода. Смею предположить, что код консоли в такой форме занимает приличный % от всего проекта. Для МК с небольшим количеством флеш <=256K, консоль может и не влезть, либо влезть только "за счет урезания функционала". Цитата(zltigo @ Jun 3 2009, 02:07)  Это когда Вы командуете "светодиодами" и "самый главный", ибо "светодиоды" сугубо беспрекословные твари. Теперь давайте Вами будут командовать во полне реальном времени железки сторнних производителей, протокольчики будут с подтверждениями, переповторами, уходами на резервные и обходные направоения... Каналов тоже будет далеко не один. Ну а Вы постоите и поотлаживаетесь.... В общем секрет прост: 1. В консоли замечаем проблему. 2. в коде ставим ловушку: Цитата ... if ( <проблема> ) TrapIt(); <-- сюда ставим точку останова. 3. сопоставляем конкретные данные с кодом 4. устраняем проблему. И не важно что после "2" произойдет снаружи. Как правило, одной остановки в "правильном" месте достаточно чтобы пофиксить проблему. PS: Насчет того что "2" можно опустить, "3" заменить на просто "изучаем исходники", спорить не буду - можно и так, но не факт что так получится быстрее.
|
|
|
|
|
Jun 3 2009, 05:58
|

Йа моск ;)
     
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610

|
Цитата(SasaVitebsk @ Jun 3 2009, 00:01)  Будьте добры. Приведите пример ошибки привнесённой по результатам работы с отладчиком. Там буквально в каментах было написано, что автор долго плясал с бубном, по результатам трассировки пришлось сделать так-то и так-то. Смысл ошибки - неверная синхронизация двух потоков и железа. Цитата А сам пост, именно и оживляет воспоминания о том замечательном времени, когда внутрисхемных эмуляторов, и прочей хрени типа запоминающих осциллографов не было. Дада. Запоминающий осциллограф, в который войдет несколько часов с семплрейтом 96к/с. У меня и сейчас такого нет А внутрисхемными эмуляторами - не пользуюсь. Есть осциллограф (уже цифровой, но не брезговал и C1-64, главное - сделать правильный ногодрыг на отдельной ножке для синхронизации) для разбора узких мест на периферии, и есть отладочная печать в разных формах - например, когда делал TCP-стек, банально отправлял raw-пакеты с отладочной инфой. В сниффере отлично все видно - пакеты TCP-сессии и между ними - мои пакеты с состоянием. Оказалось очень удобно.
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
Jun 3 2009, 06:22
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(singlskv @ Jun 3 2009, 02:32)  Ха-ха, у меня контроллер может быть далеко не главным и быть просто звеном длинной цепочки, Хи-Хи ну и что? Либо это элемент просто построенной системы, пусть и мегагерцами и прочим, и сисмтема "не заметит потери бойца", либо система более сложно организована и ..... и обломитесь  . Цитата ...и вот сейчас стою на одном из промежуточных девайсов и легко отлаживаюсь. Рад за Ваш большой и интерфейсно-мегагерцово-понтовый (ой у меня на текущей железке через контроллер в основном гонят информацию только два SPI, стыдно признаться  на 7,5MHz....) "контроллер многих светодиодов". Только во множестве случаев и множестве протоколов принятых, например, даже на самых обычных и банальных телефонных сетях "стою и отлаживаюсь" заканчиается максимум через считанные секунды. После чего дальше уже не продолжите а пойдете медленнои печально через процедуры поднятия линков, установки каналов в исходные состочния и даллее с нуля.... Угадали с точкой останова отладчика? Нет? Тогда сидите и долбитесь. А я лучше головой подумаю, по ходу дела, возможно и еще какие потенциально скользкие моменты в исходнике замечу. Вы можете позволить себе постоять и ммееедленно пойти дальше - рад. Я в очень большом количестве случаев - не могу. При этом владея методикой отладки и без "стою отлаживаюсь" мне совершенно не хочется зачем-то ее менять и для простых логических систем, где "стою отлаживаюсь" вполне себе допустимы. Цитата(defunct @ Jun 3 2009, 03:52)  Я уже вижу недостаток такого подхода - размер отладочного кода. Смею предположить, что код консоли в такой форме занимает приличный % от всего проекта. Занимает, конечно, но единицы процентов - иногда предусматриваеется сборка системы без возможности включить параноидальные уровни отладки (ну типа все на нижних уровнях уже отлажено, а возможноть запаса по загрузке системы не помешает ) так уменьшение размера кода именно единицы процентов. То, что остается, и того меньще - отладчные распечатки стоят в узких узловых местах системы. Тут реальная проблем только одна - нужно крепко думать об отладке до и во время написания, а не после, как уже ранее писал, не в стиле а не поставить-ли сюда fprintf( "a=%i", a ) является основным методом. Цитата 1. В консоли замечаем проблему. Да. Цитата 2. в коде ставим ловушку: И ждем, хорошо, если несколько часов, а не месяцев или лет ( бывало и такое  ) до следующего неудачного расположени звезд.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Jun 3 2009, 07:32
|

читатель даташитов
   
Группа: Свой
Сообщений: 853
Регистрация: 5-11-06
Из: Днепропетровск
Пользователь №: 21 999

|
Цитата(defunct @ Jun 2 2009, 03:51)  2. Использовать только консоль (трассы) - не все ошибки можно так отловить, банальная ситуация "Device Dead" и приплыли А почему Вы считаете, что на консоль coredump получить нельзя? Очень даже можно, чем я и пользуюсь. Реально правда применял два раза всего... По поводу пошаговой отладки. Общеизвестно, что самый выгодный метод поиска ошибок - вычитывание кода. Это вполне заменяет пошаговую отладку, надежнее, часто быстрее. Не забывайте, кроме того, про разработку-через-тестирование (согласен, что не везде можно использовать, конечно). В итоге весь Ваш Священный Набор "кордамп + трассы + пошаговая отладка" с заменой пошаговой отладки на мозг чудесно работает в поле без всяких лишних девайсов.
|
|
|
|
|
Jun 3 2009, 08:37
|
Гуру
     
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521

|
Цитата(Rst7 @ Jun 3 2009, 08:58)  Там буквально в каментах было написано, что автор долго плясал с бубном, по результатам трассировки пришлось сделать так-то и так-то. Смысл ошибки - неверная синхронизация двух потоков и железа. Да не имеет это отношение к принципу отладки. Симулятор, эмулятор, монитор... Он впёр бы эту ошибку всё равно. Это ошибка человека писавшего программу, а не отладчика. Цитата Дада. Запоминающий осциллограф, в который войдет несколько часов с семплрейтом 96к/с. У меня и сейчас такого нет  Да знаю я всё это. Проходил. Я, к примеру сделал железяку к компу, на которой делал предварительную обработку, сжатие данных и передачу на комп. Правда ч/з LPT. Ну тогда с процами работал - 1/2 мипса. Реальный сигнал помедленней - успевал. Ну и прога (громко названная осциллограф  ). Ей просматривал до 8 лучей с поиском.  Сохранилась как раритет. Последнее время не работаю. Отладчика достаточно. В том числе и с синхронизацией и с прочими хренями. Конечно при работе более 2 устройств в системе сложновато, но, как правило система работает по принципу от 2. Иными словами достаточно связки мастер-ведомый. При полной отладке этой системы - далее масштабируется как угодно. А связка мастер-слэйв прекрасно разруливается ч/з отладчик. На уровне транзакций единичных. Если останавливать и то и то. Но даже если не останавливать мастер к примеру, то всё равно любой протокол вылизывается - только дольше. Кроме того, никто не мешает использовать сам монитор встроенный. Или отладочный вывод. Зато нет необходимости городить сложные прибамбасы для вывода этой отладочной инфы. Есть возможность просмотреть её и так. Цитата А внутрисхемными эмуляторами - не пользуюсь. Зря. Цитата Есть осциллограф (уже цифровой, но не брезговал и C1-64, главное - сделать правильный ногодрыг на отдельной ножке для синхронизации) для разбора узких мест на периферии, и есть отладочная печать в разных формах - например, когда делал TCP-стек, банально отправлял raw-пакеты с отладочной инфой. В сниффере отлично все видно - пакеты TCP-сессии и между ними - мои пакеты с состоянием. Оказалось очень удобно. Вот например раньше я тоже осциллографом некоторые вещи делал. Например оценку времени занятой прерываниями. Ну по известному сценарию: выводим на ножку, смотрим заполнение, дрожание и т/п. А сейчас - ввожу пару переменных запускаю тестовую задачу или даже работаю несколько часов под отладчиком, останавливаю и просматриваю статистику. Среднее время исполнения, максимальное. Вообще любой профиллинг. Очень удобно, быстро, без гимороя. А Ваша отладочная печать "в разных формах", как раз и отталкивает. Это как раз то, о чём я и говорю. Наработки - незначительны. Каждый раз приходится править эти самые формы. Для TCP-стека так, для CAN-open по другому.  Это я к примеру. Ну хорошо, вы обошлись готовым снифером. А не было бы его - пришлось бы городить. А я CAN SAE J1939 отладил без снифера и без командировки на МАЗ. Упёрся и не поехал.  Они мне блок управления двигателем купили.  А себе купили и снифер и прочую хрень. Прямо со снифера тестируют теперьготовые изделия. А я прекрасно всё отладчиком вижу. Понятно, что совсем без мониторов и трассировщиков никуда.  Последний раз когда я их применял - модем. Там была мной обнаружена ошибка Гипертерминала win. В том числе в XP. Не помню, но по-моему одна на 20Мбайт передаваемых данных. Я помню эти безразмерные портянки. Волосы шевелятся на голове. Если можно от этого уйти, то я постораюсь. Ну а при однотипных проектах, использование своего монитора очень толково. Однотипных, не значит с однотипным железом. Например есть ОС с кучей отлаженного софта и мы прикручиваем к нему новое железо. Обработка этого железа занимает 2% времени проекта. Конечно, в этом случае JTAG будет проигрывать отлаженному монитору с отлаженным аппаратным выводом дебажной инфы в удобоваримую форму. Особенно если я этим 10 лет пользуюсь. Только это выход не для всех.
|
|
|
|
|
Jun 3 2009, 08:45
|

Йа моск ;)
     
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610

|
Цитата Да не имеет это отношение к принципу отладки. Симулятор, эмулятор, монитор... Он впёр бы эту ошибку всё равно. Это ошибка человека писавшего программу, а не отладчика. Разве я что-то другое утверждал? Видимо, Вы меня не совсем верно поняли. Конечно, ошибка внесена человеком. Как на это повлиял отладчик? Неужели Вы никогда не видели кода, который пестрит костылями типа "if (a>(b+2))"? Костыль - это именно "+2", это явно сделано по результатам шагания в отладчике. Цитата Зря. И не уговаривайте. Я сторонник подхода господина zltigo - вдумчивое чтение кода и результатов kprintf  - куда более правильное занятие.
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
Jun 3 2009, 10:53
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(HARMHARM @ Jun 3 2009, 10:32)  А почему Вы считаете, что на консоль coredump получить нельзя? Очень даже можно, чем я и пользуюсь. Реально правда применял два раза всего... Я так не считаю потому как и сам через консоль дампы вывожу (и полные и сокращенные). Написал же - "Device Dead" ситуация - все заткнулось ничего не работает в том числе аварийная консоль, что делать? Вот здесь два варианта: 1. Подключиться отладчиком и посмотреть в чем дело. 2. Отснять дамп бутлоадером после резета. Цитата(HARMHARM @ Jun 3 2009, 10:32)  Общеизвестно, что самый выгодный метод поиска ошибок - вычитывание кода. Это вполне заменяет пошаговую отладку, надежнее, часто быстрее. Не забывайте, кроме того, про разработку-через-тестирование (согласен, что не везде можно использовать, конечно). В итоге весь Ваш Священный Набор "кордамп + трассы + пошаговая отладка" с заменой пошаговой отладки на мозг чудесно работает в поле без всяких лишних девайсов. Ну ну, я на Вас посмотрю как Вы будете "надежнее и быстрее" перелопачивать например хотя бы пару MB исходного текста в поисках проблемы "а почему 1 пакет из миллиона теряется". Вычитывать исходники бесспорно полезно, только не тогда когда проблема горит, а тогда когда есть время для этого.
|
|
|
|
|
Jun 3 2009, 11:29
|
Гуру
     
Группа: Свой
Сообщений: 2 712
Регистрация: 28-11-05
Из: Беларусь, Витебск, Строителей 18-4-220
Пользователь №: 11 521

|
Цитата(Rst7 @ Jun 3 2009, 11:45)  Разве я что-то другое утверждал? Видимо, Вы меня не совсем верно поняли. Конечно, ошибка внесена человеком. Как на это повлиял отладчик? Неужели Вы никогда не видели кода, который пестрит костылями типа "if (a>(b+2))"? Костыль - это именно "+2", это явно сделано по результатам шагания в отладчике. Ну это уж чересчур. Мне даже представить себе сложно. Всётаки видимо разные задачи. Я не представляю что можно внести в код, по результатам отладки отладчиком. Обычно - исправляются ошибки. Я костыли по другому себе представляю. Вот у меня несколько пока живых проектов осталось на асме. Просят переделать. К примеру вместо датчика аналогового ввести датчик частотный. Или увеличить демпфирование. А структура проекта, изначально на это расчитана не была. Написано всё было 5 лет назад и вылизывалось в деталях - год. Ну и начинаются вставки в готовую прогу. Это конечно никому не нравится. Особенно мне, естественно. С переходом на Си - таких ситуаций практически не возникает. Цитата И не уговаривайте. Я сторонник подхода господина zltigo - вдумчивое чтение кода и результатов kprintf  - куда более правильное занятие. Я не уговариваю. Кроме того вдумчивое чтение исходников никто не отменял. Для примера скажу, что последний перенос проекта, а он достаточно значительный (под AVR занимал 60к). Было много ковыряний с переферией, разборок с аппаратурой ARM. Одна ошибка переноса. Из-за небрежности при переносе констант из внутренней EEPROM AVR в спец блок 24c512, с соответствующими процедурами на ARM. Плюс в двух местах выравнивание. В одном просто изменил объявление, а в другом (упакованная структура шла с внешнего источника) пришлось изменить объявление, и при приёме вставить нули (распаковать). И всё заработало. И это при полной оптимизации под 8-ми битовик со множеством указателей. Конечно - главное спасибо IAR, но в тоже время я удовлетворён, так как считаю, что и я корректно прогу написал. Иначе вылизываний было бы много (я этого и ожидал, если честно). Теперь я перепишу RS232. Потом затестирую рост производительности за счёт производительности проца (именно по этому сохранил 8-ми битовую направленность проекта) потом буду переписывать на 32 битную платформу. Чтобы оценить рост производительности за счёт архитектуры. Люблю переписывать проекты. Так как в конце, на проект смотришь несколько по-другому.  Так что зависимость от JTAG у меня "на лицо", но пока не считаю это "вредной зависимостью". Думаю от человека зависит. С другой стороны у Вас "зависимость от мониторов".
|
|
|
|
|
Jun 3 2009, 14:39
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(SasaVitebsk @ Jun 3 2009, 14:29)  Так что зависимость от JTAG у меня "на лицо", но пока не считаю это "вредной зависимостью". Думаю от человека зависит. С другой стороны у Вас "зависимость от мониторов". Повторяю, "вредной зависимостью", это является, когда человек слабо представляет как оно без отладчика, "вредной зависимостью" это является, когда дойдя отладчиком куда-то радостно пишут те самые "+2" (о господи! сколько раз я такое наблюдал!) и ждут пока где-то вылезет боком, дабы доковыляв отладчиком в другом месте написать "-2". Во многих случаях речь идет просто о привычках, даже без приставки "вредных"  . И с этими привычками можно прекрасно жить долго и счастливо, если вдруг условия не изменятся. Я уже ноеднократно писал, что для меня отладчик есть своеобразный "последний шанс", Для кого-то отладчие один, пусть и любимый, но "один из шансов". Нешуточные проблемы это когда у многих и очень многих  этот "последний шанс" становится "первым" и единственым шансом.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
  |
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|