На всякий случай напомню, что насовсем избавиться от дребезга помогает RS триггер и SPDT кнопка. Делал у себя в конструкции для надёжного разделения длинных и коротких нажатий.
При условии что триггер работает быстрее чем кнопка. Благо это условие выполняется всегда с механическими кнопками, а с оптическими датчиками не всегда, и могут возникать ситуации запрещенного состояния RS-триггера. А на ещё больших скоростях вообще используют двойные D-триггеры, и то это не всегда спасает... снижает вероятность проникновения "дребезга" со входа на выход до 1 на миллиард. Но это так, уже не про кнопки.
Добавлено after 5 hours 33 minutes 9 seconds:
Цитата:
на короткое нажатие повешен, например, Channel_Up, а на длинное - Volume_+
За такое надо линейкой по рукам...
Совершенно не проблема отслеживать события как нажатия кнопки так и её отпускания, сравнивая с предыдущим состоянием. Но а короткое-длинное-ещёдлинее нажатие ИМХО это пример совершенно ужасного дизайна. Мало того что устройство вынуждено реагировать с задержкой, так ещё поди запомни что и какая кнопка означает. Я вот без инструкции к велокомпьютеру на три кнопки ничего не могу сделать. Там и комбинации одновременного нажатия, и короткое-длинное... просто УЖАС. А подбирать стремно - одна из комбинаций это полный сброс с обнулением.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Кстати, почти все гарнитуры так работают. Да и много где (разного рода плееры) я видел именно такой подход к переключению треков/перемотке файла или переключению/громкости.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Заголовок сообщения: Re: Ассемблер (ASM) для AVR в вопросах и ответах
Добавлено: Вт янв 23, 2018 08:53:00
Встал на лапы
Карма: 3
Рейтинг сообщений: 7
Зарегистрирован: Чт сен 10, 2015 06:59:03 Сообщений: 106 Откуда: Гродно, BY
Рейтинг сообщения:0
Нормальное применение кнопок (что бы не загромождать устройство) для функций, не требующих оперативного управления. Правда при этом требует звуковой или оптический сигнал подтверждения короткого (до 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, то началось чтение массива с нуля. В этом случае бегущая строка будет бежать циклически. Не подскажете, как это сделать?
так и делайте, как написали: вычисляйте сумму счетчиков на каждой итерации и сравнивайте её с 77
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
так и делайте, как написали: вычисляйте сумму счетчиков на каждой итерации и сравнивайте её с 77
Я, конечно, сравниваю. Попробовал сделать так: Если сумма этих двух счётчиков больше либо равна 78 (переход по brcc), то устанавливаю флаг в регистре общего назначения, а в той части программы, где прибавляю счётчики к Z, при наличии этого флага вычитаю 78. Таким образом адрес Array + 78 = Array, Array + 79 = Array + 1 и т.д. Чтобы вместо пустого элемента по адресу Array + 78 прочитался снова нулевой элемент массива. Но почему-то не работает Может, я вычитаю константу из регистровой пары неправильно? Делаю subi ZL,78 sbci ZH,0
Для побайтовой продвижки массива в ОЗУ предпочтение использованию указателей в X, Y и счетчика итераций с буферным регистром временного хранения.
И предпочтительно разделить операции вывода на индикацию из буфера отображения от модуля обработки продвижки информации в буфере сообщения.
Я пока что не использую ОЗУ. Читаю прям из флэша и сразу в порт (по прерываниям от таймера) Т.е. желательно сначала загрузить все 78 байт в ОЗУ, а потом их оттуда читать? А что за буфер сообщения?
_________________ Фак, кот грызёт провод! Сейчас его ударит либо током, либо тапком! ))
Здравствуйте! Подскажите плз куда подсунуть тему Отправка, прием по прерыванию и анализ принятого по USART? На ASM. C одного МК отправляю сообщение по кнопке, а на другом дрыгаюсь по прерыванию и вывожу принятые символы по нажатию кнопки. Есть наброски и проект протеус. Нуждаюсь в помощи.
Сразу подскажу, что при использовании UART лучше сразу прикрутить кварц на МК… заметил тенденцию у некоторых МК – не в какую не желают попадать в заявленные частоты при передаче… когда тактируются от внутреннего генератора.
Хочу отработать алгоритм прерывания по получению сообщения и сохранению сообщения во flash с последующим его анализом и реакцией в главной программе. Прерывание отрабатывает, сохраняет сообщение без проблем, если сообщение кидаю через HyperTerminal. Создал в протеус второй МК, который по кнопке отправляет сообщение, первый по прерыванию должен это сообщение принять и сохранить, а по нажатию на кнопку - выдать сохраненные символы обратно в усарт. чОт фигня получается. Кварцы использовал.
Прерывание срабатывает при получении одного байта. При окончании получения сообщения должен приняться байт, сигнализирующий об окончании пакета. Вот после приёма такого байта и нужно уже всё обрабатывать.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 35
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения