Я хочу выучить С++ под ембедед. Подскажите какие нибудь он лайн курсы или другой материал. Хотелось бы также посмотреть готовые проекты на С++ чтоб прочувствовать все аспекты.

easyelectronics

спасибо. там действительно хорошие статьи по С++. плохо что в разброс.

С++ в embedded обычный, поэтому изучайте по любой книге. Специфика embedded в ограниченности ресурсов, поэтому нужно отчетливо понимать "сколько стоит" та или иная языковая конструкция.
К примеру, RTTI - тяжелая вещь, ее не применяют в первую очередь (хотя можно, если хочется).
https://vk.com/wall-112797241_4
https://vk.com/wall-112797241_104?w=away-112797241_104
https://vk.com/wall-112797241_147

Надо же!
И сколько же стоит?

Столько ссылок и все ни о чем.
Это не embedded.

Погуглив я обнаружил что нет нормальных обучалок по С++ именно под микроконтролеры. Так чтоб объяснили с азов и именно под микроконтролеры. Скачал пару проектов сижу разбираюсь на примерах. Не факт что эти примеры являются образцом.

И чернил для второго класса тоже не выпускают...

Если Вы знаете как использовать базовый С (без привязки на контроллеры), и знаете-умеете использовать C++
т.е. анализ задачи, разбивку ее на объекты, их иерархию и все подобное, то курсы Вам (как-бы) не нужны.
Если этой базы у Вас нет, то курсы мало помогут. Разве что курсы по ООП.

Особенность контроллеров - мало ресурсов (оперативная память, память программ).
Соотв-но, основное отличие программирования с OOP под PC от embeded - ХОРОШО-ОПТИМАЛЬНО
продуманная-спроектированная структура данных и методов их обработки.







PS
Чтобы прочуствовать.
Возьмите простую задачу отрисовки простых граф. объектов, и действий с ними (движение, вращение, модификация формы)
И попробуйте реализоваь эту задачу на С и на C++

Это наивное заблуждение.
Люди обычно не сидят и не продумывают.
А кодят. А потом переписывают. Это рефакторинг, он самое главное. Только так и можно что-то написать.
Поэтому С++ здесь идёт стороной, и потому никто практичных примеров для embedded на C++ показать и не может.




Ну так и почувствуйте. Возьмите uC/GUI написанную на чистейшем C и переведите ее на C++.
Или операционку вроде FreeRTOS и покажите что там даст C++.


Ничего не даст абсолютно кроме тормозов.

Я давно пишу на С. Я также пишу на С# так что знаком с ООП. Мне нужен конкретный,толковый туториал по которому можно начать писать под ембедед. Именно со спецификой ембедед. И такого я еще не нашел к сожалению.

Ставьте компилятор IAR и там в хелпе найдете кое-что. Еще есть статьи у IAR как правильно применять embedded С++.
Но пожалейте свое время, пользы от C++ в embedded ноль.
Лучше уж портируйте .NET micro framework и продолжайте писать на C# для микроконтроллеров.

я с вами согласен на 120%. но это не мои требования. есть пару проектов которые по дикому желанию заказчика должны быть написаны на С++. что я могу поделать.

Я таки извиняюсь, Ваше Великолепие.... Можно я вставлю свои 2 пенса ? Это ничего, что самая распространенная на планете Земля операционка (на свое время) Symbian OS была полностью написана на С++, включая драйвера и realtime kernel (EKA2) ? Да, С++ в ядре и драйверах был искуственно ограничен, в юзере более-менее нормален...
Решение спорное, но тем не менее так было.
Насчет симбиановского гуя: как правило, каждая компания, лицензировавшая ОС писала свой гуй с сопутствующими глюками и тормозами..

Есть хорошие бесплатные курсы по C++ на https://www.coursera.org/
Лично проходил. Понравилось, что обучают последним версиям языка и очень много дают шаблонного программирования и использования stl.
Курс назывался C++ для Си программистов.

Ну так переименуйте файлы .c в .cpp и делов-то.
Вон даже Mentor в своей операционке Nucleus Plus так делать не стесняется.
И в Symbian так наверняка было сделано.

спасибо. посмотрю.


а если проверят? а там ни класов ни строковых типов.

Кстати, могут возникнуть некоторые забавные глюки от такого переименования.. Может потребоваться тонкая доводка исходников молотком и напильником
Ну, например, если в С-файле была использована переменная с именем, которое является зарезервированным в С++, ("new", например).
Опять же, name mangling появится, что-то там было про разное отношение к one definition rule.

Строковые типы? В embedded? На Cortex-M4 с сотней килобайт RAM-а на борту? Это очень самоуверенно я вам скажу.

Хотя если речь про Raspberry PI, то все нормально.
Но это чудо теперь и на C# программируется.
Я прямо сейчас для него на C# пишу сервер IoT.

Если имеется ввиду std::string, то да, лучше не использовать. Но со строками как-то работать надо, поэтому колхозим свой велосипед:

Класс добивается своими методами по потребностям. Можно полностью содрать интерфейс с std::string.
Если встречу хорошо написанный класс строки, с удовольствием выкину свою поделку

Вы как понимающий знаете что и где колхозить. а что делать начинающему?

Учиться.
Нужны материалы?
Просто С++ - любые 3 хорошие книги (читать в фоне).
Со спецификой embedded - мне очень понравилась эта книга https://vk.com/wall-112797241_4

Быстрый старт.
1. Начните использовать ссылки.
2. Начните использовать С++ приведения типов reinterpret_cast, static_cast, const_cast. Запретите себе приведение типов в стиле C.
3. Используйте namespace.
4. Используйте перегрузку функций (если надо конечно).
3. Пробуйте проектировать простые классы. Напишите класс светодиода, пусть плохенький (для начала). Это уже объектно-ориентированный анализ и проектирование, есть отдельные книги.
Спрашивайте здесь, как написать класс под ту или иную задачу.

спасибо.

Жесть. Заказчик требует определенный язык пр-ия... и может отругать за то, что не он использован.

А чего не жабку или пхытон? Не, даже жабоскрипт! Если уж и быть извращенцем, так по полной!

что тут удивительного? в военных проектах (да и не только в военных. любой серьезный заказчик.) обычно определяют и язык програмирования и RTOS и среду тестирования и еще много чего. например был авиационный проект там вообще запретили микроконтроллеры. все писали на FPGA.

C++ и embedded — это промежуточный шаг к ардуйне! Хотя, ацефалия нонче в моде.

Да-да, еще каких-то 20 лет назад продвинутые ассемблерщики так же ругали Си. Некоторые до сих пор ругают. Не знаете плюсов, не умеете их применять в контроллерах - промолчите, не позорьтесь, не мешайте развиваться другим.

Если не для себя, а для заказчика, то да, проще всего сделать как советовал AlexandrY - переименовать c в cpp и переработать код, добавив классы. Вроде такой стиль программирования так и называют - "си с классами". Если другие фишки C++ при этом не использовать, то в производительности/ресурсах вроде не потеряете, а некоторые удобства (например, инкапсуляция) добавятся.

"С с классами" - так сначала назывался С++. Стоит только переименовать с в срр, как сразу в голову полезут идеи, как этими ++ попользоваться. Сначала немного, дальше больше.

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

В авиационном проекте запретили микроконтроллеры?

Это вы сочиняете. Там наверно запретили все таки FPGA. Перечитайте первоисточник.




Ох уж этот загадочный C++.
Настоящие программисты наделают себе классов с шаблонами для моргания светодиодом, шевеления пинами, соединения строк и с гордостью нам эту лабуду демонстрируют.

именно в авиационном и именно микроконтролеры. мне нечего сочинять. я сам делал проект и потом сдавал.

Ну так значит проект был не авиационный либо где-то рядом с авиацией.
FPGA только недавно в автомобилях разрешили применять.

может был не авиационный. значит зря я по боингу неделю лазил.

Это тот проект, на котором вы 3-4 месяца форум мучали по поводу своего кхм, кода (пытаясь экономить такты процессора и допуская грубейшие ляпы в простых конструкциях)?
Тогда я рад за оборонку, авионику и прочее..

Отстают ваши европы. Я еще в 2003 на МАКСе российскую бортовую электронику на FPGA видел.

я разве задавал вопросы по VHDL на форуме? что то не припомню.

От части согласен, от части нет. Если программировать ради программирования, тогда да. А если стоит конкретная задача, если работаешь постоянно с чем-то новым и видишь, что вроде-чтото подобное делал, но не совсем, тогда на помощь приходит C++ (а возможно и Rust).
Кроме того в C++, а тем более Rust компилятор постоянно проверяет программиста гораздо более строго, чем сишный(С практически ничего не проверяет).

Понимаю, что от части это холивары, но я не буду голословить а покажу конкретный например.

Класс-контейнер, хранящий один исполняемый обьект любого размера и типа, но в рамка заданных критериев, то есть сигнатуру исполняемой функции.


Очередь исполняемых обьектов:

Эта очередь принимает любой исполняемый обьект любого размера. Сама очередь фиксированного размера Size_w, определенного достаточным заранее.

Стоит задача - на шине PSI висит 10 устройств, нет, давайте хватит 5ти. Каждое из них совершенно разное. И использует шину совершенно непредсказуемо.
Это AЦП, DataFlash, Акселерометр, гироскоп и термометр.
АЦП выдает 1000 выборок в секунду. Гироскоп и аксель по 100. Термометр - одна выборка в секунду. Dataflаsh вообще редко используется, в основном когда юзер что-то в менюшке нажимает.
Как это все быстро и просто реализовать на C?
Как на C++ - да очень просто - используя нашу очередь(и производные от нее классы), однажды один раз написанную за несколько дней.
Для работы с SPI мы будем использовать DMA, но это не важно.

