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

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

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

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

А я предлагаю (модераторы, не рвите на части) вообще не пользоваться всякими там протеусами и вмлабами! Здесь сколько раз уже мелькали фразы типа - "В протеусе работает, а на "железе" нет. Поможите!". Да нах такой СИмулятор нужен, если он кроме вопросов ничего не вызывает! Моё мнение - любой проект нужно отлаживать ТОЛЬКО В "ЖЕЛЕЗЕ"! Есть прекрасный инструмент - 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. имхо асм + консольная отладка действительно культивируют самодисциплину. Но так не хочется вырываться из сладкого плена си + внутрисхемного эмулятора.