void Buttons_Poll(void) { if (PINB & 1) { Buttons_Timeout[0] = 0; } else { Buttons_Timeout[0]++; if (Buttons_Timeout[0] == Button_Delay) { // Some event here }; if (Buttons_Timeout[0] > Button_Delay) Buttons_Timeout[0] = Button_Delay; }; if (PINA & 1) { Buttons_Timeout[1] = 0; } else { Buttons_Timeout[1]++; if (Buttons_Timeout[1] == Button_Delay) { // Some event here }; if (Buttons_Timeout[1] > Button_Delay) Buttons_Timeout[1] = Button_Delay; }; // Другие обработчики };
Соответственно, Buttons_Poll() вызывается каждую милисекунду в основном потоке выполнения, не блокирует работу основного потока и обрабатывает события нажатия (не отпускания, но и это можно сделать).
Oxford - ваше видео тонкое послатие найух. Что вы показали, спрашивается? Какое-то ублюдочное решение? Ублюдочное не в плане автора, а самого решения. Если вздумаете возмутиться. Вот мой пример. Ссылка.
Примерщикам: Везде, во всех ваших примерах я вижу стремление показать насколько короче ваш код. То есть подспудное желание показать, типа вот как у меня короче чем у тебя. Но каждый раз я вижу какие-то огрызки решения. Вы покажите полностью ваш код. От опроса кнопок до определения кода кнопки. И как остальным модулям реагировать на события, коды кнопок и так далее.
От подобного описания мне хочется головой биться об стол. Куда катится мир? Ардуинщик описывает как обрабатывать кнопу. Блджааад! Много заумных слов, мало толку. Чистый программер или админ дорвался до электронной платы со своими нулевыми познаниями в электронике... Порой мне хочется какого-нибудь ардуинщика за яйцы подвесить, чтобы не лезли куда не следует...
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Везде, во всех ваших примерах я вижу стремление показать насколько короче ваш код. То есть подспудное желание показать, типа вот как у меня короче чем у тебя. Но каждый раз я вижу какие-то огрызки решения. Вы покажите полностью ваш код. От опроса кнопок до определения кода кнопки. И как остальным модулям реагировать на события, коды кнопок и так далее.
не нужен никакой хитроумный алгоритм против дребезга. а опрашивать кнопки каждую миллисекунду - величайшая глупость. реакция человека на столько медленная, что обрабатывать действия кнопок нельзя слишком часто. нужно, чтобы человек успевал реагировать на произведенное действие.
мне приходилось работать с промышленными приборами, у которых приборный цикл составлял 0,32 сек. за 0,32 сек., после приобретения навыков (тренировки реакции) можно было успевать реагировать. тут я имею в виду, например, при изменении значения параметра нужно не проскочить мимо нужного значения и своевременно отпустить кнопку.
в своих разработках я увеличил обработку состояний кнопок до полсекунды, когда приобрести навык своевременного отпускания кнопки проще, чем при более коротком периоде. поэтому и порты кнопок достаточно опросить один раз за полсекунды. нашли, что кнопка нажата - поставили соответствующий этой кнопке бит. а дребезг нажатия и отпускания кнопки останется далеко за пределами того "мгновения", когда кнопка проверяется. да, теоретически момент опроса порта может совпасть с моментом нажатия кнопки и тогда из-за дребезга кнопка определится не нажатой. ну, подержишь эту кнопку еще не менее 0,5 сек. чтобы зафиксировать ее нажатие.
опрос кнопок один раз за полсекунды - это абсолютный минимум, чтобы дребезг не влиял. и этот абсолютный минимум прекрасно работает!!! я у себя проверял. но реально я делаю чуть сложнее. я у себя делаю опрос кнопок каждую 0,1 сек. и подсчитываю число нажатых состояний для каждой кнопки. за весь интервал 0,5 сек. получается максимум 5 срабатываний нажатого состояния. когда я обрабатываю состояние кнопок (один раз за 0,5 сек.), то не менее 3 срабатываний считается за нажатое состояние. но это уже излишество. и поскольку абсолютный минимум прекрасно работает, я собираюсь отказаться от этого излишества, и опрос кнопок сделал тоже один раз в 0,5 сек.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Карма: 90
Рейтинг сообщений: 1289
Зарегистрирован: Чт мар 18, 2010 23:09:57 Сообщений: 4510 Откуда: Планета Земля
Рейтинг сообщения:0 Медали: 1
Щелчёк - это ~ 0.2...0.3 сек. А ждать 0.5 сек нажатой кнопку, для одного клика - мазохизм. Встречался я с пром-приборами, ПО для которых писались такими горе-программистами. Одно только лазанье по меню вызывает раздражение, переходящее в нервоз. Не говоря уж о том, когда увеличиваешь/уменьшаешь цифровые значения параметров
это время реакции человека, а не время, затрачиваемое на замыкание контактов. к тому же, за 0,2 сек. далеко не каждый человек сможет без опоздания среагировать на появившееся изменение и без опоздания отпустить кнопку.
Starichok51 писал(а):
мне приходилось работать с промышленными приборами, у которых приборный цикл составлял 0,32 сек.
0,32 сек. вполне согласуется с твоим понятием "щелчка" кнопкой. и как я уже сказал, 0,32 сек. вполне достаточно, чтобы успеть вовремя отпустить кнопку. и как я уже сказал, что даже для 0,32 сек. нужно время для приобретения навыка вовремя отпускать кнопку. первое время работы с этими приборами (за 0,32 сек.) и я сам и ВСЕ люди безнадежно опаздывали вовремя отпускать кнопку. и только со временем появлялся навык вовремя реагировать. а то, что я решил увеличить время на реакцию человека до 0,5 сек. - это только мое личное дело. горе-программист тот, кто не заботится о людях, а думает, что абсолютно все люди обладают такой же "мгновенной" реакцией, как он, и делают кнопочный цикл 0,2 сек. а 0,5 сек. - это забота о людях, которые будут повторять мои конструкции, чтобы они потом не плевались на слишком быструю смену показаний прибора.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Карма: 90
Рейтинг сообщений: 1289
Зарегистрирован: Чт мар 18, 2010 23:09:57 Сообщений: 4510 Откуда: Планета Земля
Рейтинг сообщения:0 Медали: 1
Причём тут быстрая смена показаний ? Быстро меняться должно когда держишь кнопку длительное время, и это может быть доп. опцией, упрощающей большие изменения. А на клик прибор должен реагировать адекватно, т.е. щёлкнул - показания сменились, а не ждать какое-то время. Бывает нужно щелчками подогнать показания, при этом ждать, когда прибор отреагирует на щелчок 0.5 сек - некомильфо. Частота таких нажатий может достигать более 5 Гц. Клик - это событие, происходящее при изменении одного состояния на другое, а не время удержания кнопки. Именно изменение состояния и нужно обрабатывать. Это избавит от предсказывания реакции пользователя. Он нажал->отпустил - клик прибором зафиксирован. А сколько он будет её удерживать, 0.1 сек или 1.0 сек - это уже его дело.
Цитата:
горе-программист тот, кто не заботится о людях
Тут я совершенно согласен. По этому я и назвал тех "программистов" таковыми. Они совершенно не думали о пользователях, а делали как им хочется(проще, ...).
А сколько он будет её удерживать, 0.1 сек или 1.0 сек - это уже его дело.
на этот случай у меня есть бит блокировки кнопок. можно удерживать хоть "до посинения". для лучшего понимания вкратце изложу суть. у меня есть список параметров. его можно "листать" вперед или назад. вот тут я с тобой могу согласиться, что переход от одного параметра к другому может проходить меньше, чем за 0,5 сек. например, за 0,1 сек. и другие действия, не связанные с изменением какого-либо параметра, тоже можно делать за 0,1 сек. а когда у меня происходит изменение значения параметра, то для изменения на большую величину кнопка удерживается на продолжительное время, пока не подберемся близко к требуемому значению. и вот тут интервал срабатывания кнопки должен быть относительно медленным, чтобы пользователь успел вовремя отпустить кнопку. я вот этот относительно медленный интервал (0,5 сек.) выбрал основным для любых действий с кнопками.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
я одно время был озабочен какой-то стандартизацией обработок кнопки в своих проектах, и даже 5-6 проектов сделал по этому "стандарту"... а потом как-то снова скатился в ... в разнообразие скатился.
сделал я два уровня абстракции: нижний, где определена единственная функция get_scancode(), возвращающая код нажатой кнопки, и верхний, где реализована функция get_key(), реализующая нужный протокол обработки.
get_scancode() делает минимум: собирает битовые состояния всех кнопок в один единственный байт, таким образом этот байт соответствует сканкоду, если говорить в терминах больших компов. откуда этот сканкод берется - дело программиста: можно опрашивать по битику разные порты, можно сразу один порт, если все кнопки на нем висят, можно ждать, пока какая-то переменная будет обновлена в прерывании (например, при совмещении линий кнопок с другими функциями, обычно с дисплеем). можно эту функцию даже макросом заменить, только тогда модульность нарушится...
get_key() делает больше: обращается к get_scancode() и затем борется с дребезгом, сравнивая предыдущий сканкод с новым, а затем отсчитывает задержки для автоповтора. алгоритм работы этой функции не зависит от способа получения сканкода. get_key() в основном реализует следующий алгоритм: если кнопка нажата и удерживается, то отсчитывается интервал до первого автоповтора, после чего возвращается сканкод. любое последующее обращение к get_key() обрабатывается иначе: если кнопка все еще удерживается нажатой, то выдача сканкода происходит после задержки автоповтора. если обнаруживается, что состояние кнопок изменилось, например, когда нажали вторую, не отпустив первую, то один раз возвращается NO_KEY (нет нажатых кнопок), после чего происходит обработка, как будто было первое нажатие, т.е. сначала задержка перед автоповтором, а потом автоповтор.
задержка перед автоповтором у меня обычно от 1 до 3 секунд, в зависимости от проекта. а задержка автоповтора обычно 0,5-0,3 сек. такие задержки позволяют четко отличить ДОЛГОЕ УДЕРЖАНИЕ кнопки от кратковременного нажатия, и при этом позволяет производить достаточно быстрое изменение параметра при удержании, но не требует особой реакции от пользователя.
как-то так...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Еще раз обьясняю. Тебе нужно отдельно сделать таймер или задачу в ОС создать, которая будет постоянно вызывать опрос каждые 10мс. Идеально если это будет программный таймер средствами ОС повторяющийся с периодом 10мс.
И все будет работать сладко и гладко. Больше ничего не надо, ни прерываний, ни конденсаторов на линию. Работать будет железно как танк. Частоту опроса регулируешь таймером подстраиваешь отклик системы, а переменная DELAY_PRESS_BUTTON регулирует паузу нажатия и отпускания, фильтр.
Добавлено after 29 minutes 37 seconds: Re: Программный антидребезг
Demiurg писал(а):
Oxford - ваше видео тонкое послатие найух. Что вы показали, спрашивается? Какое-то ублюдочное решение? Ублюдочное не в плане автора, а самого решения. Если вздумаете возмутиться. Вот мой пример. Ссылка.
Примерщикам: Везде, во всех ваших примерах я вижу стремление показать насколько короче ваш код. То есть подспудное желание показать, типа вот как у меня короче чем у тебя. Но каждый раз я вижу какие-то огрызки решения. Вы покажите полностью ваш код. От опроса кнопок до определения кода кнопки. И как остальным модулям реагировать на события, коды кнопок и так далее.
В чем истерика? Логика работы такая же, реализация немного другая и все более туповатая.
_________________ Инженер R@D
Telegram чат: https://t.me/radiowolf или в поиске приложения @radiowolf. Личка:@cncoxford
Карма: 90
Рейтинг сообщений: 1289
Зарегистрирован: Чт мар 18, 2010 23:09:57 Сообщений: 4510 Откуда: Планета Земля
Рейтинг сообщения:0 Медали: 1
При дин. индикации, реакция глаза человека тоже выше 25 Гц не видит, хотя все эту частоту завышают. Тоже спросите "нахрена ?" ? Я, например, вообще делаю переключения каждую миллисекунду. А это - на порядок выше частоты реакции глаза (при 4-ех индикаторах). И на вопрос "нахрена так часто ?" отвечу - просто мне так удобно, т.к. во всех проектах имею системные миллисекундные тики. К чему я это всё... А к тому, что реакция человека совсем тут не при чём. 10 мс. выбрано из соображений подавления дребезга, а не какой-нибудь физической возможности человека. Общепринятое время = ~10...20 мс. Я делаю 20 мс. , проблем пока не было обнаружено, в т.ч. и с пром-устройствами.
учитывая время реакции человека, ты можешь объяснить, а на хера нужно так часто опрашивать кнопки?
Можно делать опрос и реже если не требуется быстрая реакция GUI на кнопки.
Можете настроить под ваше приложение дефайнами и периодом таймера. #define DELAY_PRESS_BUTTON 5 #define BUTTON_REPEAT 50
Дело в том что у кнопки два состояния дребезга. Нажатие и отпускание. Время обработки кнопки увеличивается в двое.
В моем случае при таймере 10мс: #define BUTTON_FILTER 2 #define BUTTON_REPEAT 20
Т.е. 20мс нажатие, 20мс отпускание 40мс обработка одного нажатия. Если кнопка удерживается нажатой, работает авто повтор нажатий. При этом авто повтор имеет хорошую реакцию и период 200мс, авто повтор работает внутри алгоритма нажатия кнопки. В итоге работает стабильно и с отличной производительностью. Без глюков, пропусков и прочих артефактов.
_________________ Инженер R@D
Telegram чат: https://t.me/radiowolf или в поиске приложения @radiowolf. Личка:@cncoxford
а целесообразно ли включать програмно внутренние подтягивающие резисторы при наличие оных извне ?
я бы ставил вопрос иначе: целесообразно ли ставить внешние резисторы при возможности подтянуть кнопку изнутри? и в подавляющем количестве домашних поделок-игрушек ответ был бы "нецелесообразно": дополнительные компоненты - это удорожание и усложнение.
в вашей же формулировке внутренние резисторы приведут лишь к небольшому увеличению потребляемого схемой тока, причем на мизерную величину. так что вопрос целесообразности не стоит - всё равно. или скажем так: будет подтяжка - не повредит, не будет - хуже не станет.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 22
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения