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

[WiseLord]

На самом деле, при записи (1<<TOIE0) МК ничего никуда не сдвинет, ему транслятор ассемблера уже сразу даёт готовое число (0b00000100, например). Поэтому нет смысла писать магические числа в программе, которые непонятно откуда берутся, а сразу писать на уровне определений регистров. Код становится понятнее, но при этом ни на йоту "тяжелее" для МК.

[СКАЗОЧНИК]

чем транслятор отличается от компилятора??? Все время их путаю, а так и не понимаю, что это такое...

[WiseLord]

Транслятор - более общее понятие. Компилятор - лишь подвид трансляторов, обычно преобразующий программу на языке высокого уровня в программу на низкоуровневом языке.

Любой ассемблер - это фактически это лишь более удобная запись тех же машинных команд. Поэтому тут компиляции как таковой и нет.

[ПТУ-шник]

Ещё один нубский вопросик
Стандартный код задержки:

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

DELAY:             
subi r16, 1 ; Просто вычитания константы, у меня константа ==1       
sbci r17, 0 ; Вычитание константы (в моём случае нуля) и бита С (бит переноса) регистра SREG
sbci r18, 0      
brcc DELAY ; Переход если нет переноса.

Так вот. В первой командой понятна, она просто вычитает и если переходит через ноль то записывается бит С.

Со второй и последующей непонятно. Допустим бит С установлен. Это бит успешно вычтут из r17, r18 и переход brcc НЕ сработает т.к. бит С установили и его не кто не сбрасывал. И дальше в программе он будет установлен всегда, пока его вручную не сбросят. Верно рассуждаю? Или этот бит каким то образом сам по себе сброситься? Если сброситься то когда и почему?

Я честно уже раз 10 перечитывал эту часть из книжки «Практическое программирование на языке ассемблера» и гуглил не раз, но ответа так и не нашёл

[COKPOWEHEU]

Команды subi и sbci сами меняют бит переноса. Для них, это - заем из старшего байта. То есть если в r16 будет 0, результат будет 0xFF, а бит C будет установлен. Для любого другого числа r16 уменьшится на 1 без переноса, то есть бит С будет сброшен. Тоже самое с остальными регистрами. Таким образом, вся эта последовательность уменьшает на 1 трехбайтное число r18:r17:r16 и крутится в цикле, пока оно не станет равным нулю.
Читать надо было справку по ассемблерным командам и пройти эти операции в уме.

[ILYAUL]

или в симуляторе той же студии

[ПТУ-шник]

Команды subi и sbci сами меняют бит переноса. Для них, это - заем из старшего байта. То есть если в r16 будет 0, результат будет 0xFF, а бит C будет установлен. Для любого другого числа r16 уменьшится на 1 без переноса, то есть бит С будет сброшен. Тоже самое с остальными регистрами. Таким образом, вся эта последовательность уменьшает на 1 трехбайтное число r18:r17:r16 и крутится в цикле, пока оно не станет равным нулю.
Читать надо было справку по ассемблерным командам и пройти эти операции в уме.

Читал справку, помойму как раз с радикота скачал. Там не написано что эти команды так битом С управляют. Из ваших слов я понял что:
Когда r16 прошёл через ноль, бит С установился. Затем это бит переноса вычитается из r17 и сбрасывается и так по кругу до тех пор пока r17 не перейдёт через ноль и бит переноса не вычтится из r18. Как то так.
Получается r16 будет проходить через 0 пару десятков тысяч раз прежде чем через ноль перейдёт r18.


Студией не пользуюсь. Откуда можно взять полный справочник по ассмеблеру? Есть две штуки, одна распечатана на 5 страницах и ещё с радиокота на 40 страниц. Но там тоже самое почти...

[ILYAUL]

А зря , 4.19 самый цимес. Всё остальное дерьмо

[Demiurg]

...

Я уже не могу спокойно читать эти вопросы. Книга Вольфганг Трамперт #AVR-RISC микроконтроллеры фирмы Atmel#. Сайт gaw.ru. Забудьте про форум, пока не прочитаете книгу. И да, студию установите, 4.19.

[Z_h_e]

