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

[Bumbarra]

Вот во вложении проект в протеусе:
Как видишь, все прекрасно работает.
Два синусоидальных сигнала подаются на входы RA0 и RA1 контроллера. Они являются входами двух аналоговых компараторов. Вторым входом компараторов является внутренний источник опорного напряжения, управляемый регистром VRCON. Как только напряжение на любом из входов RA0 или RA1 превысит порог 3,12 В, будет вызвано прерывание.
Определяется источник прерывания - модули аналоговых компараторов, определяется на каком конкретно модуле компараторов произошло превышение и формируется выходной сигнал на порт Б

Если всенепременно желаешь использовать этот самый контроллер и цифровые входы, тогда обязательно нужен внешний формирователь фротнов с гистерезисом срабатывания. Регилия это не запрещает. Контроллер то универсальный, а не специализированный, к тому же, довольно старый и простой.

Только прошу заметить, это ни в коем случае не глюк протеуса.

[Dok_Alex]

Регилия это не запрещает.

Bumbarra, я вообще атеист. Спасибо конечно за описание работы модуля компараторов, но с этим вопросов нет никаких абсолютно.

Контроллер то универсальный

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

[Dok_Alex]

Провёл серию опытов по выявлению возможности сбоя при прерываниях по изменению уровня сигнала, подобного, что был при симуляции. Подавал полусинусоиду начиная от 1гц, пробовал наблюдать переключения при медленном заряде конденсатора и т.п.
В резултате не было выявлено ни единого паразитного ухода в прерывание, подобного при симуляции в Proteus. Так что, всё-таки можно смело использовать прерывания по аналоговым сигналам на цифровых входах TTL, но с умом! На практике всё работает без проблем!
Конечно, следует понимать при этом, что есть вероятность сбоя при попадании "шума" в пороговую зону, если уровень шума будет больше ширины этой пороговой зоны.
Т.е. использовать нужно с осторожностью и пониманием! Соответственно, чем круче фронты прерывающего сигнала, тем теоретически меньше вероятность сбоя. При крутизне фронтов от единиц до десятков микросекунд, такая вероятность стремится к нулю, т.к. на выход из прерывания требуется примерно такое же время, с такими фронтами, можно даже не переживать за сбой. Также на МК с высокой тактовой частотой, теоретически вероятность сбоя выше при тех же прочих условиях.

[dosikus]

Подобные "глюки" скорее не мешают, а помогают тем, что приходится делать подобный "разбор полётов". За это только огромное спасибо разработчикам из ёркшира. Если бы не заметил сбоя при симуляции, то не обратил бы внимания, и как следствие, в железе была бы как минимум мина, замедленного действия.

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

[Dok_Alex]

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

Не согласен, я не говорил, что изучать нужно только по симулятору. Я сказал, что в симуляторе можно увидеть то, чего не замечаешь в железе. И для чего тогда симулятор, чтоб не видеть в нём "глюков", пусть даже они и по не знанию. Вот увидел и узнал, это и есть процесс обучения. Разве не так? Существуют ли программисты, которые знают всё и сразу?
В железе я никогда подобного не видел, всё всегда работало без проблем, увидел только в симуляторе, поэтому и написал.

Продолжение темы.
Не всё так просто, оказывается.
Просьба обязательно посмотреть представленный демопроект!!! Всем будет очень интерестно.
Тут уже зона неустойчивого состояния не причём.
Прерывания происходят из стабильного уровня нуля и единицы. Попробуйте для дополнительного интереса подёргать переключатель.
Вопрос: что вызывает прерывание при нулевом входном уровне??????????????????? И всё-таки глюк, похоже... Или я чего-то не доглядел опять? Уважаемые коллеги, что теперь скажете???

[d2812]

v7.8 SP2.PIC16F627A,628A,отладка,отображение: Регистр PORTB,выводы на Вход --- при изменении сигнала во время Отладки,не отображаються изменения сигналов в Регистре,при этом :
tm_flag
btfsc PORTB,0
btfss PORTB,0
goto tm_flag
movwf taimer
работает правильно.
Как исправить Отладчик ?
С кодом проблемм нет,"косяк" в Отладчике ------ не отображаються изменения сигналов в Регистре PORTB,пример:изменяю на входе RB0 с "0" на "1" ,код Работает,а в Регистре как был "0" так и остаеться.
В MPLAB все ОК.
p.s.v.P7.9sp1,P710sp0 --- "глюк" остался,изменения Отображаються только после Сброса.

