Как стать автором
Обновить

Комментарии 23

Сам фанбой 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 раст на МК гораздо интереснее с++

Зато плюсовые стандартные библиотеки могут легко скушать 50-100 килобайт флешки.

Стандартные библиотеки любого ЯП, реализованные в полном обьеме, будут отьедать непростительно много для большинства МК. И раста это тоже касается.

В расте я std использовал, потому что из коробки нет аллокатора.

Но hal там интереснее реализован, так, что не выжирает килобайты флеша, а транслируется непосредственно в код на этапе компиляции.

Так что нет, не в любом ЯП так будет.

А в чем проблема-то с 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.

Только платно, поэтому переехал на VScode + PlatformIO, иногда через Сmake, но тоже на VScode

Ни винды, ни VisualGDB у меня нет, потому что macOS.

Среди них: отсутсвие автодополнения кода,

Справедливости ради, в CubeIDE есть автодополнение. Не слишком удобно всё время Ctrl+Space жамкать, но всё же.

Вот именно это я и назвал "отсутствием".

Все же Visual Studio + VisualGDB лучше будет, как выше сказали. У него хотя бы есть поддержка, которая работает отлично и куча МК работает сразу, плюс поддержка WSL и SSH.

CLion довольно тормозной, плюс надо руками настраивать под каждый МК. В таком случае лучше уже и VSCode настроить.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.