Ассемблер для STM32. Сложно ли, стоит ли пытаться?

[VladislavS]

Вы придумываете проблемы на ровном месте. Пишите грамотный код и результат будет предсказуемым без чтения листингов. Хотя, их чтение таки полезно хотя бы иногда, для общего понимания. Применение асма и ассемблерных вставок заставляет обкладывать код директивами условной компиляции, определяющими тип компилятора. В случае с __set_MSP() и другими интринсиками это сделали разработчики CMSIS, что позволяет мне их свободно использовать. Не потому что это сделал кто-то другой, а потому что это сделано правильно и позволяет их использовать независимо от типа компилятора.

Есть места, где без асм тяжело и даже невозможно. Но на кортексах это скорее исключение. И ваш пример с переходом на прошивку к таковым не относится. Там просто нереально получить нерабочий код. Чуть менее оптимальный возможно, но всё равно рабочий. Конкретно это место не требует марания кода асмом.

[iddqd]

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

Если я сказал "volatime asm" - компилятор уже не имеет права умничать, это должно быть именно так как указано (в этом фрагменте). Если это не так - это уже баг компилятора. И вот тут я уже в своем праве закатать разработчикам компилятора баг, и отругаться в коменте что вон те костыли - из-за бага XXYYZZ компилера версии такой-то, а не потому что програмер скурил что-то лишнее.

Применение асма и ассемблерных вставок заставляет обкладывать код директивами условной компиляции, определяющими тип компилятора

1) Только если я целился в несколько компилеров. Для МК актуально с большими оговорками и местами.
2) В МК есть много других вещей специфичных для компилера. Даже просто положить вон то в конкретную секцию - компилерспецифично. При желании можно сделать относительно симпатично, типа SECTION(x) который где-то в одном месте задефайнен для gcc, для iar, и кого там еще. А основной код соответственно везде одинаковый.
3) Естественно такого счастья как по мне должен быть минимум, как раз чтобы в случае чего не переписывать половину кода. Но вот мелкую фигню 3-5 команд я не обломлюсь переписать и под принципиально другой процессор.
4) А прикиньте, у допустим RISCV нет никакого CMSIS самого по себе. И ядро другое. Зато у китайцев уже есть типа-STM32 у которого оторвали ядро ARM, приделали RISCV, и по моему прикольно придумано. И в свете назревающей покупкой nvidia фирмы arm мне кажется что уже пора начинать учиться чему-то такому.

Но на кортексах это скорее исключение.

Вот тут я полностью соглашусь, по минимуму я могу F1xx стартануть вообще без либ, интринсиков и асма. И все же CPSID I какое-нибудь ну вот не делается сишными абстракциями, а без него быстро выключить прерывания нельзя. И то что его в интринсик или билтин перепрятали - все же не отменяет этот факт. А раз так, почему-бы мне немного не научиться этому? С пониманием что этот код конечно придется переписать на другой процессор, что его должен быть минимум, etc. Зато это предсказуемо, побайтово, и не должно зависеть от версии, флагов и соседнего кода.

[VladislavS]

[uquote="iddqd",url="/forum/viewtopic.php?p=3929774#p3929774"]Даже просто положить вон то в конкретную секцию - компилерспецифично.[/uquote]Уже давно нет.

Код: Выделить всё

__attribute__((section("name")))

[iddqd]

Уже давно нет.

Увы, но __attribute__((section("name"))) - вроде бы не закреплено ни в каком стандарте, или я что-то проспал. И если кто это не умеет или делает не так, ему ничего и не предъявишь особо вроде.

[VladislavS]

Вы уже в который раз ссылаетесь на возможность кому-то что-то предъявить. Вас она греет, когда на столе проект со сроком выполнения "вчера"? Вы предпочитаете его выполнить, получить деньги и перейти к следующему или "предъявить" и сказать заказчику "сорри, я не виноват"?

[AVI-crak]

[uquote="iddqd",url="/forum/viewtopic.php?p=3929948#p3929948"]Увы, но __attribute__((section("name"))) - вроде бы не закреплено ни в каком стандарте, или я что-то проспал.[/uquote]
Видимо не просто проспал, но даже не желаешь просыпаться. Поиском по ключевым словам можно найти всё что угодно.
https://gcc.gnu.org/onlinedocs/gcc-3.2/ ... butes.html

