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

[BOB51]

Ну что же Вы такой вредный?
Допустим я сделал какое-то специфическое размещение данных в памяти, скомпилировал исходник и определил, что нужная мне ячейка имеет адрес 0x0120.
Но по каким-то причинам (схемотехнические хитрости - как та же внешняя память программ/данных или еще чего поизвратнее) поручить компилятору автоматическое вычисление этого адреса невозможно.
Вот тогда я и буду использовать
.EQU name = 0x0120
для доступа к той ячейке.
Довольно типовое решение к примеру в моей котуинке (биос + подгружаемые во внешнюю совмеенную память программ/данных целевых программ устройства)...

Последний раз редактировалось BOB51 Чт янв 18, 2024 19:46:42, всего редактировалось 1 раз.

[С.Н.]

Ух уж эти перепалки "Друзей Кота" про длину своих "хвостов". Почище Санта-Барбары.

[linkov1959]

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

[КРАМ]

BOB51 писал(а):

Ну что же Вы такой вредный?
Допустим я сделал какое-то специфическое размещение данных в памяти, скомпилировал исходник и определил, что нужная мне ячейка имеет адрес 0x0120.

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

[Engineer_Keen]

Ну вод представьте, есть код:

Спойлер

Код:

   .equ   TX_BUFFER   =0x0100
   .equ   RX_BUFFER   =0x0120
   .equ   TX_PTR      =0x0122
   .equ   RX_PTR      =0x0124
   ..........
   .equ   VAR123412151   =0x1234


или

Спойлер

Код:

   .equ   TX_BUFFER_SIZE   =32
   .equ   RX_BUFFER_SIZE   =32
   .equ   PTR      =2
   .dseg
TX_BUFFER:   .byte   TX_BUFFER_SIZE
RX_BUFFER:   .byte   RX_BUFFER_SIZE
TX_PTR:      .byte   PTR
RX_PTR:      .byte   PTR
.........
VAR123412151:   .byte   1


И тут я решил изменить размер буфера передачи, на один байт... По-моему нижний вариант просто удобнее.
Ну да, я не знаю какой по факту адрес у конкретной переменной, пока в .map или в .lst не посмотрю, но оно не часто и нужно.
ИМХО для каждой директивы свое применение.

[Gennadiy]

Сдается мнение, что критикой занимаются пользователи Си.
Я полностью согласен со Старичком, т.к. мы с ним активные Ассемблерщики. А в Ассемблере контроль размера буфера переменных лежит исключительно на программисте, как и расположение их в памяти МК. Тем более при пошаговой отладке знать точное распределение памяти (RAM, EEPROM, Flash) крайне необходимо.

[КРАМ]

Gennadiy писал(а):

Сдается мнение, что критикой занимаются пользователи Си.

Мнение НЕ верное. Я занимаюсь критикой, но на Си из полусотни проектов для 8 бит (те, что в серийных изделиях - хоббийные не в счет) написан лишь один. Но поскольку я пишу и на Си (это проекты для АРМов), то у меня есть вполне определенный взгляд на написание кода вообще - независимо от языка.

Gennadiy писал(а):

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

И как это противоречит использованию .byte? Вы очевидно не понимаете, что никакого "принудительного" размещения в ассемблере нет НИ ПРИ КАКИХ синтаксических оборотах. Просто принципиально нет.

Gennadiy писал(а):

Тем более при пошаговой отладке знать точное распределение памяти (RAM, EEPROM, Flash) крайне необходимо.

И что? Именно директива .byte позволяет получить ВИДИМОСТЬ переменных ПО ИМЕНИ. А адрес и так всегда указан рядом с именем.
Такшта вы просто пытаетесь критиковать "вкус устриц", ни разу их не пробуя... И это действительно факт. Железобетонный.

Добавлено after 6 minutes 40 seconds:

Engineer_Keen писал(а):

Ну да, я не знаю какой по факту адрес у конкретной переменной, пока в .map или в .lst не посмотрю, но оно не часто и нужно.

С чего бы вы не знаете? И смотреть в map или lst нет никакой необходимости.
В окне Watch адрес рядом с именем обозначен. В тексте кода имя переменной является ее адресом, поэтому и тут нет необходимости обращаться к численному значению.
Ну и достаточно просто обозначить через org начало списка byte.

[Engineer_Keen]

Gennadiy, а зачем контролировать размещение в памяти переменных, вручную задавая адреса, если среда разработки (в данном случае AVR студия) сама позволяет их расставлять? Я же привел выше пример. Что вы будете делать, если в начале адресов переменных придется изменять их размер или количество? Все следующие адреса вручную пересчитывать и переписывать?
И это не только вопрос удобства. Я (да все, кто более менее большие программы пишет) весь код делю на модули, UART - отдельный asm-файл, SPI - отдельный файл, работа с каким-нибудь дисплеем - отдельный файл, так и к ним еще inc файлы. Например UART.inc с константами для определения/вычисления скорости, размерами буферов, кодами команд, и там же - выделяем области памяти в dseg. И не надо среди всего кода искать то что относится именно к UART. И эту пару модулей, можно в другом проекте использовать с минимальными переделками, не боясь что области памяти друг на друга налезут, т.к. все переменные на этапе компиляции сами в нужное место встанут, в зависимости от того, где .inc в тексте основной программы вписать!
А в случае использования для резервирования .equ? В одном модуле определил адрес массива в 200 байт, а в другом можно случайно одну переменную для какого-нибудь счетчика в середине этого массива определить, и здравствуйте глюки...
Ни кто не запрещает equ для переменных, ну например в целях той-же отладки какой-либо определенной переменной, ну или если нужна какая-либо хитрость, выравнивание, чтобы буфер или массив начинался с адреса хх00, но в 99% случаев этого не нужно.

