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

[Starichok51]

да, я не могу представить, как из одного числа адреса можно получить разные значения первого байта. и уж тем более, получить два управляющих байта для фьюзов.
вот ты увидел в мплабх конкретные числа адресов, и начались домыслы про какие-то маски.
а мои домыслы, как я уже сказал выше, что мплабх тот адрес заменяет на правильные байты для каждого действия.
так возьми даташит, хотя бы, на АТмега8, и увидишь для фьюзов "пустой" третий байт, который в таблице обозначен "хххххххх", то есть, его значение произвольное.

[КРАМ]

Starichok51 писал(а):

возьми даташит, хотя бы, на АТмега8, и увидишь для фьюзов "пустой" третий байт, который в таблице обозначен "хххххххх", то есть, его значение произвольное.

У меня открыта аппнота по программированию...
Произвольное значение разрядов говорит лишь о множественном доступе и более ни о чем.
Мы с тобой имеем совершенно разное понимание сущностей в программировании.

[Starichok51]

ну и ладно, ну и пусть...

[AQ29]

BOB51 писал(а):

Вроде как определенная область адресов ПЗУ позволяет сие сделать.
Я просмотрел документацию на имеющиеся у меня образцы АВРок и нигде намека на адрес байта конфигурации не заметил. Хоть для режима параллельного программирования, хоть для ISP…

Скорее всего, пустым делом занимались, нет в МК секретных адресов доступа. Как я понял, «виртуальные адреса» в файле – это, фактически, просто указание на тип данных в файле. Программа программатора распознаёт тип данных и посылает их в МК, расположенный в программаторе. А тот программирует стандартным образом.
Плюсом такого решения – все данные в одном файле, а так приходится хранить 3 файла.
Правда, неясно, как хранится информация о том, надо или нет, например, программировать фьюзы при запуске программирования.
В моём случае в загрузочном файле кроме информации о битах фьюзов есть еще данные, будут ли они программироваться или нет.
Вообще полное программирование за раз почти никогда не использовал. Такое удобно при программировании отдельного МК.
Всегда запаивал МК в печатную плату, а там есть разъём программирования, не нужны разные сокеты.
В этом случае лучше программировать по отдельности.

Just_Fluffy, считывание переменной из МК – это понятно.
Но переменная в разных точках программы принимает разные значения. Как при отладке проводится привязка считывания к точкам программы?
JTAG не пользовался, на мой взгляд неудобен. Он присутствует не во всех МК и использует 4 вывода МК.

При объявлении переменных в RON объём программы, а главное, скорость выполнения значительно возрастает. Это очень существенно при управлении скоростными процессами, надо успеть, а тактовая частота МК – не гигагерцы.
Насколько слышал, у СТМ32 тоже небольшое число RON – всего 12 штук, правда, они 4-хбайтные.
Интересно узнать максимальный размер переменных и их видимость.

[Jack_A]

AQ29 писал(а):

При объявлении переменных в RON объём программы, а главное, скорость выполнения значительно возрастает.

имелось в виду: "объём программы уменьшается" ? Ведь в этом случае адрес операнда - в слове самого кода и не требует отдельного слова для адреса. По крайней мере, так в АВР.

[Just_Fluffy]

Да простят меня модеры, ибо это тема ассемблера АВР и все нижесказанное будет оффтопиком.
AQ29, самая простая "народная" СТМка - F103C8 - имеет тактовую до 72 МГц. Китай-клоны - до 108 МГц... Вам мало?

Но переменная в разных точках программы принимает разные значения. Как при отладке проводится привязка считывания к точкам программы?

Хммм.... Вы внутрисхемной отладкой программы в МК пользовались хоть раз?
Есть такое понятие как точка останова. Брякпоинт. Breakpoint. Вы в окне с текстом программы выставляете эти точки останова там, где вам нужно. И запускаете выполнение программы. Выполнение не в эмуляторе, а в железном МК, подключенном через отладочный интерфейс.
И при достижении точки останова выполнение программы в МК останавливается. В окне с программой выделение стоит на той строке программы, где в данный момент остановлено выполнение программы МК.
Наведя мышью на переменную в строке программы вы видите значение этой переменной в данный момент.
По F7 можно шагать по одной строке программы и смотреть, как меняются переменные, регистры периферии и прочее.
В соседнем окне можно просмотреть другие локальные переменные текущего блока программы. Можно просмотреть глобальные переменные, изменять их значения, поиграться с периферией. Это все работает, пока МК остановлен.
Можно настраивать, будут ли в режиме останова продолжать считать таймеры или тоже остановятся...

Jack_A, у СТМ флеша и оперативки обычно больше, нежели у простых АВРок. И экономить объем программы, загоняя какие то переменные в РОН - в большинстве случаев нет смысла. Равно, как и писать программы на ассемблере. Сейчас вообще тенденция максимально огородить программиста от МК, предоставив ему максимально универсальные обертки железа и кодогенераторы для стандартных применений периферии.
В нашей с GoldenAndy игровой консольке стоит СТМка - 512 кб флеша, 128кб ОЗУ.
И в этой СТМке поместился полноценный компилятор бейсика в байт-код и выполнятор этого байт-кода. И шустренькая консолька вышла. И, кстати, еще куча места в СТМке осталась. Цена вопроса - 4 бакса за СТМ на отладочной платке. (Ну я так покупала у китайцев).
И на ассемблере писать под такие объемы - увольте. Последние мои проги на асме закончились на тиньке2313 и меге8 на момент изучения платформы. Скорость разработки на ЯВУ несоизмеримо выше. Да, за это надо платить размером программы. Но как утверждают в интернете знающие люди - грамотно написанная программа на Си дает прирост объема кода 20-30% против грамотной программы на асме.

[КРАМ]

AQ29 писал(а):

Плюсом такого решения – все данные в одном файле, а так приходится хранить 3 файла.
Правда, неясно, как хранится информация о том, надо или нет, например, программировать фьюзы при запуске программирования.
В моём случае в загрузочном файле кроме информации о битах фьюзов есть еще данные, будут ли они программироваться или нет.
Вообще полное программирование за раз почти никогда не использовал. Такое удобно при программировании отдельного МК.
Всегда запаивал МК в печатную плату, а там есть разъём программирования, не нужны разные сокеты.
В этом случае лучше программировать по отдельности.

Не вижу никакой связи между внутрисхемным программированием и программированием фьюзов вместе с кодом.
В производство выдается файл для прошивки с защитой кода, а при разработке защита кода закомментирована.
Но МК всегда впаян в схему. Зачем его программировать до монтажа?
Более того, в коде может быть условная компиляция, которая позволяет генерировать разные версии кода по объявленным в хедере переключателям.
В этом случае и фьюзы и еепром могут стать объектом такого управления трансляцией.

AQ29 писал(а):

При объявлении переменных в RON объём программы, а главное, скорость выполнения значительно возрастает. Это очень существенно при управлении скоростными процессами, надо успеть, а тактовая частота МК – не гигагерцы.

"Гигагерцы" тут не причем. Для МК с "гигагерцами" скорость исполнения кода так же важна. Иначе зачем нужны эти "гигагерцы"?
Тут все дело в том, что и AVR, и ARM являются RISC-архитектурами, а значит система команд ограничивает всю арифметику АЛУ регистровыми операндами. То есть работа с ОЗУ происходит только через инструкции LOAD/STORE. В отличии от CISC, где РОНов обычно немного, но имеются инструкции арифметики прямо с содержимым ОЗУ. Среди МК к этой архитектуре относятся PIC-и и dsPIC-и, причем в 16-разрядных их представителях РОН-ов достаточно много (целых 16), но почти вся арифметика разрешает работу АЛУ с первыми 8К байт ОЗУ одним из операндов (непосредственная адресация).
ЗЫ. Стесняюсь спросить, а почему вы называете регистры общего назначения через латинскую транслитерацию? Что означает RON?
Вообще то они называются GPR - general purpose registers.

Just_Fluffy писал(а):

Скорость разработки на ЯВУ несоизмеримо выше.

И тем не менее, работать на АСМе порой очень даже целесообразно. Например на критических участках кода. Или когда архитектура имеет ненативные для Си (или другого ЯВУ) инструкции. И эти инструкции дают значимые для кода и изделия ништяки.
Не нужно относится легкомысленно к объемам памяти в ARM-ах. Нужно помнить, что скорость выборки инструкций из флеша ограничена частотой 25...40 МГц. А это означает, что к высокой скорости ядра в ARM нужно относится очень осторожно, обращая особое внимание на величину WS (waite state) в чипе. И чтобы обойти этот неприятный нюанс порой нужно выгружать исполняемый код в ОЗУ. Правда, в некоторых МК это делается автоматически и прозрачно. Иногда есть выбор между такой автоматической загрузкой и применением ОЗУ по прямому назначению и тогда WS не равен нулю...

[Martian]

КРАМ писал(а):

В отличии от CISC, где РОНов обычно немного, но имеются инструкции арифметики прямо с содержимым ОЗУ. Среди МК к этой архитектуре относятся PIC-и и dsPIC-и

Полагаю, "к этой" ссылается на упомянутую ранее RISС

[Just_Fluffy]

И тем не менее, работать на АСМе порой очень даже целесообразно. Например на критических участках кода. Или когда архитектура имеет ненативные для Си (или другого ЯВУ) инструкции. И эти инструкции дают значимые для кода и изделия ништяки.

Ну я же не утверждала, что всегда... Я написала - в большинстве случаев)))))

[Jack_A]

Just_Fluffy писал(а):

Jack_A, у СТМ флеша и оперативки обычно больше, нежели у простых АВРок. И экономить объем программы, загоняя какие то переменные в РОН - в большинстве случаев нет смысла.

Я не говорил о целесообразности - речь шла о бесспорном, IMHO, факте, что код с использованием РОН короче, чем с памятью. По крайней мере, для AVR.

В нашей с GoldenAndy игровой консольке стоит СТМка

Я к СТМ - никаким боком. К сожалению.
----------

Спойлер

"Бесспорно" - Word считает, что правильно писать : "Бес с порно". А "мультиканальный" - "мультик анальный"

[Just_Fluffy]

Jack_A, Для маленьких проектов - да. Для больших - РОНов не напасёшься.
Кстати (опять же, оффтоп для данной темы) - сишный компилятор локальные переменные (счетчики циклов и т.д.) старается по возможности в регистры упихать. А уже что не влезло - уносится на стек.
А то, что "Никаким боком к СТМ" - в этом прелесть ЯВУ. Вы пишете, невзирая на то, какой у вас МК. Единственное зависимое место - взаимодействие с периферией. Оно железозависимо. А логика программы - она должна быть абстрактная. Хотя абстракция - это некий объем доп.кода.

[AQ29]

Just_Fluffy, насчёт отладки.
На мой взгляд, при отладке с точками остановок есть недостатки.
Иногда нельзя останавливать МК, потеря управления может привести к тяжёлым последствиям, скажем, система пойдёт в разнос.
Кроме того, вы смотрите данные только в одной точке.
Для меня это старая отладка из прошлого века.
Давно использую следующую отладку.
В нужных точках программы ставятся команды, выводящие в программатор номера точек и интересующие переменные.
При пуске МК на компьютере появляются номера точек и значения переменных.
Такая отладка, на мой взгляд, намного удобней. Можно проконтролировать ход выполнения программы и значения переменных в реальном режиме и без остановки МК.
Недостаток – используется пара выводов МК (реально обычно один) и вывод переменных занимает некоторое время. В основном, это несущественно.
Такой программатор недорогой, комплектация – Atmega8 и немного периферии.

«...Для больших – РОНов не напасёшься...»
Почему не напасёшься?
Есть же определённые правила программирования.
Большей частью программа состоит из вызовов подпрограмм (Sub и макросы). Подпрограммы решают небольшие задачи.
В подпрограммах в РОНах объявляются локальные переменные, их там обычно относительно немного.
Какие переменные объявить в РОН, какие в SRAM, решает разработчик. После компиляции можно посмотреть число вызовов той или иной переменной. Много вызовов – объявить в РОН, мало – в SRAM.

«…грамотно написанная программа на СИ на 20-30 % больше…»
Сильно сомнительно, что в СИ код возрастает только на 20-30 %.
Кто утверждает, как сравнивали? Возможно, взяли небольшую программу, неплохо написанную на СИ, и получили такой результат.
Скорее всего, в серьёзных программах всё гораздо хуже.

«…независимость от МК – в этом прелесть ЯВУ…»
Не вижу в этом прелести. Выигрыш почти никакой, а потери большие. Возрастание объёма, может быть, не очень существенно, а вот скорость работы может быть очень критична.
Сталкивался с плохо работающей следящей системой, СИ-шник писал.
На форуме описывали случай, когда «медленный» МК вообще привёл к смертельному случаю.

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

КРАМ писал(а):

Стесняюсь спросить, а почему вы называете регистры общего назначения через латинскую транслитерацию? Что означает RON?

Отчего стал применять аббревиатуру RON, сейчас уже не вспомнить. Скорее всего, где-то в программе, где только английские буквы, надо было использовать такую переменную, GPR показалось неблагозвучным.
Конечно, здесь на сайте надо было использовать общепринятое обозначение, а не «самодельное», заметили правильно.
Какая аббревиатура на английском общепринятая – для меня вопрос. На мой взгляд, GPR не подойдёт.
В новых МК АВР в регистрах ввода/вывода есть регистры общего применения, которые также называются. Причём это официальная документация, так что такая аббревиатура уже занята. Похоже, эти регистры удобно использовать для флагов, поскольку с ними работают команды SBI и другие.
В документации ещё указывают, что РОН это ещё и рабочие регистры, но про аббревиатуру GPWR я ничего не слышал.

По поводу полемики о фьюзах.
В новых МК АВР фьюзы действительно расположены в общем адресном пространстве данных, адрес &H1050. Однако записать фьюзы можно также только программатором UPDI, через CPU невозможно.
Если кому интересно, в даташите на МК AVR32DA32 в разделе 7 есть таблица 7-5, где указано, что можно программировать через программатор, что через CPU.

[Just_Fluffy]

AQ29, Я не собираюсь вам что то доказывать или уговаривать.
Если вы, как программист и разработчик, решитесь в критичной секции поставить точку останова - ну так это ж вы решили осознанно и прекрасно понимаете последствия. Ну а если не осознаете , то ССЗБ увы...
Отладка критичных секций логированием тоже имеет место быть. Но это разные случаи и один другой не заменяет. Скорее, дополняет.
Касательно смотреть значение только в одной точке - я смотрю значения именно в тех точках, где мне нужно. И пошагово прохожу по коду, при необходимости. Причем эти точки могу расставлять и убирать на лету.
А еще - я ответа на свой вопрос "Вы внутрисхемной отладкой программы в МК пользовались хоть раз?" так и не увидела.

Касательно абстракции.
Просто скажу, что мне приходилось пару раз проекты переносить с одной платформы на другую. И это было вообще безболезненно для логики работы программы. Менялся только блок взаимодействия программы с периферией, вынесенный в отдельный файл.
А внутри семейства вообще перенос безболезненный.

И да, позор тому программисту, у которого абстракция снизила производительность на ощутимом уровне.

И, кстати, в пользу ЯВУ.
Большинство операций с периферией, вынесенные в простые процедуры в блоке взаимодействия с железом, превращаются оптимизатором компилятора в обычные обращения к периферии, без накладных расходов в виде вызова процедуры.
В частности, установка/сброс бита в порту, загрузка/чтение регистров периферии - прекрасно оптимизируются.

Засим позвольте откланяться, постараюсь в теме ассемблера больше не оффтопить.

[КРАМ]

AQ29 писал(а):

Какая аббревиатура на английском общепринятая – для меня вопрос. На мой взгляд, GPR не подойдёт.

А ваш взгляд никого не интересует.
Это общепринятая аббревиатура. Русский РОН суть есть дословный перевод - General Purpose Register.

