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

[akl]

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

Слишком категорично. В ATtiny13 бутлоадера нет, а возможность записи FLASH есть.

16. Self-Programming the Flash
The device provides a Self-Programming mechanism for downloading and uploading program code by the MCU itself. The Self-Programming can use any available data interface and associated protocol to read code and write (program) that code into the Program memory. The SPM instruction is disabled by default but it can be enabled by programming the SELFPRGEN fuse (to “0”).

Сам активно использую возможность записи калибровок во FLASH ATtiny2313, кстати тоже не имеющего бутлоадера.

[BOB51]

Так бутлоадер - всего лишь программная "надстройка" для использования протокола самопрограммирования, отличного от исходного аппаратного, созданная изготовителем устройства.
А базируется всегда на аппаратном протоколе самопрограммирования (у АВРок вариации команды SPM).
Кроме того, обычный код 0xFFFF/0xFF при аппаратном "переборе" также равноценен NOPам - заполнение памяти программ чем-то иным используется в основном для табличных селекторов и/или сверхбыстрых кодеров/декодеров.
Чтоб МК с внутренним ПЗУ от внешних факторов "сбрендил" при исполнении программы...
Другое дело ежли внешние сигналы на лапках "за 50" перевалили. Или программные "извраты" слишком мудреные и на грани разумной нагрузки на МК - но на то тест-испытания имеются.
Насчёт "соломки" - смотри правила у микрощипа уж там перестрахерились "с запасом" - но более не от залета по кодам команд, а по возможности отказа системного генератора (ибо уж слишком пикачу микромощный) и по неконтролируемым "иглам" по питанию - в обеих случаях светит глухой "ступор" - полный останов МК в произвольном месте программы.
Следующим фактором сбоев может быть некорректный переход в несоответствующую ячейку ПЗУ,но такая проблема актуальна лишь для МК с произвольной длиной кода команды. У АВР, ПИКов и АРМ - фиксированная длина кода каманды, выполнение "бредятины" там просто невозможно ( в отличии от I8080, Z80, I8086, mcs51).

[Jack_A]

С основными тезисами согласен. А вот...

...МК с произвольной длиной кода команды. У АВР, ПИКов и АРМ - фиксированная длина кода каманды

А что, бывают такие ? Команда в 19 байт. А у АВР тоже не все команды 2-байтовые -- LDS, STS к примеру.

[BOB51]

Основной формат команд АВР - двухбайтовое слово.
Дополнительно возможен формат с адресным полем опять же размером в слово. Однобайтовых кодов просто не существует (но производная проблема - вечная путаница в вопросах с размещением таблиц данных и строк данных).
У ПИКов также соблюдается подобная форма (но полностью двухбайтовые только у 18-й и выше -у среднемладших 12-14 битовый формат ).
I8080, Z80, mcs51, I8086 имеют произвольный формат, включающий в себя различные компоненты (адрес, данные, различные префиксы), кроме того для команд счетчик там идет ПОБАЙТОВО (любой встретившийся первый байт - начало команды), тем самым возможно случайное попадание в середину команды и соответствующие последствия. Для АВР или ПИКа попасть во второй байт слова при выборке команды практически из области фантастики. Частично там есть еще один уровень защиты, распознающий подобную ситуацию с пропуском "фиктивной команды" (попадание на второе слово, содержащее адрес) - но как то организовано, честно-не вникал.
Насчет бывают "длинные команды" или нет...
Достаточно двухбайтовой команды с приращением счетчика команд в один байт и сбойного возврата не на начальный код, а на второй байт. (А может и похуже MOV add,ads mcs51 или INC (IX+rel), SET 5,(IY) в Z80).

[Kavka]

Для АВР или ПИКа попасть во второй байт слова при выборке команды

Думаю, что Jack_A имел в виду команды состоящие из двух машинных слов (а не байт). Соответственно можно на второе слово "джампнуть" так или иначе. И можно утверждать с очень большой долей вероятности, что защиты против этого нет.

[BOB51]

В принципе возможно, но гораздо меньше, чем в тех же системах с произвольной длиной кода команды.
А ежли о таблицах... так у компилятора достаточно средств для правильного определения смещения адреса метки... Другое дело когда вручную на листочке трансляцию делать приходилось...
Да и насчет "детектора фальшивой команды".... все ж гдей-то встречалось... ШКЛЕРОЗЬ...

[Jack_A]

Мне не нравится слово "произвольная". Бывают команды различной длины, но при этом - всегда детерминированной, а не произвольной.
Насчет трудностей ложного "перескока" . Давно, еще в прошлом веке , Атмел выпустила баг репорт о том, что если после команд типа SBRC идет двухсловная команда, то может произойти х.з.ч. Но начиная с ревизии Х мы, мол, эту багу пофиксили. А если будете писать, мол, на С, то вумный компилятор и сам не допустит ничего такого даже на старых ревизиях.
А перескочить "не туда" -- как 2 байта об асфальт : загоняешь в Z адрес перехода -- IJMP -- и вы уже в Хопре. И представить механизм, который может предотвратить это аппаратно -- совершенно невозможно, в отличие от вышеописанной ошибки. Разумеется, все вышесказанное относится к прогр. на АСМе.
Про "попасть во второй байт" команды я и не думал и не говорил. Ес-сно, речь шла о втором слове команды.

[BOB51]

Но ведь в указателе Z перед тем компилятор поставит правильно заданный адрес метки.
(как и в случае подстановки адреса возврата через стек).
Зачем абсолютными значениями пользоваться, ежли в компиляторе метки имеются???
Возможность загнать туды чегось неудобоваримого возможна только при некорректности работ с вычисляемыми по ходу программы самим МК адресами - а то уж "баг программиста", а не железа
Насчёт SBRC Rr,b (и прочей группы "пропуск инструкции при совпадении")....
это ж какой глюккос-валериани споймать надо, чтоб за ней команду длинного перехода (двухсловник) впихнуть?
там же четко оговорено, что пропуск одной инструкции, а не двусловного монстра.
произростание от cjne a,#d,rel (да и остальных cjne в mcs51), заодно и "зеркальная" по смыслу CPSE Rd, Rr у АВРок пропуск одной ячейки для счетчика команд ( у АВРок = слову, у 51-х = байту, у пичков ячейка в соответствии разрядности).

[Kavka]

Раньше была ошибка в ядре, да.

там же четко оговорено, что пропуск одной инструкции, а не двусловного монстра.

А сейчас и "двухсловного монстра" можно.
Например, из спецификации на мегу168

Спойлер

И не только инструкции длинных переходов из двух слов...

[Jack_A]

возможна только при некорректности работ с вычисляемыми по ходу программы самим МК адресами - а то уж "баг программиста", а не железа

" Вот иманно !" (С)
Если можно сделать какую-нибудь ошибку - она будет сделана. Закон Мэрфи.
Ладно, разобрались.

[BOB51]

Отдельные "исключения" не в счет - у АВРок куча всяческих нюансов в конкретных даташитах, но "исключение", не являющееся общим правилом обычно и приводит к проблемам.
Кстати... в основном документе так и стоит PC+2 (or 3) одначе 2 выполняется в любом случае, а насчет 3 это в конвеере предвыборки анализ проводится должен на предмет "а кто там у нас следующий?" - есть ли такой аппаратный обработчик а самом имеющимся в лапах экземпляре МК токмо пробный тест кода на данном МК покажет.

[Jack_A]

В новых поступлениях -- есть, Атмелы на старые грабли не наступают.
Кстати, была у меня единожды с ними заморочка. Гоняю прогу - бредятина выходит, переход не срабатывает. Голову сломал, анализируя код -- ничего. Последовательным приближением нашел проблемную команду -- флаг не устанавливается. Заменил абсолютно эквивалентной парой команд -- ОК. Прогнал в симуляторе исходный вариант -- так тоже нормально! Написал Атмелям -- пришли, говорят, прошивку. Не слать же им всю рабочую прогу -- там до проблемного места через два десятка ветвлений добираться. Уменьшил код, выщемив только интересующий участок. Ни хрена себе! Тут работает нормально!
Так и остался в неведении, прога пошла с эквивалентной парой.
И дело тут не в том, что эквивалент не полный -- сам натыкался на то, что INC и ADD, к прмеру, по разному устанавливают С. До атомов разобрал в симуляторе и на макете на разных режимах эту пару и подозрительную команду - абсолютная идентичность. Но вот в конкретном контексте с конкретным МК что происходит -- так и осталось покрытым мраком.
А вы говорите -- Си, где к возможным багам МК могут добавиться заскоки компилятора.

