Придлагаю скидывать в данную ветку все встричающиеся баги программ симуляторов-эмуляторов (Proteus, Vmlab, AvrStudio).

Сам пока столкнулся только со следующим:

В Proteus 6.9.03 не работает прерывание от Input Capure (могу ошибаться, буду рад если меня исправят, но программа МК ATmega8 рабочая - проверено в Vmlab).

А я предлагаю (модераторы, не рвите на части) вообще не пользоваться всякими там протеусами и вмлабами! Здесь сколько раз уже мелькали фразы типа - "В протеусе работает, а на "железе" нет. Поможите!". Да нах такой СИмулятор нужен, если он кроме вопросов ничего не вызывает! Моё мнение - любой проект нужно отлаживать ТОЛЬКО В "ЖЕЛЕЗЕ"! Есть прекрасный инструмент - JTAGICE (Zltigo сейчас взбеленится), с помощью которого можно увидеть, что творится с программой и "железом" реально в данный момент времерни. А фраза "МК ATmega8 рабочая - проверено в Vmlab" меня привела в полный восторг!

Нельзя научиться ездить на велосипеде, не имея велосипеда.

Просто я вполне уверен в её работоспособности.



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

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

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

А чего это мне "белениться" - каждый сам себе Буратино. В конце концов и если кто-то не может прочитать пару сот строк документации, обдумать и после этого написать пару десятков строк без ошибок и при этом принципиально пишет на ASM (которым на самом деле не владеет) то мне до этого просто нет дела. Пусть методом тыка тыкается хоть симуляторах, хоть в эмуляторах, хоть в железе попутно набираясь "уверенности", что все железо, отладчики, эмуляторы, компиляторы и Windows иже с ними крупно покрыты "багами" .

Это да!

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

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

Ну так если действительно абсурд. Вы проверили программу в VMlab (а это тоже симулятор) и говорите, что она рабочая. Вините протеус. Так может протеус верно говорит: программа не работает, а VMlab врет?
Тем более не все улыбались, Вам дали много хороших советов!
От себя прибавлю: отладчиками вообще не пользуюсь. JTAG хотел собрать в свое время, но не собрал. А сейчас понимаю, что он вроде и не нужен. Да и мнение уважаемого zltigo для меня ценно. И нужно сказать, что программы пишуться и работают. А отлаживась с помощью LCD, на который вывожу необходимую информацию, сейчас LCD убрал, все вывожу в USART и в терминале на PC смотрю. Довольно таки удобно!


+1

+1
Я тоже заметил, что Си++ (ну а чуть ранее Си) такие языки, на которых совершить ошибку не так просто. Если четко понимаешь чего хочешь получить в результате и владеешь этим языком, то получаешь это!


А зачем тогда симулируете?
Слово вполне настораживает.

Я Вас отлично понимаю! Но лучше заняться другим более полезным делом, чем искать баги в одном симуляторе с помощью другого!

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


Ибо вы вероятно работаете с одним и тем же набором камней с одинаковой периферией и операционкой которая покрывает весь "низ". Плюс у вас есть довольно толстая консоль (по меркам AVR) которая заменяет функционал внутрисхемного отладчика.

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


Может быть вам так удобно. Мне например удобнее сразу писать и отлаживать программу в target железе в том виде в каком она потом будет в конечном изделии.

Писать и отлаживать на инструментальной машине - это все равно что делать двойную работу. Писать - потом портировать. Зачем? ведь можно сразу писать под target девайс.


TCCR1B = (1 << WGM12) | 5;
Синтаксически все правильно. На разных МК будет совершенно разный результат.
Чем тут может помочь инструментальная машина?

свято верить, что на C/C++ можно сходу написать программу без ошибок - это вторая крайность, граничащая с писателями на ассемблере.

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

Я свято не верю. Вожно мой небольшой опыт пока не позволяет сделать верных выводов.
Но если бы я верил, то не использовал бы вышеназванных LCD и USART. А вообще для меня очень ценны все замечания! Спасибо!

+1. Алгоритмические вещи проверяю в симуляторе. Содержимое памяти и опреации они все нормально воспроизводят. Остальное - внутрисхемный отладчик. Эта штука кажется ненужной, пока не попробуешь. Потом любых денег не жалко будет. Раньше тоже отлаживал через уарт и светодиодами. Потом преодалел лень - собрал айс (m16 + 2 транзистора и диод + на пальцах посчитать росыпи). Очень бережет нервы и время.
Периферию в симуляторе конечно не проверишь. Некоторое исключение - кейл. Я в нем и связь с хостовой программой отладил и i2c. Но все равно прикупил мтлинк.