КРАМ, я отладкой занимаюсь либо протеусе (пока железка не готова), либо в железке, так вот протеус со списком watch из студии подружить не получается, там приходится адреса вручную вбивать

[Gennadiy]

Можно взглянуть на пример использования (запись/чтение/модификация) переменной, созданной с помощью директивы .byte, в Ассме? И да, у меня тоже есть большие проекты критичные ко времени исполнения (real-time), содержащие до 10 массивов, 206 (на данный момент) переменных и флагов различной размерности. Я не представляю, как во всем этом можно было бы ориентироваться (при пошаговой отладке), не пригвоздив каждую к конкретному месту, полагаясь только на среду разработки.
Возможно Ваши примеры направят меня на путь истинный. Без подколов и шуток, покажите преимущество .byte, пожалуйста.

[Engineer_Keen]

Чтение/запись/модификация будет выглядеть точно также, можете просто переписать весь код определения переменных с .equ на .byte а все что в .cseg - не трогать, оно скомпилируется без ошибок!
Что для .equ ИМЯ=АДРЕС, что для ИМЯ: .byte РАЗМЕР, и там и там компилятор генерирует пару ИМЯ-АДРЕС, только в первом случае адрес задает программист (а он может ошибаться), а во втором его вычисляет компилятор автоматически.

[Gennadiy]

Значит, есть желание контролировать память - .equ, нет желания париться с этим вопросом (пусть компилятор сам решает) - .byte. Так? Спасибо.
Тогда в чем весь сыр-бор, устроенный тут? Ведь обработка переменной, длиной отличной от 8 бит, все-равно ляжет на плечи программиста.

[Just_Fluffy]

Gennadiy, Перечислите случаи, когда вам нужно было "прибивать" переменную гвоздями к конкретному месту в ОЗУ?
Вот когда переменная должна лежать только в этом месте и ни в каком другом?
equ именно это и делает. Но тогда распределение переменных в ОЗУ становится вашей головной болью.
Переносимость кода резко падает. Поскольку в других проектах нужно заново пересчитывать расположение переменных в ОЗУ.
И зачем?
Есть правильный инструмент, поддерживаемый компиляторами и отладчиками. но нужно придумывать что то свое.
Директива equ говорит компилятору, где должна быть переменная.
А директива byte - сколько занимает ваша переменная.
И к той и к другой можно обращаться одинаково - по имени.
Но в случае изменений в проекте, когда надо буферу размерчик добавить, или ввести новую переменную - придется руками пересчитать все equ, которые лежат после новой переменной или обновленного буфера.
В случае byte - компилятор сам подвинет все прозрачно для программы.... И в 99.8% случаев это никак не повлияет на программу.
Остаются редкие случаи, когда на область ОЗУ проецируется какая то периферия или внешнее ОЗУ - там да, нужно явно указать, откуда оно начинается.
Или когда буфер должен начинаться с какого то кратного адреса, что б указатель легче обсчитывать ... Но это блин , настолько редкие случаи....
Откройте любой учебник по асму, прочтите, как резервировать ОЗУ - и радуйтесь жизни

[КРАМ]

Gennadiy писал(а):

Значит, есть желание контролировать память - .equ, нет желания париться с этим вопросом (пусть компилятор сам решает) - .byte. Так? .

Поток сознания.
Компилятор ничего не решает. После привязки через org адреса идут по списку строго последовательно.
Так что по сути программирования никакой разницы нет.
Если не считать того, о чем я сказал ранее.

[Gennadiy]

Согласен с Вами, по сути программирования никакой разницы нет. В итоге имеем имя к которому обращаемся в программе. Почему прибиваю? Да потому что в отладчике мне удобнее ориентироваться в данных, которые именно я разложил "по полочкам", а не компилятор.
По Вашим словам "Именно директива .byte позволяет получить ВИДИМОСТЬ переменных ПО ИМЕНИ. А адрес и так всегда указан рядом с именем." Вопрос. Директива .equ
не позволяет сделать то же самое, заменяя имя переменной ее адресом, указанным в листинге? Немного возни с порядком, зато полный контроль за процессом.

[Just_Fluffy]

Gennadiy, в нормальном отладчике как раз наоборот. Переменные через .byte видны как переменные и их не нужно искать в простыне содержимого памяти. Ну да дело ваше. Кому и *** невеста.

[ARV]

Купите дракона... Сыт голодного не разумеет

[Starichok51]

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