@Финский

Возникла необходимость отслеживать четыре кнопки и мгновенно реагировать на нажатие одной из них, при этом на остальные в этот момент не реагировать (система Брейн-Ринг). Опытные игроки утверждают, что интервал между двумя разными кнопками может исчисляться микросекундами, поэтому важно как можно быстрее определить ПЕРВУЮ нажатую кнопку. Значит опрос в цикле отпадает.
Наколхозил вот такое решение - заводим все четыре кнопки на логический элемент 4И-НЕ а выход логики - на прерывание. В прерывании по восх. фронту опрашиваем порт с кнопками. По результатам - действуем.
Если существует более быстрое и безошибочное решение - подскажите алгоритм, закодить не проблема.
код

0

@инкер

Ошибка в том, что существует возможность на выходе получить две нажатых кнопки, а должна быть одна. В этом же смысл работы схемы?

0

@Ymk

я не в теме, но что значит "переиграть"? новый вопрос зададут? так все вопросы останутся без ответа.

0

@omokost

Не знаток теории вероятностей, но нажать одновременно две кнопки с интевалом 1мкс (1Мгц быстродействие КМОП) по моему физически невозможно. Ну или вероятность этого исчезающе мала.

0

@komtrottir

Ну. блин, вы даете.
На релюхах сделайте

0

@tid_fom

на лампах! чтобы было труЪ.

0

@инкер

Смотря какая цена вопроса. Штангистов перевзвешивают до грамма, спринтеры перестарты делают только из-за того, что кто-то рванул одновременно с выстрелом.

0

@drvtos

Ни разу не глянул эту тему, а потом разобрало любопытство: что же так упорно народ перетирает? Смотрю, тут серьезный разговор, тока холивара еще нет. Редкий случай :)

Но, как это иногда и бывает, долгий и "бесполезный" разговор вдруг дал интересный поворот: тестирование системы. И тут, ИМХО, вылез критерий, по которому можно оценить и сравнить варианты: "метрологическое обеспечение". Действительно, система должна пользоваться 100%-ным доверием участников. Так? Значит, должна быть процедура тестирования, с понятными результатами. Какая процедура напрашивается? Правильно, одновременные нажатия (двух или более) кнопок.
Что получится во всех этих рандомизаторах или в честных "мгновеннорегистрирующих" устройствах? Получится, что при тестах система будет выдавать приоритет кнопок случайным образом. А как это выглядит для проверяющего? А вот как:

1 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 1

Да, друзья, вы тоже заметили, что я намухлевал! Почему это нулей больше? А потому, что случайность - она и есть случайность! Если продолжить ряд (и если система идеально честная), то вскорости мы увидим побольше единиц (вот, опять повод для возмущения), а потом посчитаем по всей совокупности - о-па! Так все гут! 50 на 50, без балды.
Но вопрос: доживет ли автор конструкции до того светлого момента, когда всем станет ясно, что 50 на 50? Или его забросают помидорами значительно раньше?
Вы понимаете, о чем я? Демонстрация честности системы должна быть короткой и бесспорной.
И как бы вы на ухищрялись с "честной" системой - ее проверка потребует долгой процедуры и хотя бы небольшой лекции по теории вероятностей. А уж если вы "поможете" системе рандомизировать ответы - есть вероятность того, что это искусственное подправление честности кто-то подловит другим тестом: постледовательным быстрым нажатием двух кнопок. И тогда рандомизатор сыграет злую шутку. Это как гистерезис...

Мое предложение: забудьте про индукцию и дедукцию микросекунды! Система должна выдавать результат "множественное нажатие" во всех случаях, если интервал между нажатиями меньше, чем какое-то время Х. Всегда.
И тогда тестовые одновременные нажатия дадут всегда "МНОЖЕСТВЕННОЕ", а постепенное разнесение их (если таковое смогут организовать) с какого-то момента даст четко преимущество реально первой нажатой кнопки.
Само время Х должно быть выбрано экспериментально как раз многократным нажатием. Сначала делаем его ноль, а потом растим до тех пор, пока не начнем получать всегда "МНОЖЕСТВЕННОЕ". И тут же прекратим его увеличивать. Все. Система готова к проверкам и работе.

