Так и есть. Набрал текст и получил hex-файл. А в чём проблема?

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

В ассемблере в качестве надстройки есть макрос с параметрами. А подпрограмма - это собственно код с вызываемой его инструкцией вида call.
Суть ассемблера в отсутствии генератора кода. Ассемблер лишь производит подстановки. Кстати, на выходе ассемблера в общем случае не хекс, а объектный файл. Для получения хекса требуется еще линкер.
Учите матчасть.

Вы несете отборный бред. Причем тут ТС? И где у ТС "500 строк кода" вместо 6 на асме? У ТС исходник чисто начинающего любителя. Какой смысл его поделие обобщать?

Вы даже не понимаете что такое алгоритм задачи...
Я вам привел пример вычисления CRC16. В нем есть алгоритм его вычисления. Он легко читается.
Есть, например, алгоритм квадратурного энкодера. Он тоже легко читается. В его основе на Си лежит переключатель switch-case.
Есть алгоритм машины состояния. Он тоже должен легко читаться, а не представлять из себя спагетти-код.
Есть алгоритмы шифрования. Они тоже должны быть прозрачными и легко администрируемыми.
"Последовательное исполнение кода", которое называется суперлупом, не должно препятствовать корректной обработке критических участков кода. То, что у вас задачи суперпримитивны, не дает вам право учить и даже давать советы по программированию.
Прежде чем давать советы, потрудись изучить предмет, в котором вы желаете быть советчиком. А то ваши тексты лишь вызывают смех.
У вас нет никаких "методов".У вас есть деревянный велосипед с квадратными колесами

Это "пожалуй" звучит как "точно". Настолько оно глупое.

Пустое - потому что бессмысленное. Но это не означает, что работать не будет. Точно так же, как не мешает работать NOP.

Вешать кнопки на один порт КАК ПРАВИЛО не позволяет используемая периферия и особенности конкретно AVR, где она не мапируется на другие порты.
Пару-тройку кнопок повесить можно, да и то не всегда... Рекламировать глубоко частный код - такое себе...

Это очередная чушь. Использовать Keys в ОЗУ (УВВ или ЕЕПРОМ) в вычислениях напрямую невозможно в RISC машинах. И передать эти особенности в виде параметров в ассемблере так же невозможно. Это можно только оттранслировать с помощью ЯВУ, а не ассемблера.
ОЗУ, УВВ и ЕЕПРОМ требуют инструкций загрузки-выгрузки в/из РОН.

Передачи пакета ЧЕРЕЗ ЧТО? И посредством КАКОГО ПО?
Практически все каналы передачи используют CRC.
Но дело не в этом, дело в том, что у вас тупо нет опыта, но есть амбиции.
Может стоит эти амбиции кратно редуцировать?

и этот его любимый велосипед называется Алгоритм Билдер.

КРАМ.
Я в начале назвал ассемблер условным, он богаче обычного ассемблера.
Вы плохо знаете возможности программы, поэтому ваша критика несколько мимо.

Программа сразу выдаёт готовый hex-файл, зачем здесь объектный файл и линкёр.
Опрос кнопок – это команда с параметрами. Преобразуется в вызов подпрограммы без параметров.

У вас алгоритм небольшой задачи вычисления CRC16. У меня нет такой программы, сравнить не с чем. У вас алгоритм небольшой задачи, я пишу о написании программы в целом.
Разбиваю программу на простые или, как вы пишите, суперпримитивные задачи. Написать и отладить просто. Хороший контроль за ходом программы, благодаря чему легко справляется со скоростными задачами.
Насколько представляю, в СИ с этим плохо, настолько плохо, что приходится использовать другой язык, даже администрируемый алгоритм не помогает.

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

В команде опроса кнопок Keys – это однобайтная переменная, которую пользователь может объявить в разной памяти.
Дело не в RISC машинах, а в том, что программа с элементами ЯВУ, есть и переменные, и операции с ними.

