Внешнее прерывание INT/RB0

[vinni_puh]

Добрый день всем! Попалась засада..понять не могу где сидит.
Есть проц, ПЫК16F714. На нем поднимаю прерывание INT на RB0.

В первом приближении хочу, чтобы оно словило сигнал CS (на этом странном устройстве это ВЛУ), повисело в while пока сигнал есть и вылетело с исчезновением ВЛУ на RB0. Парюсь... А когда пин RB0 сконфигурирован как INT с него вообще читается TTL-уровень???

void main(void) {

OPTION_REG = 0b11000000;//RBPU=1, INTEDG = 1; //rising edge, отключение подтяжки
TRISA = 0b00010000;
TRISB = 0b11001101;
INTCON = 0b10010000; //GIE,INTE=1, INTF=0
RB0 = 0;
RB1 =0;

while(1)
{
;
}
}




void interrupt isr(void)
{
if(INTF)
{
INTF = 0;
while(RB0)
{
RB1 ^= 1; //мигаю с большой скоростью
}
}
}


Если убрать while и оставить только "мигание" то четко видно подмаргивание в момент, когда происходит обмен по шине. Т.е ловится. А с вайлом - мертво. Не ловится условие.

[NStorm]

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

[vinni_puh]

CS это пакетный строб, но внутри еще есть байтовый строб..хочу его захватывать не отходя от кассы.. Будет там где сейчас вайл.

Под мою ответственность))
А захват RB0 вообще легален? Так его опрашивать? Или косяк? Или он тупит и прерывание уже выстреливает а RB0 еще нет?

Собственно мне он там и не нужен (RB0), но не люблю "отложенных на потом непоняток", а честное курение вот именно этого ответа не дает.

[uldemir]

Sorry, no products were found matching your search for "pic16f714" ?????

Ну если от балды, то с 16f84 в своё время была засада. Чтение с порта шло прямиком с TTL уровнями, а на прерывание с того же пина шло через триггер Шмитта. В результате, если амплитуда импульса не достигала порога триггера Шмитта, то лог.1 прекрасно читалась, но прерывание не происходило. Или это было на 16c84? уже не помню точно

[vinni_puh]

Простите, соврал. 716.

[uldemir]

Ну, тогда написанное для 16F84 для этого кристалла тоже в силе:

Какие у вас там уровни "ВЛУ"? по электрическим характеристикам проверяли?

[vinni_puh]

ВЛУ 5V.
Я так понял, должна быть некоторая задержка срабатывания прерывания. У меня обратная ситуация, есть прерывание но нет TTL.
Я же не туплю, "rising edge" - означает по переходу "НЛУ->ВЛУ"??

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

К слову. Компилятор XC8, включил оптимизацию типа standart, с акцентом "оптимизация на время исполнения".(т.к слыхал, что без оптимизации вообще ХС8 в код мусора добавляет и ухудшает тайминги, не знаю на сколько так, но похоже)

[NStorm]

Я же не туплю, "rising edge" - означает по переходу "НЛУ->ВЛУ"??

Да.

У меня обратная ситуация, есть прерывание но нет TTL.

Это ваши догадки пока что.

[vinni_puh]

Скорее всего ДА. Про платку с ПИКом известно только то, что она разработана для захвата данных с этой шины, но производитель отказался давать хексы, вот я и реверсю.

"есть прерывание но нет TTL".
Ммм... код я выложил весь. Разве из него может следовать что-то другое?
Другой вопрос.. это может быть CS не на весь период сессии а только короткий синхроимпульс, и к моменту попадания в вайл его действительно уже нет.

Всем спасибо!

[КРАМ]

[uquote="vinni_puh",url="/forum/viewtopic.php?p=3799552#p3799552"]Всем спасибо![/uquote]
Какие то у Вас убогие методы захвата сигнала...
На этой же ноге сидит ECCP. Так и сделайте на нем захват - он для этого и создан. Сразу узнаете длительность импульса.