Вы скажете: фигасе! Это что, переигрывать? Мой ответ прост: да, если это возможно.
А если невозможно, то добавить процедуру ЧЕСТНО СЛУЧАЙНОГО выбора. Жребий, грубо говоря. Причем, что важно, отделить его от устройства! Показать участникам, что устройство работает настолько честно, насколько электроника позволяет зафиксировать разновременность нажатия вот этих конкретных кнопочек. А когда этого не достаточно - мы включаем такое же честное устройство типа "орел-решка" (электроное или с монеткой, совмещенное с описываемым девайсом или отдельное - не суть важно).

0

@PRS

Про случайные числа. Читал интервью с одним программистов, из команды писавших то ли героев, то ли еще какую-то пошаговую стратегию. Так вот, там на лучников можно было наложить проклятие, которое с вероятностью 50% (точно не помню) заставляло их промахиваться. В результате посыпались жалобы, что это проклятье вообще не дает лучниками пользоваться, что не может оно так часто срабатывать. И им пришлось вводить искусственное ограничение "честного" рандома:)
А в данном случае делать аппаратную защиту от дребезга и фиксацию первой нажатой кнопки, как мне кажется, будет вполне хватать. Учитывать длину проводов и особенности кнопок уже будет перебором.
Для тестирования - пусть каждая команда попытается за каждым столом быстрей других нажать на кнопку, раз так десять-двадцать. Если всегда будет побеждать один и тот же стол, значит есть проблемы.

0

TixoK

<Изображение удалено>
Пробежал тему, вроде такой мысли еще не было. Суть: в этой схеме ничего не надо перебирать/сканировать. При наступлении прерывания выходы PC0-PC3 становятся входами с включенной подтяжкой, а вход INT0 становится выходом с "0". Затем читаем (PINC & 0x0F). Где "0" - там нажато. На все, про все – четыре команды.

@omokost

Да здесь уже стоит проблема в разной длине проводников к кнопкам, т. е. разном затухании в линии. Правда до терминаторов пока не дошло. Пока...
По моему, вся проблема выеденного яйца не стоит, упражняемся в красноречии.
Вдогонку, сколько предполагается ставить на кон? Если миллионы, закажите у фирмы, получите сертификат.

0

@инкер

Если уж ловить блох, то нужно ИЛИ от кнопок на INT0, в прерывании только чтение порта, в теле программы циклическая проверка регистра с копией порта, другие прерывания не использовать. Кнопка мембранного типа с конденсатором параллельно контактам гарантирует, что сигнал-инициатор прерывания доживет до момента чтения в неизменном виде.

0

@Ymk

1. псевдо-случайные числа должны быть хорошо случайными, неотличимыми от настоящих случайных. в настоящих случайных длинной последовательности нулей быть не должно с большущей вероятностью. скажем, на 20 попытках распределение должно составлять 50+-10%, этого вполне достаточно (и для контроля).

2. речь идет о вполне конкретной игре, поэтому переиграть здесь хз как получится, ибо к моменту нажатия вопрос уже задан. только жребий вручную. но почему бы не переложить это на плечи девайса?

3. схема с заведением по ИЛИ на одно прерывание и дальнейшим чтением из порта ущербна! городить огород, чтобы прерывание пришло, а из порта прочиталось, что ни одна кнопка не нажата - это ппц. тупой цикл из опроса порта и то лучше будет.

0

@Финский

- это в каких условиях возможно?

0

@omokost

