[Golikov 0]

ну все, убедили.

 

переписываю все проекты с прерываниями:(....

 

даже тот где кнопки различали еще и комбинации разно длительных нажатий и при том не занимали под себя отдельный таймер.... ;)

 

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

[HHIMERA 0]

Мой ответ так делать в конкретно этом случае хорошо!

Ещё не факт...

В 95-98% случаев периодический опрос кнопок даёт наилучший результат...

 

[Golikov 0]

Окей Окей :)...

[adnega 11]

Пример, конечно, надуманный, но все же: что будет, если на ножку кнопки подать сигнал частотой под мегагерц? в случае работы по прерыванию и в случае работы по опросу? ;)

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

[Golikov 0]

ну я же согласился:)

 

второй надуманный пример,

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

 

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

[Tahoe 0]

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

Это почему же? Если частоту опроса выбирать не на след. утро после пьянки, а осмысленно, то тоже ничего не пропустится. ;)

[jcxz 242]

второй надуманный пример,

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

Так-ли? В случае работы по прерыванию (и особенно наличия ОС), проц скорее всего загрузится на 100% и прикладное ПО встанет колом. В случае периодического опроса, работоспособность остального ПО, не зависящего от событий нажатия, скорей всего не нарушится. :smile3046:

 

Ещё один минус прерывания от кнопки Вы сами выше упомянули:

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

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

 

даже тот где кнопки различали еще и комбинации разно длительных нажатий и при том не занимали под себя отдельный таймер.... ;)

И это надеюсь без привязки к частоте CPU? Вот это интересно! а можно примерчик в студию? :laughing:

Да и кто кстати сказал что периодический опрос должен занимать отдельный таймер? Почему нельзя его сделать на каком-то уже существующем подходящем периодическом прерывании таймера?

[Golikov 0]

В целом я уже согласился, прерывание плохо, полинг это хорошо. Просто потому что это ничего не меняет, а вам это почему то важно:)

 

уточню только эти моменты:

если пользователь хочет нажимать с частотой 1 МГц, а вы пропустите половину нажатий - это некорректная работа! :)

 

мер не нужно, но они уже сделаны, зачем отговаривать человека от использования прерывания в этом случае?:)

 

если подбирать подходящий таймер, то это делает трудным поддержку проекта. Если есть модуль и он занял таймер, то таймер можно менять как хочешь, если от этого таймера начинают зависит другие модули - это пипец. Это код где каждый шаг как на минном поле, и ты никогда не узнаешь все ли хорошо, если ты что-то поменял...

 

Пример:

естественно чудес не бывает).

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

 

этот сквозной таймер могут использовать все модули, без возможности менять его параметры. Проект легко обслуживается, и поддерживается. Можно делать все что хочешь в основном цикле, хоть пихать паузы while(1), делать длительные обработки, реакция на кнопки будет правильной и корректной.

 

 

 

[jcxz 242]

Вот!!! Так и думал! :laughing:

Т.е. - таймер у вас всё-же есть и кнопка его использует. А теперь просто вместо использования чтения переменной счётчика таймера, делаем в процедуре ISR таймера вызов нашей процедуры сканирования кнопы (с соответствующим делителем). И всё - раньше этот один таймер использовался и теперь так же один таймер используется ;)

 

PS: А ведь могли-бы, из неприязни к таймерам, на ещё одну ногу прицепить RC-цепочку, по нажатию кнопки включать зарядку её и ловить прерывание по достижении порога. Лишние ноги конечно, но зато без таймера!

 

Шутка, не обижайтесь :)

[Golikov 0]

вы не внимательны.

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

Прерывание кнопки позволяет точно фиксировать момент, что в отличии от полинга дает неопределенность с точностью до частоты опроса.

 

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

 

Естественно это немного идеализированный пример, потому что в большинстве случаев неопределенность до частоты опроса не важна... но если уж мы копаем нюансы - так вот они.

 

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

 

 

 

заряжать конденсатор - это сильно конечно, там и АЦП можно к процессу подключить, но достаточно просто внешнего таймера:) как я и написал...

 

Кстати! совсем забыл:))))

 

Кнопка на прерывании легко и безоговорочно побеждает кнопку по полингу если речь идет о режиме энергосбережения и пробуждению по нажатию кнопки... При полинге вы либо не проснетесь вообще, либо регулярными пробуждениями потратите всю энергию!

 

тадам!!!! прерывание - полинг 1 : 0

[Tahoe 0]

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

Вот так и знал, что про это зайдет. Но не надо путать, событие "wake_up" и событие "button_pressed" - абсолютно разные, хотя, как частный случай, могут наступить от одного источника. Для "wake_up" - только прерывания, без вариантов. А дальше... угу, он самый, поллинг кнопок.

[deplen 0]

даже не думал, что обработка нажатия на кнопку вызовет такое обсуждение на 3 страницы :)

[deplen 0]

Реализовал чтение порта на нажатие кнопки. Каждые 0.05 секунды выполняется чтение нажатия. Никакого дребезга больше нет.

 

Но хотелось бы как то заставить таймер следить что бы не было слишком длительных ожидания нажатий. Всмысле, например, пользователь нажал 2 раза, а третий не нажал, то в памяти так два раза и останется. А хотелось бы, если было хотя бы одно нажатие, то запускался счетчик на 5 секунд втечении которых пользователь должен успеть нажать еще 2 раза. Может есть идеи как это реализуется в таймере LPC?

Изменено 11 февраля, 2013 пользователем deplen

[Golikov 0]

запустить в таймере счетчик?

[deplen 0]

запустить в таймере счетчик?

 

Счетчик, который таймер внутри себя считает?