Вроде все уже сказали правильно. В симуляторе отлаживаются программные алгоритмы, с помощью эмулятора (JTAG+target) работа перифирии и реал-тайм устройства.

Отнюдь! Ошибки бывают весьма замысловатые, которые выловить бывает весьма непросто. Типичная сложноуловимая ошибка - "наползание" стека на сегмент данных. Или вот вчера было у меня.
Полтора часа убил на то, чтобы в железе с дебаггером выловить простую описку в тексте СИшной программы. Проявлялось это так, что breakpoint, установленный в прерывании показывал, что прерывание не вызывается до тех пор, пока не будет выполнен хотя бы однократный останов по другому бряку в любом другом месте программы, даже даже в менее приоритетном прерывании.
Причина была в управлении флагами по которым запрещались/разрешались прерывания. А всего-то навсего закопипастил сравнение вместо присваивания

Да, жостка. Я тоже страдаю такого рода описками. Плюс бывает перед циклом do while забываю проинициализировать локальную переменную цикла. Хорошо, если стек просадит и камень перегружается - тогда ясно. В таких случаях требуется аналитических подход для локализации.

Все с точностью до наоборот У меня прериферия очень разная и очень внешняя (контроллер это почти всегда самый маленький чип на плате ). Контроллеры тоже за многие годы очень разные на пути встречались.

Консоль обязательна. Толщина консоли, для, например MSC51 может более, чем скромная. Многое, очень многое и самое сложное отлаживается на другой машине. Как Вы вообще представляете себе отладку на железе, например обработки оцифрованного сигнала? Только не надо говорить, что приведенная задача это исключительно для толстых контроллеров - это, например, и задача для банальной AVR-ки по измерению преременого напряжения, или посложнее АОН/DTMF какой-нибудь телефонный...

Всегда можно загнать себя у угол .


А что, эту строчку трудно написать без мутной '5' ? А в чем вообще можно в ней ошибиться?

Разумеется нет. Только глупо ошибится/описаться много много сложнее и самое главное получив результат "не работает" много эфективнее просто прочитать и обдумать написанный исходник, нежели тыкаться в снижающем кругозор (а многих, по моим наблюдениям провоцирующем на заплатки ) окошке отладчика. Для ASM писания польза от отладчика естественно много больше. В случаях типа полного рассыпания программы после внесения большого количества изменений отладчик поможет сориентироваться в проблеме. При самых первых шагах на новом контроллере не бесполезен...
Я имею внутрисхемные отладчики на все контроллеры, которые использую, но пользуюсь ими КРАЙНЕ КРАЙНЕ редко - практически только при освоении собственно отладчика .

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




От такого, очень хорошо помогает опыт вдумчивого ЧТЕНИЯ исходников, вместо хватания за эмулятор.
Многие вещи начинают просто бросаться в глаза, особенно.

А от такого - включение в компиляторе ВСЕХ Warnings, Remarks.
Ну не встречал я за последний десяток лет компиляторов, которые не выдали-бы что-то типа
"Expression has no effect"

+ 1. имхо асм + консольная отладка действительно культивируют самодисциплину. Но так не хочется вырываться из сладкого плена си + внутрисхемного эмулятора.

Заметил я, что любите вы, zltigo, банальности изрекать. Видимо считаете, что ваша колокольня самая высокая и самая прямая?

Вполне нормально представляю. Такие задачи отлаживал внутрисхемным отладчиком. Собирается стенд. Подается на вход измеряемый сигнал.
Запускается девайс под отладкой, смотрится результат - будь то посчитанная переменка или распознанный DTMF event. Если результат неверный - выпонение приостанавливается и смотрятся все структуры в памяти, если причины не понятны, добавляются отладочные поля. Повторный запуск и просмотр. Точки останова в ключевых местах, и баг находится не дольше чем за час.


Цифра 5 тут как раз ничего страшного не делает, цифра "5" всегда приведет к запуску таймера, но возможно с разными значениями предделителя на разных МК. А вот более понятный (1 << WGM12) более опасен и на разных МК полностью меняет поведение таймера.



