Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?
Сложнее перечисленных. Пытаться разбираться не стоит. Писать на асме бесперспективно. На STM32 нормальные проекты все на C. Поэтому куда перспективнее учить С. Хоть для STM32, хоть для чего угодно.
А что тогда делать? "С" - он же намного сложнее асма, я его просто не осилю.
Если не осилишь С, значит тем более не осилишь периферию STM32, в таком случае будешь только дрыгать ножками и тогда С действительно не настолько и нужен...
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
С, возможно, сложнее в изучении ( особенно С++ ), чем ассемблер (хотя тоже кому как). Но зато потом на нем писать легче, а главное быстрее. А вот с тем, что ассемблер учить не надо, и он потом не пригодится - не соглашусь. Если есть силы - учить стоит. Пригодится. Есть много задач, которые имеет смысл писать на ассемблере. Правда, обычно речь идет не о самостоятельное приложение, а скорее об ассемблерных вставках в программе на том же С. Так что С все равно в приоритете.
protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.
protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.
Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.
Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?
ARM-ассемблер - наверное самый простой из всех, которые я знаю/использовал. Но полностью писать на нём - малополезное занятие. Лучше всё-таки изучить си.
Хочу попробовать как нибудь использовать эти микроконтроллеры. Знаю ассемблер для 8051, не очень хорошо - для PIC и AVR. А сложно ли будет разобраться с асмом для STM32, и стоит ли вообще пытаться?
Если действительно разобрались с одним ассемблером, разберётесь без особых проблем и с любым другим. Ну ладно, с почти любым, т.е. бывает действительно мозговыносительная экзотика (вроде DSP, например) -- но и там, в общем-то, всё вполне постижимо.
Периферия МК вообще никакого отношения к ассемблеру не имеет; и, опять-таки, если освоил, скажем, "ручное" (самостоятельное, а не с помощью готовых библиотек) программирование некоего интерфейса на одном МК, освоишь и на любом другом. Понятно, что дрыгать ногами проще, чем, скажем, написать полноценный драйвер USB-хоста, но всё это возможно, а к используемому языку особого отношения не имеет.
Знать ассемблер, как по мне, просто необходимо, если работаешь с низкоуровневыми вещами. Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.
Ну и, наконец, бывают задачи, где каждый такт на счету, и решить их можно только на ассемблере (ну или поставив намного более мощный проц, что не всегда возможно).
Ну а Си (а точней, Си++) знать крайне полезно. Не потому, что язык хороший (гадость та ещё), но рынок-с диктует-с. Ну и, опять-таки, писать крупные вещи на асме можно, но утомительно, и обычно лучше использовать какой-либо язык высокого уровня -- а из-за этого самого рынка таким языком с большой долей вероятности будет именно Си++. Чистый Си учить сейчас особого смысла уже нет: у Си++ куча преимуществ в плане повышения надёжности и читабельности программы, даже если не использовать классы. Но, как по мне, изучать его лучше на ПК, поскольку VisualStudio -- в 100500 раз более удобный инструмент, чем любые IDE для МК, и не надо сразу же заморачиваться с низкоуровневыми вещами (ОС за тебя всю черновую работу сделает). Плюс полно литературы, форумов и т.д. и т.п.
protoder, никто не говорил, что "ассемблер учить не надо, и он потом не пригодится". Я написал, что пытаться писать (само собой целиком прошивку) на асме для STM32 бесперспективно.
Ну да. Кроме каких-то совсем уж экзотических ситуаций. В принципе, на вскидку даже и в голову для примера ни чего не приходит.
Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).
Ну, например, ресурсов у МК не хватает. Был, например, в своё время (лет 10 назад, наверное) популярен рыбацкий эхолот "Практик-ЭР4" на АТМеге-162. Его прошивка написана на асме, поскольку контроллер был хилый, а хотели многого (и контроллер заменить было нельзя по нетехническим причинам).
Это уже обычно неактуально для армов. Времена другие. Ресурсов больше, компиляторы C стали умнее.
Хочу попробовать как нибудь использовать эти микроконтроллеры.
Китайская печатка с чипом и отладчик - в сумме примерно 300р. Даже если не взлетит - не столь страшно. Думать и выбирать на этом этапе вообще не нужно - у вас нет приоритетных направлений. Нужно просто открыть IDE, и написать свой код.
Ну по факту-то они всё-равно 32-битные. Даже если там только 1 бит не reserved.
Про битность Вы говорили в плане сложности (количества полей в регистре). А в этом случае важно количество реально задействованных бит, а не разрядность операций чтения/записи.
Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.
Хоите сказать что не зная асм не получится определить причину попадания в HardFault? Вот к примеру рассмотрен случай попадания в HardFault из-за особенности работы ядра. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599 Причина ошибки и место ее возникновения были найдены без необходимости знания асма.
Это может пригодиться, например, при отладке: если у тебя программа падает с каким-нибудь HardFault, ты сможешь понять причину лишь в том случае, если понимаешь, как реально этот процессор работает, а это невозможно без понимания ассемблера.
Хоите сказать что не зная асм не получится определить причину попадания в HardFault? Вот к примеру рассмотрен случай попадания в HardFault из-за особенности работы ядра. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599 Причина ошибки и место ее возникновения были найдены без необходимости знания асма.
Ну, методом научного тыка вообще можно что угодно отыскать, вопрос лишь во времени и силах. Так что лишние знания лишними не будут в любом случае. В частности, в приведённом Вами примере, если б человек реально умел писать на армовском асме, он бы, надо полагать, заранее знал бы о необходимости выравнивания операндов в памяти, а соответственно, подобную ошибку вряд ли бы допустил.
В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов. НА AVR я еще люблю поиграться с прерываниями - С слишком много сохраняет регистров перед вызовом, в итоге реакция на прерывания становится неприлично медленной.
Но вообще согласен с SII. Ассемблер нужен программисту в первую очередь затем, зачем водителю представления о том, что происходит под капотом. Ездить без этого можно, но есть ситуации, где эти знания могут очень пригодиться, даже если ты и не собираешься сам чинить машину.
В принципе да. Но учитывая большие объемы памяти STM, могу представить, какой должна быть программа, что б не поместиться. И сколько придется попотеть, переписывая ее на АСМ. Хотя если надо выиграть немного пространства, можно переписать лишь пару особо заумных алгоритмов.
Всё равно можно столкнуться. Например, в следующих эхолотах (ЭР-6) стояла уже STM32L151-что-то-там, если память не изменяет. Брали, естественно, подешевле, со сравнительно небольшим объёмом памяти. Для первоначальных задач хватало выше крыши (фактически это была переделка ЭР-4, а сама нужда возникла из-за проблем Атмела, из-за чего начались серьёзные перебои с поставками атмег). Но аппетиты-то росли, а замена контроллера -- это нередко переделка платы и всё такое, что увеличивает себестоимость изделия (цена одной платы в партии из 10000 одинаковых плат ощутимо меньше, чем одной в партии из 1000, сборка тоже дешевле будет, ну и т.д. и т.п.). Поэтому человеку, который писал прошивку, пришлось прилично изгаляться. Почти всё было написано, правда, на сях, но кой-какой критический по скорости код был на асме (и остаётся таким и в последних эхолотах тоже, хотя они отличаются от прежних кардинально, в том числе и МК).
Кстати говоря, дело не только в объёме кода в прямом смысле (т.е. в расходе памяти). Больше команд выполняешь -- больше энергии жрёшь. Для устройств с батарейным питанием это может быть очень немаловажным. Ну а эффективность компиляторов... Хреновая она, откровенно говоря. Более того, иногда впечатление такое, что новые компиляторы становятся хуже. Думаете, индусские быдлокодеры только быдлосайтики и быдлобоинги кодят?
Хреновая она, откровенно говоря. Более того, иногда впечатление такое, что новые компиляторы становятся хуже. Думаете, индусские быдлокодеры только быдлосайтики и быдлобоинги кодят?
Полностью согласен! Иногда смотрю на код, сделанный из какого-то выражения компилятором, так возникает ощущение, что он его специально старается деоптимизировать. Т.е. - я его стараюсь писать так, чтобы требовалось меньше команд для компиляции, а компилятор просто тупо вставляет лишние команды. Или преднамеренно использует более длинные формы команд в тех местах, где можно использовать короткие. Речь про IAR.
Сейчас этот форум просматривают: HardWareMan и гости: 21
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
