Сложно, потому что есть спрос и в тех местах шастает слишком много людей по тем же самым магазинам(без интернета же), получается как в море вымывается песок водой и остаются одни камушки — люди покупают простые часы а остаются не очень популярные и дорогие.
таймер или delay — это не так важно, просто с прерываниями появляются дополнительные проблемы — прерывание реагирует на каждый импульс в том числе и на дребезг и с этим что-то надо делать. Если же просто опрашивать кнопки со строго заданным интервалом то все эти проблемы решаются сами собой — и дребезг устраняется для всех датчиков сразу и узких мест нет. Просто считываем состояние датчиков в ячейку памяти, делаем XOR с предыдущим значением и у нас есть вся необходимая информация для решения — какой датчик изменил своё состояние и в какую сторону.
Именно с точки зрения логики этот алгоритм прост и легко проверяем а значит более надежен, хотя может и вылиться в большее количество строк чем с прерываниями. Но количество строк кода это не показатель, главное это сложность и надежность алгоритма.
Ну замечательно, чего. С дребезгом тут можно столкнуться, если вдруг состояние входа изменится между проверками — между UPDATE и READ. Отловить такое событие будет чрезвычайно трудно, но оно будет происходить.
И столько кода для считывания состояния входов? из мухи слона… нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.
Мы уходим от темы, в обычных клавиатурах организация матричная и коллизии при нажатиях двух и более кнопок неизбежны, так получается by design.
У нас же 6 входов ОТДЕЛЬНЫХ, умудрится сделать так чтобы программа вела себя не адекватно при одновременном срабатывании датчиков в произвольных комбинациях — это высший пилотаж.
Есть 6 входов, никаких матриц — поэтому логично требовать от программы работы во всех комбинациях и любыми одновременностями.
Независимых прерываний тут только два — INT0 и INT1.
PCINTx имеют один общий обработчик на каждый порт и не умеют работать по отдельным фронтам — только на изменение уровня. замаешься определять какая ножка и куда перешла и потом обрабатывать эти события а потом еще и подавлять дребезг индивидуально по каждому входу, разруливать как-то ситуации когда прерывание по другому входу возникает во время обработки, а если оно возникнет в тот момент когда контроллер еще будет входить в прерывание еще до сравнения состояния входов?
Все это называется одним словом — из мухи раздувать слона. PCINT — хороши для матричных клавиатур, чтобы пробудить контроллер из спячки по нажатию любой кнопки.
Не, не вариант… маленького балончика хватает на несколько секунд. Ну это просто смешно. Компрессора с ресивером на 20Л хватает на пол минуты… а это такая бандура.
Пожалуй, от балончика бор успеет только раскрутится.
200мс в тех часах это скорей всего период сканирования кнопок клавиатуры, раньше он просто видимо не успевает зарегистрировать факт нажатия. да и речь все же идет не о кнопках а датчиках, которые срабатывают хоть и медленно но полностью асинхронно и независимо друг от друга — могут ведь сработать и все 6 одновременно с точностью до десятков наносекунд!
Будет очень смешно и весело, если программа не справится с одновременным нажатием кнопок…
О нет, она конечно умеет при необходимости, но тут проблемы другого плана. Аппаратных прерываний всего два а надо 6 датчиков подключить… приходится задействовать прерывание по изменению состояния порта, а оно будет ОДНО на все датчики — это значит что надо будет отслеживать какой именно датчик привел к прерыванию, — эта операция не атомарна, состояние датчика из-за дребезга до проверки может изменится и программа не обнаружит ничего. Надо усложнять код, бороться с дребезгом и последствиями неатомарности операций — зачем этим всем забивать голову когда есть простые понятные и эффективные решения?
Зависнуть он не может, но от вибрации не застрахован, правда у мелких герконов вибрация нужна такая что его просто разорвет в клочья. В целом, конечно герконы срабатывают четче чем механические кнопки.
больше-то оно не вредно, речь идет о минимальной длительности — вдруг импульс проскочит мимо проверок, и не будет зарегистрирован… Это граничное условие — импульс длительностью ровно в период опроса. Больше — будет зарегистрирован всегда, меньше — как повезет. В данном случае, геркон замыкается на протяжении 2-3Л по счетчику, нетрудно догадаться при каком расходе счетчик даст импульс короче одной секунды и соответственно когда начнутся проблемы.
да… городить историю с прерываниями чтобы потом дополнительно бороться с дребезгом программно — замечательный способ нагрузить себя ненужной работой. Существующий подход и так хорошо справляется с работой. Только надо иметь в виду, что длина импульса с геркона — всего 2-3Л, т.е. при скорости потока 2Л/сек и больше существует шанс что программа не заметит импульс, впрочем при таких значениях эту особенность скорее надо иметь в виду чем что-то предусматривать. Вдруг устройство попытаются поставить на промышленный трубопровод, где поток воды больше… а тут такая засада.
Все эти фильтры не избавляют от дребезга, только лишь уменьшают его влияние. Ну зафильтруешь, всеравно фаза луны сойдется и пропустит один из тысячи импульсов дребезга. Самый надежный способ избавления от дребезга — это одновибраторы(но повышается чувствительность к помехам — ведь любой самый короткий импульс будет рассмотрен как срабатывание) или синхронный триггер защелкивающий состояние линии каждые N милисекунд, где N заведомо больше периода дребезга контакта.
Собственно, второй вариант с синхроным триггером сейчас и реализован программно — данные защелкиваются для последующего анализа раз в секунду. Недостаток этого подхода — негарантированное время реакции на срабатывание.
Часто бывает потеря электричества на целый день? Ну, подумаешь местами на время отключения света статистика будет несколько сглажена, зато скольких проблем удастся избежать. Другое дело конечно если вы педант и даже такая мелочь вас беспокоит… тогда да, потраченные ресурсы скорей всего будут оправданы.
Конденсаторы это не выход, они лишь уменьшают дребезг но не избавляют от него совсем, один из ста импульсов все же проскочит.
И еще интересное замечание. Герконы ведь обычные контакты, чтобы считать их состояние необходимо «подпереть» их резисторами, а в некоторых комбинациях(все счетчики остановились в состоянии «замкнуто») ток через эту подтяжку может свести на нет все старания по энергосбережению. Имеет смысл, включать подтяжку за 100-200мкс до считывания состояния датчиков и после отключать. И подтяжку сделать посильнее, 1...5кОм иначе могут запросто ловится наводки, 50кОм — уже ловит статику по входу как изменение уровня, встроенная подтяжка тоже никуда не годится — слишком мягкая.
Все сигналы с датчиков желательно зашунтировать супрессорами, иначе ардуинка вылетит вмиг от близкой грозы, все-таки провода слишком близки от труб в которых будет наводится напряжение от ЭМИ грозового разряда. Поверь, это будет не лишним — есть печальный опыт всего лишь торчащим проводком длиной 30см из обесточенного компьютера — при следующем включении сгорел RS-232 выходной драйвер(с дымком) и чипсет(через 4 секунды) на материнке. А в гараже вольтметр(электронный, питается от измеряемой цепи) подключенный к 2-м метрам свободно висящих проводов просто разлетелась физически микросхема на части, не говоря о сгоревших защитных стабилитронах в питании.
Именно с точки зрения логики этот алгоритм прост и легко проверяем а значит более надежен, хотя может и вылиться в большее количество строк чем с прерываниями. Но количество строк кода это не показатель, главное это сложность и надежность алгоритма.
И столько кода для считывания состояния входов? из мухи слона… нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.
У нас же 6 входов ОТДЕЛЬНЫХ, умудрится сделать так чтобы программа вела себя не адекватно при одновременном срабатывании датчиков в произвольных комбинациях — это высший пилотаж.
Есть 6 входов, никаких матриц — поэтому логично требовать от программы работы во всех комбинациях и любыми одновременностями.
PCINTx имеют один общий обработчик на каждый порт и не умеют работать по отдельным фронтам — только на изменение уровня. замаешься определять какая ножка и куда перешла и потом обрабатывать эти события а потом еще и подавлять дребезг индивидуально по каждому входу, разруливать как-то ситуации когда прерывание по другому входу возникает во время обработки, а если оно возникнет в тот момент когда контроллер еще будет входить в прерывание еще до сравнения состояния входов?
Все это называется одним словом — из мухи раздувать слона. PCINT — хороши для матричных клавиатур, чтобы пробудить контроллер из спячки по нажатию любой кнопки.
Пожалуй, от балончика бор успеет только раскрутится.
Будет очень смешно и весело, если программа не справится с одновременным нажатием кнопок…
Собственно, второй вариант с синхроным триггером сейчас и реализован программно — данные защелкиваются для последующего анализа раз в секунду. Недостаток этого подхода — негарантированное время реакции на срабатывание.
И еще интересное замечание. Герконы ведь обычные контакты, чтобы считать их состояние необходимо «подпереть» их резисторами, а в некоторых комбинациях(все счетчики остановились в состоянии «замкнуто») ток через эту подтяжку может свести на нет все старания по энергосбережению. Имеет смысл, включать подтяжку за 100-200мкс до считывания состояния датчиков и после отключать. И подтяжку сделать посильнее, 1...5кОм иначе могут запросто ловится наводки, 50кОм — уже ловит статику по входу как изменение уровня, встроенная подтяжка тоже никуда не годится — слишком мягкая.
Все сигналы с датчиков желательно зашунтировать супрессорами, иначе ардуинка вылетит вмиг от близкой грозы, все-таки провода слишком близки от труб в которых будет наводится напряжение от ЭМИ грозового разряда. Поверь, это будет не лишним — есть печальный опыт всего лишь торчащим проводком длиной 30см из обесточенного компьютера — при следующем включении сгорел RS-232 выходной драйвер(с дымком) и чипсет(через 4 секунды) на материнке. А в гараже вольтметр(электронный, питается от измеряемой цепи) подключенный к 2-м метрам свободно висящих проводов просто разлетелась физически микросхема на части, не говоря о сгоревших защитных стабилитронах в питании.