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

[Shuspano]

Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?

[NStorm]

Сложнее перечисленных. Пытаться разбираться не стоит. Писать на асме бесперспективно. На STM32 нормальные проекты все на C. Поэтому куда перспективнее учить С. Хоть для STM32, хоть для чего угодно.

[Shuspano]

Пытаться разбираться не стоит. Писать на асме бесперспективно

А что тогда делать? "С" - он же намного сложнее асма, я его просто не осилю.

[Reflector]

Shuspano писал(а):

А что тогда делать? "С" - он же намного сложнее асма, я его просто не осилю.

Если не осилишь С, значит тем более не осилишь периферию STM32, в таком случае будешь только дрыгать ножками и тогда С действительно не настолько и нужен...

[Shuspano]

Понял, не мое значит.
А собственно, чего там в этой периферии сложного. Вроде те-жи регистры. Или нет?

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

PWR_CR   EQU   0x40007000
PWR_CSR   EQU   0x40007004
RCC_CR   EQU   0x40021000
RCC_CFGR   EQU   0x40021004
RCC_CIR   EQU   0x40021008
RCC_APB2RSTR   EQU   0x4002100C
RCC_APB1RSTR   EQU   0x40021010
RCC_AHBENR   EQU   0x40021014
RCC_APB2ENR   EQU   0x40021018
RCC_APB1ENR   EQU   0x4002101C
RCC_BDCR   EQU   0x40021020
RCC_CSR   EQU   0x40021024
GPIOA_CRL   EQU   0x40010800
GPIOA_CRH   EQU   0x40010804

[NStorm]

Ну посмотрите Reference Manual. Сколько там регистров. А еще учитывая, что они 32-битные.
https://www.st.com/content/ccc/resource ... 031936.pdf

[protoder]

С, возможно, сложнее в изучении ( особенно С++ ), чем ассемблер (хотя тоже кому как). Но зато потом на нем писать легче, а главное быстрее.
А вот с тем, что ассемблер учить не надо, и он потом не пригодится - не соглашусь. Если есть силы - учить стоит. Пригодится. Есть много задач, которые имеет смысл писать на ассемблере. Правда, обычно речь идет не о самостоятельное приложение, а скорее об ассемблерных вставках в программе на том же С. Так что С все равно в приоритете.

[NStorm]

protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.

[protoder]

NStorm писал(а):

protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.

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

[jcxz]

Shuspano писал(а):

Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?

ARM-ассемблер - наверное самый простой из всех, которые я знаю/использовал. Но полностью писать на нём - малополезное занятие.
Лучше всё-таки изучить си.

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

Shuspano писал(а):

А собственно, чего там в этой периферии сложного. Вроде те-жи регистры. Или нет?

Сложность не в регистрах, а их количестве. Из всех ARM-процессоров у STM32 кстати самая простая периферия.

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

protoder писал(а):

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

Полиморфный код например.

Добавлено after 2 minutes 4 seconds:

NStorm писал(а):

А еще учитывая, что они 32-битные.

Вы наверное хотели сказать: "В основном 16-битные".

[SII]

Shuspano писал(а):

Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?

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

Периферия МК вообще никакого отношения к ассемблеру не имеет; и, опять-таки, если освоил, скажем, "ручное" (самостоятельное, а не с помощью готовых библиотек) программирование некоего интерфейса на одном МК, освоишь и на любом другом. Понятно, что дрыгать ногами проще, чем, скажем, написать полноценный драйвер USB-хоста, но всё это возможно, а к используемому языку особого отношения не имеет.

Знать ассемблер, как по мне, просто необходимо, если работаешь с низкоуровневыми вещами. Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.

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

Ну а Си (а точней, Си++) знать крайне полезно. Не потому, что язык хороший (гадость та ещё), но рынок-с диктует-с. Ну и, опять-таки, писать крупные вещи на асме можно, но утомительно, и обычно лучше использовать какой-либо язык высокого уровня -- а из-за этого самого рынка таким языком с большой долей вероятности будет именно Си++. Чистый Си учить сейчас особого смысла уже нет: у Си++ куча преимуществ в плане повышения надёжности и читабельности программы, даже если не использовать классы. Но, как по мне, изучать его лучше на ПК, поскольку VisualStudio -- в 100500 раз более удобный инструмент, чем любые IDE для МК, и не надо сразу же заморачиваться с низкоуровневыми вещами (ОС за тебя всю черновую работу сделает). Плюс полно литературы, форумов и т.д. и т.п.

