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

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

Пт сен 20, 2019 19:12:28

Вообще-то, это дело может оказаться полезным при организации сопрограмм. Применяется, например, в драйверах со сложными протоколами. Например, так (объясняю упрощенно): надо передать, допустим, что-то кому-то через нечто, вроде RS485. То есть получаем адрес абонента и блок данных, надо через UART достучаться до принимающего абонента и передать ему блок данных.

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

Вторая половина программы ожидания запустится по прерыванию от UART'а, она сохранит нужные регистры, поднимет в них данные, сохраненные первой половиной и перейдет командой ijmp по адресу, добытому первой половиной из стека. Таким образом, драйвер продолжится с команды, следующей за вызовом специальной программы ожидания. Далее, готовим следующий байт, или готовим прием байта ответа (подтверждения от адресованного абонента) и снова вызываем ожидание. После очередного прерывания снова получит управление команда, следующая за последним вызовом ожидания, и т.д.

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

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

Сб сен 21, 2019 06:15:21

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

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

Сб сен 21, 2019 09:44:13

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

Единственное допустимое применение подобного подхода - создание ядра ОСРВ.

никогда никому не посоветую так писать свои программы!

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

Сб сен 21, 2019 10:13:29

ARV, по сути, совершенно стандартные LIBC функции setjmp()/longjmp() этот механизм и обеспечивают. Или их тоже никогда нельзя использовать? А я то их неоднократно применял для организации кооперативной мультизадачности...

Добавлено after 5 minutes 42 seconds:
не нашел готового решения

setjmp()/longjmp()

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

Сб сен 21, 2019 11:09:29

...

Хотелось бы увидеть вашу реализацию.

Если вы хотите, чтобы вашим кодом мог пользоваться кто-то другой, или чтобы кто-то другой мог его модифицировать, если вы не хотите сломать голову при отладке своего кода и не желаете этого другим, никогда так не делайте!!! Единственное допустимое применение подобного подхода - создание ядра ОСРВ. никогда никому не посоветую так писать свои программы!

Здесь два конца одной палки. 1 - Прогнуться под "всех" и писать свои проекты с этой позиции. 2 - Если вы знаете, что делаете, и уверены, что именно такой ваш подход решает ВАШИ задачи, значит так и делаете. Отладка проекта - автоматом - вы точно знаете, что делаете, как работает ваша программа. Если нет нужного инструмента, значит создайте его. Я про тестовые программные закладки.

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

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

Сб сен 21, 2019 11:31:56

Если вы знаете, что делаете, и уверены, что именно такой ваш подход решает ВАШИ задачи, значит так и делаете.

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

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

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

Сб сен 21, 2019 11:43:52

...

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

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

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

Сб сен 21, 2019 12:27:52

ГЫММ...
Это ж вроде ветка про АССЕМБЛЕР....
В Си ассемблер всего лишь ВСПОМОГАТЕЛЬНОЕ звено.
Выше рамок компилятора выходить крайне опасно по многим вышеуказанным КОТАМИ причинам.
А вот "в чистом виде" пишем как пожелаем, не забывая про документирование.
:wink:

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

Сб сен 21, 2019 12:54:57

ГЫММ...
Это ж вроде ветка про АССЕМБЛЕР....

Совершенно верно. На ассемблере специалист сам решает, как реализовать проекты.

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

Сб сен 21, 2019 13:00:57

BOB51, если документирование так же подразумевает, например, отступление от принятой ранее конвенции по использованию регистров, и это отступление действительно обосновано, то почему бы и нет? Но мне сложно представить себе причины, по которым 16-битные переменные передаются не в регистрах-спарках, а 8-битные - наоборот )

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

Сб сен 21, 2019 13:01:29

