Ну грустно конечно, если для Вас это дело второе. Поднят он потому что оно сработало, и вот тут точно никакой другой причины нет: были явно соблюдены условия для срабатывания.kip96 писал(а): А почему он поднят , это уже дело второе.
Вы это серьезно? Вместо того чтобы разбираться, почему оно при включении устройства сработало, будете сбрасывать флаги? Если так, то тут и говорить не о чем...kip96 писал(а):Тем более, что другого решения нет, как сбросить флаги.
Это же Ваши слова?edm2007 писал(а):дело не во флагах.
Решение тут только одно - разбираться, почему прерывание срабатывает. Вы не задумывались, что для декремента переменной нужно два условия? Срабатывание прерывания & низкий уровень на втором выводе. Как так выходит, что без стороннего вмешательства выполняются оба этих условия? Почему у меня в железе этот код нормально себя ведет, без всяких сбросов флагов? Или метод костылей и подпорок Вам ближе и роднее?kip96 писал(а):Тогда предложите другое решение.
Думаю!, и не только во флагах. По этому всегда на ногу "Reset" МК вешаю кондёр с резистором.edm2007 писал(а):Не думаете же Вы, что при включении во флагах мусор?
А надо думать, и уточнять. После моего поста Вы написали что "дело не во флагах". А оно всё-таки во флагах.edm2007 писал(а):Не думал, что уточнять нужно, очевидно же.
edm2007 писал(а):Пины энкодера подтянуты к питанию? Очевидно же, что при включении программа сразу уходит в прерывание
Странно, Вам очевидна проблема, но код у Вас с очевидной проблемой ведёт себя нормально.edm2007 писал(а): Почему у меня в железе этот код нормально себя ведет, без всяких сбросов флагов?
Вам не приходило в голову, что энкодер , при включении МК может находиться в таком положении, что пин может быть замкнут на "0"?edm2007 писал(а):низкий уровень на втором выводе. Как так выходит, что без стороннего вмешательства выполняются оба этих условия?
Безусловно, но я-то прекрасно понял куда Вы клоните. Во флагах, но не в самопроизвольном их возникновении. Срабатывание прерывания отметится флагом, понятное дело. Не за то Вы уцепились.kip96 писал(а):А оно всё-таки во флагах.
kip96 писал(а):Странно, Вам очевидна проблема, но код у Вас с очевидной проблемой ведёт себя нормально.
В коде никаких проблем нет, и если в железе все в порядке, то и ведет он себя нормально. Такое конечно возможно. Не должно быть у исправного энкодера, но чего только не бывает. И-и-и? Начнем с начала. Если прерывание настроено на спад, при каком условии оно сработает? Или еще проще, сработает ли прерывание, если на этом выводе сразу будет низкий уровень?kip96 писал(а):Вам не приходило в голову, что энкодер , при включении МК может находиться в таком положении, что пин может быть замкнут на "0"?
По сему, другого решения нет, как сбросить флаги при включении прерывания.А если сразу высокий? Сработает?edm2007 писал(а): если на этом выводе сразу будет низкий уровень?
А так, нет конечно. Пока перепада с высокого на низкий не будет, прерывание не сработает. И даже если Ваш чудный энкодер будет прижимать пин внешнего прерывания к земле до старта МК, при включении прерывание не сработает. edm2007 писал(а):Пины энкодера подтянуты к питанию? Очевидно же, что при включении программа сразу уходит в прерывание, и считает что на втором пине тоже 0. Потому и декремент переменной.
Так это для Вас же очевидно! Вы нам и объясните!edm2007 писал(а):Пока перепада с высокого на низкий не будет, прерывание не сработает
Очевидно - это относится к тому, как такое могло произойти, что при включении никто ничего не трогал, а переменная уменьшилась (и перевалила через 0). Прерывание сработало и на втором выводе тоже был 0. Логично же? Других вариантов нет. Как могло сработать прерывание? Только по перепаду с высокого на низкий. Следовательно, Ваша версия с кособокими энкодерами, у которых один вывод уже прижат к земле не жизнеспособна. Нужен перепад, а тут всегда земля. 
Вы уже путаетесь. У меня не было ни когда такой версии. Я ответил на Ваш вопрос, как "и на втором выводе тоже был 0"edm2007 писал(а): Прерывание сработало и на втором выводе тоже был 0. Логично же? Других вариантов нет. Как могло сработать прерывание? Только по перепаду с высокого на низкий. Следовательно, Ваша версия с кособокими энкодерами, у которых один вывод уже прижат к земле не жизнеспособна
Еще бы.kip96 писал(а):У меня не было ни когда такой версии.
Естественно, это моя версия. Это я анализировал, как могло произойти, что при включении программа сразу попала в прерывание и уменьшила переменную. Понятно? Прерывание сработало и на втором выводе оказался 0. Именно это и очевидно. Все еще понятно? Как могла уменьшиться переменная понятно. Другое дело, почему это произошло. Энкодер не крутили, перепадов не создавали, а оно все равно произошло. Как Вы? Не потеряли нить? 1. Пин INT0 настроен на выход (точнее весь порт D, а INT0 под раздачу попал, потому как он PD2)kip96 писал(а):Вот вам идеальные условия
Нет, не догадываюсь, просветите!edm2007 писал(а):Догадаетесь, почему?
Код: Выделить всё
$baud = 38400
Из всех наших дебатов понял, что очевидно, что прерывание сработало, и навело на эту мысль подтянутые пины энкодера к питанию, энкодер у автора тоже видимо глючный, либо кондёр на ноге большой, дело не во флагах, и просто так их сбрасывать опасно.edm2007 писал(а):Пины энкодера подтянуты к питанию? Очевидно же, что при включении программа сразу уходит в прерывание
Но тут уж действительно, каждому - свое. Не хочется разбираться, с какого это перепугу прерывание само сработало, ну да и ладно. Проще флаги сбрасывать, ну да ради бога. Можно таймер завести, чтобы само все сбрасывалось, мало ли чего, а ну как сработает еще само. Завтра, например. В этом-то все и дело.kip96 писал(а):Вы же не хотите неожиданностей.
На этом закончим, было бы о чем спорить.присоединяюсь, было бы интересно узнать Ваш вариант решения моей проблемы, возможно он будет более правильным,kip96 писал(а): Я предложил решение проблемы, Вы его оспорили "дело не во флагах." И написали , что Вам что-то очевидно. Вот и расскажите Вашу версию, может она лучше.
