C++ Siberia 2019: Игнат Ворошилов, Возможности С++ для программирования микроконтроллеров

Ближайшая конференция: С++ Russia 2024, 24 мая (online), 2-3 июня (offline, Москва)
Подробности и билеты: jrg.su/W8skjE
- -
. . . Обычно, программирование микроконтроллеров подразумевает использования языков программирования ASM, C, и лишь изредка C++. Но даже те проекты, которые написаны с использованием C++, написаны в стиле C, без использования преимуществ C++ в полной мере. Эти утверждения справедливы для подавляющего большинства проектов с открытым исходным кодом, библиотек от разработчиков микросхем, различных SDK и иже с ними. На мой взгляд, игнорирование возможностей C++ и возможностей ООП, при разработке ПО для микроконтроллеров, неоправдано. Предлагаю рассмотреть конкретные примеры использования возможностей языка C++, которые помогут сэкономить время разработчика и повысить качество проекта.

[@ArtemMELNYK]

Грамотно изложено. Спасибо.

[@iliasalaur]

Очень классный доклад. Как не крути, хоть объект тратит немного больше памяти, преимуществ у ООП на много больше

[@user-xm5zl9up4r]

Интересно. Для начинающих сложновато. Спасибо

[@dmitry.shpakov]

Спасибо.

[@dmitry.shpakov]

Хороший доклад. Красиво рассказываете.

[@alexandrgacov9882]

ассемблерные вставки имеет смысл делать только маленького размера. большие подпрограммы на ассемблере писать нет смысла - тут компилятор уделает человека, компилятор С/С++ владеет скрытыми данными о работе внутреннего конвейера. Пример - я писал для Cortex-M3/4/7 (компилятор gcc) целочисленный фурье. мой ассебмлерный код был на 5% более компактнее чем сгенерированный С, но в итоге С обогнал меня по времени на 3% примерно.

[@alexanderurezchenko6651]

Было интересно

[@user-jn8mu4no3i]

В програме proteus можно создавать вертуальный МК с разной обвязкой заливать туда прошивку и проверять код. PS если не ошибаюсь)

[@olong5854]

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

[@NRelectronics]

Так вот хотелось действительно узнать сколько времени на это уходит то?

[@olong5854]

@@NRelectronics Следуя указаниям в документе "OOP in C" от Quantum Leaps ( www.state-machine.com/doc/AN_OOP_in_C.pdf ) можно довольно быстро и красиво реализовать свою иерархию классов. А если есть возможность использовать флаг MS extensions при компиляции (как здесь: stackoverflow.com/questions/1237266/how-can-inheritance-be-modelled-using-c ), код будет выглядеть ещё аккуратнее. Этих средств должно хватить для многих задач, в том числе и для создания абстракций аппаратных интерфейсов, потока ввода-вывода или, например, драйвера акселерометра. Как видно из документа, количество кода невелико. Наверное, стоит накинуть минут 15 по сравнению с C++ разработкой. Но, конечно, все зависит от задачи.

[@NRelectronics]

@@olong5854 благодарю.

[@user-wv5wj7sz2e]

scmRTOS операционка для МК на С++ и юзаю её уже лет 5, очень нравится мне. А на С++ пишу для МК уже лет 15...

[@user-vq2ib4dl4r]

можно Ваш скайп или вайбер ?

[@ParanoidAndroid23r]

Тоже имел возможность использовать scmRTOS. Использовал не без удовольствия.

[@user-gd9fl6og6w]

Я бы очень хотел изучить С++ и программировать на нём микроконтроллеры, можете дать пару советов?

[@user-vh9fn9hi7j]

@@user-gd9fl6og6w тоже интересно, изучаю Си, но c++ более читабельный

[@Scherbakov]

Использовал cueue и bitset в stm32f4 - всё летает.

[@andrewandrosow4797]

Чисто на Си разве что терморегулятор сделать либо реле времени. Если же что-то серьезное - например измеритель комплексного импеданса цепи (RLC метр) то применение Си++ может помочь разбить программу на части - ибо число строк тут уже более 1000.Это на мой взгляд...

[@HeavyHeavyvich]

Visual Studio + VisualGDB вполне красиво работает в плюсах. Но! Стандартная тема начинающих - это попадос в фрагментацию памяти. По мне так нужно перегружать new() и писать свой аллокатор, размещая объекты в каком-нибудь пуле. Ну и дефраг можно придумать, но это еще то веселье. Как вы боретесь с фрагментацией? Или вы не работаете с new()? Ну, и, соответственно... Раз проект такой забористый, что уже закипает мозг от Си, то почему бы не взять какую-нибудь Pi (nano Pi, orange Pi, Raspberry zero), и переложить весь этот гемор на Pi, спокойно юзая все прелести ООП ? А для МК оставить участь ногодрыга.

[@HedgehogInTheCPP]

В Разбери тоже GPIO есть и МК вообще не нужен.

[@ignat_for_example]

Привет! Динамическое выделение памяти не используем. Для некоторых модулей размещаем объекты по очереди в заранее отведённый кусок памяти, но в основном память статически размечена. Про сложность - на заре проекта была простая железяка с бедным функционалом, MVP, она пошла по клиентам и в железяку была заложена функция перешивки по интерфейсам связи. И со временем проект развивался, обрастал фичами и только то, что изначально был выбран такой путь (кресты вместо чистых с), позволило ему отрасти до такой сложности. Сейчас уже думаем, что в следующую версию будем закладывать однопалатный компьютер. Тут проблема в том, что индустриальных однопалатных компьютеров, к тому же и дешёвых, нет или мы не нашли. А низкая цена железяки в этом проекте критична. Таков рынок.

[@allaksusallaksus2402]

11:26 лучше говорить "машинный код"

[@cppprograms5868]

Кто бы что не говорил, С++ отличный язык программирования.

[@MikeSmith-qc3ow]

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

[@user-hr9cw6iz3d]

Есть пример программы, где отражена, описанная Вами, красота с++ ?