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

[BOB51]

Ну "точные задержки" с разрешением до такта можно и программным способом сформировать...
Все зависит от конкретной программы, принятых приоритетов и имеющихся в распоряжении ресурсов.
У каждого метода свои особенности и ресурсные требования. Выбор за автором конкретной прожки.

[Serhio]

Подскажите пожалуйста где в Atmel Studio 6.2 хранятся инклудники. Например tn2313def.inc

[Z_h_e]

Есть очень удобная штука в компе - поиск файлов.

[Serhio]

Есть.
Написал несколько строчек кода

.include "m8def.inc"
.list
.def temp = r16

.equ kdel = 64 // Ввели константу и обозвали ее - kdel

ldi Temp, High(RAMEND) // Причесали стек как в даташите
out SPH, Temp
ldi Temp, Low(RAMEND)
out SPL, Temp

.dseg
.cseg
.org 0

собственно все стандартно, НО при написании любой другой строчки, например элементарно
ldi temp, 0

выпадает следующая ошибка при компиляции
Overlap in .cseg: addr=0x0 conflicts with 0x0:0x4
Господа, что это такое? Такая реакцию на любую последующую запись будь то инициализация чего-либо или просто запись в temp. Что я упустил?

[Z_h_e]

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

.include "m8def.inc"

.def temp = r16

.equ kdel = 64 // Ввели константу и обозвали ее - kdel

.cseg 
.org 0

ldi Temp, High(RAMEND) // Причесали стек как в даташите
out SPH, Temp
ldi Temp, Low(RAMEND)
out SPL, Temp

Добавлено after 4 minutes 53 seconds:
Кстати, .include "m8def.inc" можно убрать. Atmel Studio 6 сама их подключит автоматом что надо. Только в настройках проекта правильно МК выберите.

[BOB51]

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

Как вариант альтернативы (дабы не заморачиваться с предупреждениями и подсчетами по конкретным МК)

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

  .cseg
		.org 0x000
	irq_res:
		rjmp init ; переход к началу программы инициализации системы
; - - - - - - - - - - - - - - - - - - - - - - - - - - -
; блок размещения векторов активных прерываний
;		.org OC0Aaddr
;	irq_t0:
;		rjmp timers_bum ; steps
; - - - - - - - - - - - - - - - - - - - - - - - - - - -
;________________________
   .org (irq_res+int_vectors_size) ; обход блока векторов прерываний
		init:                    ;блок начальной инициализации кристалла

[Serhio]

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

[Z_h_e]

Нет. Ошибка не в этом у Вас была. Я же поправил код.
Если не указывать с какого адреса будет код, он будет с 0 адреса. После инициализации регистра стека, Вы указывает что следующий код пойдет опять с 0 адреса (.org 0). Вот и вся ошибка. Текст ошибки об этом и говорит.

[Serhio]

Я же поправил код.

ВИНОВАТ, действительно не увидел сразу, спасибо Вам.
Все работает.

[dimmer]

С вашего позволения, ещё замечание. Если записать имя файла в директиве include в таких скобках <m8def.inc>, то компилятор будет искать этот файл сначала в собственной библиотеке, и вам не придётся копировать файл в папку проекта. Хотя иногда требуется в настройках указать компилятору путь к библиотеке.

[Z_h_e]