Добавлено after 2 minutes 39 seconds:

protoder писал(а):

[uquote="NStorm",url="/forum/viewtopic.php?p=3741164#p3741164"]protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.

Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.[/uquote]

Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).

[NStorm]

jcxz писал(а):

Вы наверное хотели сказать: "В основном 16-битные".

Ну по факту-то они всё-равно 32-битные. Даже если там только 1 бит не reserved.

SII писал(а):

Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).

Это уже обычно неактуально для армов. Времена другие. Ресурсов больше, компиляторы C стали умнее.

[AVI-crak]

Shuspano писал(а):

Хочу попробовать как нибудь использовать эти микроконтроллеры.

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

[jcxz]

NStorm писал(а):

Ну по факту-то они всё-равно 32-битные. Даже если там только 1 бит не reserved.

Про битность Вы говорили в плане сложности (количества полей в регистре). А в этом случае важно количество реально задействованных бит, а не разрядность операций чтения/записи.

[Мурик]

Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.

Хоите сказать что не зная асм не получится определить причину попадания в HardFault? Вот к примеру рассмотрен случай попадания в HardFault из-за особенности работы ядра. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599
Причина ошибки и место ее возникновения были найдены без необходимости знания асма.

[SII]

Мурик писал(а):

Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.

Хоите сказать что не зная асм не получится определить причину попадания в HardFault? Вот к примеру рассмотрен случай попадания в HardFault из-за особенности работы ядра. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599
Причина ошибки и место ее возникновения были найдены без необходимости знания асма.

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

[protoder]

>> Ну, например, ресурсов у МК не хватает.

В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов.
НА AVR я еще люблю поиграться с прерываниями - С слишком много сохраняет регистров перед вызовом, в итоге реакция на прерывания становится неприлично медленной.

Но вообще согласен с SII. Ассемблер нужен программисту в первую очередь затем, зачем водителю представления о том, что происходит под капотом. Ездить без этого можно, но есть ситуации, где эти знания могут очень пригодиться, даже если ты и не собираешься сам чинить машину.

[SII]

protoder писал(а):

>> Ну, например, ресурсов у МК не хватает.

В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов.

Всё равно можно столкнуться. Например, в следующих эхолотах (ЭР-6) стояла уже STM32L151-что-то-там, если память не изменяет. Брали, естественно, подешевле, со сравнительно небольшим объёмом памяти. Для первоначальных задач хватало выше крыши (фактически это была переделка ЭР-4, а сама нужда возникла из-за проблем Атмела, из-за чего начались серьёзные перебои с поставками атмег). Но аппетиты-то росли, а замена контроллера -- это нередко переделка платы и всё такое, что увеличивает себестоимость изделия (цена одной платы в партии из 10000 одинаковых плат ощутимо меньше, чем одной в партии из 1000, сборка тоже дешевле будет, ну и т.д. и т.п.). Поэтому человеку, который писал прошивку, пришлось прилично изгаляться. Почти всё было написано, правда, на сях, но кой-какой критический по скорости код был на асме (и остаётся таким и в последних эхолотах тоже, хотя они отличаются от прежних кардинально, в том числе и МК).

Кстати говоря, дело не только в объёме кода в прямом смысле (т.е. в расходе памяти). Больше команд выполняешь -- больше энергии жрёшь. Для устройств с батарейным питанием это может быть очень немаловажным. Ну а эффективность компиляторов... Хреновая она, откровенно говоря. Более того, иногда впечатление такое, что новые компиляторы становятся хуже. Думаете, индусские быдлокодеры только быдлосайтики и быдлобоинги кодят?

[jcxz]

SII писал(а):

Хреновая она, откровенно говоря. Более того, иногда впечатление такое, что новые компиляторы становятся хуже. Думаете, индусские быдлокодеры только быдлосайтики и быдлобоинги кодят?

Полностью согласен! Иногда смотрю на код, сделанный из какого-то выражения компилятором, так возникает ощущение, что он его специально старается деоптимизировать. Т.е. - я его стараюсь писать так, чтобы требовалось меньше команд для компиляции, а компилятор просто тупо вставляет лишние команды. Или преднамеренно использует более длинные формы команд в тех местах, где можно использовать короткие. Речь про IAR.

[NStorm]

GCC и нет проблем.