[QUOTE="Финский"][QUOTE="Цитата:[/QUOTE] - это в каких условиях возможно?
Не зафиксирово аппаратно триггером, еще раз повторюсь, это какие же руки должны быть у игроков, что они могуть жмакать быстрее логики?

0

@Ymk

в условиях дребезга (руки-то тут не при чем). факт нажатия мы словить - словили, а чье оно из 4х кнопок - можем не узнать. в любом случае, такая ситуация, как и нажатие более одной кнопки сразу, должна быть как-то обработана.

причем, если в случае одноврем. нажатий мы можем кнопкам дать приоритет (не намеренно) и это никто не заметит без тщательного тестирования, то в случае чтения из порта, что ни одна кнопка не нажата, может случиться эпикфэйл.

0

@omokost

Ну так смотрим, сколько денег на кону. Если играем по копеечке, а Рабинович начал возбухать с спорном случае - в пятак ему.
Если игра на миллионы - вызываем представителей фирмы/поставщика и в бубен им. С последующем возмещением издержек.
Если вы все это напроектировали - в бубен вам. Насчет возмещения придумают за вас.
Диалектика....

0

@BykTiho

О чем вы говорите? Какие проверки системы? Как проверить систему "на честность", и где гарантия того, что проверяющая система будет честна? В общем, это все фигня. В любом случае, спорить с этой электроникой никто не будет, поскольку в любом случае посчитают, что она права.
Даже если, чисто гипотетически, предположить, что произошло действительно одновременное нажатие, вероятность которого стремиться к бесконечности, тогда рандом - и все. Никто никогда не докажет, что он нажал кнопку раньше. Да и кнопки все разные. У одной чуть слабее пружина, и нажимается она с меньшим усилием на доли микрограмма, что увеличит скорость ее нажатия. А в другой ситуации нажатие происходило немного другой частью ладони или пальца, где кожа ближе к кости, и меньше амортизирующий эффект плоти. Да и как тут уже писали, провода обрезали на микрометр короче, или вставили в разъем на тот же микрометр глубже - уже изменилось время реакции системы на нажатие кнопки. Давайте уже не будем вдаваться в такие крайности.

0

@tid_fom

ага, а то так можно договориться до помещения всей системы в контролируемые условия.

0

@dsodir

>> вероятность которого стремиться к бесконечности
Мой мозг требует компенсацию за моральный ущерб! %)

0

@drvtos

По-моему, единственный человек, кто прочел мой постинг. Ну, и на том спасибо!

Сторонники супер-пупер быстродействующей системы на самом деле просто увлеклись чистой задачей получения супер-пупер быстродействующей системы. В полнейшем отрыве от реальной задачи. Что ж, это тоже интересно, само по себе. И решения предложены классные. Особенно на аппаратном защелкивании - ух, как быстро! Но я эти решения не обсуждаю, мне интереснее привязка к поставленной задаче.

А вот с этим уже НЕ НАДО думать о микросекундах. Вообще не надо. Нужно либо считать, что системе верят, либо делать систему, выдерживающую проверку.
Если системе верят, то абсолютно пофик, какой канал зафиксируется, если сигналы приходят в интервале нескольких миллисекунд. Визуально все выглядит прекрасно. И тогда решение с МК вполне катит. И даже тупое опрашивание (без прерывания) - вполне. Кто хочет поспорить - расскажите, как будете доказывать, что несколько миллисекунд реакции - это слишком много. Пожалуйста, подробненько.
Если же система должна выдерживать тестирование - то только предложенный мною подход. А именно (для тех, кто не читал мои фантазии выше): система честно говорит "МНОЖЕСТВЕННОЕ", когда более одного нажатия приходит в интервале Х (я думаю, это будут десятки миллисекунд, но, повторяю, опыт покажет). И потом уже можно бросать (хорошо, в том же девайсе, Ymk прав) жеребок. Это очень честно, это можно доказать даже если игра на миллионы. Собственно, я понятия не имею, о какой игре идет речь. Телевизора у меня нет и я его не смотрю никогда.

0