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

Halex07 · 03.04.2012, 18:15

1Dimon1, эмоций много, толку никакого "у_сройство" может и у_сраться, но хотелось бы видеть пример некорректной работы, чтобы было за что зацепиться. Аналогично и с перегрузом ЦП - это можно сделать как в кинЕ: "легким движением руки брюки превращаются...". Студия ожидает... ЭкстрасеКс уже машет руками...

1Dimon1 · 04.04.2012, 08:28

Извините, вопрос снят, все таки ошибка была в коде, но возникала произвольно (при старте прописывался флаг внешнего прервывания и он мешал выполнению процедуры прерывания когда это действительно был нужно, сейчас это скорректировано.) вопрос о загрузке процессора - актуален. в прицепе - мой проект. там есть процедура начальной инициализации (после включения необходимо нажимать кнопки в определенной последдовательности - имитация отработки механики).
последовательность следующая: 1) датчик парковки, 2)после начала вращения нижнего двигателя - нажать кнопку датчик №2, загориться зеленый светодиод -нажать последовательно датчик №1 и датчик №2.
дождаться пока повторно начнет вращаться нижний двигатель и повторить процедуру 2. после этого - устройство работает. на U2 - имитация системы радиоуправления (8 каналов, стандартный PPM) но выведено только 6 каналов. 3-я пара переключателей - управляет верхним двигателем. кнопка sw9 -отдельная исторя, ее пока касаться не будем - условие - держать в зажатом состоянии.

ELena-Elena · 11.04.2012, 16:44

Помогите пожалуйста, не могу добавить компонент, выходит такая ошибка:

Dok_Alex · 11.04.2012, 18:43

Столкнулся с глюком при использовании прерывания по изменению уровня на входах RB4..RB7.
Если подавать чисто цифровой сигнал, проблем нет. Но если сигнал имеет хотя бы незначительные значения dU/dt (наклоны фронтов), то наблюдаются вторичный (глюковой) уход в прерывание как по переднему, так и по заднему фронтам, хотя сигнал по факту не имеет никаких выбросов или спадов.
Кто-нибудь может объяснить причину подобного поведения???
Всё предельно ясно видно в приведённом проекте. Пробовал в разных версиях Proteus, выяснил, что от версии не зависит. Попробуйте попереключать разные источники сигналов и посмотрите повнимательней осциллы (фронты сигналов).
В качестве решения, приходится между процом и источником сигнала ставить доп. инверторы, тогда всё в норме.

1Dimon1 · 12.04.2012, 08:14

Запретите прерывание (лучше в процедуре его обработки) и уже потом (когда нужно будет) включите его снова.

Dok_Alex · 12.04.2012, 09:43

Цитата:

Запретите прерывание (лучше в процедуре его обработки) и уже потом (когда нужно будет) включите его снова.

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

Someone · 12.04.2012, 10:57

Сообщение от 1Dimon1

при старте прописывался флаг внешнего прервывания

А об этом я тут уже не один раз и не первый год твержу, изменений 0. Версии 4 сменилось, а флаги внешних прерываний так и стоят в 1 после запуска симуляции.

Сообщение от 1Dimon1

все таки ошибка была в коде

и таки это не ошибка в коде, а ошибка исиса, потому что в реальном авр (впрочем и в симуляторе студии), после подачи питания флаги внешних прерываний сброшены.

Сообщение от 1Dimon1

и он мешал выполнению процедуры прерывания когда это действительно был нужно

Для того, что бы побороть сей глюк протеуса достаточно знать о нём, и перед разрешением глобальных прерываний командой sei сбросить эти флаги, записав в них логические 1. В частности для тини2313 это будет выглядеть так: GIMSK = 0xE0; Ну а когда надобность в симуляции в протеусе отпадёт, удали или закоментируй эту строчку. А можешь и оставить. Как пятка почешется.

1Dimon1 · 13.04.2012, 10:03

Спасибо, именно это и было сделано, сейчас вопрос о загрузке ПК больше 100 процентов, причем сравнивалось на разных (по мощности ПК) и результаты были примерно одинаковы.... ну а очистку флагов оставлю - не помешает...

1Dimon1 · 13.04.2012, 12:57

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

Halex07 · 13.04.2012, 22:16

ELena-Elena, судя по картинке - это внутренняя ошибка ARES при попытке открыть окно вьювера (просмотрщика библиотек). Что-то у вас коряво в установке Протеуса. Версия какая? Какая ОС на компьютере. И пользовались ли русификатором - очень частая причина таких улетов.

Dok_Alex, я готов преклоняться перед "пытливым русским умом", но боюсь, что авторы Протеуса не учитывали, что кто-то додумается подавать на цифровой вход микроконтроллера синусоиду амплитудой +-5V и не просчитали Ваш вариант. Не знаю как поведет себя "железный" 16F628A с таким сигналом на RB4, выдержат входные защитные диоды или нет - я как-то тоже далек от таких экспериментов в железе, и без этого "палева" хватает, но если даже в симуляторе подавать адекватный сигнал на вход RB4 - картинка - пусть даже и медленно меняющийся (я постарался положительный импульс максимально аппроксимировать к вашей синусоиде, которая оставлена без изменений), МК ведет себя вполне прилично и никакого "дребезга" в прерываниях не наблюдается.