В программе есть встроенные команды посылки данных с параметрами.
Есть необязательный параметр Check_Sum. Если его написать, в конце пакета будет послан один байт контрольной суммы.
Один байт на основе суммы байтов пакета используется в hex-файлах программаторов МК. Наверно, считается, что передача идёт через короткий кабель, вероятность сбоя небольшая.
В принципе, наверно, в команде может появиться параметр, названный, например, CRC16, по которому будет посылаться эта пара байтов.
Будет одна строчка команды, что, наверно, меньше строчек СИ, о чём я писал.
В новых МК вроде как делают аппаратный расчёт CRC. В новых AVR для проверки памяти есть CRC16 и CRC32. Может ли их пользователь использовать - пока не разбирался.

Мне как-то не до амбиций. Предлагаемых вариантов много, времени мало.

Вы ошибаетесь, у меня велосипед называется Mongoose 250. Не сказал бы, что любимый, шины тонкие, но по асфальту хорошо идёт.

Можно подумать над таким вариантом.
Пока по основной программе есть вопросы.

В старых МК AVR нет хорошей отладки, вроде как нужен программатор-отладчик. В программе для этого должны быть встроены соответствующие команды.
Насколько понял, для новых МК AVR мало у кого есть программаторы, вроде как программатор тоже нужен.
У новых МК есть много преимуществ, использовать старые Tiny не имеет никакого смысла. Кому нужна программа, если программатора нет.

Даже интересно стало: одной командой?! Независимо от длины участка памяти и её месторасположения?
Интересно было бы узнать фамилию этого мудрого МК.

Ниже: моя многолетняя мечта "сбылась" (в шутку с друзьями) : отладчик в ATtiny13A (+переводчик),
MPLAB X v6, MPLAB Snap In-Circuit Debugger PG164100 (~10 €).

Просто измените подход: используйте современные инструменты, выводы. И понимания. Все строят и производят.

слазьте вы уже с этих богом забытых AVR и переходите на ARM, откройте для себя RTOS, и вообще забудете о таких проблемах ...

на STM-ке (любой, даже самой дешманской) я бы завел 2 потока, один опрашивает кнопки, во втором логика в зависимости от состояния кнопок, там хоть 100 кнопок заведи и пиши любую логику, если хочется совсем по фэншую то RTOS+прерыывания

+ остальные плюшки STM-ок коих не мало

по цене авр и стм сопоставимы, так что вообще не понимаю людей которые создают себе проблемы на ровном месте

Никаких убогих ртосей в такой простой задаче не нужно! Просто несколько конечных автоматов…
Вот чесслово: уже лет 15 или больше пишу под МК. И ни разу не натыкался на задачу, которую невозможно было бы решить классическим способом, а понадобилось бы городить ртос!
А вот с советом перейти на STM32 согласен. Но если человеку на аврке все так сложно, то, боюсь, на стмке он вообще ничего сделать не сможет! Или погрязнет в помойке калокуба, испугавшись "толстых мануалов".

Добавлено after 7 minutes 36 seconds:

Самый обычный STM32. Понятно, что регистр данных 32-битный, и длинные посылки нужно "по кускам" вкладывать. Зато более-менее аппаратно вычисляет + можно задавать свой полином.
Правда, как я понял, DMA в этой операции использовать нельзя, т.е. придется в КА "молотить"...

Почему нельзя? 32-бит CRC считается за 4 такта, 8-бит вообще за такт, т.е. главное чтобы DMA не слал данные быстрее.

Объектный файл нужен для написания перемещаемого кода. Линкер компонует один или несколько перемещаемых исходников, а так же определяет абсолютные адреса переменных в памяти разных типов.
писать сразу абсолютный код - это мало того, что дурной тон, так еще и множитель ошибок. Самая распространенная ошибка - наползание адресов друг на друга и выход за пределы памяти. В объемном коде найти такую проблему без контроля линкером - это беда.
ЗЫ. Линкер пишется через "е" с ударением на первом слоге. Это не ликёр, а линкер.

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

