Заголовок сообщения: Re: Ассемблер (ASM) для AVR в вопросах и ответах
Добавлено: Пн дек 09, 2024 07:47:17
Друг Кота
Карма: 67
Рейтинг сообщений: 1060
Зарегистрирован: Чт сен 18, 2008 12:27:21 Сообщений: 19716 Откуда: Столица Мира Санкт-Петербург
Рейтинг сообщения:0 Медали: 1
Свап битов в слове мало чем отличается от свапа битов в байте - на выходе просто поменять порядок байт.
_________________ [ Всё дело не столько в вашей глупости, сколько в моей гениальности ] [ Правильно заданный вопрос содержит в себе половину ответа ] Измерить нннада?
Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.
Adrift, не, я по тупому всегда делала, циклом сравнивала с двигающейся маской. В основном это для проверки, а не нажато ли более одной кнопки. Если нажато, то все события от кнопок блокируются, пока не будут отпущены все кнопки. Ну либо, если нужно отследить одновременно нажатые - то тут уже массив допустимых масок.
А кнопка может дребезжать без нажатия на нее? Какой смысл ждать бездребезгового состояния на интервале опроса большем, чем время дребезга? Попадание на дребезг ничем не грозит. Просто читаете состояние.
Кнопки анализирую не по прерыванию, а делаю опрос на каждом витке программы. Считывание кнопок во время дребезга надо исключать, это мусор. Какой отсчёт мусорный – неизвестно, а для дальнейшей обработки нужен правильный отсчёт. Для решения этой проблемы и применяю предложенный алгоритм. Использовал три отсчёта с интервалом больше дребезга. При нажатии одной или двух кнопок один или два отсчёта могут быть мусором, но третье будет правильным. Соответственно, три одинаковых отсчёта всегда будут верными. Придумал этот метод, когда был совсем начинающим. Наверно, нажатие на кнопку - вторая задача начинающих. Первая – помигать светодиодами. Программа получилась очень простая, написать её намного проще, чем найти оптимальное решение на вторую задачу Just_Fluffy.
Про дребезг без нажатия кнопки не понял. Если это помеха, то здесь есть защита от неё.
А можно сделать программный симулятор дребезжащей кнопки,и сравнивать с ним,а не с предыдущими двумя считываниями ?
Для чего нужен программный симулятор – непонятно. За всё время я не помню ни одной неправильной реакции на кнопку, что там проверять. Симулятор при работе с внешними устройствами никогда не использовал, была уже такая полемика.
На фоне решения Adrift табличный вариант выглядит чудовищной растратой памяти. Но СИ-шникам, похоже, такие растраты привычны.
1. Я описала 2 алгоритма, которые применяю при опросе кнопок. 2. Алгоритмы сами по себе никак не относятся к ликбезу по ассемблеру. 3. Реализации алгоритмов могут быть на любом языке. И красивые решения конкретных задач (как, например, проверка поднятости одного бита) - они могут быть применены в любом языке. И да, я совершенно не возражаю, что некоторые частные случаи алгоритмов могут быть выписаны на ассемблере гораздо более изящно, нежели на любом ЯВУ. Но это конкретные частные случаи.
AQ29 писал(а):
На фоне решения Adrift табличный вариант выглядит чудовищной растратой памяти. Но СИ-шникам, похоже, такие растраты привычны
Ну куда уж нам всем.... Главное - нужно применять современный супер-пупер-турбо-ассемблер. Тогда алгоритмы сами пишутся. Вроде как для этого даже есть супер-программа - алгоритм-билдер. Где то на форуме видела, хвалили её. Лограифм на асме за одну команду вычисляет.
Так вот, решение должно быть в голове. А только потом уже переложено на язык программирования. И не важно, какой это язык будет. И если есть задача выжать из кода максимум быстродействия - то и на асме можно применить табличное решение. Это ценой расхода ОЗУ/флеша сэкономит пару тактов.
_________________ Белая и Пушистая
Последний раз редактировалось Just_Fluffy Пн дек 09, 2024 13:58:13, всего редактировалось 1 раз.
Кнопки анализирую не по прерыванию, а делаю опрос на каждом витке программы. Считывание кнопок во время дребезга надо исключать, это мусор. Какой отсчёт мусорный – неизвестно, а для дальнейшей обработки нужен правильный отсчёт. Для решения этой проблемы и применяю предложенный алгоритм..... Про дребезг без нажатия кнопки не понял. Если это помеха, то здесь есть защита от неё.
1. Нарисуйте эпюру с нажатием и отпусканием кнопки с дребезгом и наложите на нее опрос с интервалом больше дребезга. И вы внезапно обнаружите, что захват нажимаемой кнопки во время дребезга НИЧЕМ НЕ ГРОЗИТ. Предположим вы ПРИ НАЖАТИИ на кнопку с какой то там вероятностью захватили во время дребезга состояние "нажато". Значит нажатие произойдет именно в этот момент. Следующий опрос гарантированно произойдет по завершении дребезга. Предположим вы ПРИ НАЖАТИИ на кнопку с какой то там вероятностью попадете в состояние "НЕ нажато". Значит нажатие на кнопку произойдет В СЛЕДУЮЩЕМ ОПРОСЕ уже без дребезга. Все тоже самое произойдет при отпускании кнопки. 2. Помех на кнопке кроме дребезга быть не может по определению. Там смещение чистым питанием через резистор порядка 1...10 кОм. Метод, которым вы создаете интервал опроса значения не имеет. Но интервал создаваемый таймером выглядит куртуазнее. И не нужно обрабатывать захват в прерывании от таймера. Достаточно просто захватить порт и выставить флаг требования обработки. Хотя и в прерывании по таймеру обработка тоже не сильно тяготит.
Последний раз редактировалось КРАМ Пн дек 09, 2024 14:03:28, всего редактировалось 1 раз.
Дребезг мигрировал в мк из цифровой логики. Там он действительно представлял проблему, так как отсутствовало элементарное тактирование, была сложность с таймерами, сложность с установкой периода опроса клавиатуры, сложность с задержкой возврата из процедуры обработки нажатия.. и прочее. И во время ухода системы на обработку какого либо события опрос нажатий оставался постоянным.
Поэтому решали при помощи триггеров и других аппаратных наворотов. И этому посвящено достаточно литературы.
Но многие никак не могут расстаться с этим рудиментом.. видимо психологически
табличный вариант выглядит чудовищной растратой памяти.
Все зависит от потребного объема флеша для кода и имеющегося в чипе флеша. Не припомню в своей практике ни одного случая, когда были проблемы с размером флеша. Это самый дешевый ресурс в МК.
1. Нарисуйте эпюру с нажатием и отпусканием кнопки с дребезгом и наложите на нее опрос с интервалом больше дребезга. И вы внезапно обнаружите, что захват нажимаемой кнопки во время дребезга НИЧЕМ НЕ ГРОЗИТ.
Кстати, рисовал уже и выкладывал.. примерную ))
Добавлено after 1 minute 13 seconds: но я под себя рисовал, у меня задержки перед возвратом
shonty, Дребезг - это физическое явление. И от него никуда не деться. Просто в МК варианты его нивелирования гораздо более широкие. И 2-3 опроса с интервалом больше дребезга - это тоже АЛГОРИТМ. С кучей реализаций - на обычных счетчиках, на вертикальных, на массивах, на задержках и повторных опросах.... Вот когда будут идеальные кнопки - тогда это будет рудиментом.
И, кстати, мы с вами уже проговорили - в вашем случае могут быть ложные срабатывания от коротких случайных нажатий на кнопку (но это частный случай, опять же... "Кто бросил сапог на пульт управления ядерной ракетой?!")
КРАМ писал(а):
Не припомню в своей практике ни одного случая, когда были проблемы с размером флеша. Это самый дешевый ресурс в МК.
Забейте. Когда мир сошелся клином на тине13 или меге8 с современным ассемблером - то да. А когда копеешный арм с мегабайтом флеша - то тут уже и ассемблер как то не в кассу, да и табличку можно разместить, не переживая за оставшееся место.
Идеальные кнопки есть и сейчас. Это кнопки с перебросом. Но на самом деле для просто кнопок нажимаемых пальцем не нужно никаких сложных алгоритмов. Алгоритмы с фильтрацией нужны для механических энкодеров с малым временем дребезга и потребностью не пропускать импульсы на максимально возможной скорости. Тогда можно разменять задержку получения информации на высокую скорость вращения без пропусков.
Три страницы явно для темы про оригинальные алгоритмы, а не про ассемблер. Ну и часть сообщений надо в особую писькомерную тему модераторам выделить...
Кстати, про реверс битов: я такой вопрос-конкурс сто лет назад здесь проводил... Ничто не ново в подлунном мире...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Так то можно на каждое слово тему создать.. но они мёртвые будут Да и эта умрёт. Были же перерывы, когда тут никто не писал более чем по полгода. Сейчас уже не та активность у людей Всё переговорили вдоль и поперёк.
Не думаю, что обсуждение дребезга или "конкурсы" особо мешают кому то решать сложные задачи..
Тогда уж.. Может про мой ""слэнг" в работе с многофайловыми проектами" под ассемблером потрындеть? В отличии от "стандарта" там только один файл в настройках компилятора указывается... Удобненько получилось... Так про то в почти половине котуинки ( viewtopic.php?f=62&t=156720) проговорено... Особо смысла не вижу...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения