Форум РадиоКот

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

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

[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"]Вообще-то там не макрос, а Sub с параметрами.[/uquote]
В ассемблере в качестве надстройки есть макрос с параметрами. А подпрограмма - это собственно код с вызываемой его инструкцией вида call.
Суть ассемблера в отсутствии генератора кода. Ассемблер лишь производит подстановки. Кстати, на выходе ассемблера в общем случае не хекс, а объектный файл. Для получения хекса требуется еще линкер.
Учите матчасть.
[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"]Дело не только в сокращении листинга. Написать и прочитать 6 строк гораздо проще, чем, например, 500 строк у ТС.[/uquote]
Вы несете отборный бред. Причем тут ТС? И где у ТС "500 строк кода" вместо 6 на асме? У ТС исходник чисто начинающего любителя. Какой смысл его поделие обобщать?
[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"][uquote="КРАМ",url="/forum/viewtopic.php?p=4777973#p4777973"]В том и дело, что простые. Текст понятен до уровня его исполнения. Алгоритм в нем вообще не читается.
А под читабельностью понимается не код, а алгоритм.[/uquote]
Скорее всего, у нас разные алгоритмы, точнее, концепция программы.
Пишу просто, МК большей частью последовательно выполняет текущие задачи.[/uquote]
Вы даже не понимаете что такое алгоритм задачи...
Я вам привел пример вычисления CRC16. В нем есть алгоритм его вычисления. Он легко читается.
Есть, например, алгоритм квадратурного энкодера. Он тоже легко читается. В его основе на Си лежит переключатель switch-case.
Есть алгоритм машины состояния. Он тоже должен легко читаться, а не представлять из себя спагетти-код.
Есть алгоритмы шифрования. Они тоже должны быть прозрачными и легко администрируемыми.
"Последовательное исполнение кода", которое называется суперлупом, не должно препятствовать корректной обработке критических участков кода. То, что у вас задачи суперпримитивны, не дает вам право учить и даже давать советы по программированию.
Прежде чем давать советы, потрудись изучить предмет, в котором вы желаете быть советчиком. А то ваши тексты лишь вызывают смех.
У вас нет никаких "методов".У вас есть деревянный велосипед с квадратными колесами
[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"][uquote="КРАМ",url="/forum/viewtopic.php?p=4777973#p4777973"] Феерично. Си не знает, но точно знает, что читаемость на ассемблере будет лучше...[/uquote]
Вообще-то у меня было слово «пожалуй», а не «точно».[/uquote]
Это "пожалуй" звучит как "точно". Настолько оно глупое.
[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"][uquote="КРАМ",url="/forum/viewtopic.php?p=4777973#p4777973"]"Читать три раза подряд с заданным интервалом" - совершенно пустое мероприятие. Мало того, оно еще и блокирующее или требует специально выделенного таймера.[/uquote]
Почему пустое мероприятие? Много лет пользуюсь – никаких проблем. Если по условии задачи надо быстро выскочить, есть такая команда с флагом, по которому программа выскочит.[/uquote]
Пустое - потому что бессмысленное. Но это не означает, что работать не будет. Точно так же, как не мешает работать NOP.
[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"][uquote="КРАМ",url="/forum/viewtopic.php?p=4777973#p4777973"]Во вторых, кнопки могут висеть на разных портах[/uquote]
Не вижу смысла вешать кнопки на разные порты.
Команда, конечно, не универсальная, но для большинства задач подойдёт.[/uquote]
Вешать кнопки на один порт КАК ПРАВИЛО не позволяет используемая периферия и особенности конкретно AVR, где она не мапируется на другие порты.
Пару-тройку кнопок повесить можно, да и то не всегда... Рекламировать глубоко частный код - такое себе...
[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"][uquote="КРАМ",url="/forum/viewtopic.php?p=4777973#p4777973"]В третьих, AVR является RISC машиной, то есть вся математика возможна только с РОНами. А это значит, что регистр Keys - это РОН. Со всеми вытекающими последствиями для остального кода и его читабельности.[/uquote]
Keys может быть РОН, SRAM, РВВ и даже EEPROM. Выбор - на усмотрение разработчика.[/uquote]
Это очередная чушь. Использовать Keys в ОЗУ (УВВ или ЕЕПРОМ) в вычислениях напрямую невозможно в RISC машинах. И передать эти особенности в виде параметров в ассемблере так же невозможно. Это можно только оттранслировать с помощью ЯВУ, а не ассемблера.
ОЗУ, УВВ и ЕЕПРОМ требуют инструкций загрузки-выгрузки в/из РОН.
[uquote="AQ29",url="/forum/viewtopic.php?p=4778695#p4778695"]Функции подсчета CRC16 у меня нет, сравнить не с чем.
А при передаче пакета контрольная сумма считается. Сделано просто на основе простой суммы байтов. Этот метод вроде как стандартный для hex-файлов программатора.[/uquote]
Передачи пакета ЧЕРЕЗ ЧТО? И посредством КАКОГО ПО?
Практически все каналы передачи используют CRC.
Но дело не в этом, дело в том, что у вас тупо нет опыта, но есть амбиции.
Может стоит эти амбиции кратно редуцировать?

КРАМ писал(а):У вас есть деревянный велосипед с квадратными колесами

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

КРАМ.
Я в начале назвал ассемблер условным, он богаче обычного ассемблера.
Вы плохо знаете возможности программы, поэтому ваша критика несколько мимо.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4778964#p4778964"]В ассемблере в качестве надстройки есть макрос с параметрами. А подпрограмма - это собственно код с вызываемой его инструкцией вида call.
Суть ассемблера в отсутствии генератора кода. Ассемблер лишь производит подстановки. Кстати, на выходе ассемблера в общем случае не хекс, а объектный файл. Для получения хекса требуется еще линкер.
Учите матчасть.[/uquote]
Программа сразу выдаёт готовый hex-файл, зачем здесь объектный файл и линкёр.
Опрос кнопок – это команда с параметрами. Преобразуется в вызов подпрограммы без параметров.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4778964#p4778964"]Я вам привел пример вычисления CRC16. В нем есть алгоритм его вычисления. Он легко читается.
Есть, например, алгоритм квадратурного энкодера. Он тоже легко читается. В его основе на Си лежит переключатель switch-case.
Есть алгоритм машины состояния. Он тоже должен легко читаться, а не представлять из себя спагетти-код.
Есть алгоритмы шифрования. Они тоже должны быть прозрачными и легко администрируемыми.
"Последовательное исполнение кода", которое называется суперлупом, не должно препятствовать корректной обработке критических участков кода. То, что у вас задачи суперпримитивны, не дает вам право учить и даже давать советы по программированию.[/uquote]
У вас алгоритм небольшой задачи вычисления CRC16. У меня нет такой программы, сравнить не с чем. У вас алгоритм небольшой задачи, я пишу о написании программы в целом.
Разбиваю программу на простые или, как вы пишите, суперпримитивные задачи. Написать и отладить просто. Хороший контроль за ходом программы, благодаря чему легко справляется со скоростными задачами.
Насколько представляю, в СИ с этим плохо, настолько плохо, что приходится использовать другой язык, даже администрируемый алгоритм не помогает.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4778964#p4778964"]Вешать кнопки на один порт КАК ПРАВИЛО не позволяет используемая периферия и особенности конкретно AVR, где она не мапируется на другие порты.
Пару-тройку кнопок повесить можно, да и то не всегда... Рекламировать глубоко частный код - такое себе...[/uquote]
Если кнопки вешают на разные порты, то почти нет свободных выводов. На мой взгляд, во многих случаях это не очень.
Предпочитаю ставить МК с запасом свободных выводов, тем более сейчас это легко решается. Обычно повесить две-три кнопки не проблема.
Вообще-то, написав подряд две команды с разными портами, наверно, можно прочитать и пару портов, но это будет совсем не оптимально.
Можно расширить возможности команды для чтения нескольких портов, если есть запрос, можно сделать.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4778964#p4778964"]Это очередная чушь. Использовать Keys в ОЗУ (УВВ или ЕЕПРОМ) в вычислениях напрямую невозможно в RISC машинах. И передать эти особенности в виде параметров в ассемблере так же невозможно. Это можно только оттранслировать с помощью ЯВУ, а не ассемблера.
ОЗУ, УВВ и ЕЕПРОМ требуют инструкций загрузки-выгрузки в/из РОН.[/uquote]
В команде опроса кнопок Keys – это однобайтная переменная, которую пользователь может объявить в разной памяти.
Дело не в RISC машинах, а в том, что программа с элементами ЯВУ, есть и переменные, и операции с ними.
[uquote="КРАМ",url="/forum/viewtopic.php?p=4778964#p4778964"]Передачи пакета ЧЕРЕЗ ЧТО? И посредством КАКОГО ПО?
Практически все каналы передачи используют CRC.
Но дело не в этом, дело в том, что у вас тупо нет опыта, но есть амбиции.
Может стоит эти амбиции кратно редуцировать?[/uquote]
В программе есть встроенные команды посылки данных с параметрами.
Есть необязательный параметр Check_Sum. Если его написать, в конце пакета будет послан один байт контрольной суммы.
Один байт на основе суммы байтов пакета используется в hex-файлах программаторов МК. Наверно, считается, что передача идёт через короткий кабель, вероятность сбоя небольшая.
В принципе, наверно, в команде может появиться параметр, названный, например, CRC16, по которому будет посылаться эта пара байтов.
Будет одна строчка команды, что, наверно, меньше строчек СИ, о чём я писал.
В новых МК вроде как делают аппаратный расчёт CRC. В новых AVR для проверки памяти есть CRC16 и CRC32. Может ли их пользователь использовать - пока не разбирался.

Мне как-то не до амбиций. Предлагаемых вариантов много, времени мало.
[uquote="Starichok51",url="/forum/viewtopic.php?p=4778976#p4778976"]и этот его любимый велосипед называется Алгоритм Билдер.[/uquote]
Вы ошибаетесь, у меня велосипед называется Mongoose 250. Не сказал бы, что любимый, шины тонкие, но по асфальту хорошо идёт.
[uquote="Adrift",url="/forum/viewtopic.php?p=4778892#p4778892"]AQ29, проблема в том, что недоработанный отладчик или симулятор не должны мешать выложить ассемблер в свободный доступ, разве что он сам еще недоработанный.[/uquote]
Можно подумать над таким вариантом.
Пока по основной программе есть вопросы.

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

[uquote="AQ29",url="/forum/viewtopic.php?p=4779866#p4779866"]В новых МК вроде как делают аппаратный расчёт CRC.[/uquote]
Даже интересно стало: одной командой?! Независимо от длины участка памяти и её месторасположения?
Интересно было бы узнать фамилию этого мудрого МК.

[uquote="AQ29",url="/forum/viewtopic.php?p=4779866#p4779866"]... В старых МК AVR нет хорошей отладки, вроде как нужен программатор-отладчик..[/uquote]
Ниже: моя многолетняя мечта "сбылась" (в шутку с друзьями) : отладчик в 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:
[uquote="Jack_A",url="/forum/viewtopic.php?p=4779884#p4779884"]Даже интересно стало: одной командой?! Независимо от длины участка памяти и её месторасположения?
Интересно было бы узнать фамилию этого мудрого МК.[/uquote]
Самый обычный STM32. Понятно, что регистр данных 32-битный, и длинные посылки нужно "по кускам" вкладывать. Зато более-менее аппаратно вычисляет + можно задавать свой полином.
Правда, как я понял, DMA в этой операции использовать нельзя, т.е. придется в КА "молотить"...

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4779972#p4779972"]Правда, как я понял, DMA в этой операции использовать нельзя, т.е. придется в КА "молотить"...[/uquote]
Почему нельзя? 32-бит CRC считается за 4 такта, 8-бит вообще за такт, т.е. главное чтобы DMA не слал данные быстрее.

[uquote="AQ29",url="/forum/viewtopic.php?p=4779866#p4779866"]Программа сразу выдаёт готовый hex-файл, зачем здесь объектный файл и линкёр.[/uquote]
Объектный файл нужен для написания перемещаемого кода. Линкер компонует один или несколько перемещаемых исходников, а так же определяет абсолютные адреса переменных в памяти разных типов.
писать сразу абсолютный код - это мало того, что дурной тон, так еще и множитель ошибок. Самая распространенная ошибка - наползание адресов друг на друга и выход за пределы памяти. В объемном коде найти такую проблему без контроля линкером - это беда.
ЗЫ. Линкер пишется через "е" с ударением на первом слоге. Это не ликёр, а линкер.
[uquote="AQ29",url="/forum/viewtopic.php?p=4779866#p4779866"]Опрос кнопок – это команда с параметрами. Преобразуется в вызов подпрограммы без параметров.[/uquote]
Очередной бред сивой кобылы.
Полное непонимание основных сущностей программирования.
Команда - это универсальная сущность - простейшая операция, а опрос кнопок - это частная задача.
Опрос кнопок можно выполнить в виде библиотечной функции. Причем она должна быть универсальной, то есть имела входные аргументы и выходное значение.
Это не привязано к языку программирования. Это ОСНОВЫ программирования.
[uquote="AQ29",url="/forum/viewtopic.php?p=4779866#p4779866"]У вас алгоритм небольшой задачи вычисления CRC16. У меня нет такой программы, сравнить не с чем. У вас алгоритм небольшой задачи, я пишу о написании программы в целом.
Разбиваю программу на простые или, как вы пишите, суперпримитивные задачи. Написать и отладить просто. Хороший контроль за ходом программы, благодаря чему легко справляется со скоростными задачами.
Насколько представляю, в СИ с этим плохо, настолько плохо, что приходится использовать другой язык, даже администрируемый алгоритм не помогает.[/uquote]
Вы вообще не представляете себе что такое не только язык Си, но и состав компилятора Си.
Ассемблер является неотъемлемой частью компилятора Си. Инструменты языка позволяют писать вставки на ассемблере и это нормально. Но нужно это крайне редко и в случаях, которые вы даже себе представить не можете. Поэтому и написать что либо на эту тему не сможете. Контроль кода определяется не только возможностью пошагового исполнения - трассировки, возможностью установки точек останова, включая условные, и контроля значений переменных, но и возможностями контроля компилятора за самим кодом - обнаружение ошибок (не только и не столько синтаксических), а так же генерация варнингов - предупреждений о возможных ошибках.
Причем все это работает не само по себе, а в составе среды разработки (IDE).
Скоростные участки кода, называемые критическими, обеспечиваются В БОЛЬШИНСТВЕ СЛУЧАЕВ не явно. То есть самый короткий код далеко не всегда является самым быстрым. Поэтому в компиляторах есть несколько уровней оптимизации и самый быстрый код не является самым компактным.
Кроме этого, даже не самые сложные задачи требуют сущностей ЯВУ, что бы не утонуть в алгоритме, абстрагируя для этого код, а не выдумывая ненужного пошагового контроля.
Так же при написании кода очень часто нужно вносить изменения в алгоритм и структуру переменных. Это должно выполняться максимально просто и неинвазивно, то есть не обрушая не только модифицируемый фрагмент, но и его взаимодействие с остальным кодом.

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4779972#p4779972"]Никаких убогих ртосей в такой простой задаче не нужно![/uquote]
Ну как же без них... Даже кухонный таймер без РТОС - убогое поделие
И таки да: РТОСи кэк бэ все платные? (Взлом не комментируем). Сам не применял, как-то обошлось, только краем уха.

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

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

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

[uquote="КРАМ",url="/forum/viewtopic.php?p=4779982#p4779982"]Кроме этого, даже не самые сложные задачи требуют сущностей ЯВУ, что бы не утонуть в алгоритме, абстрагируя для этого код, а не выдумывая ненужного пошагового контроля.[/uquote]
Мне кажется, не умаляя достоинств ЯВУ в плане экономии времени при написания объёмного кода, ясности пониманияне алгоритма при последующем чтении - не стоило бы абсолютизировать его безошибочность. Я как-то цитировал одного моего коллегу: "Прога написана на Си, поэтому ОШИБОК В НЕЙ БЫТЬ НЕ МОЖЕТ!". Ему простительно, он руководил группой программистов (-ок), сам не написав ни строчки кода. Но случаются иногда трудноуловимые ошибки, которые не поддаются логическому вычислению, и приходится прибегать к "ненужному пошаговому контролю".

Спойлер

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

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

[uquote="Adrift",url="/forum/viewtopic.php?p=4779979#p4779979"]главное чтобы DMA не слал данные быстрее.[/uquote]
Проблема в том, что у блока CRC нет выхода на тактирование DMA, поэтому придется еще и какой-нибудь таймер задействовать, если возникнет желание длинные посылки "обсчитывать".
// Сам я никогда не работал с CRC напрямую, кроме убогого модбаса. Но я его считаю пережитком прошлого. А в CAN все "разруливается" аппаратно.

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4780056#p4780056"]Проблема в том, что у блока CRC нет выхода на тактирование DMA, поэтому придется еще и какой-нибудь таймер задействовать, если возникнет желание длинные посылки "обсчитывать".[/uquote]
Зачем таймер? У вас нет ни одной серии STM32 где бы DMA справлялся с единичной передачей быстрее чем за 4 такта. MemToMem, на максимальной скорости.

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

[uquote="Adrift",url="/forum/viewtopic.php?p=4780070#p4780070"]У вас нет ни одной серии STM32 где бы DMA справлялся с единичной передачей быстрее чем за 4 такта. MemToMem, на максимальной скорости.[/uquote]
Я бы на этот счет посомневался. Таки есть всякие разные… И уж всяко передача 32 бит по DMA идет быстрей четырех тактов! (разве что "нулевки" могут подтормаживать).

Добавлено after 1 minute 4 seconds:
[uquote="Starichok51",url="/forum/viewtopic.php?p=4780075#p4780075"]прекращайте посторонние разговоры.[/uquote]
У нас-то как раз разговоры в тему… А вот у кой-кого ушли в офтоп.

[uquote="linux_rulezz",url="/forum/viewtopic.php?p=4780165#p4780165"]И уж всяко передача 32 бит по DMA идет быстрей четырех тактов! (разве что "нулевки" могут подтормаживать).[/uquote]
Откуда такая уверенность?
Мой опыт говорит мне, что скорость транзакций ДМА ровно в 4 раза ниже системной частоты МК.
Без учета коллизий шины.