[Starichok51]

«…грамотно написанная программа на СИ на 20-30 % больше…»
Сильно сомнительно, что в СИ код возрастает только на 20-30 %.
Кто утверждает, как сравнивали?

видимо, сравнивали те программисты, которые на ассемблере пишут по тем же принципам, по каким работает сишный компилятор.
если писать на ассемблере грамотно и не зная принципов сишного компилятора, то ассемблерный код может быть даже в несколько раз меньше, чем после сишного компилятора.
приведу пример.
у меня разработаны собственные подпрограммы (функции) работы с плавающей точкой. я в сишной программе посмотрел дизассемблерный код стандартных функций умножения и деления.
так вот, умножение у меня примерно имеет примерно в 1,5 раза меньше строк. а деление там разбросано на несколько подпрограмм-"кусков". я даже не стал прикидывать общий размер функции деления, но на вскидку у меня объем подпрограммы деления (в строках) в несколько раз меньше.
но больше всего меня в стандартной библиотеке интересовал вывод числа с плавающей точкой в строку. и я нашел нужную мне функцию - strtod. она работает быстро за счет использования табличного метода при любом значении числа типа float. поэтому я её заимствовал себе в мою "библиотеку".

[КРАМ]

Starichok51 писал(а):

программисты, которые на ассемблере пишут по тем же принципам, по каким работает сишный компилятор.

Как программист, который примерно лет 15 писал практически все на АСМе, могу возразить по существу.
1. Писать по принципам работы компилятора невозможно. Можно писать "как на Си". Компилятор тут вообще не причем.
2. На Си можно писать что угодно и как угодно. Поэтому сравнивать плохо написанный код на Си с АСМом как то несерьезно.
3. Строить программу на АСМе аналогично построению программ на Си позволяет соединить читабельность Си и эффективность АСМа.
4. Размер кода не является критерием сам по себе. Есть разный подход к оптимизации кода. В общем случае компактный код работает медленнее.

[OKF]

Я бы добавил, что основным преимуществом Си является переносимость кода. При элементарно аккуратном написании, исходники с минимальными правками (только в хедерах) переносятся не только внутри семейства, но и между платформами (типа PIC, AVR, X51...). Зачастую нужно только пины назначить и всё. При этом не важно какое семейство и какая платформа.
Ну или взять Ардуино. Там о железе ВООБЩЕ можно не думать и не знать!

[Just_Fluffy]

OKF, я про это же и говорю.
Мне доводилось переносить дважды свои проекты с 8-разрядной платформы на 32-разрядную.
Кардинально правке подвергалась только c/h-файлы с описанием работы с периферией.
В каких то местах еще что то подправилось в угоду 32-разрядной платформе, но то чисто косметика.

С асмом сложнее, он гораздо более платформозависим.
Иногда даже в пределах одного семейства АВР есть нюансы - тини/мега, память выше 64к (хотя я себе не представляю, как можно писать на асме под ту же 128 мегу и сколько времени займет разработка... )
Но вынести работу с периферией в отдельный инклюдник можно и на асме, оформив либо макросами, либо подпрограммами с определенными соглашениями.

[BOB51]

При хорошей проработке я особой разницы в работе под ассемблером для mcs51/avr/pic не замечаю.
Правда "чуток слэнг" в том помогает.
Си/С++ (от адуринки) помогает с алгоритмами (как и "в обратную сторону" - решения из ассемблера к ЯВУ).
Касательно "ардуиноплатформенных"...
В одном из возможных вариантов применения это вообще чуток иная картинка в подходе - имеем DIP микросборку "черный ящик" с собственным набором команд ЯВУ.

Но ... Данная тема то ассемблеру для AVR посвящена, а не обсуждению "несколько отвлеченных тем".

[Transformer-V]

КРАМ писал(а):

Есть разный подход к оптимизации кода. В общем случае компактный код работает медленнее.

Компактный код не может работать медленно, особенно при использовании РОН и специфических команд процессора, это и есть оптимизация, "раздутый" код будет работать медленно, особенно, если программист часто использует память ОЗУ, а не РОНы.