Смотря для каких проектов.
Долгострои с отлаженной операционкой я и сам редко отлаживаю внутрисхемными отладчиками.
А в новых небольших проектах, там где надо сделать hal, портировать ОСку, настроить периферию зачем себя ограничивать?


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

Многие, очень многие вещи банальны, в том числе и слежение за Warnigs, но Вы почему-то этим не воспользовались и предпочли потратить полтора часа на копание в дебагере. Причем после этого сочли возможным укорить компилятор .
Насчет банальностей - нет ничего банальнее в эмбеддерстве, нежели использование внутрисхемного отладчика вместо всего и вся по по анекдотному принципу "а чего тут думать - трясти надо".

Мои 'колокольни', как минимум, ободраны многочисленными моими влезаниями и падениями с них. Я уже писал на этом форуме, повторюсь, я не родился таким "умным" - многое достигалось изучением чужого опыта и собственным. Более того многие из моих 'колоколен' достаточно высоки, дабы говорить о некотором видении горизонтов.

как насчет такого бага:
if ( .... ); // .....
{
....
...
}

или такого
if ( pSmth->x = z )
{
}

слежение за Warning'ами становится нетривиальной задачей, когда в проекте около сотни файлов и около сотни известных warning'ов, порождаемых обращениями к открытым массивам ( Payload[1] ).

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

Вы где-то на этом форуме видели мои призывы к выкидыванию внутрисхемных отладчиков?
Если нет - то о чем это Вы?

Ну знаете уж.. Что может быть достоверней натурного моделирования?
НИ-ЧЕ-ГО.
Вот с моделированием в матлабе и в прочей лабуде как раз и получается результат "какой угодно".


Не понял фразы.
Матлаб я вообще не использую.


В этой ветке! По крайней мере видел, что Вы дали понять - что пользы от внутрисхемных отладчиков мало.

Да, такое обычно молча падает жертвой оптимизации.
Если посмотрите несколько выше на мои посты, то увидите, что включение Warnings было не первым условием - первым ВАЖНЕЙШИМ условием было развитие умения читать исходные тексты. Умение читать на таком уровне 'грамотности', когда всякие 'мелочи' типа лишних или отсутствующих 'запятых' режут глаз. К сожалению, по личным наблюдениям, это умение много хуже развито у чрезмерных пользователей отладчиков (не важно, внутрисхемных или, например Visual C). Чуть что в отладчик и топать, пока отладчик 'пальцем' не покажет. Много хуже другое, что проблемы развиваются и написанием. "Чего-то напишу, а потом, что 'неправильно' отладчик покажет - залатаю" заметно сказывается на результате .

Это возмутительно - какой компилятор позволил себе не выдать Warning|Remark на такое?

Опять изреку 'банальнось' - известные Warnings в 98 случаях из 100 исчезают, если четко выразить мысль компилятору. В одном случае из 100 давятся конкретно в одном конкретном месте конкретной прагмой. И только оставшийся один, относящийся к, например, к портабельности (типа присвоения указателя лонгу совершенно законный на ARM платформе, но череватый при переносе на другую платформу) давится глобально в проекте/make.

P.S.
Еще совет - рекомендую пользоваться С++ компилятором, даже для компиляции "С" исходников - кроме небольших, но приятных, бонусов, обычно более строгие разброки с исходниками.

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

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

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

Смотря что понимать под 'натурным'. Нормальная не 'паркетная' натура, стоит всегда ОЧЕНЬ дорого.
Вы там писали "Подается на вход измеряемый сигнал" от чего он подается? От, например, генертора
синусоиды? Ладно, амплитуду своего лабораторного генератора сможете менять, частоту тоже. Что там с гармониками? Ничего - почти наверняка не изменить. Шумы подмешать сможете - да, если есть генератор шума. А что там с не белыми да розовыми шумами? Ага, ставим еще импульсный генератор. Так, теперь добавляем еще семь синусоидальных генераторов и получаем неплохой стенд для натурного моделирования банальнейшего DTMF приемника.
Спасибо, но такая натура для меня это дороговато будет. Хорошо еще, что не самолет делаю и не надо будет при натурных испытаниях их пачками ломать .
Причем, я вообще не представаляю в какое 'место' сунуть отладчик, если при каком-то сочетании будет неверное распознавание.
Это:

и

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

Да, не много, и уж тем более не панацея, но в наборе инструментов все может пригодитсься - огульным отрицанием не занимаюсь.