[ВячеславX]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3929545#p3929545"]Что ещё для счастья надо?[/uquote]МХО Есть каста программистов, которые не понимают в электронике (но считают что понимают хорошо и достаточно для них), и программу рассматривают узко, как математические функции, обработка данных. Для них существует только контроллер с числовым входом и выходом. Таким людям язык Си самое оно и больше ничего не надо. И эти люди просто не могут понять задачи выходящие за рамки "программы в вакууме". И с пеной у рта кричат что кроме Си ничего не надо, а все кто не согласен неадекваты или тупые.

[iddqd]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3929961#p3929961"]Вы уже в который раз ссылаетесь на возможность кому-то что-то предъявить. Вас она греет, когда на столе проект со сроком выполнения "вчера"?[/uquote] Это критерий оценки соответствия стандартам кода и компиляторов. Если некий компилер это не умеет - что дальше? Я свалюсь им как снег на голову и скажу что это, дескать, плохо? Плохо почему? Потому что он - не GCC? Я такие даже видел

Вы предпочитаете его выполнить, получить деньги и перейти к следующему или "предъявить" и сказать заказчику "сорри, я не виноват"?

С таким отношением как мне кажется сайты-визитки - и быстрее и безопаснее! А если надо вчера - либ на пару мегов насовать и за 10 минут готово, красота.
[uquote="AVI-crak",url="/forum/viewtopic.php?p=3930112#p3930112"]Видимо не просто проспал, но даже не желаешь просыпаться. Поиском по ключевым словам можно найти всё что угодно.
https://gcc.gnu.org/onlinedocs/gcc-3.2/ ... butes.html[/uquote]Что-то я решительно не вижу где там написано что __attrubute__ является стандартом. Зато вижу обратные рассуждения про _Pragma, с коментом что это дескать более неудобно. И ведь хрен поспоришь, доки и GCC неплохие. И обычно не врут. Конечно как любителю опенсорса льстит что GCC в фаворе, но истина все ж дороже.
p.s. а ты случайно не какой-то из древних реверсеров или типа того? Ник какой-то. Как будто я его видел. Давно.

[uquote="ВячеславX",url="/forum/viewtopic.php?p=3930183#p3930183"]МХО Есть каста программистов, которые не понимают в электронике (но считают что понимают хорошо и достаточно для них), и программу рассматривают узко, как математические функции, обработка данных. Для них существует только контроллер с числовым входом и выходом. Таким людям язык Си самое оно и больше ничего не надо. И эти люди просто не могут понять задачи выходящие за рамки "программы в вакууме". И с пеной у рта кричат что кроме Си ничего не надо, а все кто не согласен неадекваты или тупые.[/uquote]Говоря за себя - я полагаю что для каждой задачи хорош свой инструмент. Иногда и немного и ассемблер на сабже не смотрится дурно. Но писать на нем более-менее серьезную прошивку для ARM - а ну его в болото: на асме общая логика этого плохо ухватывается. А отладить математику типа крипто на стороне компа кстати удобно - мощные инструменты типа asan/ubsan есть, проверят что код не говно. Это намного лучше чем непонятный трэш с выносом памяти пытаться в дебагере осмыслить, особенно когда состояние сильно урыто. На стороне МК так инструментировать сложно - оно много хлама в рантайм добавляет. Да и статические анализаторы для си умные стали, иногда дельно спрашивают - а что это у вас тут за подозрительная штука? На ассемблере так не получится. И да, на cortex M можно без напрягов сделать на сях и чисто управляющую задачу. Ну я до кучи шаговик покрутил, нормально вполне. Куда железнее? Там математики в понимании математивов - вообще нет . Cortex'ы на си здорово оптимизированы.

p.s. однако на мой вкус асм у cortex M весьма логичный и приятный, получше многих других.

[AVI-crak]

