[Яrik 0]

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

 

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

 

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

Изменено 24 августа, 2007 пользователем Яrik

[Igor26 0]

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

 

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

 

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

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

 

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

[Яrik 0]

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

 

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

 

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

 

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

[Гость =AVR=]

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

[zltigo 0]

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

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

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

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

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

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

Это да! :)

[Яrik 0]

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

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

[libricon 0]

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

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

протеус вообще с уартом не пашет нормально с мегой8 , хотя в железе работает

[haker_fox 60]

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

Ну так если действительно абсурд. Вы проверили программу в VMlab (а это тоже симулятор) и говорите, что она рабочая. Вините протеус. Так может протеус верно говорит: программа не работает, а VMlab врет? :a14:

Тем более не все улыбались, Вам дали много хороших советов!

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

 

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

+1

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

+1

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

 

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

А зачем тогда симулируете?

Слово вполне настораживает.

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

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

[defunct 0]

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

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

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

 

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

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

 

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

 

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

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

 

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

 

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

TCCR1B = (1 << WGM12) | 5;

Синтаксически все правильно. На разных МК будет совершенно разный результат.

Чем тут может помочь инструментальная машина?

 

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

 

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

[haker_fox 60]

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

Я свято не верю. Вожно мой небольшой опыт пока не позволяет сделать верных выводов.

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

[vesago 0]

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

 

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

Периферию в симуляторе конечно не проверишь. Некоторое исключение - кейл. Я в нем и связь с хостовой программой отладил и i2c. Но все равно прикупил мтлинк.

[rezident 0]

Вроде все уже сказали правильно. В симуляторе отлаживаются программные алгоритмы, с помощью эмулятора (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 0]

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

[zltigo 0]

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

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

Плюс у вас есть довольно толстая консоль (по меркам 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 0]

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

 

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