Proteus - глюки, проблемы с установкой

[pifa]

Снова об I2C для AVR. У меня уже были проблемы с этим. Вот еще одна.
Решил использовать протокол Atmel для прерываний по I2C (AVR311, AVR315). Взял связку ATMega128 - ATMega8535. Истратил уйму времени, чтоб оживить, но все безуспешно. Эту же программу поставил на связку ATMega128 - ATMega8. Работает. Все не проверял, только передачу одной команды (по кнопке). Сейчас буду смотреть дальше.

P.S.
Проверил и остальное. Работает.
Видимо, глюк в модели именно ATMega8535.

[firew0rker]

Proteus 7.10SP0, PIC16F1827. При исполнении инструкции CLRF TRISA пик зависает, т.е. симуляция идёт дальше, пик не выполняет больше ничего.

[Kabron]

Proteus 7.10SP0, PIC16F1827. При исполнении инструкции CLRF TRISA пик зависает, т.е. симуляция идёт дальше, пик не выполняет больше ничего.

Тут принято сопровождать свою претензию тестовым примером...

[firew0rker]

Тут принято сопровождать свою претензию тестовым примером...

Глюк и так просто воспроизвести, но раз надо - вот.

[4epemuxa]

Всем добрый день!
Проблемы с CYCLE COUNT и таймерами.
Пример первый.
Стартуем отладку и еще не шагая имеем CYCLE COUNT=1 (первая картинка)
Ладно. Учли и идем дальше.
Ставим breakpoint на старт и останов таймера. Выполняем несколько раз запоминая значения счетчика и видим, что первый раз переполнение наступает за большее количество циклов. Но ведь это не АЦП!
Пример второй.
Убираем инициализацию таймера в подпрограмму. И в дополнение к первому получаем еще переменное, циклически изменяющееся, время каждого переполнения. Результаты в таблице (вторая картинка)
Проверял и для таймера 1. Аналогично. В Atmel Studio все циклы одинаковы.
Proteus 7.10 sp0

[Halex07]

4epemuxa, начнем с первого пункта:

Стартуем отладку и еще не шагая имеем CYCLE COUNT=1 (первая картинка)
Ладно. Учли и идем дальше.

Стартуем отладку чем??? Кнопов то две и назначение у них совсем разное. Стартуем отладку кнопой с картинки 1 - это сразу выполнение одного шага симуляции (смотри внизу конкретное время), если стартуем ПРАВИЛЬНО, то и имеем то, что нужно (картинка 2).
Вот теперь учли...
Щас гляну, что там у Вас еще... добавлю позже.

[4epemuxa]

Ну это тоже неверно, на первой картинке видно, что указатель стоит на адресе 0000 и первая команда, следовательно, еще не выполнена. И rjmp, в любом случае, выполняется за 2 такта...

[Halex07]

Ну это тоже неверно, на первой картинке видно, что указатель стоит на адресе 0000 и первая команда, следовательно, еще не выполнена. И rjmp, в любом случае, выполняется за 2 такта...

Согласен!!! Зато всегда можно обратиться к первоисточнику и подтвердить примером., что мы и сделаем...
Загоним Ваш тестовый пример в четвертую AVR студию и посЧупаем там. Все-таки это от производителя... Результат намного лучше!!! И лишнего клока в начале перед джампом нет, и точность полная. Табличка в стиле вашего пошиба разве не впечатляет? Вложил и проектик ниже...
Все-таки не стоит забывать, что любой симулятор - это прежде всего программа, и как реализовал то или иное действо программист, это зависит только от него. Искать здесь наносекундного соответствия оригиналу только зря время тратить. Просто надо для себя учитывать такие нюансы.
Кстати, rjmp и выполняется в Протеусе за два такта, а при отсутствии пределителя и тактировании TMR0 тактовой в Протеусе первое прерывание отрабатывает нормально. Пределитель и в реальной таблетке даст Вам ошибку при первом прерывании, хоть Вы его и сбрасываете PSR-ом. В идеале бы его надо останавливать битом TSM, но в Меге 8 это не реализовано.

[4epemuxa]

Просто обидно, что такой удобный инструмент - значительно более высокая скорость симуляции, чем у студии, работа с реальной переферией - и такие неточности со временем выполнения, что не позволяет его использовать для точной отстройки временных интервалов в программе... Часики врать будут. Если это и с другими контроллерами также (с 88 мегой тоже самое, кстати), значит что-то общее с симулятором, а не с моделями. Печально, уж лучше бы я ошибался.

[Halex07]

Печально, уж лучше бы я ошибался.

Да все это нормально для симуляции, просто не надо ставить ее во главу угла или уповать как на манну небесную, что некоторые и делают. И опять-же, если не использовать первое прерывание (ну в смысле тот первый неадекватный цикл), а в общем то все эмбеддеры, про эту хохму знают, и стараются обойти ее стороной, то можно легко воспользоваться любым симулятором. Ну, а насчет того, что "часики врать будут" - это какОТЬ посмотреть и написать... Во-первых, я не помню таких часиков, которые со старта питания сами устанавливают правильно время, дату, ну, может еще и будильники по-желанию клиента (не удивлюсь, если и такие претензии возникнут, ко всякому бреду заказчиков привык). Можно, конечно, уср*ться, и задействовать какие нибудь мировые временные ресурсы, типа серверов или радиомаяков, вот только затраты на реализацию в большинстве случаев будут несопоставимы с итоговым результатом. А это значит, что Вам все-равно проводить первоначальную коррекцию установки времени, так чем тогда вообще Вас смущает первый стартовый цикл прерывания? Остальные то работают адекватно. Кстати, заметьте, что в данном случае мы получаем только один лишний пустой цикл тактового генератора, а в реальности первоначальный сброс занимает в сотни раз больше по времени. Конечно, если вы работаете в Росавиакосмосе, и Вас "взгрели" за ту несчастную упавшую ракету, то да... Тут поневоле начнешь ловить наносекунды и дружить организмами с главным "нанофокусником страны на букву Ч", но для большинства гражданских приложений этот фактор можно легко учесть и предотвратить возможные неточности.