Напоследок, на первой странице обработка дребезга по 4 входам параллельно 644 байт (2%). Готов обсуждать если будет меньше....
Да я то понял. Я ж говорю - если кнопка порождает прерывание (проц спит и мы его будим), то твой код очень даже красивое решение. Но я всегда буду решать задачи аппаратно, если их можно решать аппаратно. Просто я минималист по жизни.
А вот нифига, минималист как раз я, все решается программно, причем прекрасно!!! Без обвязки, и особенно заметно это в серии!
Я сказал аппаратно, а не схемотехнически))) Аппаратно - это если мы можем задействовать логический блок в xmega для решения булевой задачи, значит его надо задействовать, а не вычислять программно.
Пойду я спать Почитайте, на досуге, Решение очень простое, и очень красивое, Главная проблема мало кто понимает, как работает Для опроса кнопок, датчиков с сухими контактами, сигнализаций со шлейфами - лучше не придумаешь... Ну, если нет - так нет, больше предлагать не буду....
Идея правильная, то же самое делается в следующих строчках для 8 битов (8 входов) за раз и за 1 вызов функции. Код (C++): uint8_t vc_debounce(uint8_t SWKEYS) // Verical_Couners_debounce, вызывается каждые 10 мсек, можно из таймера { // в SWKEYS состояние вводов static uint8_t SLATCH = 0; // текущее устоявшееся значение входов после устранения дребезга static uint8_t VCBIT0 = 0; // счетчик бит 0 static uint8_t VCBIT1 = 0; // счетчик бит 1 uint8_t vcmask = 0; // Маска uint8_t vctemp = 0; // vcmask = SWKEYS ^ SLATCH; // скинем счетчики для установившихся и неактивных значений VCBIT0 &= vcmask; VCBIT1 &= vcmask; // Каждая '1' в SLATCH представляет установившееся значение // каждый '0' установившееся нулевое значение SLATCH ^= (vctemp = vcmask & VCBIT0 & VCBIT1); if( vctemp ) // есть изменения входов, взведем флаги { LATCH_ON |= vctemp & SWKEYS; // взведем биты нажатых кнопок и сработавших входов. LATCH_OFF |= vctemp & ~SWKEYS; // Биты сбрасываются в обработчиках. } VCBIT1 ^= (vcmask & VCBIT0); // инкрементируем счетчик. VCBIT0 ^= (vcmask); }
Я пытаюсь всем объяснить, но никто не хочет понимать, что вместо того, чтобы бегать и опрашивать каждый вход отдельно, потом в цикле проверять как он изменился, можно просто сложить все входы в байт, отбросить все изменения, за раз, и в 10 строк, для всех входов, понять, что изменилось и что уже стабильно последние 4 запроса. .. Но, это тут никому не нужно, будем форить, вайлить, нахрен оптимизация.... 300 команд против 30 и пофиг... Зато, все хотим поговорить, как соптимизировать код....
Осталось добавить, ну не понимаете Вы как это работает, ну скопируйте, проверьте и пользуйтесь!!! Код оптимален, меньше не получится - искал. Не хотите - не пользуйтесь, пользуйтесь последовательной обработкой каждого входа и последовательным анализом изменений на нем... Ну проверено не раз, все же работает на ура, и пример выложен! Ну, блин... расстраиваюсь...
День добрый. Спасибо всем. Не ожидал что такая дисскусия возникнет. Думаю что полезно знать как можно больше способов. И каждый способ хорош если применять его к месту. А целом ребята давайте жить дружно). А то чуть священная война не началась).
Идея хорошая. Но для трех кнопок, например, уже надо смотреть - возможно опрос в лоб будет и быстрее и компактнее по коду. Это актуально для малышей с 1-4 кБ памяти на борту.
Да какая война Идея не моя, где-то нашел. Делал для себя очередное устройство, и задался вопросом, как лучше опрашивать входы (шлейфы) и кнопки, с отсеиванием всевозможных помех и дребезга. Подумал может есть "правильный" вариант, вместо изобретения велосипеда, решил поискать. Когда нашел, разобрался - прифигел от оптимальности скорости работы. Использую уже давно, и радуюсь. Хотел до народа донести, но, видимо не судьба пока...
Попробуйте, все же только критикуют, говорят: Я, и для двух так делаю. Согласен, здесь это не нужно, просто вчера за 10 минут правил то, что выкладывал тут Там нужно.