А если так:




Просто притормозить МК, и посмотреть, а что же там насчитало.
Ведь всю память видно, все структуры.


Дык не одноразовый же стенд. Окупается с головой.


PS: zltigo, я с Вами во многом согласен во взглядах, но Вы уж больно категорично пытаетесь доказать непотребность или малую пользу внутрисхемных отладчиков. Можно и с помощью одного светодиода все отладить, но ведь дольше ж будет. А время, как известно, - деньги.

Да, описка вышла. 3.42A.

Ну вот. Опять из вас поперло ЭТО Ну почему я должен выглядеть глупее вас, только потому что вам так хочется кажется? Да не выключены у меня эти долбанные варнинги! Не имею привычки их выключать. Вам весь проект прислать или скриншотов достаточно?
На первом скриншоте результат компиляции всего проекта. Как видите там два варнинга.
На втором скриншоте протокол компиляции именно того модуля для которого выданы эти предупреждения. На операцию с переменными volatile ругнулся, а описанную мной ошибку (на третьем скриншоте выделено) в том же модуле спокойно пропустил.

Ну это ваши религиозные предрассудки, с которыми вам и жить. А на религиозные темы спорить ИМХО бесполезно.

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

P.S. Ну включил еще дополнительно ремарки. Нашел лишнюю запятую в enum-е в одном из хидеров. Других отличий от уже описанного протокола компиляции нет. Ну не обнаруживает в этом конкретном месте компилятор никаких ошибок или недоразумений. А программа-то глючит безбожно

P.P.S. А вот как эта строка компилируется.

С ошибкой

R14 в данной функции нигде не используется.

А вот без ошибки

что собственно и хотелось в этой операции.

"ЭТО", это что? Уверенность, что разработчики компиляторов умнее меня и компилятор ошибается много реже, чем я? Да, дело имено так и обстоит.

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

Забавно Прямо в этой ветке Вы пинали IAR IDE и сетовали на ее глюки, после чего меня, который ее НЕ использует (в том числе и по причине глюков) обвиняете в "предрассудках". Зачем, черт побери, пользоваться явно прохими продуктами, если есть продукты, которые выпускаются производителями для которых это основной кусок хлеба, а не попытка сделать 'как у всех' натягивая дежурную маску дружелюбности?

Комментировать не буду, ибо имею свое мнение о основных причинах глюков, которое опять несколько не совпадает с доминирующем на форуме .


Я просто пытаюсь 'намекнуть', что после маленьких проектов (что абсолютно естественно), у которых буквально все на виду и достаточно просто взглянуть на окно отладчика сразу становится все ясным и понятным. Для которых отладчик реально демонстрирует просто потрясающую (особенно для ассемблерных) воображене эффективность, обычно приходит время проектов посложнее. В них эфективность применения отладчика резко падает. На первое место выходит проблема "кто шил костюм"
а отладчик прекрасно помогает только с разборками с "пуговицами", к которым, как известно, "притензий нет". Зато отсутствие навыков (в том числе и провоцируемых отладчиком!) вдумчиво писать и уменя читать (в том числе и чужие исходники, ибо куда без них в больших проектах) начинает со страшной силой пожирать и время, и деньги, и нервы.
Подходишь к такому человеку, а он "висит" в отладчике днями, месяцами, неделями. Что-то замучал и произошло самое сташное - отпралено на обьект. Глючит. Любимейшая фраза в таком случае - а у "меня все работает", "как мне это здесь повторить"(дабы припасть к окну отладчика). Все, труба дело навыки анализа "глюков", вычитывания тектстов, раздумия над алгоритмами минимальны. Уверености в написанном нет. Начинается слепое латание и замена одних проблем на другие. Все это я наблюдал и наблюдаю, удручающе часто .
Повтояюсь - отладчик, как и любой инстумент, полезен, но для определенных условий и ситуаций. В противном случае он похож на детскую соску, которую пихают когда и куда не поподя, добиваясь что-бы дите не плакало, но отнюдь не того, что бы оно было здорово.

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

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

IAR значит по-вашему абсолютно не профессиональный продукт???

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

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

Я реагировал на Ваши жалобы на IDE и Ваши упреки (несправедивые ) в мой адрес по поводу не использования IAR IDE. Не валите в эту кучу компилятор.