BOB51 писал(а):А вот "в чистом виде" пишем как пожелаем, не забывая про документирование
никакое документирование не поможет разобраться в коде, который произвольно меняет точки исполнения! ассемблер позволяет сделать что угодно, не нарушая парадигму программирования низкого уровня, но МОЖНО не означает НУЖНО. редкие исключения, как я уже говорил, только подтверждают общее правило.
ПростоНуб писал(а):стандартные LIBC функции setjmp()/longjmp() этот механизм и обеспечивают
во-первых, тема про ассемблер, и говорить о LIBC тут неуместно.
во-вторых, если многие считают goto злом, то setjmp/longjmp - это просто адское зло, открывающее врата ада.
в-третьих, я еще раз повторяю: в некоторых узкоспециализированных случаях типа разработки ядра ОСРВ это допустимо, но только в виде исключения и с условием, что всякого, кто посмеет к этому потом прикоснуться, либо сожгут на костре, как еретика, либо вознесут до уровня ангела :)

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

Сб сен 21, 2019 13:20:33

ARV, Вы действительно считаете, что на ассемблере недопустимо использовать конструкции, которые в ассемблером коде формируются компилятором ЯВУ? И Вы никогда из ассемблера не вызываете функции, написанные на ЯВУ? Объясните причины, пожалуйста. Я так часто пользуюсь и первым, и вторым. Причем пользовался ещё на ассемблере IBM/370, и с тех пор не прекращаю )

Добавлено after 8 minutes 50 seconds:
BOB51, возможно, у нас разные подходы, но, в подавляющем большинстве случаев, у меня в проектах С и ассемблер взаимодействуют в тесной связке. То есть, как в С используются ассемблерных вставки и вызываются функции на ассемблере, так и из ассемблера вызываются функции на С, включая библиотечные. Это очень экономит время, почти не влияя на производительность программы и размер кода

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

Сб сен 21, 2019 13:28:39

ПростоНуб писал(а):Вы действительно считаете, что на ассемблере недопустимо использовать конструкции, которые в ассемблером коде формируются компилятором ЯВУ?
при чем тут конструкции? вы не видите разницу между командой ret или jmp и алгоритмом, в котором эти команды перемещают программный счетчик в неожиданное место, не отслеживаемое "разумом"? вы никогда не сможете предсказать, в каком состоянии находится программа, написанная при таком подходе, просто взглянув на её текущий "снимок" РОН и PC - вам придется долго и скрупулезно исследовать содержимое стека и листинга, чтобы понять, где программа окажется спустя 100 следующих тактов...

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

Сб сен 21, 2019 13:48:15

вы не видите разницу между командой ret или jmp и алгоритмом, в котором эти команды перемещают программный счетчик в неожиданное место, не отслеживаемое "разумом"? вы никогда не сможете предсказать, в каком состоянии находится программа, написанная при таком подходе, просто взглянув на её текущий "снимок" РОН и PC - .

Совершенно верно. Диспетчеры и RTOS в этом плане существенно проигрывают автоматному программированию.

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

Сб сен 21, 2019 14:06:27

ARV, поэтому, когда таким образом я реализую кооперативную мультизадачность, я отдаю себе отчёт, что не знаю через какой промежуток времени у какой задачи будет управление. Такова цена почти любой мультизадачности и ничего Вы с этим не сделаете

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

Сб сен 21, 2019 17:47:04

Я и сам не хочу с этим ничего делать, да и другим не советую. "Мультизадачность" по обычным прерываниям в 100500 раз проще и понятнее, менее проблема в отладке и без побочных эффектов.

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

Сб сен 21, 2019 18:07:46

"Чистый ассемблер" предусматривает ПОЛНОЕ ПЛАНИРОВАНИЕ ресурсов МК автором проекта.
Под Си есть естественные ограничения для ассемблера - планировка ресурсов, включая стек, модель регистров и проччее.
С одной стороны как проектировщику на ассемблере это "серпом по....", с другой - преимущества ЯВУ.
Ассемблерные вставки под Си допустимы и в спецслучаях весьма удобны... НО оные делаются уже ВНУТРИ правил, определяемых компилятором Си а это таки довольно жесткие рамочные правила. Да и приемы, являющиеся основой проектов под "чистым асмом" при работе с ассемблерными вставками часто просто НЕДОПУСТИМЫ.
8)

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

