против этого я и хотел выступить - 1) ты сделал 2 коротких нажатия, а получил одно длинное, т.к. второе нажатие совпало с вторым опросом, 2) даже если надо одно короткое, но выверенное по времени, то это будет сложно сделать т.к. система будет ожидать 2го замера, чтобы убедиться, что нажатие было коротким, и вообще система будет казаться тормознутой (по той же причине).
В отличие от диванных теоретиков, никогда не писавших ничего сложнее диммеров и регуляторов вентилятора для уборной, у меня есть вполне рабочие проекты с многоуровневыми меню. Пример для Прот.8 ниже. Попробуй вызвать в нем длинное нажатие двумя короткими и расскажи, как оно. Ну а неспособным написать простейший автомат состояний никто не запрещает юзать задержки, благо, в серию эти поделки никогда не пойдут.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
я так для себя и решил delay_us(); можно, если осторожно, а вот delay_ms(); это уже перебор.
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
вот скажите мне, пожалуйста, если мне нужна задержка в 10 мкс, что мне делать? Таймер использовать?
Ну зачем же крайности ? Я сам в таких случаях пустой цикл закручиваю. Я о другом: сгенерировали событие, которое откликнется миллисекунд через 10 - тупо ждем? Да за это время кучу арифметики можно обсчитать, а потом спокойно берешь готовый результат. https://www.youtube.com/watch?v=lNa6i7rXqyQ
вот скажите мне, пожалуйста, если мне нужна задержка в 10 мкс, что мне делать? Таймер использовать?
Ну зачем же крайности ? Я сам в таких случаях пустой цикл закручиваю. Я о другом: сгенерировали событие, которое откликнется миллисекунд через 10 - тупо ждем?
если в это время ничего делать не надо, то да, тупо ждем
...вы инициализируете дисплей, там нужны задержки порядка 200 ms...
то инициализация, она один раз проходит, ради этого таймер расходовать - большее зло а вот если семисегментник? - тут неумелое и/или неумеренное использование задержек видно на глаз (причем в прямом смысле )
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
то инициализация, она один раз проходит, ради этого таймер расходовать - большее зло
Вооот, совершенно верно, имо. Бывают эпизодические места в коде, когда городить автомат это явный оверкилл, и там задержка смотрится вполне уместно. К примеру, после записи во внешний епром нужно пожождать 10 мс перед очередным обращением к нему. В моем случае событие редкое, программа вполне может подождать. Впрочем, по образованию я не программист и вполне могу ошибаться.
К примеру, после записи во внешний епром нужно пожождать 10 мс перед очередным обращением к нему.
вот из подобных рассуждений обычно и растут ноги того самого применения delay, которое некоторые горячие головы называют абсолютным злом.
дело в том, что задержки на время ожидания завершения какого-либо процесса действительно можно назвать злом, разве что не абсолютным. длительные процессы обязательно должны как-то уведомлять о своем завершении, а основная программа вместо ожидания должна периодически эти уведомления получать и обрабатывать.
в частности, завершение записи EEPROM сопровождается падением бита EEPE в регистре EECR - именно эту ситуацию и следует ждать, и, очевидно, ждать ПЕРЕД ТЕМ, КАК ПРИСТУПИТЬ К ЗАПИСИ, а никак не после! аналогично следует поступать и в остальных случаях, например, при работе с ЖКИ1602 - крайне популярный подход "тупых задержек" на время, "достаточное" для реакции контроллера ЖКИ частенько приводит к тому, что самописные "библиотеки" то работают, то не работают... а правильный подход заключается в чтении бита занятости контроллера ЖКИ перед тем, как что-либо туда писать. и тогда задержки (хоть тупые, хоть умные) становятся не нужны, библиотека работает всегда и везде, мир и спокойстве царит повсеместно
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
ну вот, пока стригся, АRV про ЕЕПРОМ расписал , отвечу про семисегментник: бывает задержки вставляют внутри какого либо прерывания и всё, будет яркость плавать (глобальны прерывания разрешать тоже нужно умеючи - сколько там граблей по переполнению стека найдено новичками - не счесть, причём чаще какраз теми, кто делаями балуется ).
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
касательно delay-ев лично я стараюсь придерживаться такой классификации: если задержка есть самоцель, т.е. неотъемлемая часть алгоритма, то не грех её сделать "тупо". если же задержка необходима для синхронизации параллельно выполняющихся алгоритмов, то следует тупости избегать. прежде чем до этого додуматься, я пробовал разные варианты, доходившие до создания виртуальных таймеров с виртуальными же прерываниями.
и в доказательство того, что мой подход приносит не вред, а пользу, снова приведу пример алгоритма приема кодов дистанционного управления RC5 (и даже в общем случае - любого стандарта). наверняка вам знакомы реализации с использованием режима захвата таймера, с прерываниями по сигналу с ИК-датчика... и наверняка вы согласитесь, что разобраться во всем этом порой сложно не только начинающему, но и заканчивающему... а вот мой вариант на ТУПЫХ ЗАДЕРЖКАХ - проще только два пальца обсосать! и это работает очень хорошо - в статье сказано о нюансах разработки, но по сравнению с труднопонимаемыми, но "правильными" не тупыми алгоритмами, все это мелочи. в статье есть ссылка и на другую мою статью - о том, как принимать ИК-коды любых (если честно - почти любых) стандартов НА ТУПЫХ ЗАДЕРЖКАХ. хотя можно и без них....
так что всё хорошо, что хорошо
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
я к контроллеру отношусь как к коту: если можно спать, он будет спать.
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Мне, к слову, как-то понадобилась либа для ик пультов, самому для написания наглости не хватило, попробовал разные варианты, в т.ч. вариант от многоуважаемого ARV выше, все это было не то, мягко говоря. И когда совсем уж отчаялся найти нужное, мне попалось действительно изящное, на мой взгляд, решение, которое почти ничего не весит, легко портируется в любой код и работает сразу "из коробки".
изящное-то оно изящное, но никак не отличает основной код от кода автоповтора. конечно, к теме задержек это не имеет отношения... кстати, принцип построения алгоритма практически тот же самый, что и у меня, просто реализация на прерываниях.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: veso74 и гости: 48
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
