Ассемблер (ASM) для AVR в вопросах и ответах

[ARV]

Just_Fluffy писал(а):

Avrasm настолько убогое говнище, что я вообще не понимаю, зачем его использовать, если есть avr-as, часть тулчейна avr-gcc. ... Гнутый асм ничем не хуже, уверяю вас!

Роман, простите мою глупость, но как могут отличаться ассемблеры для одной платформы? Система ж команд одинаковая... Или вы имеете ввиду мощность и плюшки препроцессора?
(про себя скажу, что писала на чистом асме в четвертой авр-студии, когда изучала архитектуру АВРок. Потом уже седьмая студия и ассемблерные вставки в Си. На голом асме давно не пишу.)

да, плюшки.

Когда-то я был озабочен созданием макроса для сохранения в стеке списка регистров и восстановления их потом оттуда.
Как-то так:
ENTER R6,R11,R24
...
LEAVE

Не всех подряд, а именно списка нужных. Достаточно полезный макрос, согласны? В 51ом асме это реализуется, пусть не просто, но... А в avrasm это попросту невозможно. Кстати, как ни странно, но подобное невозможно и средствами препроцессора Си! Однако, as (gnu as) справляется так же и тем же способом, что и старичок 51й...

Добавлено after 1 minute 50 seconds:

BOB51 писал(а):

Если уж быть корректным то не "ассемблеры",
а компиляторы ассемблера...

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

Последний раз редактировалось ARV Пт дек 13, 2024 13:49:10, всего редактировалось 1 раз.

[OKF]

Дед, читай трансляторы, компиляторы, ассемблеры... и т.п.
Извиняюсь, опередили.)

Добавлено after 11 minutes 6 seconds:

ARV писал(а):

Однако, as (gnu as) справляется...

А IRP или IRPC он поддерживает? Отож.

[ARV]

Так, если склероз не подводит, благодаря этим и им подобным макросам-итераторам и удалось мои хотелки реализовать!

Добавлено after 2 minutes:
Кстати: в контексте сайта и форума предлагаю использовать спецтермин мышинное слово

[Starichok51]

Команды CPI Rd, Rr в системе команд AVR не существует - какой смысл ее обсуждать то?

так ты же первый написал эту несуществующую фуету.
если ты забыл, то я напомню:

CPI Rd, Rr...

[AQ29]

КРАМ писал(а):

1. Нарисуйте эпюру с нажатием и отпусканием кнопки с дребезгом и наложите на нее опрос с интервалом больше дребезга.
И вы внезапно обнаружите, что захват нажимаемой кнопки во время дребезга НИЧЕМ НЕ ГРОЗИТ…

2. Помех на кнопке кроме дребезга быть не может по определению. Там смещение чистым питанием через резистор порядка 1...10 кОм.
Метод, которым вы создаете интервал опроса значения не имеет. Но интервал создаваемый таймером выглядит куртуазнее. И не нужно обрабатывать захват в прерывании от таймера. Достаточно просто захватить порт и выставить флаг требования обработки. Хотя и в прерывании по таймеру обработка тоже не сильно тяготит.

1 Сомнительно, что дребезг ничем не грозит.
Рассмотрим случай, когда есть режим нажатия на 2 кнопки. У второй кнопки свой режим.
Вы нажали на 2 кнопки. Первая кнопка из-за дребезга была прочитана, как не нажатая, вторую, как нажатая. Соответственно, перешли на режим второй кнопки. Это ошибка, очень плохо. Жмёшь одно, получаешь другое.
В моём варианте такого нет.
Разработал свой алгоритм давно, решил проверить. Программа простая, написать – несколько минут, макетные платы есть.
Работает чётко, даже когда вторую кнопку нажимаю чуть-чуть раньше первой, читается, как нажатые две кнопки.

2 Сомнительно, что помех не может быть по определению.
Обычно питание от сети 220 вольт. В сети бывают короткие даже киловольтовые импульсы. Даже если у вас на столе не было сбоев, не факт, что у пользователя их не будет.
Проверку на сбои из-за помех надо проводить согласно ГОСТу, а не доверяться «определению».
А с такими испытаниями были проблемы. Полноценное оборудование для такой проверки стоит дорого даже для завода. Можно заказать испытание аппарата, но это тоже стоит дорого. Каждый раз после доработки заказывать испытание – в трубу вылетишь.
Может быть, сейчас ситуация лучше, не знаю.
В этом плане программная защита – хороший простой и бесплатный вариант.
Программа простая, фактически несколько ассемблерных команд плюс задержка. Для последней обычно использую программную задержку, это будет всего одна команда: Delay 30 ms.
В ассемблере, который из прошлого века, такой команды нет, но тогда у разработчика в арсенале должны быть программы задержки.

Just_Fluffy писал(а):

На фоне решения Adrift табличный вариант выглядит чудовищной растратой памяти. Но СИ-шникам, похоже, такие растраты привычны

Ну куда уж нам всем.... Главное - нужно применять современный супер-пупер-турбо-ассемблер.
Тогда алгоритмы сами пишутся.
Так вот, решение должно быть в голове. А только потом уже переложено на язык программирования. И не важно, какой это язык будет. И если есть задача выжать из кода максимум быстродействия - то и на асме можно применить табличное решение. Это ценой расхода ОЗУ/флеша сэкономит пару тактов.

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

Сомнительно, что для вашей второй задачи табличный вариант сэкономит пару тактов.
Как я представляю, в табличном варианте надо прочитать байт из флеша. Но это долгая операция. Для этого вроде как надо записать в регистры Z начальный адрес таблицы и прибавить байт. Это будет 4 команды. Плюс команда LPM, получается 5 команд, как и в решении Adrift. Но LPM – длительная команда, 3 цикла, так что вроде как табличный вариант проигрывает.

[shonty]

Первая кнопка из-за дребезга была прочитана, как не нажатая, вторую, как нажатая.

Сомневаюсь, что при максимальной частоте опроса какая-то кнопка будет прочитана как ненажатая.

Поймали нажатие -> ушли на выполнение..
Вернулись, закинули удочку, ждём дальше))

Добавлено after 5 minutes 45 seconds:
слово вспоминали? "интерпретатор" (ассемблера) - вроде оно))

[ARV]

AQ29 писал(а):

...

Не бывает в реальном мире ничего одновременного. Если нажатия двух кнопок у вас воспринимаются, как одно одновременное, есть какой-то подвох: либо всё не так, как вы говорите, либо реакция на нажатия у вас тормозная, т.е. как минимум время дребезга ОБОИХ кнопок вы ждете.

Однако, при правильном алгоритме обработки нажатий нет никакой проблемы в неодновременности... Т.е. решение проблемы, имхо, следует делать уже на верхнем уровне, а на нижнем тупо опрашивать состояние, как рекомендовал КРАМ, и я с ним согласен 100%

[КРАМ]

AQ29 писал(а):

1 Сомнительно, что дребезг ничем не грозит.
Рассмотрим случай, когда есть режим нажатия на 2 кнопки. У второй кнопки свой режим.
Вы нажали на 2 кнопки. Первая кнопка из-за дребезга была прочитана, как не нажатая, вторую, как нажатая. Соответственно, перешли на режим второй кнопки. Это ошибка, очень плохо. Жмёшь одно, получаешь другое.

Вы пишите чушь. Вы никогда не нажмете кнопки одновременно. Поэтому этот режим должен обслуживаться с неким временнЫм окном позволяющим некоторую неодновременность. Все это не имеет к дребезгу никакого отношения. Все на самом деле очень просто. Читая состояние кнопок с интервалом больше дребезга, вы получаете защиту от дребезга. А дальше обрабатываете эти состояния так. как это вам нужно. Так что:

AQ29 писал(а):

В моём варианте такого нет.

В моем тоже.

AQ29 писал(а):

2 Сомнительно, что помех не может быть по определению.
Обычно питание от сети 220 вольт. В сети бывают короткие даже киловольтовые импульсы. Даже если у вас на столе не было сбоев, не факт, что у пользователя их не будет.

Это определяется топологией платы и шлейфов, а не тупыми попытками защиты при отвратительной схемотехнике.
С чего бы помехе не быть 50 или 100 Гц?
Или импульсной, но с некоей частотой повторения и прохождением через высшие зоны Найквиста.