Сб сен 21, 2019 18:13:35

ARV, проще, но менее универсальна. Она применима только в случае, если во всем коде есть только один длительный расчет, способный занять ресурсы CPU на длительное время. Если же необходимость в таких расчетах возникает асинхронно, то приходится реализовывать мультизадачность. А кооперативная мультизадачность, при всех ее недостатках, экономит и память, и ресурсы CPU, в сравнении с мультизадачностью по таймеру.

Добавлено after 5 minutes 1 second:
BOB51, когда требуется даже 32-битная арифметика, не говоря уже об арифметике с фиксированной точкой с ее алгебраическими функциями, кодировать это на ассемблере, вместо использования ЯВУ - совершенно неоправданная трата времени. Оптимальнее того же GCC все равно вряд ли напишете, а времени потратите в разы больше.

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

Сб сен 21, 2019 19:35:46

Demiurg писал(а):Хотелось бы увидеть вашу реализацию.
Я, в конце 80-х - начале 90-х, писал по такому принципу драйвера для наших клонов PDP-11 (Электроника-60, ДВК), для ОС RT-11. В той системе команд это получалось изящно и элегантно. Но, в принципе, оно работоспособно на любом процессоре, где вызов CALL помещает адрес возврата в стек и его оттуда можно достать не только RETURN'ом, но и обычным добыванием числа из стека, вроде команды POP. В частности, оно неплохо получалось и под MS-DOS, хотя там я так толком и не освоил АСМ - не смог преодолеть рвотный барьер при переходе от изящной архтиектуры PDP-11 к убожеству х86. :) Пришлось переквалифицироваться в СИонисты... :)

Здесь, в смысле с AVR, я тоже попробовал программировать, используя этот прием, и тоже получилось неплохо, но боевой задачи у меня не было, только учебно-тренировочная. Убедился, что получается хорошо, и забросил. А затем и вообще утратил интерес к AVR и переключился на STM32, а там на асме толком не попрограммируешь. Зато Си вспомнил... :)

В общем, если надо, могу прислать что-нибудь из драйверов PDP-11, это законченные программы, в отличие от пробных вещей на AVR.

ПростоНуб писал(а):когда требуется даже 32-битная арифметика, не говоря уже об арифметике с фиксированной точкой с ее алгебраическими функциями, кодировать это на ассемблере, вместо использования ЯВУ
Не помню, зачем мне понадобилось включить в проект на АСМе вычисление по какой-то довольно сложной формуле. Написал раз, что-то не то. Второй - тоже. Плюнул, написал этот кусок на Фортране, оттранслировал его компилятором уровня H с предельной оптимизацией и с выдачей ассемблерного текста, после чего вырезал нужную часть и включил ее в свою программу на АСМе. Дело было году в 83-85, ЕС ЭВМ aka Система 360.

Это с одной стороны. С другой, существует куча действий, которые невозможно выразить на ЯВУ, но элементарно делаемых на асме. Тот же самый мой пример.

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

Сб сен 21, 2019 20:00:58

afz, во-первых, уже в начале 80-х, найти IBM/360 было нереально. MVT почило в бозе раньше и везде уже были, как минимум, IBM/370 с поддержкой виртуальной памяти и, как минимум, под SVS, если не TKS или даже VM/SP или СВМ. А ассемблер под SVS, особенно при общении с каналами ввода-вывода с их абсолютной адресацией памяти - совершенно иная задача, чем под MVT/MFT/DOS, где виртуальной памяти не было в помине.
Во-вторых, мне совершенно непонятно, нахрена было усложнять сборку проекта преобразованием объектного кода выдаваемого компилятором в ассемблерный исходный код на каком-то убогом REXX, если этот код можно было и так без проблем слинковать с ассемблерным объектным файлом. Или вы после каждой правки в Fortran или PL/I вручную таскали этот код, без автоматизации сборки?
Ответить