Баги симуляторов ... Опции

[Яrik]

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

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

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

Сообщение отредактировал Яrik - Aug 24 2007, 14:26

[Igor26]

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

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

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

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

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

[Яrik]

А фраза "МК ATmega8 рабочая - проверено в Vmlab" меня привела в полный восторг!

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

Моё мнение - любой проект нужно отлаживать ТОЛЬКО В "ЖЕЛЕЗЕ"!

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

[Guest_=AVR=_*]

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

[zltigo]

Моё мнение - любой проект нужно отлаживать ТОЛЬКО В "ЖЕЛЕЗЕ"!

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

Есть прекрасный инструмент - JTAGICE (Zltigo сейчас взбеленится), с помощью которого можно увидеть, что творится с программой и "железом" реально в данный момент времерни.

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

А фраза "МК ATmega8 рабочая - проверено в Vmlab" меня привела в полный восторг!

Это да!

[Яrik]

А фраза "МК ATmega8 рабочая - проверено в Vmlab" меня привела в полный восторг!

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

[Kirill Trusov]

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

[haker_fox]

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

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

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

+1

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

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

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

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

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

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

[defunct]

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

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

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

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

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

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

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

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

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

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

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

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

[haker_fox]

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

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

[vesago]

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

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

[rezident]

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

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

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

Код

void reInitTimer(void)
{ if (flag==FLAG_STOP)
  { flag==FLAG_START; //<==здесь ошибка на которую компилятор даже не мяргнул;)
    ...
    _enable_interrupt(Timer0); //более высокий приоритет у Таймера0
    _enable_interrupt(Timer1); //менее высокий приоритет у Таймера1
  }
}

__interrupt void Timer0(void) //это прерывание не вызывалось до любого останова
{ ...
  if(cntr>=NUM_DOT)
  { ...
    flag=FLAG_STOP;
    _disable_interrupt(Timer0);
    _disable_interrupt(Timer1);
  }
}
__interrupt void Timer1(void) //а менее приоритетное вызывалось, т.к. частота его вызовов была выше
{ ...
}

[vesago]

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

[zltigo]

Ибо вы вероятно работаете с одним и тем же набором камней с одинаковой периферией и операционкой которая покрывает весь "низ".

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

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

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

мелкие AVRки со своим объемом памяти не позволяют разместить ни консоль, ни нормальную ОС.

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

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

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

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

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

Внутрисхемный эмулятор - инструмент позволяющий сэкономить ваше время. Нет причин им не воспользоваться.

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

А всего-то навсего закопипастил сравнение вместо присваивания

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

{ flag==FLAG_START; //<==здесь ошибка на которую компилятор даже не мяргнул

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

[vesago]

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

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

[rezident]

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

[defunct]

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

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

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

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

Я имею внутрисхемные отладчики на все контроллеры, которые использую, но пользуюсь ими КРАЙНЕ КРАЙНЕ редко - практически только при освоении собственно отладчика .

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

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

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

[zltigo]

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

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

Видимо считаете, что ваша колокольня самая высокая и самая прямая?

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

[defunct]

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

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

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

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

[zltigo]

Такие задачи отлаживал внутрисхемным отладчиком. Собирается стенд. Подается на вход измеряемый сигнал....

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

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

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

[defunct]

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

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

А вообще такие эадачи моделирутся НЕ НА ОДНОМ КАКОМ-ТО входном сигнале в Матлабе

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

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

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

[zltigo]

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

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

if ( pSmth->x = z )
{

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

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

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

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

[rezident]

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

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

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

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

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

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

[zltigo]

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

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

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

и

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

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

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

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

[rezident]

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

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

[zltigo]

Дык не было варнига-то!!! В этом-то все и дело!

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

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

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

Опять двадцать пять! А с какого это перепуга вы решили, что я...

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

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

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

[rezident]

Какой компилятор?

IAR EW430 4.32A.

В любом случае начать с ознакомления с инструментом

Ознакомлен.

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

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

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

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

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

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

[singlskv]

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

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

[zltigo]

zltigo я Вам задам один простой вопрос, приходилось ли Вам отлаживать работу
i2c на чипах AT91SAM7 ?

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

Если не приходилось, то наверное мы друг друга не поймем

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

Вам просто не поверю, хотя бы на том основании что IAR, из-за
глючности/плохой/ошибочной документации на эти чипы, просто сделала доступ в своих исходниках
по i2c, побайтовым!

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

IAR EW430 4.32A.

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

Код

    if( count = 3 )
    {  do_dummy();
    }    
    count == 7;

Получаем:

IAR MSP430 C/C++ Compiler V3.42A/W32 [Evaluation]
Copyright 1996-2006 IAR Systems. All rights reserved.
Warning[Pe187]: use of "=" where "==" may have been intended ....
Warning[Pe174]: expression has no effect ....

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

что-то там не в порядке в этой версии. Иногда возникают ошибки в том месте, где их до этого не было и где я ничего не менял. Вроде помогает Rebuild All или выгрузка/загрузка среды снова.

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

есть сообщение о версии 3.42E, которая видимо только в full-версии имеется. Версия Evaluation по-прежнему только 3.42A доступна.

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

[fmdost]

Вопрос, сможете ли Вы, без отладчика, написать пару десятков строк для обслуживания i2c
на SAM7 пользуясь только даташитом ?

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

Сообщение отредактировал Т.Достоевский - Aug 25 2007, 23:06

[defunct]

компилим:
...
Получаем:
Warning[Pe187]: use of "=" where "==" may have been intended ....

А если так:

Код

    if( count = *(volatile char *)0x00 )
    {  do_dummy();
    }

Причем, я вообще не представаляю в какое 'место' сунуть отладчик, если при каком-то сочетании будет неверное распознавание.

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

Спасибо, но такая натура для меня это дороговато будет.

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


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

[rezident]

Полагаю 3.42

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

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

Код

    if( count = 3 )
    {  do_dummy();
    }    
    count == 7;

Получаем:

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

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

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

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

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

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

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

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

С ошибкой

Код

//  100   { GD.cap.flag==CAP_FLAG_NEWSMPL;
        CMP.B   #0x1, &GD + 82
        JNE     ??fStartTimerCap_1
        MOV.B   #0x1, R14
        JMP     ??fStartTimerCap_2
??fStartTimerCap_1:
        MOV.B   #0x0, R14
??fStartTimerCap_2:
        BIT.B   #0x1, R14

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

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

Код

//  100   { GD.cap.flag=CAP_FLAG_NEWSMPL;
        MOV.B   #0x1, &GD + 82

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

[zltigo]

Ну вот. Опять из вас поперло ЭТО

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

Вам весь проект прислать или скриншотов достаточно?

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

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

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

А программа-то глючит безбожно

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

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

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

[rezident]

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

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

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

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

Зачем, черт побери, пользоваться явно прохими продуктами, если есть продукты, которые выпускаются производителями для которых это основной кусок хлеба, а не попытка сделать 'как у всех' натягивая дежурную маску дружелюбности?

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

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

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

[zltigo]

Я вам говорю, что предпреждения у меня НЕ выключены, а вы меня укоряете в том, что я их выключил.

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

Предупреждения и сообщения об ошибках выдает...

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

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

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

Еще раз повторяю, я не зацикленный на отладчике ембеддер.

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

[rezident]

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

[zltigo]

Все понятно стало. Под "продуктом IAR" вы подразумеваете только IDE

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

IDE у IAR самый не профессиональный и неудобоваримый продукт...

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

Если вы имеете сведения..

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

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

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

[ReAl]

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

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

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

С одной стороны:
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) )
и я отстану"
Вторые скобки "прячут" присвоение и "снаружи" остаётся результат присваивающего выражения, он перестаёт ругаться.

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

[defunct]

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

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

Код

    if (jsContext.Cfg.RetransmissionMode = jsContext.AllowedRetransmissionMode); // retransmission mode
    {
        ....

Компилятор 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).

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