IDE у IAR самый не профессиональный и неудобоваримый продукт из виденных мной. Когда за буквально считанные минуты использования наступаешь на несколько лежащих на поверхности граблей, то это многое о чем говорит. А то, что несколько багов даже описаны авторами, но по неведомым причинам не исправляются уже несколько лет, говорит об отношении к продукту.
Самые первые проблемы на которые наступил:
- Назначение Hotkeys, не всегда отрабатывает, а если отрабатывает, то не всегда в меню отображается или отображается, но не надолго..
- Падает достаточно часто
- Настройки проекта сохраняются только при выходе, посему при падении все можете начинать сначала.
- Где-то что-то в IDЕшных (не проектных) настройках регулярно заклинивает, помогает снос директории SETTINGS, но не надолго. Баг описан, рекомендации по сносу выданы, почему-бы не исправить?
Дальше и запоминать перестал
Если к этому добавить минималистичную фуннкциональность, хотя-бы того-же редактора, то говорить о "продукте" как-то язык не поворачивается.
Собственно IAR компиляторы вполне на уровне - не жалуюсь.

Я еще раз с Вами соглашаюсь, или от меня еще требуется какя-то особая форма покаяния ?

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

Я ничего не подразумеваю. Я прямо называю своим именем:

За то, что Вам привидилось я не в ответе.

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

решаются очень просто и радикально - использованием наиболее качественного программного компонента.

С одной стороны:
gcc -Wall -Wextra
foo.c: In function 'foo':
foo.c:8: warning: empty body in an if-statement
foo.c:12: warning: suggest parentheses around assignment used as truth value

Во втором предупреждении он имеет ввиду "если ты понимаешь, что ты делаешь, то напиши
if( (p->x = z) )
и я отстану"
Вторые скобки "прячут" присвоение и "снаружи" остаётся результат присваивающего выражения, он перестаёт ругаться.

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

Предупреждения никогда не нужно отключать! Я никогда нигде не советовал отключать warning'и.
Всегда включаю "параноидальный" режим, помогает.
Но именно на эту ситуацию

Компилятор CA v.2.42. Warning level 3 (максимальный).
compiling jittersim.c...
linking...
creating hex file from "NPU"...
"NPU" - 0 Error(s), 0 Warning(s).

компилятор RVCT3.0. All warnings.
compiling jittersim.c...
jittersim.c(1232): warning: #1293-D: assignment in condition
linking...
".\Objects\npu_rvds.axf" - 0 Error(s), 1 Warning(s).

исправляем ошибку:


компилятор RVCT3.0. All warnings.
compiling jittersim.c...
linking...
".\Objects\npu_rvds.axf" - 0 Error(s), 0 Warning(s).

И еще совет. Я использую PC-Lint: строгие разборки с исходниками, вылавливает вышеприведенные баги и описки влет, существенная экономия времени. Тоже, конечно, вываливает огромную кучу Warning-ов связанных с архитектурой, но среди них есть весьма ценные замечания.

Avr Studio 4.13 build 528
При работе с UART в меге48P регистр UBRR0H так и продолжает мапиться с USCR0C.

А подскажите, уважаемые, эта фигня до сих пор?

ЗЫ. А в собственно меге 48 нет ли нефиксенного бага, как в PWM3 по тому же поводу ?

Сообщение отредактировал _Pasha - Nov 13 2007, 10:44

Люди всё же разные. По разному отлаживают и по разному осмысливают. И совершают ошибки разные. Поэтому, на мой взгляд, нет и не может быть единых подходов к написанию и, тем более к отладке.

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

В последнем проекте я делал и полный симулятор на PC и модель строил и отладчиком пользовался. Кстати к JTAG ICE MKII тоже есть, не то чтобы претензии, но так ... типа непродуманность на мой взгляд.
На счёт "вдумчиво прочитать программу и найти все ошибки", я их делаю достаточно мало. Но если уже сделал, то вдумчивое чтение не всегда помогает. Хотя это первейшее дело во всех делах.

2Zltigo. А теперь представьте такую ситуацию. Принесли с монтажного участка штук так надцать плат размером с формат А3. Начинаем их "заводить", а они нивкакую! Вот тут очень даже облегчает жизнь JTAGICE. Сразу видно, что замкнута или оборвана шина данных/адреса, "косит" микросхема на SPI шине и т.д. и т.п. "Оживление" платы сокращается в разы.

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

Пожалуйста, сообщите № версии и билд.

У меня не висло, но проблема, которую я ранее описывал, решалась таким образом:


Если же UCSR0C инициализировать после UBRR, то UBRR0H будет равен UCSR0C. Что явно не согласуется с doc2545.pdf

Остальное - Well known issues

За последнее время, однако, появилось еще кое-что.
АврСтудия глюканула безвозвратно после того, как я повторно установил WINAVR. Но это - уже другая история...

P.S. я компилил по версии асм 1. Асму 2 не доверяю пока.

Сообщение отредактировал _Pasha - Nov 15 2007, 18:29