15 лет назад писали, что из-за подобного бага даже у NASA прокол получился. Из-за лишней точки с запятой в программе была потеряна связь с аппаратом, запущенным к Марсу или куда подальше (точно не помню уже).

Какой компилятор? В любом случае начать с ознакомления с инструментом и принудительной активизации всей ругани.

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

Я не решил. Просто упорно излагаю свои мысли. Извините, если некоторые из них показались реакцией именно на Ваши посты.

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

IAR EW430 4.32A.

Ознакомлен.

Включена, но что-то там не в порядке в этой версии. Иногда возникают ошибки в том месте, где их до этого не было и где я ничего не менял. Вроде помогает Rebuild All или выгрузка/загрузка среды снова. Я уже покаялся, что начал проект в версии 4.32A, хотя до этого работал с вполне вменяемой 3.30A. Судя по всему команда разработчиков IAR немало багов исправила, т.к. есть сообщение о версии 3.42E, которая видимо только в full-версии имеется. Версия Evaluation по-прежнему только 3.42A доступна.

Не всегда человек властен над реальностью, иногда и она доминирует

Тоже изреку банальность. Современная железка на базе МК без софта, наполняющего его "жизнью", остается "мертвой" и никому не нужной. Се ля ви

zltigo я Вам задам один простой вопрос, приходилось ли Вам отлаживать работу
i2c на чипах AT91SAM7 ?
Если не приходилось, то наверное мы друг друга не поймем
А если приходилось, и Вам удалось это сделать(написать пару десятков строк основываясь только
на даташите), то извините, я Вам просто не поверю, хотя бы на том основании что IAR, из-за
глючности/плохой/ошибочной документации на эти чипы, просто сделала доступ в своих исходниках
по i2c, побайтовым!
Вопрос, сможете ли Вы, без отладчика, написать пару десятков строк для обслуживания i2c
на SAM7 пользуясь только даташитом ?

Нет, но приходилось многое, что другое.

Зато для меня обыденное дело иметь дело с периферийными чипами для которых документация измеряется многими сотнями-тысячей листов. Причем эта документация скудная и ввиду много меньшего круга пользователей такими чипами мнооооого худшего качества. Я пока жив. Разбоки и лабораторные работы трудоемки, обращения support неизбежны, но до сих пор все получалось. Кроме того у меня есть приобретенне за многие годы "чувство железа", а оно только путем логических размышлений достигается а не изучения эмуляторов.

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




Полагаю 3.42
Берем вышеозначенный компилятор. Без всякого заумства в виде добвавления каких-либо ключей,
хотя я обычно сразу добавляю
--warnings_affect_exit_code
--warnings_are_errors
--remarks
компилим:

Получаем:

Вот такой эксперимент.
Вопрос зачем было supress на warning ставить можете задать себе.

IDE не пользую, точнее пользую, но не чаще, чем отладчик

Если patch успели скачать до изменения IAR-ом upgrade политики, то прикрутим его и к Evalution..

Вмешаюсь и Я. А может быть, что АТМЕЛ сделал такие даташиты намеренно? Ну например платные семинары или скорее всего сбор данных о специалистах обращающихся в службу поддержки? Другого обьяснения качества datasheet на sam7 не представляю.
А как там у других АРМов? Может быть они(камни) или дороже/хуже? Раз АТМЕЛ может позволить такой datasheet?

А если так:




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


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


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 по тому же поводу ?

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

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

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

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

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

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

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


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

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

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

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

AVR Studio 4.13.555
Обычно вечером пишу в программе "завет на завтра", утром компильнул - выскочили ошибки - сразу вспомнил, что делать. А сегодня не так.



Результат? Да: "Assembly complete, 0 errors. 0 warnings" Аргументы макросов не проверяются?

проверил: ldi r16,low(CmdSyn) тут неправильно.
Сразу 14 ошибок, на каждую русскую букву.

Не вижу противоречий, макросу передаётся всё, что указано в параметрах вызова. Просто в вашем случае не используется @4="тут" @5="неправильно." Добавьте в определение вашего макроса:

И получите свои 14 ошибок.

А с какого перепугу пробел стал разделителем аргументов?!!
У меня при подстановке аргументов в макрос возникает

И типа всё нормально.
То же самое, написанное в программе, вызывает 14 ошибок. Это, ребята, бага.

Небось, AVRASM 2 ???

Мне по спешке было проще заменить мегу48 на мегу 8, не мог запустить на асме уарт. По свободе попробую исчо. Но даташит это песня.