Любой ассемблер - это фактически это лишь более удобная запись тех же машинных команд. Поэтому тут компиляции как таковой и нет.

Конечно же компиляция есть, просто она на много проще, чем у языков высокого уровня.

Там не написано что эти команды так битом С управляют.

Вы что-то не то читаете или не внимательно. Если команда выставляет флаги по результату операции, то она выставит их, независимо в каком состоянии флаги были перед выполнением. Если был перенос С=1, если не было С=0. Остальных флагов это тоже касается.

[Jack_A]

Если команда выставляет флаги по результату операции, то она выставит их, независимо в каком состоянии флаги были перед выполнением.

... с той оговоркой, что бит С и сам может быть одним из операндов ( напр. , в команде SBCI ) , поэтому результат операции, в т.ч. и состояние бита С, будет зависеть от его состояния "до того".
Все это замечательно, вплоть до последнего бита, расписано в Comset.pdf на сайте Атмела.

Ну я ж не писал что результат операции должен быть один и тот же при разных начальных значений флагов.

Это уточнение для новичков, чтоб не было разговоров : "А ить нам говорили, что..." А как же :

Если команда выставляет флаги по результату операции, то она выставит их, независимо в каком состоянии флаги были перед выполнением.

[Z_h_e]

Ну я ж не писал что результат операции должен быть один и тот же при разных начальных значений флагов.

[Shark-vc]

прошу помощи более опытных товарищей)

Не получается справиться с ЖКИ, пишу на ассемблере, контроллер атмел 8535.
Закоментировал передачу данных по интерфейсам spi и twi и обработку этих данных для удобства.

Вроде делаю все по инструкции, да и по форуму лазил, смотрел кто что пишет, но успеха нет)

[Demiurg]

...

Какой именно ЖКИ?

[Shark-vc]

...

Какой именно ЖКИ?

lm016l

[Demiurg]

...

У тебя либо инициализация хромает, либо аппаратная часть (непропай, замыкание, обрыв). Возможно просто нужно подкрутить контростность.
Я даю тебе архив с рабочей либой для ЖКИ. У меня 20х4, 4-битный интерфейс. Работает либа так: раз в 1 мс, посимвольно отправляется содержимое буфера на дисплей. В программе работаем с буфером. Но можно работать и напрямую с дисплеем. Разбирайся сам. Отвечу только на уточняющие вопросы.

[Jack_A]

Работает либа так: раз в 1 мс, посимвольно отправляется содержимое буфера на дисплей.

Даже если инфа не изменилась ? Если так, то это затратно по ресурсам. Я бы в таком случае, обновляя буфер, выставлял бы флаг. Либа снимала бы этот флаг после полнго обновления дисплея.

[Demiurg]

...

Так сделано по следующей причине: дело в том, что если информация статична, на некоторых знакоместах со временем появляются кракозябры. То есть, дисплеи крайне чувствительны к помехам по питанию. В пром условиях вплоть до сброса дисплея. Я занимаюсь промоборудованием. И как бы я не фильтровал питание дисплея, время от времени появляются кракозябры. Притом они иногда появляются даже в домашних тепличных условиях. Поначалу я периодически выводил всю нужную информацию на дисплей, потом стал использовать буфер. В конечном итоге воспользовался советом участника одного форума, возможно он есть и на этом форуме. Koyodza. Создается буфер размером Max_X*Max_Y. Раз в 1 мс содержимое буфера посимвольно выводится на дисплей. При 20х4 полное обновление происходит за 84 мс (4 адреса строк).
Как показала практика, это надежный способ работы со знакосинтезирующими дисплеями.
Затраты минимальны.

[WiseLord]

Кстати, по поводу затрат. Добавление флага обновления только их увеличит.

Я подобный принцип использую для графических (128x64) дисплеев, правда там буфер требует уже 1КБ памяти, поэтому сгодится для МК от ATmega32 и выше. Но принцип на самом деле очень хорош, так как отрисовка происходит фактически аппаратно и очень быстро, так как не нужны никакие задержки между отправкой данных в дисплей.

[Demiurg]

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

Да, такой способ еще и этим хорош. Не нужно выдерживать задержки между отправкой команд и данных.