Как вариант альтернативы (дабы не заморачиваться...

Я не так делаю. Копирую таблицу векторов из ДШ, вставляю в проект, заменяю все переходы на reti, по мере написания проекта, восстанавливаю нужный переход на обработчик прерывания. Вот например вектора atmega8 из кой-какого проекта.

Спойлер

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

 .org 0
rjmp RESET ; Reset Handler
	reti//rjmp EXT_INT0 ; IRQ0 Handler
	reti//rjmp EXT_INT1 ; IRQ1 Handler
	reti//rjmp TIM2_COMP ; Timer2 Compare Handler
rjmp TIM2_OVF ; Timer2 Overflow Handler             
	reti//rjmp TIM1_CAPT ; Timer1 Capture Handler
	reti//rjmp TIM1_COMPA ; Timer1 CompareA Handler
	reti//rjmp TIM1_COMPB ; Timer1 CompareB Handler
	reti//rjmp TIM1_OVF ; Timer1 Overflow Handler
rjmp TIM0_OVF ; Timer0 Overflow Handler          
	reti//rjmp SPI_STC ; SPI Transfer Complete Handler
rjmp USART_RXC ; USART RX Complete Handler			
	reti//rjmp USART_UDRE ; UDR Empty Handler
rjmp USART_TXC ; USART TX Complete Handler         
	reti//rjmp ADC ; ADC Conversion Complete Handler
	reti//rjmp EE_RDY ; EEPROM Ready Handler
	reti//rjmp ANA_COMP ; Analog Comparator Handler
	reti//rjmp TWSI ; Two-wire Serial Interface Handler
	reti//rjmp SPM_RDY ; Store Program Memory Ready Handler
;

[ARV]

Я не так делаю. Копирую таблицу векторов из ДШ, вставляю в проект, заменяю все переходы на reti, по мере написания проекта, восстанавливаю нужный переход на обработчик прерывания.

всегда возражаю против этого подхода, возражу и сейчас.

существует, на мой взгляд, более правильная методика работы с векторами прерываний: при помощи директивы ORG задавать адрес вектора, используя именованную константу, описанную в соответствующем инклюднике. неиспользуемые векторы, таким образом, в тексте программы не упоминаются вообще.

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

.ORG 0 ; старт
   rjmp begin_program
.ORG OVF0addr ; обработчик переполнения 0-го таймер
   rjmp vector_ovf0

begin_program:
   ldi r16, 0
   ...

как-то так...

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

[ILYAUL]

..при помощи директивы ORG задавать адрес вектора...

+100500

[Z_h_e]

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

ошибка, когда из-за copy-paste таблицы векторов обработчик оказывался не в той ячейке - одна из самых распространенных.

Если не смог скопировать таблицу из ДШ правильно, то и в другом случае легко допустишь ошибку с таким же успехом, тем более тут уже надо набивать ручками.

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

Что это дает?

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

Это какая-то крайняя необходимость и ее надо избегать.

в-третьих, в программе минимум "магических чисел", т.е. она становится более переносима,

В данном случае нет ни одного магического числа. На счет переносимости соглашусь, хотя и абсолютно не трудно поменять таблицу векторов как и инклудники.

наконец, в программе нет ничего лишнего,

Текста то явно больше будет, на одно прерывание.

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

Хотя надо конечно попробовать, очень даже может быть, что я по консервативному не хочу менять точку зрения.

[akl]

По мне, нет нужды искать инклудники, вполне достаточно открыть DS, расставить используемые вектора директивой .ORG и дать оным осмысленные названия. Например, ATmega8515

Спойлер

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

	.CSEG
	.ORG	$0000
RESET:
	LDI	R16,LOW(RAMEND)
	OUT	SPL,R16
	LDI	R16,HIGH(RAMEND)
	OUT	SPH,R16

	CLR	ZH		; в этой программе всегда 0
	OUT	SPCR,ZH; очистить ячейку признака клавиатуры 

	RJMP    START		; On Reset
;************************************************
	.ORG	$000E ;Timer/Counter0 Compare Match
COMP_50mks:
	RETI
;************************************************
;************************************************
;************************************************
;************************************************
;************************************************
START:

[ARV]

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

я прихожу к выводу, что многие адепты ассемблера слишком ослеплены его низкоуровневыми возможностями, зачастую продолжая считать его мнемоническим обозначением машинных кодов. не смотря на то, что формально такая точка зрения имеет право на существование, кардинальный прогресс в саморазвитии программиста начинается только с момента, когда ассемблер начинают воспринимать именно как язык программирования, а не эквивалент машинных кодов. осознание этого факта заставляет ужаснуться убогости языковых возможностей "классического" AVR-ассемблера от Atmel и посмотреть в сторону GNU AS... где подобные "таблицы джампов" не то, чтобы порицаются, но крайне не приветствуются... ибо есть ПРАВИЛЬНЫЙ подход в дополнение к ДОПУСТИМОМУ.

отсюда и моё, основанное на достаточно большом опыте работы с ассемблером (и не только AVR - я так же прошел школу 51-го ассемблера, MASM и TASM для х86), твердое убеждение, что надо делать именно так, как я и посоветовал ранее, и не иначе. сиюминутные выгоды от иного подхода меркнут в сравнении с возможностью единообразно работать ВСЕГДА И СО ВСЕМ...

[ptr128]

Следует отметить, что, например, с точки зрения MISRA, ассемблер допустим только в виде вставок в код на C или C++. И дело даже не в том, что разработка на ассемблере дороже и поддерживать ее сложнее. Дело в том, что контролировать безопасность кода на ассемблере не реально, в отличии от C.
Если пишете для себя, то, конечно, можно плевать на все стандарты и рекомендации.
Но если от Вашей программы для микроконтроллера будет зависеть жизнь людей, как у членов MISRA, то стоит десять раз подумать, прежде чем писать ассемблерный код.

Я не в коем случае не утверждаю, что эффективно программировать на МК можно не используя ассемблер. Сам люблю на ассемблере ваять. Но если хотите стать профессионалом, то используйте ассемлер только тогда, когда это действительно необходимо. Обычно, это только незначительная часть bootloader и ассемблерные вставки в C.

[dimmer]

ARV, можно подробнее об альтернативе атмелевскому ассм?
ptr128, а с точки зрения тех кто знает только Delphi, ассемблер - происки бабы Яги.

[ptr128]

dimmer, я же писал выше, что сам люблю на ассемблере ваять. Когда-то с удовольствием проекты на несколько тысяч строк кода на ассемблере IBM/370 писал и внедрял (для Сбербанка РФ и для РЖД, например). Тогда это было оправдано. А сейчас, когда ESP8266 или STM32 стоят копейки, а AVR32 уже и виртуальную память поддерживает, стоит ли овчинка выделки?

Я за свою жизнь писал на нескольких десятках языков программирования и на почти десятке ассемблерах. При чем тут Баба Яга?

[ARV]

можно подробнее об альтернативе атмелевскому ассм

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

1. avr-as входит в состав WinAVR и любого иного GNU-того компилятора Си/С++ в качестве обязательного средства
2. вызывается автоматически "компилятором" avr-gcc для файлов с расширением .S и .s
3. работает по принципу модульной компиляции, т.е. выдает на выходе объектный файл на каждый файл-исходник, а затем линкер собирает из всех объектников итоговый "загружаемый" файл (coff или elf, например)
4. поддерживает препроцессор Си в полном объеме
5. содержит средства встроенных "макросов" в стиле TASM, например, для повтора команд, "сканирования" списка параметров макроса и т.п., что позволяет создавать очень гибкие программы на ассемблере
6. особенности синтаксиса описаны в соответствующем разделе документации на WinAVR и/или AVR Toolchain, но в целом можно сказать, что синтаксис (директивы) имеет много общего с MASM и препроцессором Си

остальное - в доках...

что могу сказать... я плотно познакомился с avr-as в тот момент, когда пробовал сделать многоголосый синтезатор, как у Чена. и получилось так, что сишный обработчик прерываний тупо был слишком медленным, и альтернативы ассемблеру не было... но для ассемблера приходилось каждый раз сохранять в стеке кучу регистров, а потом восстанавливать их в нужном порядке... сами понимаете, когда на ходу изобретаешь программу, приходится задействовать то один, то другой регистр, а потом выясняется, что лучше вместо этих совсем другие... в итоге много сил уходило на отслеживание того, какие регистры в каком порядке сохранялись и потом извлекались из стека... очень хотелось автоматизировать этот процесс. и avr-as такую возможность предоставил!

я сделал (при помощи советов знатоков, конечно) макрос ENTER и макрос LEAVE. для первого надо было в параметрах перечислить через запятую любое количество любых регистров, и макрос автоматически заталкивал этот список в стек - начало обработчика прерывания. а в конце обработчика надо было поставить LEAVE уже без параметров - и этот макрос автоматически в обратном порядке восстанавливал из стека все регистры, которые передавались в параметрах первого. в итоге разработка обработчика прерывания становилась просто сказочно удобной:

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

my_vector:
   ENTER r0,r1,r17,r16
   ; тут делаем все, что надо с перечисленными регистрами
   LEAVE
   reti

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

ну, есть и ряд других плюшек... однако хочу предостеречь: avr-as предназначен (и наиболее удобен) именно как средство расширения проектов Си/С++, а не как средство разработки проектов на ассемблере целиком (хотя можно и это, разумеется).