[uquote="iddqd",url="/forum/viewtopic.php?p=3932133#p3932133"]Что-то я решительно не вижу где там написано что __attrubute__ является стандартом.[/uquote]
Стандарты бывают разными: языка программирования, спецификаций, форматы линкера, а в данном случае самого компилятора GCC. Для других компиляторов есть свои стандарты, и всё это между собой не совместимо. Просто нужно копать в одном направлении, а не везде по чуть чуть.

[iddqd]

Стандарты принимаются стандартизирующими организациями и одинаковы для всех. В этом весь их смысл. А собственный креатив авторов компилятора - стандартом, соответственно, не является. Как максимум "стандартом де-факто", но при всем уважении к GCC даже это было бы слишком громким заявлением: я видел компиляторы где это делалось иначе. И это не нарушало никакие стандарты. А так максимум что стандартизировано применительно к мк - разве что nostdlib какой-нибудь, но, увы, это не все что было надо.

[VladislavS]

__attribute__((section("name"))) поддерживают, как минимум, gcc, iar и arm compiler. По состоянию на сегодня это все основные компиляторы под ARM.

[iddqd]

Да и собственно фирма ARM чуть ли не выбросила уже свой компилер в пользу GCC. Однако вот именно стандартом оно от этого все же не становится - никто не назовет обозначение стандарта и стандартизирующую организацию ратифицировавшую это. Разработчики GCC просто однажды сделали как им было удобно, GCC стал довольно популярен, остальные собезьянили. Но не все и не везде. И эти разработчики даже не обещали что никогда не будут менять например этот интерфейс, или там что еще.

А так то у gcc довольно много дельных расширений есть. Некоторые даже в стандарты попали постепенно. Но, увы, опять же далеко не все. Ну вон у них например case с диапазоном в switch. Очень клево и удобно - но, к сожалению нестандартно. Хотя конечно идея устроить проприетарщикам вендорлок на gcc выглядит стебно, что сказать. На самом деле я порой грешу нестандартными 0b1001100... - ну, блин, слишком уж удобно и наглядно для микроконтроллеров чтобы не использовать такое, хорошо визуально показывает структуру всяких битовых штук - и вообще все что я видел минимально разумевшее C99-like такое все же сжирало.

[Eddy_Em]

Не gcc единым… Тот же шланг успешно развивается. Уже сейчас у него значительно более вменяемые сообщения об ошибках и предупреждениях, нежели у gcc! Разве что с ARMянами пока не очень (судя по слухам). Но, возможно, версии к 12 шланг полноценно сможет и на этом поприще с gcc конкурировать.
По крайней мере, на ПК уже вовсю расходятся истории успеха о замене gcc на шланг в той же генте! И ядро уже полноценно собирается шлангом…

[iddqd]

Собственно clang собезьянил с gcc почти все особенности и расширения. А так пусть себе развивается где-нибудь там, его эппл и гугл поделили на двоих, микроконтроллеры эту сладкую парочку особо не интересуют, зато за обоими этими фирмами никогда не ржавело кинуть своих адептов с поддержкой тех или иных технологий и проектов, при том резко и внезапно. Гентушникам что, они к этому привычные, там вся система такая что может резко и внезапно помереть.

[VladislavS]

iddqd, Eddy_Em, господа хорошие! Да прекратите вы рассуждать на темы в которых не разбираетесь. ARM Compiler это и есть LLVM и CLANG.

iddqd, двоичные литералы через 0b в стандарте C++14 ещё ввели.

Eddy_Em, берёшь Keil и пользуешься Clang "из коробки".

[oleg110592]

примеры для тестирования stm32 clang/gcc. В линуксе просто установить из репозитория clang и llvm
https://github.com/dwelch67/stm32_sampl ... LEO-F401RE
з.ы. для blink получается clang бинарник больше чем gcc

[VladislavS]

Неудачный код для тестирования компиляторов. Вы его загоняете в рамки того что написали в асме. Без вызова ассмеблерных функций компилятор сделает код лучше.

[oleg110592]

оно в обоих листингах одинаково

Код: Выделить всё

bl   8000050 <GET32>

[VladislavS]

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

[oleg110592]

ну дык написал - уже на блинке проявилось, кому не лень может посмотреть почему (для этого ссылка). Мне лень