Ассемблер для STM32. Сложно ли, стоит ли пытаться?
- Сообщения: 270
- Зарегистрирован: Вс окт 20, 2019 13:03:56
Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?
- Реклама
- Сообщения: 1978
- Зарегистрирован: Ср июл 17, 2013 13:55:57
Сложнее перечисленных. Пытаться разбираться не стоит. Писать на асме бесперспективно. На STM32 нормальные проекты все на C. Поэтому куда перспективнее учить С. Хоть для STM32, хоть для чего угодно.
- Сообщения: 270
- Зарегистрирован: Вс окт 20, 2019 13:03:56
А что тогда делать? "С" - он же намного сложнее асма, я его просто не осилю.NStorm писал(а):Пытаться разбираться не стоит. Писать на асме бесперспективно
- Сообщения: 2089
- Зарегистрирован: Вс июн 19, 2016 09:32:03
[uquote="Shuspano",url="/forum/viewtopic.php?p=3741147#p3741147"]А что тогда делать? "С" - он же намного сложнее асма, я его просто не осилю.[/uquote]
Если не осилишь С, значит тем более не осилишь периферию STM32, в таком случае будешь только дрыгать ножками и тогда С действительно не настолько и нужен...
Если не осилишь С, значит тем более не осилишь периферию STM32, в таком случае будешь только дрыгать ножками и тогда С действительно не настолько и нужен...
- Сообщения: 270
- Зарегистрирован: Вс окт 20, 2019 13:03:56
Понял, не мое значит.
А собственно, чего там в этой периферии сложного. Вроде те-жи регистры. Или нет?
А собственно, чего там в этой периферии сложного. Вроде те-жи регистры. Или нет?
Код: Выделить всё
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
Последний раз редактировалось Shuspano Чт ноя 21, 2019 22:02:23, всего редактировалось 1 раз.
- Реклама
- Сообщения: 1978
- Зарегистрирован: Ср июл 17, 2013 13:55:57
Ну посмотрите Reference Manual. Сколько там регистров. А еще учитывая, что они 32-битные.
https://www.st.com/content/ccc/resource ... 031936.pdf
https://www.st.com/content/ccc/resource ... 031936.pdf
- Сообщения: 285
- Зарегистрирован: Вс сен 05, 2010 15:35:50
С, возможно, сложнее в изучении ( особенно С++ ), чем ассемблер (хотя тоже кому как). Но зато потом на нем писать легче, а главное быстрее.
А вот с тем, что ассемблер учить не надо, и он потом не пригодится - не соглашусь. Если есть силы - учить стоит. Пригодится. Есть много задач, которые имеет смысл писать на ассемблере. Правда, обычно речь идет не о самостоятельное приложение, а скорее об ассемблерных вставках в программе на том же С. Так что С все равно в приоритете.
А вот с тем, что ассемблер учить не надо, и он потом не пригодится - не соглашусь. Если есть силы - учить стоит. Пригодится. Есть много задач, которые имеет смысл писать на ассемблере. Правда, обычно речь идет не о самостоятельное приложение, а скорее об ассемблерных вставках в программе на том же С. Так что С все равно в приоритете.
- Сообщения: 1978
- Зарегистрирован: Ср июл 17, 2013 13:55:57
protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.
- Сообщения: 285
- Зарегистрирован: Вс сен 05, 2010 15:35:50
[uquote="NStorm",url="/forum/viewtopic.php?p=3741164#p3741164"]protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.[/uquote]
Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.
Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.
- Сообщения: 1743
- Зарегистрирован: Вт авг 15, 2017 10:51:13
[uquote="Shuspano",url="/forum/viewtopic.php?p=3741127#p3741127"]Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?[/uquote]ARM-ассемблер - наверное самый простой из всех, которые я знаю/использовал. Но полностью писать на нём - малополезное занятие.
Лучше всё-таки изучить си.
Добавлено after 1 minute 58 seconds:
[uquote="Shuspano",url="/forum/viewtopic.php?p=3741156#p3741156"]А собственно, чего там в этой периферии сложного. Вроде те-жи регистры. Или нет?[/uquote]
Сложность не в регистрах, а их количестве. Из всех ARM-процессоров у STM32 кстати самая простая периферия.
Добавлено after 3 minutes 36 seconds:
[uquote="protoder",url="/forum/viewtopic.php?p=3741167#p3741167"]Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.[/uquote]Полиморфный код например.
Добавлено after 2 minutes 4 seconds:
[uquote="NStorm",url="/forum/viewtopic.php?p=3741159#p3741159"]А еще учитывая, что они 32-битные.[/uquote]Вы наверное хотели сказать: "В основном 16-битные".
Лучше всё-таки изучить си.
Добавлено after 1 minute 58 seconds:
[uquote="Shuspano",url="/forum/viewtopic.php?p=3741156#p3741156"]А собственно, чего там в этой периферии сложного. Вроде те-жи регистры. Или нет?[/uquote]
Сложность не в регистрах, а их количестве. Из всех ARM-процессоров у STM32 кстати самая простая периферия.
Добавлено after 3 minutes 36 seconds:
[uquote="protoder",url="/forum/viewtopic.php?p=3741167#p3741167"]Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.[/uquote]Полиморфный код например.
Добавлено after 2 minutes 4 seconds:
[uquote="NStorm",url="/forum/viewtopic.php?p=3741159#p3741159"]А еще учитывая, что они 32-битные.[/uquote]Вы наверное хотели сказать: "В основном 16-битные".
[uquote="Shuspano",url="/forum/viewtopic.php?p=3741127#p3741127"]Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?[/uquote]
Если действительно разобрались с одним ассемблером, разберётесь без особых проблем и с любым другим. Ну ладно, с почти любым, т.е. бывает действительно мозговыносительная экзотика (вроде DSP, например) -- но и там, в общем-то, всё вполне постижимо.
Периферия МК вообще никакого отношения к ассемблеру не имеет; и, опять-таки, если освоил, скажем, "ручное" (самостоятельное, а не с помощью готовых библиотек) программирование некоего интерфейса на одном МК, освоишь и на любом другом. Понятно, что дрыгать ногами проще, чем, скажем, написать полноценный драйвер USB-хоста, но всё это возможно, а к используемому языку особого отношения не имеет.
Знать ассемблер, как по мне, просто необходимо, если работаешь с низкоуровневыми вещами. Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.
Ну и, наконец, бывают задачи, где каждый такт на счету, и решить их можно только на ассемблере (ну или поставив намного более мощный проц, что не всегда возможно).
Ну а Си (а точней, Си++) знать крайне полезно. Не потому, что язык хороший (гадость та ещё), но рынок-с диктует-с. Ну и, опять-таки, писать крупные вещи на асме можно, но утомительно, и обычно лучше использовать какой-либо язык высокого уровня -- а из-за этого самого рынка таким языком с большой долей вероятности будет именно Си++. Чистый Си учить сейчас особого смысла уже нет: у Си++ куча преимуществ в плане повышения надёжности и читабельности программы, даже если не использовать классы. Но, как по мне, изучать его лучше на ПК, поскольку VisualStudio -- в 100500 раз более удобный инструмент, чем любые IDE для МК, и не надо сразу же заморачиваться с низкоуровневыми вещами (ОС за тебя всю черновую работу сделает). Плюс полно литературы, форумов и т.д. и т.п.
Добавлено after 2 minutes 39 seconds:
[uquote="protoder",url="/forum/viewtopic.php?p=3741167#p3741167"][uquote="NStorm",url="/forum/viewtopic.php?p=3741164#p3741164"]protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.[/uquote]
Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.[/uquote]
Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).
Если действительно разобрались с одним ассемблером, разберётесь без особых проблем и с любым другим. Ну ладно, с почти любым, т.е. бывает действительно мозговыносительная экзотика (вроде DSP, например) -- но и там, в общем-то, всё вполне постижимо.
Периферия МК вообще никакого отношения к ассемблеру не имеет; и, опять-таки, если освоил, скажем, "ручное" (самостоятельное, а не с помощью готовых библиотек) программирование некоего интерфейса на одном МК, освоишь и на любом другом. Понятно, что дрыгать ногами проще, чем, скажем, написать полноценный драйвер USB-хоста, но всё это возможно, а к используемому языку особого отношения не имеет.
Знать ассемблер, как по мне, просто необходимо, если работаешь с низкоуровневыми вещами. Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.
Ну и, наконец, бывают задачи, где каждый такт на счету, и решить их можно только на ассемблере (ну или поставив намного более мощный проц, что не всегда возможно).
Ну а Си (а точней, Си++) знать крайне полезно. Не потому, что язык хороший (гадость та ещё), но рынок-с диктует-с. Ну и, опять-таки, писать крупные вещи на асме можно, но утомительно, и обычно лучше использовать какой-либо язык высокого уровня -- а из-за этого самого рынка таким языком с большой долей вероятности будет именно Си++. Чистый Си учить сейчас особого смысла уже нет: у Си++ куча преимуществ в плане повышения надёжности и читабельности программы, даже если не использовать классы. Но, как по мне, изучать его лучше на ПК, поскольку VisualStudio -- в 100500 раз более удобный инструмент, чем любые IDE для МК, и не надо сразу же заморачиваться с низкоуровневыми вещами (ОС за тебя всю черновую работу сделает). Плюс полно литературы, форумов и т.д. и т.п.
Добавлено after 2 minutes 39 seconds:
[uquote="protoder",url="/forum/viewtopic.php?p=3741167#p3741167"][uquote="NStorm",url="/forum/viewtopic.php?p=3741164#p3741164"]protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.[/uquote]
Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.[/uquote]
Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).
- Сообщения: 1978
- Зарегистрирован: Ср июл 17, 2013 13:55:57
[uquote="jcxz",url="/forum/viewtopic.php?p=3741182#p3741182"]Вы наверное хотели сказать: "В основном 16-битные".
[/uquote]
Ну по факту-то они всё-равно 32-битные. Даже если там только 1 бит не reserved.
[uquote="SII",url="/forum/viewtopic.php?p=3741236#p3741236"]Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).[/uquote]
Это уже обычно неактуально для армов. Времена другие. Ресурсов больше, компиляторы C стали умнее.
Ну по факту-то они всё-равно 32-битные. Даже если там только 1 бит не reserved.
[uquote="SII",url="/forum/viewtopic.php?p=3741236#p3741236"]Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).[/uquote]
Это уже обычно неактуально для армов. Времена другие. Ресурсов больше, компиляторы C стали умнее.
- Сообщения: 202
- Зарегистрирован: Сб янв 09, 2016 15:51:17
[uquote="Shuspano",url="/forum/viewtopic.php?p=3741127#p3741127"]Хочу попробовать как нибудь использовать эти микроконтроллеры.[/uquote]
Китайская печатка с чипом и отладчик - в сумме примерно 300р. Даже если не взлетит - не столь страшно. Думать и выбирать на этом этапе вообще не нужно - у вас нет приоритетных направлений. Нужно просто открыть IDE, и написать свой код.
Китайская печатка с чипом и отладчик - в сумме примерно 300р. Даже если не взлетит - не столь страшно. Думать и выбирать на этом этапе вообще не нужно - у вас нет приоритетных направлений. Нужно просто открыть IDE, и написать свой код.
- Сообщения: 1743
- Зарегистрирован: Вт авг 15, 2017 10:51:13
[uquote="NStorm",url="/forum/viewtopic.php?p=3741246#p3741246"]Ну по факту-то они всё-равно 32-битные. Даже если там только 1 бит не reserved.[/uquote]Про битность Вы говорили в плане сложности (количества полей в регистре). А в этом случае важно количество реально задействованных бит, а не разрядность операций чтения/записи.
- Сообщения: 3385
- Зарегистрирован: Пн окт 11, 2010 19:00:08
Хоите сказать что не зная асм не получится определить причину попадания в HardFault? Вот к примеру рассмотрен случай попадания в HardFault из-за особенности работы ядра. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599SII писал(а):Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.
Причина ошибки и место ее возникновения были найдены без необходимости знания асма.
[uquote="Мурик",url="/forum/viewtopic.php?p=3741378#p3741378"]
Причина ошибки и место ее возникновения были найдены без необходимости знания асма.[/uquote]
Ну, методом научного тыка вообще можно что угодно отыскать, вопрос лишь во времени и силах. Так что лишние знания лишними не будут в любом случае. В частности, в приведённом Вами примере, если б человек реально умел писать на армовском асме, он бы, надо полагать, заранее знал бы о необходимости выравнивания операндов в памяти, а соответственно, подобную ошибку вряд ли бы допустил.
Хоите сказать что не зная асм не получится определить причину попадания в HardFault? Вот к примеру рассмотрен случай попадания в HardFault из-за особенности работы ядра. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599SII писал(а):Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.
Причина ошибки и место ее возникновения были найдены без необходимости знания асма.[/uquote]
Ну, методом научного тыка вообще можно что угодно отыскать, вопрос лишь во времени и силах. Так что лишние знания лишними не будут в любом случае. В частности, в приведённом Вами примере, если б человек реально умел писать на армовском асме, он бы, надо полагать, заранее знал бы о необходимости выравнивания операндов в памяти, а соответственно, подобную ошибку вряд ли бы допустил.
- Сообщения: 285
- Зарегистрирован: Вс сен 05, 2010 15:35:50
>> Ну, например, ресурсов у МК не хватает.
В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов.
НА AVR я еще люблю поиграться с прерываниями - С слишком много сохраняет регистров перед вызовом, в итоге реакция на прерывания становится неприлично медленной.
Но вообще согласен с SII. Ассемблер нужен программисту в первую очередь затем, зачем водителю представления о том, что происходит под капотом. Ездить без этого можно, но есть ситуации, где эти знания могут очень пригодиться, даже если ты и не собираешься сам чинить машину.
В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов.
НА AVR я еще люблю поиграться с прерываниями - С слишком много сохраняет регистров перед вызовом, в итоге реакция на прерывания становится неприлично медленной.
Но вообще согласен с SII. Ассемблер нужен программисту в первую очередь затем, зачем водителю представления о том, что происходит под капотом. Ездить без этого можно, но есть ситуации, где эти знания могут очень пригодиться, даже если ты и не собираешься сам чинить машину.
[uquote="protoder",url="/forum/viewtopic.php?p=3741397#p3741397"]>> Ну, например, ресурсов у МК не хватает.
В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов.[/uquote]
Всё равно можно столкнуться. Например, в следующих эхолотах (ЭР-6) стояла уже STM32L151-что-то-там, если память не изменяет. Брали, естественно, подешевле, со сравнительно небольшим объёмом памяти. Для первоначальных задач хватало выше крыши (фактически это была переделка ЭР-4, а сама нужда возникла из-за проблем Атмела, из-за чего начались серьёзные перебои с поставками атмег). Но аппетиты-то росли, а замена контроллера -- это нередко переделка платы и всё такое, что увеличивает себестоимость изделия (цена одной платы в партии из 10000 одинаковых плат ощутимо меньше, чем одной в партии из 1000, сборка тоже дешевле будет, ну и т.д. и т.п.). Поэтому человеку, который писал прошивку, пришлось прилично изгаляться. Почти всё было написано, правда, на сях, но кой-какой критический по скорости код был на асме (и остаётся таким и в последних эхолотах тоже, хотя они отличаются от прежних кардинально, в том числе и МК).
Кстати говоря, дело не только в объёме кода в прямом смысле (т.е. в расходе памяти). Больше команд выполняешь -- больше энергии жрёшь. Для устройств с батарейным питанием это может быть очень немаловажным. Ну а эффективность компиляторов... Хреновая она, откровенно говоря. Более того, иногда впечатление такое, что новые компиляторы становятся хуже. Думаете, индусские быдлокодеры только быдлосайтики и быдлобоинги кодят?
В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов.[/uquote]
Всё равно можно столкнуться. Например, в следующих эхолотах (ЭР-6) стояла уже STM32L151-что-то-там, если память не изменяет. Брали, естественно, подешевле, со сравнительно небольшим объёмом памяти. Для первоначальных задач хватало выше крыши (фактически это была переделка ЭР-4, а сама нужда возникла из-за проблем Атмела, из-за чего начались серьёзные перебои с поставками атмег). Но аппетиты-то росли, а замена контроллера -- это нередко переделка платы и всё такое, что увеличивает себестоимость изделия (цена одной платы в партии из 10000 одинаковых плат ощутимо меньше, чем одной в партии из 1000, сборка тоже дешевле будет, ну и т.д. и т.п.). Поэтому человеку, который писал прошивку, пришлось прилично изгаляться. Почти всё было написано, правда, на сях, но кой-какой критический по скорости код был на асме (и остаётся таким и в последних эхолотах тоже, хотя они отличаются от прежних кардинально, в том числе и МК).
Кстати говоря, дело не только в объёме кода в прямом смысле (т.е. в расходе памяти). Больше команд выполняешь -- больше энергии жрёшь. Для устройств с батарейным питанием это может быть очень немаловажным. Ну а эффективность компиляторов... Хреновая она, откровенно говоря. Более того, иногда впечатление такое, что новые компиляторы становятся хуже. Думаете, индусские быдлокодеры только быдлосайтики и быдлобоинги кодят?
- Сообщения: 1743
- Зарегистрирован: Вт авг 15, 2017 10:51:13
[uquote="SII",url="/forum/viewtopic.php?p=3741400#p3741400"]Хреновая она, откровенно говоря. Более того, иногда впечатление такое, что новые компиляторы становятся хуже. Думаете, индусские быдлокодеры только быдлосайтики и быдлобоинги кодят?
[/uquote]Полностью согласен! Иногда смотрю на код, сделанный из какого-то выражения компилятором, так возникает ощущение, что он его специально старается деоптимизировать. Т.е. - я его стараюсь писать так, чтобы требовалось меньше команд для компиляции, а компилятор просто тупо вставляет лишние команды. Или преднамеренно использует более длинные формы команд в тех местах, где можно использовать короткие. Речь про IAR.
- Сообщения: 1978
- Зарегистрирован: Ср июл 17, 2013 13:55:57


