Форум РадиоКот

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

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

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

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

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

на короткое нажатие повешен, например, Channel_Up, а на длинное - Volume_+

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

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

Когда кнопок мало, приходится изгаляться.

Alexeyslav писал(а):За такое надо линейкой по рукам...

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

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

WiseLord писал(а):Когда кнопок мало, приходится изгаляться.

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

в моей практике был случай, когдая "изголнулся" и сделал управление всеми функциями реобаса одной кнопкой: задание порога и гистерезиса регулятора, включение-выключение... причем ввод числовых значений был сделан в обе стороны (уменьшение и увеличение) с ускоренным автоизменением при долгом удержании... мне казалось - я придумал гениальный алгоритм: кратковременное нажатие изменяло значение на 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

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

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

[uquote="ARV",url="/forum/viewtopic.php?p=3291380#p3291380"]так и делайте, как написали: вычисляйте сумму счетчиков на каждой итерации и сравнивайте её с 77[/uquote] Я, конечно, сравниваю. Попробовал сделать так: Если сумма этих двух счётчиков больше либо равна 78 (переход по brcc), то устанавливаю флаг в регистре общего назначения, а в той части программы, где прибавляю счётчики к Z, при наличии этого флага вычитаю 78. Таким образом адрес Array + 78 = Array, Array + 79 = Array + 1 и т.д. Чтобы вместо пустого элемента по адресу Array + 78 прочитался снова нулевой элемент массива. Но почему-то не работает Может, я вычитаю константу из регистровой пары неправильно? Делаю subi ZL,78 sbci ZH,0

Добавлено after 2 minutes 37 seconds:
[uquote="BOB51",url="/forum/viewtopic.php?p=3291407#p3291407"]Для побайтовой продвижки массива в ОЗУ предпочтение использованию указателей в X, Y и счетчика итераций с буферным регистром временного хранения.

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

[uquote="Гефестион",url="/forum/viewtopic.php?p=3291475#p3291475"]...Делаю subi ZL,78 sbci ZH,0
...Читаю прям из флэша и сразу в порт (по прерываниям от таймера)...[/uquote]Думаю, в этом ошибка. Проще, по мне,

[uquote="akl",url="/forum/viewtopic.php?p=3291499#p3291499"]Проще, по мне, [/uquote]
Так это загрузка адреса нулевого элемента массива в Z. Я так и делаю. Здесь в качестве "флага" используется весь Temp4, в котором либо 0, либо 255.

[uquote="Гефестион",url="/forum/viewtopic.php?p=3291503#p3291503"]Так это загрузка адреса нулевого элемента массива в Z. Я так и делаю.[/uquote] Почему бы и не вернуться в начало.

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

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

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

siimao писал(а):Кварцы использовал.

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

[uquote="siimao",url="/forum/viewtopic.php?p=3293062#p3293062"]...алгоритм прерывания по получению сообщения...[/uquote]
Прерывание срабатывает при получении одного байта. При окончании получения сообщения должен приняться байт, сигнализирующий об окончании пакета. Вот после приёма такого байта и нужно уже всё обрабатывать.