[OKF]

Да пофигу, что на нажнем, что на верхнем уровне.) Иной раз нужно поменьше (в размере) только и всего.

Добавлено after 3 minutes 7 seconds:

КРАМ писал(а):

[uquote="AQ29",url="/forum/viewtopic.php?p=4660041#p4660041"]1 Сомнительно, что дребезг ничем не грозит.
Рассмотрим случай, когда есть режим нажатия на 2 кнопки. У второй кнопки свой режим.
Вы нажали на 2 кнопки. Первая кнопка из-за дребезга была прочитана, как не нажатая, вторую, как нажатая. Соответственно, перешли на режим второй кнопки. Это ошибка, очень плохо. Жмёшь одно, получаешь другое.

Вы прикалыветесь? Или же далеки от людей.)

[BOB51]

Снова в "антидребезг" да кнопы вцепились.
Уж точно оно того не стоит.

[OKF]

BOBa, не тошни.)

[главный колбасист]

А если напряжение на кнопку подавать только во время считывания? Наподобие как это делается в динамической клавиатуре. Нету напряжения,нету дребезга.

[BOB51]

Так это и есть "совмещённая" с опросом кнопок динамическая развёртка.

Только "дребезг" там также присутствует - алгоритм устранения как раз на таймере развёртки строки и базируется.

[главный колбасист]

Я думал,порт включен на вход,а на кнопку постоянно питание подаётся через подтягивающий резистор.

[BOB51]

Но механику контакта никто не отменял.
Другое дело использование не механических преобразователей - оптика, магнитное поле, емкостные и/или с уже установленными "подавителями" на электронных схемках. Эти генерируют уже чистый сигнал. Просто лишние затраты аппаратной схемотехники.
Да и механика контактов может потребоваться более сложная (перекидной контакт при R-S триггере на половинке 155ла3 к примеру).
Но это не тема обсуждения ассемблера.

[Adrift]

AQ29 писал(а):

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

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

Код:

cur = IDR;
if(cur != prev)
{
    prev = cur;
    cnt = 0;
    return;
}

if(++cnt >= 9)  ...

А с тремя переменными код будет, примерно, такой:

Код:

c = IDR;
if(a != b || a != c)
{
    a = b;
    b = c;
    return;
}
....


В обоих случаях между состоянияни нужно помнить по две переменные и если ваш вариант и проще, то минимально, но зато он не масштабируется. Далее, у вас между вызовами должно быть 30ms, а вызывается функция не в прерывании, а основном цикле, с заранее не известными и изменяющими интервалами времени. Как этого добиться? И зачем? По сути считав 3 раза одинаковое значение вы просто удостоверились, что как минимум 60 ms состояние кнопок не менялось, соответственно и считать лучше время, просто добавляете к счетчику число ms пройденных с момента предыдущего вызова и тогда без разницы вызывается функция в прерывании через фиксированные промежутки времени(тогда можно просто константу прибавлять), в загруженном цикле или пустом. Ах да, у вас же нет счетчика )

ps. Не уверен, но 60ms может быть маловато чтобы уверенно детектить короткое одновременное нажатие двух кнопок. С длинными нажатиями то проблем не будет...

[BOB51]

Млин!!!
Это ж тема про АССЕМБЛЕР!!!
Версии под Си и /или адуринку в других темах.

[Adrift]

BOB51 писал(а):

Млин!!!
Это ж тема про АССЕМБЛЕР!!!

Смотрите шире. Это не С, это псевдокод!!! )

[ARV]

Adrift писал(а):

BOB51 писал(а):

Млин!!!
Это ж тема про АССЕМБЛЕР!!!

Смотрите шире. Это не С, это псевдокод!!! )

если перевести это на русский, будет "да мне насрать!"

[Just_Fluffy]

Да пофиг, про что тема - 5 страниц обжевываем АЛГОРИТМЫ.... Хотя по алгоритмам обработки нажатий на кнопки есть отдельная тема. Ссылку давала раньше...
Роман, может придумайте еще какой то конкурс/вопрос, что б вернуть тему в русло ассемблера? Типа впихнуть FatFS в Tiny13 ? ))