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

DX168B

Держи:

.include		"m32def.inc"

;*******************************************
.dseg
BUFF:			.byte			3

;*******************************************
.cseg
.org			0x0000
rjmp			RESET

.org			INT_VECTORS_SIZE

RESET:
ldi				r16,			Low(RAMend)
out				SPL,			r16
ldi				r16,			High(RAMend)
out				SPH,			r16
ldi				r18,			0

MAIN_LOOP:
mov				r16,			r18
ldi				XL,				Low(BUFF)
ldi				XH,				High(BUFF)
rcall			DECODER_BIN_10
inc				r18
rjmp			MAIN_LOOP

;*******************************************
DECODER_BIN_10:
clr				r17
DIV_10_LOOP:
cpi				r16,			10
brlo			DIV_10_END
subi			r16,			10
inc				r17
rjmp			DIV_10_LOOP
DIV_10_END:
st				X+,				r16 ;Пишем в ОЗУ результаты
mov				r16,			r17
tst				r16
brne			DECODER_BIN_10
ret

Реклама

Lekter

Доброго времени суток, товарищи!
Не знаю, может надо было писать в другую тему, но всё-таки... Помогите пожалуйста с алгоритмом программной реализации заданной логической функции: (^x0+x1)(x1+x2+x3)
Написать программу я смогу, только не подскажете ли вы, как мне объявить инверсию?

Реклама

Meteor

Lekter писал(а):Помогите пожалуйста с алгоритмом программной реализации заданной логической функции: (^x0+x1)(x1+x2+x3)
Написать программу я смогу, только не подскажете ли вы, как мне объявить инверсию?

Дык проще простого
Если на выводе 0 - идем на метку 1, иначе на метку 2. (обезличено)

Lekter

Meteor писал(а):
Lekter писал(а):Помогите пожалуйста с алгоритмом программной реализации заданной логической функции: (^x0+x1)(x1+x2+x3)
Написать программу я смогу, только не подскажете ли вы, как мне объявить инверсию?
Дык проще простого
Если на выводе 0 - идем на метку 1, иначе на метку 2. (обезличено)

Это всмысле делать метки как? Имею ввиду, сначала делать x0+x1 на одной метке, а потом x1-x0 на другой? Просто я действительно "только родился" в этих делах.
И ещё вопрос: при x1+x2+x3 команда ADD или OR?

Реклама

Meteor

Начнем с начала
что такое х0...х3?
сигналы?
байты?
числа?
в чем их мерить?

Реклама

Lekter

Вообще задание такое: составить алгоритм для программной реализации заданной логической функции (^x0+x3)(x1+x2+x3). С оговоркой, что это будет выполняться в AVR.
Я так понял, что это всё-таки байты либо числа. Скорее - байты.

Реклама

Lekter

to Meteor. Прошу прощения, не могли бы Вы проверить мою программку? AVR к сожалению на мою 7ю винду не ставится.
Буду очень благодарен, если укажете недостатки!

Meteor

Чтото мне подсказывает что речь идет о сигналах - 3 логических сигналах и функция которую выполняет МК.
Уточните у преподователя. Пишите в личку.

desolator

Скажу оффтоп, но я б использовал дял таких целей уже Си, а не асм.

Meteor

Скажу оффтоп, но я б использовал дял таких целей уже Си

Затроллим тему - в топку МК, прикрутим Циклон 5 или Спартан 6 для этого.
По существу - зачем такое навороченное создание как С, в функции 4х сигналов? Что бы раздуть программу из "10 строк машинного кода" по объему до нескольких килобайт? (хотя и это оффтоп)

desolator

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

Jack_A

/Преамбула/
Если представить, что указанная задачка имеет хоть минимально-отдаленное отношение к практическим задачам, чего в учебных примерах наблюдать приходится крайне редко по причине полной оторванности учебы от жизни, то
/Амбула/
Будем считать, что поступают 4 логических сигнала в 4 младших бита порта D, которые обрабатываются, и результат решения выводится в младший бит порта B.

Код: Выделить всё

	in           r16,PIND
	mov   r17,r16
	mov   r18,r16
	com   r18
	lsr   r17
	lsr   r17
	lsr   r17
	or    r17,r18
	andi   r17,1    ; первый операнд
   	;
	mov   r18,r16
	andi   r18,14
	breq   _66
	ldi   r18,1    ; второй операнд
   	;
_66:	and   r17,r18
	brne       _75
	cbi          PORTB,0
	rjmp       _77
_75:	sbi          PORTB,0
_77:        ........

Скептики скажут : зачем использовать R16, можно сразу вводить в операционные регистры R17,R18. Умудренные опытом так не скажут, ибо нужна одномоментная фиксация принятого сигнала, чтобы ничего страшного не произошло, если за время обработки сигналы изменятся.
Вот так на примере мелкой задачки приходят здравые мысли. Так что микроконтроллеры - это вам не шахматы, тут думать нужно.
А потом : "забудьте как кошмарный сон то, чему вас учили в институтах, идите в цех и начинайте учиться" (С) А.Райкин

Meteor

Тут особенность есть. Если х1=1, то нет смысла делать вычисления ибо (х0+1)(1+х2+х3)=1.
Еще одна, если х0=1 и х1=0, то нет смысла вычислять второй операнд ибо (не1+0)(0+х2+х3)=0.
В остальном думаю аффтор уже разобрался))

