• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

анемометр и esp8266

=AK=

New member
Обработку дребезга надо делать снаружи. Не нравицо оптрон можно триггер поставить, по мне так же замечательно работает.
Ну а триггер-то как поможет? Контакт на переключение ставить, что ли?

Аппаратно можно много чего сделать. Только это дороже получается, а результаты хуже.
 

nikolz

Well-known member
Я вообще-то писал "в основном цикле раз в 1 мс обращаемся к процедуре подавления дребезга контакта". Если хотите, то можете и обработку прерывания таймера вставить, но это хуже, поскольку из-за этого будет притормаживать обработка других прерываний.
Столько же. Для обычных кнопок я вызываю процедуру раз в 10 мс, задержка обнаружения 160 мс. Это определяется длительностью дребезга.
При работе с прерыванием всего два вызова, а задержка несколько мкс. и это при такой же сложности кода.
Согласитесь,что работа по прерываниям превосходит по всем параметрам вариант по опросу пина (опрос готовности)
 

=AK=

New member

nikolz

Well-known member
Задержка чего? Процедура тоже вызывается с задержкой всего в доли мкс.
Не хотелось бы пересказывать учебник по микропроцессорам, но я кратко
то что Вы предлагаете называется
работа с внешними устройствами по опросу готовности
Недостатком такого решения является задержка реакции процессора на готовность внешних устройств
причины две:
Если устройств много то до нового опроса пройдет цикл опроса других устройств
в результате время реакции или задержка составит N*T где N -число устройств T -время исполнения вашей функции
вторая причина - период вызова вашей функции т е время основного цикла Если 1 мс - то 1 мс если 160 - то 160.
При этом если устройство готово бывает редко процессор все равно вынужден выполнять вашу функцию т е не может быть переведен в экономный режим.
---------------
Вот для устранения этих двух недостатков Вашего решения и был создан механизм прерываний.
Поэтому я удивился, что Вы стали его отвергать.
 

=AK=

New member
Не хотелось бы пересказывать учебник по микропроцессорам, но я кратко
то что Вы предлагаете называется
работа с внешними устройствами по опросу готовности
Недостатком такого решения является задержка реакции процессора на готовность внешних устройств
причины две:
Если устройств много то до нового опроса пройдет цикл опроса других устройств
в результате время реакции или задержка составит N*T где N -число устройств T -время исполнения вашей функции
вторая причина - период вызова вашей функции т е время основного цикла Если 1 мс - то 1 мс если 160 - то 160.
При этом если устройство готово бывает редко процессор все равно вынужден выполнять вашу функцию т е не может быть переведен в экономный режим.
---------------
Вот для устранения этих двух недостатков Вашего решения и был создан механизм прерываний.
Поэтому я удивился, что Вы стали его отвергать.
То, что я предлагаю, называется "устранение дребезга". В принципе вариантов может быть много, но я предлагаю чрезвычайно простой в реализации и очень эффективный вариант.

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

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