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

[Яrik]

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

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

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

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

[Яrik]

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

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

[defunct]

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

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

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

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

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

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

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

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

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

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

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

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

[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"

[defunct]

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

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

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

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

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

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

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

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

[zltigo]

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

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

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

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