Gudd-Head

Gudd-Head писал(а):Как с помощью МК определить направление вращения энкодера, покрасивее и покомпактнее?
Энкодер двухбитный в коде Грея, т.е. последовательность 00-10-11-01 в одну сторону и 00-01-11-10 в другую.

Мдяаа, товарищи... В общем, решил я делать это табличным методом, т.е. брать 4 бита положения (2 прошлых + 2 текущих), прибавлять их к адресу начала 16-байтной таблицы и получать текущее состояние энкодера (покой или вращение по/против часовой). К слову о недавних диспутах по поводу антидребезга: его решил делать полностью программно (энкодер подключен напрямую к МК, у порты подтянуты встроенными резисторами).
В общем, почему-то работало всё примерно наполовину, не так как задумывалось. Поначалу грешил на антидребезг.
ВНИМАТЕЛЬНО изучив даташит на энкодер я наконец-то увидел, что общий вывод сбоку, а не посередине (по аналогии с переменником я почему-то был уверен что он там

).
Но! Кардинально это ничего не улучшило. В процессе отладки я понял, что даташит ввёл меня в заблуждение, а конкретно вот эта картинка:

Я предполагал, что каждом положении энкодера возможно любое из состояний (00/01/10/11).
Как оказалось, неподвижный энкодер в любом положении выдаёт "11" (видимо, на это и намекает пунктирная линия с буквой D на рисунке), а замыкание на "землю" (изменение состояний 11-10-00-01-11 или 11-01-00-10-11) происходит только в момент поворота.
Так что задача сильно упрощается: если порт (к к-рому подключен энкодер) читается как "01", то вращение в одну сторону; "10" — в другую.

DX168B

Gudd-Head обратите внимание на диаграмму:

Ложняков в направлении вращения не будет?
Может сделать так: Сначала получаем первичные биты, например 01. Уходим в первую ветку п\программы опроса и ждём там биты 10, как подтверждающие. После подтверждения выполняем действия. При вращении в обратную сторону получаем 10, потом уходим во вторую ветку программы и за тем ждём там биты 01 в подтверждение, после чего выполняем действия.
В ветках опроса, помимо ожидания подтверждения, можно устроить цикл такого рода: Если 256 раз прочиталось 11 или 00, то выйти из ветки в начало программы опроса.

Может это и изврат, но кажется, что для обычного энкодера этого должно хватить.

Gudd-Head

DX168B писал(а):Ложняков в направлении вращения не будет?

Я вот тоже уже подумал что не всё так просто, если к этой диаграмме пририсовать дребезг:

Так что либо подбирать задержку так, чтобы чётко попадать в установившиеся состояния "10-00-01", либо ждать следующих "11".

DX168B

Наверное всё-таки надо будет отслеживать порядок последовательностей. И наверное всё-таки нужно будет кондёров навешать на порты, ну и задержка в опросах пинов. Вот есть у меня парочка контактных энкодеров. В свободное время тоже поэкспериментирую. Откопал несколько микросхем PT2313L и испытываю огромное желание собрать на них электронный регулятор громкости с тонкомпенсатором + электронный темброблок + электронный баланс RL + баланс FR. Всем этим будет рулить МК с энкодером и индикатором. Ещё хочется повесить на МК индикацию уровня сигнала.

IM1 · Сообщение **IM1** » Чт июн 09, 2011 12:01:37

Gudd-Head писал(а):Мдяаа, товарищи... В общем, решил я делать это табличным методом, т.е. брать 4 бита положения (2 прошлых + 2 текущих), прибавлять их к адресу начала 16-байтной таблицы и получать текущее состояние энкодера (покой или вращение по/против часовой).

ИМХО, все значительно проще и рассмотрение инкрементального энкодера в статике не имеет смысла.
Еще в очень давние времена делал счетчик для намотки катушек: D триггер определял направление счета реверсивного счетчика.

D_trig.jpg: (15.7 КБ) 959 скачиваний

В данной схеме фиксируется лог. уровень сигнала A по положительному фронту сигнала B. А по сему однозначно: при вращении по часовой стрелке на выходе будет "1", против часовой "0". Обратите внимание, что дребезг для данной схемы не имеет значения. Для счета импульсов необходимо сформировать одиночный импульс по фронту сигнала B, длительностью немного больше "дребезга" на этой шине. В жесткой логике это легко решается одновибратором, ну а в мягкой ест. программно.
Полагаю, что такой алгоритм работы легко можно реализовать программно, например по прерыванию или иным способом. Как говорится, дело вкуса и предпочтений.

Gudd-Head

IM1 писал(а):А по сему однозначно: при вращении по часовой стрелке на выходе будет "1", против часовой "0".

А если энкодер не вращается?

IM1 · Сообщение **IM1** » Пт июн 10, 2011 21:23:21

Gudd-Head писал(а):А если энкодер не вращается?

???
А что Вы хотите делать с невращающимся энкодером? Скорее всего, ждать продолжения процесса.
Весь его смысл в том, чтобы вращать ручку влево или вправо. Схема определяет направление по каждому приходящему импульсу, а Вы этот импульс либо суммируйте, либо вычитайте, либо обрабатывайте по какому-либо хитрому закону.