Код

    if (jsContext.Cfg.RetransmissionMode == jsContext.AllowedRetransmissionMode); // retransmission mode
    {

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

[Snaky]

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

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

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

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

[_Pasha]

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

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

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

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

[SasaVitebsk]

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

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

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

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

[Igor26]

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

[taranoid]

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

[_Pasha]

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

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

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

Код

ldi    zL, (1<<USBS0)|(1<<UCSZ01)|(1<<UCSZ00)
sts   ucsr0C,zL
ldi    zL,high(BaudRate_value)
sts   ubrr0H,zL
ldi    zL,low(BaudRate_value)
sts   ubrr0L,zL
;.....etc

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

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

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

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

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

[Maik-vs]

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

Код

CP2I    Yh,Yl,high(CmdSyn),low(CmdSyn) тут неправильно.

(где CP2I - макрос :
        cpi    @0,@2        
        brne PC+2
        cpi    @1,@3    )

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

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

Сообщение отредактировал Maik-vs - Nov 19 2007, 07:47

[ae_]

Код

CP2I    Yh,Yl,high(CmdSyn),low(CmdSyn) тут неправильно.

(где CP2I - макрос :
        cpi    @0,@2        
        brne PC+2
        cpi    @1,@3    )

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

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

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

Код

.macro CP2I
ldi r16,@2 @4 @5
.end

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

[Maik-vs]

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

Код

.macro CP2I
ldi r16,@2 @4 @5
.end

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

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

Код

cpi Yl, low(CmdSyn) тут неправильно.

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

[_Pasha]

Это, ребята, бага.

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

[taranoid]

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

[Maik-vs]

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

Небось. Попробовал поменять на асм1, мама дорогая! насыпал 234 ошибки... Я поубирал комментарии //.. и /*.. */, всё равно... Ниасилил.

[011119xx]

в vmlab при просмотре окна периферии для АЦП ATmega64 вместо регистров ADCSRA и ADCSRB стоит регистр ADCSR. При симуляции при записи в регистр ADCSRA происходит изменение регистра ADCSR, а при записи в регистр ADCSRB строка помечается ошибкой и не выполняется

[SasaVitebsk]

вроде работает

Прикрепленные файлы

 macro.zip ( 1.06 килобайт ) Кол-во скачиваний: 29

 

[Igor26]

Не знали о таких?

Как это, нельзя найти в железе, а можно В ПРИНЦИПЕ найти в СИмуляторе? Т.е. я на реальном самолете В ПРИНЦИПЕ не могу попасть в грозовой фронт, а на симуляторе могу?

1. В основе симулятора лежит модель МК. Вы слышали про errata, котрые появляются в процесее эксплуатации сего МК? Что, эти errata регулярно перекладываются на модель МК в симуляторе?????
2. Сделайте в протеусе, или чем-то там еще, устройство, которое содержит под 500 компонентов, из которых пара - это FPGA достаточно жирных, и каждая имеет свою конфигурацию, а остальные примерно 40% компонентов - это ИМС, которые начали выпускаться, ну, например, в прошлом году.
3. Смоделируйте в симуляторе разводку платы в Вашем симуляторе. Вы не сталкивались с ситуацией, типа, на макетке работает, а серийной плате - нет?
4. Ну а теперь скажите, и что же Вы предполагаете выловить симулятором, что невозможно выловить в реальном устройстве? Вы в речке плавать учились тоже по компьютерной модели? А как ремонтировать неисправную аппаратуру? Надеюсь Вы вооружаетесь всякими там осциллографами, тестерами и прочей измериловкой, и начинаете ВЫЧЛЕНЯТЬ неисправность.

[okela]

В АВРСтудии 4.12сп4 была замечена следующая бага (или небага ??).

На Tiny13 запущен таймер с прерыванием при переполнении который отсчитывает циклы работы. По истечении 100 циклов включается sleep (PowerDown mode) с пробуждением по внешнему пину. МК благополучно засыпает, просыпается по внешнему пину. Вроде бы все как надо... но во время спячки продолжает молотить таймер, чего в режиме PowerDown по определению быть не должно ! И в результате просыпается МК также при переполнении таймера.
Может я чего-то упустил из виду ?