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

А можно вообще все сделать на ЛА3

Ага, лишние корпуса, лишнее место на плате. Не спорю, паять для кого-то хобби и бешеной собаке семь верст не крюк...

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

При условии что триггер работает быстрее чем кнопка. Благо это условие выполняется всегда с механическими кнопками, а с оптическими датчиками не всегда, и могут возникать ситуации запрещенного состояния RS-триггера. А на ещё больших скоростях вообще используют двойные D-триггеры, и то это не всегда спасает... снижает вероятность проникновения "дребезга" со входа на выход до 1 на миллиард. Но это так, уже не про кнопки.

Добавлено after 5 hours 33 minutes 9 seconds:

За такое надо линейкой по рукам...

Совершенно не проблема отслеживать события как нажатия кнопки так и её отпускания, сравнивая с предыдущим состоянием. Но а короткое-длинное-ещёдлинее нажатие ИМХО это пример совершенно ужасного дизайна. Мало того что устройство вынуждено реагировать с задержкой, так ещё поди запомни что и какая кнопка означает. Я вот без инструкции к велокомпьютеру на три кнопки ничего не могу сделать. Там и комбинации одновременного нажатия, и короткое-длинное... просто УЖАС. А подбирать стремно - одна из комбинаций это полный сброс с обнулением.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Когда кнопок мало, приходится изгаляться.
Кстати, почти все гарнитуры так работают. Да и много где (разного рода плееры) я видел именно такой подход к переключению треков/перемотке файла или переключению/громкости.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

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

в моей практике был случай, когдая "изголнулся" и сделал управление всеми функциями реобаса одной кнопкой: задание порога и гистерезиса регулятора, включение-выключение... причем ввод числовых значений был сделан в обе стороны (уменьшение и увеличение) с ускоренным автоизменением при долгом удержании... мне казалось - я придумал гениальный алгоритм: кратковременное нажатие изменяло значение на 1 и меняло знак изменения на противоположный, а долгое нажатие после небольшой задержки начинало быстро изменять в заданном знаком направлении. логика была у меня такая: увидев, что изменение пошло не в ту сторону, пользователь нажимает кнопку повторно и держит её, пока не "проскочит" на 1 нужное значение (если повезет, то и не проскочит). в случае проскока надо было лишь 1 раз нажать кнопку... То есть можно было изменить температуру от -55 до +125 всего за 3 нажатия кнопки (при небольшой сноровке)...
но этот алгоритм никому не понравился...

У меня немного другая ситуация. Изначально проект был по сути просто темброблоком с анализом спектра. Хватало кнопок: 1 - включение, 2 - перебор входов звука; 3 - показать/настроить часы; 4 - mute; 5 - перебор параметров для регулировки (громкость, тембры, и т.п.); ну и энкодер для собственно регулировки. Потом проект разросся - появилась поддержка радио (а, значит, появилась нужда в кнопка для переключения треков), таймера, будильника и прочее. И хотелось иметь возможность всем этим управлять не только с пульта ДУ, но и хоть как-то с передней панели. Вот и появились разного рода длительные нажатия.

Сейчас пытаюсь сделать бегущую строку на матрице 32х8. Ввёл все символы строки в массив, получилось 78 байт (каждый символ 6х8, т.е. занимает 6 байт). Естественно, все символы строки разом не помещаются на индикаторе. Соответственно, надо сначала прочитать элементы массива 0...31, потом 1...32 и т.д. Это всё я сделал на трёх счётчиках: один считает от 0 до 31 синхронно с развёрткой, второй отсчитывает N циклов первого счётчика (задержка) и после этого инкремент третьего счётчика, который считает от 0 до 77. В регистровую пару Z записывается адрес метки массива + состояние первого счётчика + состояние третьего счётчика.

Вопрос вот в чём: как зациклить массив? Очевидно, что когда третий счётчик досчитает до 46 и больше, сумма первого и третьего счётчиков может быть больше 77. В результате в Z оказываются адреса пустых ячеек памяти, в которых 0xFF. А мне надо как-то сделать так, чтобы если сумма счётчиков превысит 77, то началось чтение массива с нуля. В этом случае бегущая строка будет бежать циклически. Не подскажете, как это сделать?

так и делайте, как написали: вычисляйте сумму счетчиков на каждой итерации и сравнивайте её с 77

Для побайтовой продвижки массива в ОЗУ предпочтение использованию указателей в X, Y и счетчика итераций с буферным регистром временного хранения.

И предпочтительно разделить операции вывода на индикацию из буфера отображения от модуля обработки продвижки информации в буфере сообщения.

Я, конечно, сравниваю. Попробовал сделать так: Если сумма этих двух счётчиков больше либо равна 78 (переход по brcc), то устанавливаю флаг в регистре общего назначения, а в той части программы, где прибавляю счётчики к Z, при наличии этого флага вычитаю 78. Таким образом адрес Array + 78 = Array, Array + 79 = Array + 1 и т.д. Чтобы вместо пустого элемента по адресу Array + 78 прочитался снова нулевой элемент массива. Но почему-то не работает Может, я вычитаю константу из регистровой пары неправильно? Делаю subi ZL,78 sbci ZH,0

Добавлено after 2 minutes 37 seconds:

Я пока что не использую ОЗУ. Читаю прям из флэша и сразу в порт (по прерываниям от таймера)
Т.е. желательно сначала загрузить все 78 байт в ОЗУ, а потом их оттуда читать? А что за буфер сообщения?

Думаю, в этом ошибка. Проще, по мне,

Так это загрузка адреса нулевого элемента массива в Z. Я так и делаю.


Здесь в качестве "флага" используется весь Temp4, в котором либо 0, либо 255.

Почему бы и не вернуться в начало.

Здравствуйте!
Подскажите плз куда подсунуть тему Отправка, прием по прерыванию и анализ принятого по USART? На ASM.
C одного МК отправляю сообщение по кнопке, а на другом дрыгаюсь по прерыванию и вывожу принятые символы по нажатию кнопки. Есть наброски и проект протеус.
Нуждаюсь в помощи.

Сразу подскажу, что при использовании UART лучше сразу прикрутить кварц на МК… заметил тенденцию у некоторых МК – не в какую не желают попадать в заявленные частоты при передаче… когда тактируются от внутреннего генератора.

Хочу отработать алгоритм прерывания по получению сообщения и сохранению сообщения во flash с последующим его анализом и реакцией в главной программе.
Прерывание отрабатывает, сохраняет сообщение без проблем, если сообщение кидаю через HyperTerminal. Создал в протеус второй МК, который по кнопке отправляет сообщение, первый по прерыванию должен это сообщение принять и сохранить, а по нажатию на кнопку - выдать сохраненные символы обратно в усарт.
чОт фигня получается. Кварцы использовал.

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

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