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

[BOB51]

Кто к чему привык (или с чего начинал).

Да и область применения - абсолютно самостоятельно или в качестве комплектной единицы (да еще и чаще используемая).
До возможностей keil конечно далековато, однако вполне качественный материал.

[AQ29]

[uquote="ARV",url="/forum/viewtopic.php?p=3722735#p3722735"]

С которым я сейчас разбираюсь - его нет в общем доступе. Пока нет.

интрига! любопытство накалено до предела
думаю, в общем доступе его и не будет никогда - кому он нужен-то будет когда-то "потом"?![/uquote]

Разных ассемблеров не знаю, но, судя по примерам здесь, прогресса в развитии ассемблера не заметил.
Где-то к концу года что-то проявится.
Если представляет интерес, могу вам сообщить.

[uquote="BOB51",url="/forum/viewtopic.php?p=3722771#p3722771"]То, что имеется в наличии (avrasm2) вполне достаточно для качественной работы.
Остальное - удел ЯВУ.
[/uquote]
Если исходить из требований прошлого века, может, и достаточно.
Сейчас уже хочется чего-нибудь получше.
На мой взгляд, у хорошего ассемблера должно быть следующее.
1 Глобальные и локальные переменные (RON, SRAM, EEPROM, RVV, константы, биты). Локальные переменные видимостью модуля, процедуры или макроса. Размерность переменных – 8 байт.
2 Команды условий: If, While, Until.
3 Встроенные функции (временные задержки, матфункции и т.д.).
Для матфункции должно быть указано формат переменной, диапазон переменной, точность, время выполнения в циклах. Должен быть выбор точности. Скажем, вызов десятичного логарифма в виде: Log10_2(x) / 0,5, где 2 – это двухбайтная переменная, 0,5 – гарантированная точность расчёта логарифма в указанном диапазоне.
4 Современный сервис: свертки подпрограмм и условий, раскраска команд и переменных, подсказки и т.д.

[BOB51]

Это уже не ассемблер, а разновидность ЯВУ.
Без права на самостоятельное распределение ресурсов и свободу применяемых приемов.

[КРАМ]

Да, какая то рандомная смесь из хотелок на уровне сущностей и сервисов. И полное непонимание зачем люди пишут на АСМе.

Сервисы с колапсайдерами и раскрасками давно уже используются в средах и они никакого отношения ни к АСМу, ни к Си не имеют.
Команды в АСМе определяются наличием инструкций в платформе МК, а не АСМом как таковым.
Функции о которых шла речь так же отсутствуют и в АСМе и в Си. Они есть в библиотеках. Но библиотеки можно написать на любом языке. Это определяется опытом работы, а не выбранным языком.

[ARV]

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

так это, вроде бы, никакого отношения к ассемблеру не имеет - это имеет отношение к IDE или редактору кода.

На мой взгляд, у хорошего ассемблера должно быть следующее.

согласно ваших критериев, хороший, просто отличный "ассемблер" называется... Си он даже лучше всего того, что вы написали!

Разных ассемблеров не знаю, но

это правильно: любой дурак сможет сначала узнать многое, а потом сделать лучше всего этого. настоящий гений сразу делает лучше всех, изначально не зная ничего

[BOB51]

ARV
То "монстро" на адуринку смахивает, только разукрашенную и с подсветкой...

[КРАМ]

Товарисч AQ29 просто в принципе не понимает что такое ассемблер и как он работает. Вот и пишет рандомный бред.

[Alexeyslav]

1 Глобальные и локальные переменные (RON, SRAM, EEPROM, RVV, константы, биты). Локальные переменные видимостью модуля, процедуры или макроса. Размерность переменных – 8 байт.

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

2 Команды условий: If, While, Until.

Если ввести такие сущности в ассемблер... то это будут не более чем предопределённые макросы. Не проще ли просто подключить заранее заготовленный файл с этими макроопределениями? Ой, или его вам кто-то должен дать?

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

[ARV]

чего не хватает в нынешнем ассемблере - так это более мощной и менее ограниченной системы макроподстановок.

попробуйте gnu-as, точнее avr-as - макросы практически те же, что и в masm или tasm

[shonty]

[uquote="AQ29",url="/forum/viewtopic.php?p=3798003#p3798003"]2 Команды условий: If, While, Until.[/uquote]
AVR-asm-мом занимаюсь относительно не долго. Сначала меня обескуражило отсутствие таких явных, как if-then-else...
Уверяю, эти неудобства временны и проходящи. На данный момент я прекрасно без низ обхожусь и не настальгирую по ним.

Причём не трудно заметить, что популяризация, упрощение, "дружелюбность к пользователю" вызывают куда более непонимание и проблемы. Иной раз хочу посмотреть, как с каким-нибудь датчиком или дисплеем люди работают, так весь интернет забит безответными вопросами ардуинщиков.

[AQ29]