Вы вообще не представляете себе что такое не только язык Си, но и состав компилятора Си.
Ассемблер является неотъемлемой частью компилятора Си. Инструменты языка позволяют писать вставки на ассемблере и это нормально. Но нужно это крайне редко и в случаях, которые вы даже себе представить не можете. Поэтому и написать что либо на эту тему не сможете. Контроль кода определяется не только возможностью пошагового исполнения - трассировки, возможностью установки точек останова, включая условные, и контроля значений переменных, но и возможностями контроля компилятора за самим кодом - обнаружение ошибок (не только и не столько синтаксических), а так же генерация варнингов - предупреждений о возможных ошибках.
Причем все это работает не само по себе, а в составе среды разработки (IDE).
Скоростные участки кода, называемые критическими, обеспечиваются В БОЛЬШИНСТВЕ СЛУЧАЕВ не явно. То есть самый короткий код далеко не всегда является самым быстрым. Поэтому в компиляторах есть несколько уровней оптимизации и самый быстрый код не является самым компактным.
Кроме этого, даже не самые сложные задачи требуют сущностей ЯВУ, что бы не утонуть в алгоритме, абстрагируя для этого код, а не выдумывая ненужного пошагового контроля.
Так же при написании кода очень часто нужно вносить изменения в алгоритм и структуру переменных. Это должно выполняться максимально просто и неинвазивно, то есть не обрушая не только модифицируемый фрагмент, но и его взаимодействие с остальным кодом.

Ну как же без них... Даже кухонный таймер без РТОС - убогое поделие
И таки да: РТОСи кэк бэ все платные? (Взлом не комментируем). Сам не применял, как-то обошлось, только краем уха.

.С STM, к сожалению, не успел подружиться.

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

Мне кажется, не умаляя достоинств ЯВУ в плане экономии времени при написания объёмного кода, ясности пониманияне алгоритма при последующем чтении - не стоило бы абсолютизировать его безошибочность. Я как-то цитировал одного моего коллегу: "Прога написана на Си, поэтому ОШИБОК В НЕЙ БЫТЬ НЕ МОЖЕТ!". Ему простительно, он руководил группой программистов (-ок), сам не написав ни строчки кода. Но случаются иногда трудноуловимые ошибки, которые не поддаются логическому вычислению, и приходится прибегать к "ненужному пошаговому контролю".

Спойлер

Один из таких случаев из моей практики: в операторе ввода вместо формата %lf написал просто %f . Компилятор проглотил, даже варнинга не выдал, но при запуске... портилась переменная, лежащая рядом. Никакой логикой такое не поймёшь. И только пошагово - ущучил.
Не знаю и теперь, что было причиной - что-то в настройках компилятора? - но повторить эту хрень позже так и не сумел.

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

Проблема в том, что у блока CRC нет выхода на тактирование DMA, поэтому придется еще и какой-нибудь таймер задействовать, если возникнет желание длинные посылки "обсчитывать".
// Сам я никогда не работал с CRC напрямую, кроме убогого модбаса. Но я его считаю пережитком прошлого. А в CAN все "разруливается" аппаратно.

Зачем таймер? У вас нет ни одной серии STM32 где бы DMA справлялся с единичной передачей быстрее чем за 4 такта. MemToMem, на максимальной скорости.

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

Я бы на этот счет посомневался. Таки есть всякие разные… И уж всяко передача 32 бит по DMA идет быстрей четырех тактов! (разве что "нулевки" могут подтормаживать).

Добавлено after 1 minute 4 seconds:

У нас-то как раз разговоры в тему… А вот у кой-кого ушли в офтоп.

Откуда такая уверенность?
Мой опыт говорит мне, что скорость транзакций ДМА ровно в 4 раза ниже системной частоты МК.
Без учета коллизий шины.