[ARV]

сам натыкался на то, что INC и ADD, к прмеру, по разному устанавливают С

ну это как бы документировано изначально: INC не задействует флаг переноса вообще, а ADD изменяет его.

может быть, все чудеса заключены в чудотворцах, а не в ядрах МК?

[BOB51]

ммм....
о "длинных переходах"...
при общем объёме программной памяти для большинсьва "ходовых" МК в 4килобайта слов в большинстве случаев достаточно RJMPа чтоб перекрыть практически весь эффективный диапазон доступа в+/-2килобайта... Возможно посему и не приходилось пока с двухсловными переходами по условию сталкиваться.
ARV
с вопросом о "чудотворцах" вполне согласен - чем проще алгоритм - тем надежнее.
сам испытал ( viewtopic.php?f=57&t=84941&hilit=+%D1%83%D0%B1%D0%B8%D0%B9%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9+%D0%BA%D0%BE%D0%B4 )

[Jack_A]

может быть, все чудеса заключены в чудотворцах, а не в ядрах МК?

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

[SatinS]

Доброго времени суток. Есть массив в eeprom из 70 символов, я хочу перенести их в озу но не через стэк. Подскажите - как переделать код, что бы данные из eeprom загружались в ОЗУ "с начала" а не с конца. Вариант вручную прописать ВСЕ адреса для каждой ячейки не подходит а сам придумать не могу :|

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

ldi Temp,RamEnd
out SPL,temp
CLI
ldi temp,0
EERead:   
SBIC    EECR,EEPE
RJMP   EERead
OUT    EEARL, temp
SBI    EECR,EERE 
IN    temp1, EEDR
push temp1
inc temp
cpi temp, 70
brne EERead
SEI

[Gudd-Head]

Ну так считать не от 0 до 70, а наоборот (кстати, помимо прочего для этого не нужна команда cpi = экономия). И из регистра сохранять не в стек, а в ОЗУ c помощью команд ST/STD через указатели адреса ОЗУ X/Y/Z.

[akl]

Можно так

Спойлер

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

   .ESEG
   .ORG   $50
;***************************************************************************
COEFF:
;данные
   .DB   $00,$01,$02,$FA   
   .DB   $04,$92,$45,$E8
;.............
;.............
;.............
;.............
E_END:
;************************************************
;*************************************************   
CLR ZH
CLR YH
   LDI   ZL,LOW(COEFF)
   LDI   YL,LOW(COEFF+$40)
_E:
   RCALL   EEREAD
   ST   Y+,R0
   INC   ZL
   CPI   ZL,LOW(E_END)
   BRNE   _E
;*************************************************   

[Gudd-Head]

Почему

.ORG $50
LDI YL,LOW(COEFF+$40)

?

[SatinS]

Gudd-Head так я так и хочу, но не понимаю как)
при таком раскладе запись идёт в один и тот же регистр
ну да, если cpi уберу сэкономлю такты))

Спойлер

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

ldi Temp,RamEnd
out SPL,temp
CLI                 
ldi temp,0
EERead:   
SBIC    EECR,EEPE   
RJMP   EERead   
OUT    EEARL, temp
SBI    EECR,EERE 
IN    temp1, EEDR       
LDI   ZL,low(CalibrM)
LDI ZH,High(CalibrM)
ST Z+, R18
inc temp
cpi temp, 70
brne EERead
SEI

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

akl, либо я что то не так делаю, либо что то я делаю не так, но не работает

Спойлер

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

E_END:

CLR ZH
CLR YH
   LDI   ZL,LOW(CalibrE)
   LDI   YL,LOW(CalibrE+$40)
_E:
   RCALL   EEREAD
   ST   Y+,temp1
   INC   ZL
   CPI   ZL,LOW(E_END)
   BRNE   _E

EERead:   
SBIC    EECR,EEPE   
RJMP   EERead
OUT    EEARL, temp
SBI    EECR,EERE
IN    temp1, EEDR
ret

.ESEG 
CalibrE: 
.DB 0b00000011, 0b01100100
.DB 0b00000011, 0b01111100