Pull to refresh

Comments 14

UFO just landed and posted this here
Если уж так беспокоит дребезг, используйте кнопки на размыкание. Заодно пресекаются возмущения в духе «я раньше нажал, а в пульте где-то контакт отходит, с первого раза не сработало».
На размыкание точно такой же дребезг как и на замыкание. Условия тут одинаковые.
Разве? Мне всегда казалось, что причина дребезга в том, что контакты при соприкосновении несколько раз отскакивают друг от друга, и цепь кратковременно разрывается. А если мы их размкаем, какая сила заставит их замкнуться обратно?
Там те же процессы происходят. При размыкании подпружиненный контакт начинает вибрировать(не только в горизонтальной, но и в вертикальной плоскости, начинает изгибаться), и с самого толкателя приходит вибрация, потом еще действие самого тока… на маленьких расстояниях даже от 1В пробивает зазор напряжением.
Устройства нет, есть макет на котором была проверена программа. Как один из вариантов реализации данной функциональности.Это ведь не описание законченной разработки, а реплика в тему.
Надо фото макетки?
программа дает 10 секунд на ответ сразу после детекции нажатой кнопки. В реальной игре вроде бы ведущий должен подтвердить право ответа, указав на игрока, первым заявившего желание ответить — и время хорошо бы отмерять именно от этого приглашения. Если это так — то командная кнопка ведущего — это не reset, а обычная программно-считываемая кнопка. Длинное нажатие на нее дает сброс программного D-триггера захвата кнопок, а, например, короткое после того, как желание ответить захвачено — начинает отсчет 10-секундного интервала, предваряя его коротким звуковым сигналом.

В таком варианте хоть будет, что писать на ассемблере )
Да, именно так. Дескать — нажал кнопку — пикнуло, увидел горящий светодиод — отвечай. Такая себе экспресс-игра. Конечно можно сделать и так как вы пишете, если кому-то это будет необходимо. В настоящем виде — это просто иллюстрация к заметке…
Да пусть расцветает сто цветов — на мой вгляд вот эта схема:
простейший вариант
имеет наименьший «порог вхождения» для людей, паяльника в жизни не державших. Только, конечно, Вы правы — на «бумажных» конденсаторах.
Детали — любые, лишь бы одинаковые — вот совсем любые, от герконов до пускателей, каналов — от двух до хоть сотен — сложность с числом каналов растёт линейно, без ступенек и перегибов.
Но даже если Вы умеете отличить базу транзистора от затвора, и знаеете как помигать светодиодом на 155-й серии — ой не факт что у вас получится сваять «одократный состязательный переключатель каналов без приоритета» быстрее и проще.
И — очень часто, особо у кого это не работа а хобби — бывают поделки, основная судьба которых — не развитие-усложение со временем, а «поиграться, забросить, через пару недель/лет разобрать на детали». Кстати «ардуина» в таком применении очень, очень хороша.
В релейном варианте участники неравноправны — если участник справа начнет нажимать кнопку, и в это время то же самое сделает участник слева — то левый перехватит правого, даже если переключающий контакт правого достигнет НО вывода первым. То есть чем левее — тем выше приоритет в спорном интервале времени (пролет контактов кнопки + время заряда конденсатора через внутреннее сопротивление источника до напряжения срабатывания реле). Самый левый может вообще поднажать кнопку слегка (так, чтобы оба контакта были разомкнуты) — и держать до тех пор, пока не придумает ответ, а затем дожать полностью — и станет победителем!

Если не хочется МК — лучше уж делать на синхронной {релейной, транзисторной, ИМС} логике, а не на последовательной
Ну поробуйте нажать кнопку на мышке так, чтобы НЗ контакт микрика разомкнулся, а НР не законтачил. Спорный интервал «с одной стороной» там — время РАЗмыкания НЗ контакта кнопки — величина принципиально неформализуемая, ибо именно это размыкание и является самим физическим фактом «нажатия», а с «другой стороной» — время РАЗмыкания НЗ контакта реле — что-то порядка ОДНОЙ милисекунды у сигнальных реле axicom.
Я не против того что неопределённость имеет место быть, я лишь о том что в рельной жизни живыми людьми такая одновременность практичеки нереализуема, а в случае чуда — при домашей игре на малобюджетной поделке — непринципиальна. Кстати в исходной схеме на аТмеге — «окно одновременности» — 5 мс и внутри него тоже выбор по заранее назначенному приоритету.

Вообще не понимаю спора — я думал что лишь «заполняю ячейку таблички вариантов» _если_кому_вдруг_понадобится_ (тем более, что вобще изначально я переключал аудиовходы демостенда наушников, а там реле всё равно и так есть, а вот помехи контроллерные схемы давали, зависали при длительной работе (а может от статики с рук) и плохо масштабировались из трёх в десятки каналов).
Ну поробуйте нажать кнопку на мышке так, чтобы НЗ контакт микрика разомкнулся, а НР не законтачил
— я и не утверждал, что на конкретной модели микровыключателя это будет сделать просто. Я всего лишь заметил, что существуют условия, при которых схема ведет себя неравноприоритетно. Ширина временного зазора, в течение которого можно воспользоваться этим недостатком свойством схемы, уже зависит от конкретной реализации.

В аналогии с программным миром можно сказать, что не бывает «почти» потокобезопасного кода — он либо потокобезопасен, либо нет. Этот вариант — thread unsafe.

Вообще не понимаю спора
я, извините, с Вами и не спорил. Просто заметил, что данный вариант имеет одну особенность, которая в принципе способна влиять на качество исполняемой им функции, и привел пример, при котором это влияние проявляется.
Sign up to leave a comment.

Articles