Кнопки и кнопочный интерфейс

[Flasher]

RS решает лучше.
А еще лучше https://datasheets.maximintegrated.com/ ... AX6818.pdf

[philosoraptor]

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

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

prot_rem_v2.7z

(44.02 KiB) Скачиваний: 240

[pyzhman]

Не в тему. Не перестаю умиляться:

Jack_A писал(а):

...об delay ...

Об ледовом побоище.

[ARV]

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

вау!

[Jack_A]

не вижу ничего плохого в применении _delay где бы то ни было и уж тем более для подавления дребезга

Это пройдет со временем, наверно.

[ozonn]

Jack_A писал(а):

не вижу ничего плохого в применении _delay где бы то ни было и уж тем более для подавления дребезга

Это пройдет со временем, наверно.

я вас умоляю...
вот скажите мне, пожалуйста, если мне нужна задержка в 10 мкс, что мне делать? Таймер использовать?

[Ivanoff-iv]

я так для себя и решил delay_us(); можно, если осторожно, а вот delay_ms(); это уже перебор.

[ozonn]

Ivanoff-iv писал(а):

я так для себя и решил delay_us(); можно, если осторожно, а вот delay_ms(); это уже перебор.

представьте себе, что вы инициализируете дисплей, там нужны задержки порядка 200 ms. Тоже использовать таймер?

я вот не могу понять, чем для вас так страшен _delay?

[Jack_A]

вот скажите мне, пожалуйста, если мне нужна задержка в 10 мкс, что мне делать? Таймер использовать?

Ну зачем же крайности ? Я сам в таких случаях пустой цикл закручиваю. Я о другом: сгенерировали событие, которое откликнется миллисекунд через 10 - тупо ждем? Да за это время кучу арифметики можно обсчитать, а потом спокойно берешь готовый результат.
https://www.youtube.com/watch?v=lNa6i7rXqyQ

[ozonn]

Jack_A писал(а):

вот скажите мне, пожалуйста, если мне нужна задержка в 10 мкс, что мне делать? Таймер использовать?

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

если в это время ничего делать не надо, то да, тупо ждем

Jack_A писал(а):

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

если надо что-то считать, то, конечно надо считать

[Ivanoff-iv]

ozonn писал(а):

...вы инициализируете дисплей, там нужны задержки порядка 200 ms...

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

[ozonn]

Ivanoff-iv писал(а):

ozonn писал(а):

...вы инициализируете дисплей, там нужны задержки порядка 200 ms...

то инициализация, она один раз проходит, ради этого таймер расходовать - большее зло

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

Ivanoff-iv писал(а):

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

семисегментник, как раз, нужно подсвечивать при помощи прерываний от таймера и тогда ему никакие _delay не помеха

[philosoraptor]

то инициализация, она один раз проходит, ради этого таймер расходовать - большее зло

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

[ARV]

К примеру, после записи во внешний епром нужно пожождать 10 мс перед очередным обращением к нему.

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

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

в частности, завершение записи EEPROM сопровождается падением бита EEPE в регистре EECR - именно эту ситуацию и следует ждать, и, очевидно, ждать ПЕРЕД ТЕМ, КАК ПРИСТУПИТЬ К ЗАПИСИ, а никак не после! аналогично следует поступать и в остальных случаях, например, при работе с ЖКИ1602 - крайне популярный подход "тупых задержек" на время, "достаточное" для реакции контроллера ЖКИ частенько приводит к тому, что самописные "библиотеки" то работают, то не работают... а правильный подход заключается в чтении бита занятости контроллера ЖКИ перед тем, как что-либо туда писать. и тогда задержки (хоть тупые, хоть умные) становятся не нужны, библиотека работает всегда и везде, мир и спокойстве царит повсеместно

[Ivanoff-iv]

ну вот, пока стригся, АRV про ЕЕПРОМ расписал , отвечу про семисегментник: бывает задержки вставляют внутри какого либо прерывания и всё, будет яркость плавать (глобальны прерывания разрешать тоже нужно умеючи - сколько там граблей по переполнению стека найдено новичками - не счесть, причём чаще какраз теми, кто делаями балуется ).

[ozonn]

Ivanoff-iv писал(а):

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

а бывает, что вместо 220В дают 1000. Но тут речь не о том

[ARV]

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

и в доказательство того, что мой подход приносит не вред, а пользу, снова приведу пример алгоритма приема кодов дистанционного управления RC5 (и даже в общем случае - любого стандарта). наверняка вам знакомы реализации с использованием режима захвата таймера, с прерываниями по сигналу с ИК-датчика... и наверняка вы согласитесь, что разобраться во всем этом порой сложно не только начинающему, но и заканчивающему... а вот мой вариант на ТУПЫХ ЗАДЕРЖКАХ - проще только два пальца обсосать! и это работает очень хорошо - в статье сказано о нюансах разработки, но по сравнению с труднопонимаемыми, но "правильными" не тупыми алгоритмами, все это мелочи. в статье есть ссылка и на другую мою статью - о том, как принимать ИК-коды любых (если честно - почти любых) стандартов НА ТУПЫХ ЗАДЕРЖКАХ. хотя можно и без них....

так что всё хорошо, что хорошо

[Ivanoff-iv]

я к контроллеру отношусь как к коту: если можно спать, он будет спать.

[philosoraptor]

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

[ARV]

действительно изящное, на мой взгляд, решение

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