[uquote="BOB51",url="/forum/viewtopic.php?p=3798010#p3798010"]Это уже не ассемблер, а разновидность ЯВУ.
Без права на самостоятельное распределение ресурсов и свободу применяемых приемов.
[/uquote]
Можно назвать и вариантом ЯВУ. Дело не в названии, а в удобстве пользования.
Откуда берётся запрет «на самостоятельное распределение ресурсов»?
В чём ограничение «свободы применяемых приёмов»?
Фактически, у программы есть все возможности ассемблера.
[uquote="КРАМ",url="/forum/viewtopic.php?p=3798013#p3798013"]Да, какая то рандомная смесь из хотелок на уровне сущностей и сервисов. И полное непонимание зачем люди пишут на АСМе.

Команды в АСМе определяются наличием инструкций в платформе МК, а не АСМом как таковым.
Функции о которых шла речь так же отсутствуют и в АСМе и в Си. Они есть в библиотеках. Но библиотеки можно написать на любом языке. Это определяется опытом работы, а не выбранным языком.[/uquote]
Люди пишут на Асме, чтобы решить поставленную задачу. На хорошем Асме писать хорошо, на плохом – плохо.
Библиотека или встроенная функция - не принципиально.
Основной смысл – не изобретать велосипед, а использовать готовую функцию.
Думаю, встроенную функцию вызвать проще, соответственно, удобней.

[uquote="ARV",url="/forum/viewtopic.php?p=3798018#p3798018"]так это, вроде бы, никакого отношения к ассемблеру не имеет - это имеет отношение к IDE или редактору кода.[/uquote]
Это общее пожелание к языку, а не к конкретно к ассемблеру.
[uquote="ARV",url="/forum/viewtopic.php?p=3798018#p3798018"]согласно ваших критериев, хороший, просто отличный "ассемблер" называется... Си он даже лучше всего того, что вы написали![/uquote]
В СИ приходится делать вставки из ассемблера - это вроде как костыли. А костыли свидетельствуют об инвалидности программы, здоровому костыли не нужны.
[uquote="ARV",url="/forum/viewtopic.php?p=3798018#p3798018"]это правильно: любой дурак сможет сначала узнать многое, а потом сделать лучше всего этого. настоящий гений сразу делает лучше всех, изначально не зная ничего [/uquote]
Напоминает высказывание Эйнштейна: «Все знают, что это невозможно. Но вот приходит невежда, которому это неизвестно — он-то и делает открытие.»

[shonty]

Уважаемый AQ29, я вот только не пойму мотив Ваших претензий к AVR ASM-у. Или у Вас есть какая то прорывная идея (судя по высказыванию):
[uquote="AQ29",url="/forum/viewtopic.php?p=3803683#p3803683"]Напоминает высказывание Эйнштейна: «Все знают, что это невозможно. Но вот приходит невежда, которому это неизвестно — он-то и делает открытие.»[/uquote]

[AQ29]