В драйвере SPI должна быть функция запуска DMA следующего вида:

Использовать это очень просто:

Точно так же делается и для других устройств, но работа с каждым совершенно разная. На C это будет выглядеть, как куча структур, функций-обработчиков и void*, здесь же всю грязную работу сделает за нас компилятор, при чем проверит нас.

Это все классно, но что делать, если шина занята? Кто-то будет использовать какие-то мютексы, локи, busy флаги итд. Но мы сделаем все гораздо проще - на помощь приходит наша очередь исполняемых обьектов.
Нам понадобится очередь SPI-задач. создаем:

Эта очередь также может быть приоритетная - сначала будут выполнятся более приоритетные задачи(например акселерометр, гироскоп и АЦП, а потом менее приоритетные, например термометр, а в конце уже dataflash.

Вот функция, которая считывает данные с акселерометра, в порядке его очереди и приоритета. У юзера вообще не болит голова что там с шиной да и вообще со всем остальным.

Ну вот и все, задача решена. Все просто, понятно и довольно безопасно и без гонок. Точно так же реализовываем работу с остальными устройствами: АЦП,датафлеш,гироскоп и термометр.

Такое же можно и на C реализовать, но в C нет шаблонов, придется передавать кучу дополнительных параметров, например sizeof(AccelerometerReadSampleTask), нужно делать кучу структур(под каждый таск свою), кучу функций-колбеков и нигде не провтыкаться - компилятор в C делает гораздо меньше проверок, чем C++.
Мало того - сишная реализация может оказаться менее быстрой, чем c++. В С вы будете описывать call-back-и явно, да еще и передавать дополнительные аргументы. В c++ большинство сделано на шаблонах, компилятор сам сгенерит оптимальный код и большинство функций будет встроено в недра самой очереди.
Я все больше присматриваюсь к языку Rust - он еще более строгий, чем c++, там даже все переменные по умолчанию const и много чего еще интересного.
В C++ у меня давно выработалась привычка писать не SomeClass* ptr, а const SomeClass* const ptr. Или не int x, a const int x.

Нормально С++ в эмбеддед идет! Сам применяю и доволен.

Вы посмотрите на любой сишный проект. В том или ином виде мы всегда видим там некий struct с данными и кучу функций в качестве первого парметра принимающих указатель на этот struct.
Это как минимум первый аргумент в пользу того, чтобы перейти на С++ в формате "Си с классами". Потому как при вызове метода компилятор как раз неявно передает this в метод в качестве аргумента(прозрачно для программиста).

И это только первый, самый очевидный аргумент из списка.

Но таки да, учить язык придется!

И наименее важный. Вот когда идет динамика - указатели на функции, таблицы указателей на функции, кода появляются тонны макросов #define, когда то и видишь указатели void* которые на самом деле ссылаются на сложные структуры данных различных типов - вот тогда срочно надо переходить на плюсы - поручать делать грязную работу компилятору. Код станет гораздо проще, короче, понятнее, быстрее и безопаснее.

Но согласитесь, по сложности переноса этого добра на С++ это уже далеко не самый простой сценарий ) Более того, как правило перетащить это безобразие на плюсы методом "в лоб" и не получится. Придется и язык подучить и дизайн передизайнить, чтоб ООП задействовать. И тогда получится красиво и хорошо. Если повезет )))

Очевидный плюс перейти на С++ состоит в том, что не надо будет больше скрывать исходники. Они являются самокриптующимися, никто из конкурентов с ними ничего сделать не сможет.

Тогда надо на Rust переходить - его уж точно конкуренты не поймут, при чем там все вкусности c++ есть - шаблоны, перегрузка, динамический/статический полиморфизм, лямбды итд. Мало того, он еще и менее императивный и более экспрессивный


Чтобы получилось хорошо - надо будет учиться пару лет. Многие думают, что C++ - синтаксический сахар над C, типa мол писали Class_method(obj), a стали писать obj->method() . Но это далеко не так. C++ мощный и сложный язык.
Это все равно, что назвать C синтаксическим сахаром для ассемблера. Действительно, какая разница - написать mov r0, r1 на асме или r0 = r1; на C ?

Хотя на самом деле.. вот кусок типичного C++ кода, при чем это довольно безобидный, а бывают реально страшные

Такой код на C невозможен в принципе. Нет, ну можно что-то похожее реализовать на #define но это будет горбатый сложный и непонятный монстр, на разработку которого уйдет куча времени, а потом через пару месяцев сами не поймете что понаписывали. Проще не париться, а каждый раз(в каждом отдельном проекте или месте использования) реализовывать по новой, изменяя параметры.
А на С++ делается 1 раз(при чем времени нужно не больше, чем на одну сишную реализацию, а то и меньше) и используется повторно без изменений в куче других проектов.