Comments 24
Сам фанбой Jetbrains и в частности CLion, но С++14/20 для микроконтроллера как-то перебор, субьективно так. Да и так ли плоха родная IDE ?
Поддержу. А вот если мне хватает простого Си и нативного HALа со всеми его косяками (оные вполне поправимы руками) для пользования всеми возможностями и портами контроллера. Да и даташита с CMSIS и без HALа тоже, то что тогда? Ни разу ни CUBE IDE, ни атоллик на винде не слетели... Сам, кстати, Keil предпочитаю.
Не считаю C++14/20 перебором по нескольким причинам. Во первых, если проект является сугубо "хобби", то можно пробывать что угодно, во вторых при правильном применении C++ код будет ни чуть не хуже чем С'шный в плане размера и производительности. Как пример могу посоветовать публикации товарища lamerok.
Согласен. Пробовать и развиваться нужно, хотя бы в плане эрудиции. Просто сказал о своих наблюдениях по поводу стабильности указанных продуктов лично у меня. Суперфичами новых C++ стандартов не пользуюсь, хватает обычного Си.
С удовольствием, кстати, посмотрю на задачу, где только Си не обойтись, а есть реальная необходимость в применении C++ 11/14/20...
С удовольствием, кстати, посмотрю на задачу, где только Си не обойтись, а есть реальная необходимость в применении C++ 11/14/20...
Вот что за постановка вопроса? Естественно, на любом тьюринг-полном ЯП возможно реализовать любую задачу.
Всегда вопрос стоит в том, сколько вы потратите на это сил.
Когда мы переходим от "просто" алгоритмов (отдельных задач) к реальным проектам, с допиливанием фичь, тестированием, устранением багов и т.д. вот тут то и раскрываются возможности ЯП. И чем больше у ЯП возможностей, тем потенциально меньше строчек кода вам прийдется написать для решения одной и тойже задачи.
С удовольствием, кстати, посмотрю на задачу, где только Си не обойтись, а есть реальная необходимость в применении C++ 11/14/20...
Вот что за постановка вопроса? Естественно, на любом тьюринг-полном ЯП возможно реализовать любую задачу.
Всегда вопрос стоит в том, сколько вы потратите на это сил.
Когда мы переходим от "просто" алгоритмов (отдельных задач) к реальным проектам, с допиливанием фичь, тестированием, устранением багов и т.д. вот тут то и раскрываются возможности ЯП. И чем больше у ЯП возможностей, тем потенциально меньше строчек кода вам прийдется написать для решения одной и тойже задачи.
А я ведь ничего и не утверждал. Понятное дело, что на Ассемблере даже моргание светодиодом будет выглядеть очень непросто, если взять листинг программы. Но на том же Си всё очень даже коротко и "кашерно". Мне лично, я пишу про себя, "классический" Си пока удобен просто "до нельзя". Из статьи автора и его аргументации я для себя, опять же, не вижу, простите за тавтологию, очевидных вещей, почему вдруг стало нужно использовать "плюсы". Соответственно у меня, как у утилитарного пользователя вопрос - "А покажите пример, уважаемый???"
Опять же я только поддерживаю всё новое и если это будет реально эффективно, то обязательно буду применять.
Зато плюсовые стандартные библиотеки могут легко скушать 50-100 килобайт флешки.
Хорошо, если контроллер новый, с 512-1024 килобайтами флеша.
ИМХО, в 2021 раст на МК гораздо интереснее с++
А в чем проблема-то с 14/20? Надо, конечно, себя ограничивать, и не пихать стандартную библиотеку и всякие бусты - это очень много памяти берет, а новые синтаксические конструкции языка никак природе микроконтроллеров не противоречат.
Я позволил себе оговорку-лазейку, написав что "субьективно".
С C++14/20 все хорошо, по моему субьективному мнению, но на десктопе.
В принципе моя формулировка "не использовать С++14/20" на микроконтроллере схожа с мыслью "ограничивать себя". Ну какие там C++14/20 если, поправьте меня, даже std::thread, packaged_task,future/promise не реализованы на stm32 ? А это, на минуточку, C++11 .
А как там move semantics ?
Не использовать C++14/20 на микроконтроллере также укладывается в концепцию "развиваться и обучаться".
> std::thread, packaged_task,future/promise
Они там не реализованы по строгим причинам - нет операционки. fopen тоже не реализован, а это, извините, С73 от Ричи.
А фичи языка на параллельностях и не заканчиваются. В новых стандартах реализовано масса вещей, реально помогающих жить в МК.
Послушайте, например https://www.youtube.com/watch?v=QM3W36COnE4 (нужен c++20 емнип)
Или единицы измерения через user defined literals (c++11)
А что не так с move semantics?
Для себя пользую Segger Embedded Studio, так как по мимо stm32, использую ещё и nrf52. Лучше иметь более универсальную IDE, чем две под разные МК.
насчет С++14/20: если писать с использованием шаблонов, а с ними код реально компактней получается, то 20 версия стандарта самое то. Стандартные либы не пользую, немцы нормальной поддержки ещё не завезли к себе, а так хочется std::array ...
да и в целом IDE сейчас по сути только редактор кода да организатор дерева проекта. компилятор то любой можно подтянуть, а тут уже начинается интересное. каждый старается выдать свой компилятор как "самый-самый", но это как правило для коммерческого использования (вопрос цены все же стоит остро). а для хобби проектов\обучения по сути хватает и свободных компиляторов. отсюда и вопрос выбора IDE чисто дело вкуса. а что нам надо? адекватную подсветку синтаксиса, автодополнение да темную тему.
Да и так ли плоха родная IDE ?
мне просто не заходит eclipse в любой ипостаси, а коллега использует вполне спокойно его. так что дело вкуса
По поводу IDE и всего такого - готов "сьесть", тк. всетаки вопрос вкуса и предпочтений. К примеру в своей работе я так и не сдружился с QtCreator, хотя обьективно среда отличная - там есть почти все из коробки. Но нет ) Уже лучше VS, а в идеале CLion (на С++ лабаю).
Но вот по поводу С++14/20 прошу прощения что заела пластинка: что там такого концептуально нового на фоне С++11 из того что может быть реально использовано на микроконтроллере?
Если взять все теже шаблоны, то все это уже было в C++11
Extern templates
Template aliases
Variadic templates
Local types as template arguments
Что там в 14/20 такого, без чего не обойтись на контроллере ?
Constraints and concepts ? Да ладноооо! =)
https://habr.com/ru/post/566070/
С корутинами можно поиграться, например. Довольно удобно получается писать с их использованием. Да и места могут скушать технически меньше, чем фриртос в некоторых случаях ( см комментарии).
Из того что я использовал у себя:
в С++20 завезли: non-type template parameters of class type
template< GPIO_t T>
class Gpio{
...
}в С++17 завезли:
инициализацию статических членов сразу в шаблоне:
// строковые константы
static inline char revision_[7] = "unset";
// или так
inline static T inst_;fold expression:
...
static inline constexpr void addChannels () {
NRF_PPI->CHG[GROUP_NUM] = ( (1<<channels) | ... );
}if constexpr:
if constexpr (F != 0) {
NRF_PPI->FORK[CH].TEP = F;
}
Ни разу не было проблем ни c Atollic, ни с CUBE IDE, на винде)
Сам предпочитаю использовать Visual Studio + VisualGDB. Идеальная связка, на мой взгляд. Так же позволяет импортировать проекты из STM32CubeMX.
Среди них: отсутсвие автодополнения кода,
Справедливости ради, в CubeIDE есть автодополнение. Не слишком удобно всё время Ctrl+Space жамкать, но всё же.
Все же Visual Studio + VisualGDB лучше будет, как выше сказали. У него хотя бы есть поддержка, которая работает отлично и куча МК работает сразу, плюс поддержка WSL и SSH.
CLion довольно тормозной, плюс надо руками настраивать под каждый МК. В таком случае лучше уже и VSCode настроить.
CLion содержит лицензионный ключ для бесплатного пробного использования в течение 30 дней.
отличное достоинство!
CLion + STM32 без шелухи