[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3801741#p3801741"]Всё это есть и с самого начала. Просто поймите что в ассемблере нет такого понятия как переменная - процессор и инструкции оперируют только адресами в памяти, только не говорите что в ассемблере нет директив распределения памяти по адресам и нет меток... биты вообще больное место - не всегда есть вообще аппаратная реализация побитового доступа, поэтому битовый доступ решается при помощи макросов в конкретных условиях конкретного проекта.[/uquote]
А что, существует какой-то запрет на применение переменных в ассемблере? Про такой запрет я, действительно, ничего не слышал.
В хорошем ассемблере биты – обычные переменные, особых проблем нет.
[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3801741#p3801741"]Команды условий: If, While, Until. [/quote]
Если ввести такие сущности в ассемблер... то это будут не более чем предопределённые макросы. Не проще ли просто подключить заранее заготовленный файл с этими макроопределениями? Ой, или его вам кто-то должен дать?[/uquote]
Что представляет собой заранее заготовленный файл с этими макроопределениями? Он стандартный для всех задач, или его надо писать под конкретную задачу?
[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3801741#p3801741"]Чесно говоря, чего не хватает в нынешнем ассемблере - так это более мощной и менее ограниченной системы макроподстановок. Сейчас это выглядит как набор костылей, и понятное дело почему...[/uquote]
Я уже писал – костыли свидетельствуют об инвалидности программы.
На «здоровой» программе писать лучше.

[afz]

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

Это, так сказать, "гвоздь не от той стенки". Ассемблер - это представление машинных команд конкретного процессора в символическом виде. В частности, для AVR ассемблер позволяет, например, вместо кода 0xE41A написать команду LDI R17,0x4A, что означает "загрузить в регистр R17 шестнадцатеричную константу 4A". И, соответственно, объекты, которыми может манипулировать программа не ассемблере - только те, которыми может манипулировать процессор. То есть, 32 условно-общих регистра, какое-то количество регистров-портов ввода-вывода, какое-то количество ячеек памяти (отдельно флеш-памяти, отдельно оперативки, отдельно NVRAM), и (почти) все. Переменные в этот список, увы, не входят. И вообще, переменная - это более высокий уровень абстракции, чем ассемблер.

[Starichok51]

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

[afz]

от названия суть не меняется.
нравится ему называть один бит переменной или весь регистр называть переменной - пусть называет ...

Нет. Разговор следует вести на одном языке. Соответственно и слова надо употреблять правильно.

я, вот, никогда не пользуюсь ни макросами, на какими-то подстановками (то есть, всякими костылями) - просто пишу на ассемблере, и горя не знаю.

Ну, в общем-то, нормальные макроассемблеры во многом облегчают жизнь. Но не это АВР-овское убожество. Такое впечатление, что его авторы ни разу не видели нормального ассемблера. И вообще ничего не видели, кроме Паскаля на писюке. Один их набор символических наименований для битов в регистрах периферии чего стоит? Это какую такую траву надо курить, чтобы придумать метод набора двоичного числа в группу смежных бит одного регистра путем сдвигов нулей или единиц на обозначенное символически число бит? Я имею в виду конструкцию, вроде 0<<CS02 | 1<<CS01 | 1<<CS00 для прескалера таймера 0 вместо простого и понятного (допустим) T0prs64, которое в подключаемом по .Include файле было бы определено, как 0x03. Да даже для одиночных битов оно малополезно - команды SBI/CBI - единственные, для которых такие наименования имеют смысл, работают только с первыми тридцатью двумя портами I/O (00-1F), даже у самого первого AT90S1200 почти половина регистров I/O для этих команд недоступна.

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

В общем, единственное, для чего полезны макросредства этого недоассемблера, это мелкие операции из двух-трех команд, вроде загрузки слова в регистровую пару, типа, когда надо загрузить в XL LOW(ADR), а в XH - high(ADR)

[shonty]

В макросах ни чего плохого не вижу, тем более, если макрос создаёшь сам и знаешь для чего и как он работает. Сейчас с TFT дисплеями работаю, там постоянно нужно передавать координаты поля для вывода текста / изображения. При этом нужно отослать по SPI 3-и 8-ми битных параметра и 4-ре 16-ти битных.
Забивать код лишними строками, причём не информативными не вижу смысла.
В итоге в коде координаты поля (для вывода I-ой строки текста) выглядят так:

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

LCD_FIELD 5,310,0,47

соответственно макрос:

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

; Макрос для установки поля вывода изображения на дисплей.	
	.MACRO	LCD_FIELD
		ldi	R16	, 0x2b			; Column Address Set Координата X
		rcall dspl_SEND_COM
		ldi R16, high(@0)			; XS
		ldi R17, low(@0)
		ldi R18, high(@1)			; XE
		ldi R19, low(@1)
		rcall dspl_SEND_DATA_32
		ldi		R16	, 0x2a		; Row Address Set Координата Y
		rcall	dspl_SEND_COM					;
		ldi R16, high(@2)			; YS
		ldi R17, low(@2)
		ldi R18, high(@3)			; YE
		ldi R19, low(@3)
		rcall dspl_SEND_DATA_32
		ldi	R16	, 0x2C			; RAMWR (2Ch): Memory Write		
		call	dspl_SEND_COM	
	.ENDMACRO	

Макросы идут отдельным файлом. Применение каждого оправдано.

[BOB51]

Разница между макросом и подпрограммой -
макрос каждый раз кушает память программ, подпрограмма лежит в одном месте и только вызывается из многих, экономя ресурс ОЗУ.
Другое дело когда коротенький макрос-подстановка с перечнем параметров - замещение не имеющейся команды к примеру.
Особо актуально в случае "сокращенного набора команд" к группе которых и АВРки относятся...
Посему в Вашем, shonty, случае лучше таки подпрограмма с передачей параметров через стек или блок регистров (массив в ОЗУ).
примерно:
в макросе только заполнение параметров (для всех обработчиков) и вызов подпрограммы обработчика
а не многократный вызов разных подпрограмм у каждой из которых свои параметры.

[shonty]

[uquote="BOB51",url="/forum/viewtopic.php?p=3804114#p3804114"]Разница между макросом и подпрограммой -
макрос каждый раз кушает память программ, подпрограмма лежит в одном месте и только вызывается из многих, экономя ресурс ОЗУ.[/uquote]
Когда начинал работать с TFT тоже придерживался такого принципа.

Посему в Вашем, shonty, случае лучше таки подпрограмма с передачей параметров через стек или блок регистров (массив в ОЗУ).

и через ОЗУ тоже работал... И это было год назад.

Но через год всё привёл именно к такому виду. И это был осознанный шаг. Дисплей требует скорости вывода. Пришлось уходить от call-ов и ret-ов и даже

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

SPI_WAIT

оформлять макросом, да, в ущерб памяти.

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

BOB51, очень понравилось ваше высказывание:
[uquote="BOB51",url="/forum/viewtopic.php?p=3798010#p3798010"]права на самостоятельное распределение ресурсов и свободу применяемых приемов.
[/uquote]

[BOB51]

А через push/pop?
Там ведь предзагрузки индексного регистра не требуется (как и счетчика позиций) как в случае с
ST Rd,N+/LD Rd,N-.
Единственно порядок загрузки обратный - первый из используемых параметров загоняем с втек последним.
Это просто как предположение достаточно редкоиспользуемого варианта решения.