[Bumbarra]

Блин, нажуевертил в коде, стака букав, стока букав... А че, проще нельзя написать? Без формирования чего-то на выходе, без кучи звездочек и мега-коментариев. Вметсо пробелов - есть кнопка Tab на клавиатуре - она выставит аккуратную табуляцию, то есть, сдвиг вправо текста.

Возьми и пошагово просимулируй, глядя за исполнением кода в окошке PIC CPU Source Code. Поставь Breakpoint напротив адреса программ 0х04. и запусти симуляцию. Как только произойдет переход по вектору прерываний, симуляция остановится. И ты увидишь, как пройдет проверка флагов прерываний и какие действия будут выполняться.

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

То есть, проверяем, установлен ли флаг INTCON, RAIF. Если установлен, тогда переходим в другую подпрограмму и выполняем какие-то действия. Если этот флаг не установлен, тогда переходим к обработке ошибочного прерывания. В простейшем случае - это просто возврат из обработчика.

Interrupt:
	btfsc INTCON, RAIF
	goto IntOnChange
End_Interrupt:	
	retfie
; ..............................
IntOnChange:
    ..тут текст того, чего выполнить надо..
	bcf INTCON, RAIF
	goto End_Interrupt

А не так, как ты в тексте написал. У тебя все равно выполняются действия с выходным портом.

btfss flags,RA2
goto on_RA2 
goto off_RA2

"если второй бит из какого-то регистра "flags" установлен, то перейти на off_RA2, а если сброшен, то перейти на on_RA2, а дальше проделать ваапче накуюто херню"

Что такое "flags,RA2"? Ему присвоен адрес 0х30? А это что там? По этому адресу располагается регистр общего назначения и никакого отношения он не имеет к прерываниям.
Interrupr-on-change не относится к перифирийным модулям. А ты в тексте разрешаешь прерывания по ним - INTCON,PEIE. Ну вот и получается, что любой другой модуль может установить флаг и перейти по вектору. А там, где ты проверяешь флаги - обязательно выполнится действие по включению порта.
Хотя, конечно, после сброса контроллера все биты разрешения и флаги прерываний сброшены.


К тому же, уже не раз говорилось, что симуляция - это только симуляция. Если при симуляции устройство работает, это не значит, что оно будет работать в "железе". И наоборот, если не работает при симуляции - еще не значит, что в "железе" не будет работать.

Прерывания происходят из стабильного уровня нуля и единицы. Попробуйте для дополнительного интереса подёргать переключатель.

Подергать переключатель во время запущенной симуляции? А попробуй подергать переключатель в "железе"

[dosikus]

Как исправить ?

Проект в студию ...

[Bumbarra]

Dok_Alex
А вообще...
3.2.2 INTERRUPT-ON-CHANGE
Each of the PORTA pins is individually configurable as
an interrupt-on-change pin. Control bits IOCAx enable
or disable the interrupt function for each pin. Refer to
Register 3-4. The interrupt-on-change is disabled on a
Power-on Reset.
For enabled interrupt-on-change pins, the values are
compared with the old value latched on the last read of
PORTA. The ‘mismatch’ outputs of the last read are
OR'd together to set, the PORTA Change Interrupt flag
bit (RAIF) in the INTCON register.
This interrupt can wake the device from SLEEP. The
user, in the Interrupt Service Routine, can clear the
interrupt in the following manner:
a) Any read or write of PORTA. This will end the
mismatch condition.
b) Clear the flag bit RAIF.
A mismatch condition will continue to set flag bit RAIF.
Reading PORTA will end the mismatch condition and
allow flag bit RAIF to be cleared

[dosikus]

Разве не так? Существуют ли программисты, которые знают всё и сразу?

Естественно нет , но и не все сразу бросаются за писанину с криками "глюк программы"...