C++ Siberia 2019: Игнат Ворошилов, Возможности С++ для программирования микроконтроллеров
ฝัง
- เผยแพร่เมื่อ 16 ต.ค. 2024
- Подробнее о конференции C++ Russia: jrg.su/W8skjE
- -
. . . Обычно, программирование микроконтроллеров подразумевает использования языков программирования ASM, C, и лишь изредка C++. Но даже те проекты, которые написаны с использованием C++, написаны в стиле C, без использования преимуществ C++ в полной мере. Эти утверждения справедливы для подавляющего большинства проектов с открытым исходным кодом, библиотек от разработчиков микросхем, различных SDK и иже с ними. На мой взгляд, игнорирование возможностей C++ и возможностей ООП, при разработке ПО для микроконтроллеров, неоправдано. Предлагаю рассмотреть конкретные примеры использования возможностей языка C++, которые помогут сэкономить время разработчика и повысить качество проекта.
Грамотно изложено. Спасибо.
Очень классный доклад. Как не крути, хоть объект тратит немного больше памяти, преимуществ у ООП на много больше
Непонятно, почему сравнение проходит именно в таком виде: плохо написанный код на C против хорошо написанного кода на C++. Очевидно, что C++ смотрится аппетитнее в таком случае. Но тот, кто пишет драйвер на языке C вовсе не обязан жёстко привязывать аппаратный интерфейс к бизнес-логике и так далее. На C можно и нужно использовать абстракции, применять некоторые приемы из ООП, разница лишь в том, что все эти прелести жизни нужно реализовывать самому, без помощи компилятора. И отсюда возникает вопрос, действительно ли на это уходит так много времени, что изучение и применение другого, гораздо более сложного языка способно облегчить жизнь программисту?
Так вот хотелось действительно узнать сколько времени на это уходит то?
@@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++ разработкой. Но, конечно, все зависит от задачи.
@@olong5854 благодарю.
Хороший доклад. Красиво рассказываете.
В програме proteus можно создавать вертуальный МК с разной обвязкой заливать туда прошивку и проверять код. PS если не ошибаюсь)
ассемблерные вставки имеет смысл делать только маленького размера. большие подпрограммы на ассемблере писать нет смысла - тут компилятор уделает человека, компилятор С/С++ владеет скрытыми данными о работе внутреннего конвейера. Пример - я писал для Cortex-M3/4/7 (компилятор gcc) целочисленный фурье. мой ассебмлерный код был на 5% более компактнее чем сгенерированный С, но в итоге С обогнал меня по времени на 3% примерно.
Интересно. Для начинающих сложновато. Спасибо
Спасибо.
scmRTOS операционка для МК на С++ и юзаю её уже лет 5, очень нравится мне. А на С++ пишу для МК уже лет 15...
можно Ваш скайп или вайбер ?
Тоже имел возможность использовать scmRTOS. Использовал не без удовольствия.
Я бы очень хотел изучить С++ и программировать на нём микроконтроллеры, можете дать пару советов?
@@кастян-х9е тоже интересно, изучаю Си, но c++ более читабельный
Использовал cueue и bitset в stm32f4 - всё летает.
Кто бы что не говорил, С++ отличный язык программирования.
Visual Studio + VisualGDB вполне красиво работает в плюсах. Но! Стандартная тема начинающих - это попадос в фрагментацию памяти. По мне так нужно перегружать new() и писать свой аллокатор, размещая объекты в каком-нибудь пуле. Ну и дефраг можно придумать, но это еще то веселье.
Как вы боретесь с фрагментацией? Или вы не работаете с new()?
Ну, и, соответственно... Раз проект такой забористый, что уже закипает мозг от Си, то почему бы не взять какую-нибудь Pi (nano Pi, orange Pi, Raspberry zero), и переложить весь этот гемор на Pi, спокойно юзая все прелести ООП ? А для МК оставить участь ногодрыга.
В Разбери тоже GPIO есть и МК вообще не нужен.
Привет!
Динамическое выделение памяти не используем. Для некоторых модулей размещаем объекты по очереди в заранее отведённый кусок памяти, но в основном память статически размечена.
Про сложность - на заре проекта была простая железяка с бедным функционалом, MVP, она пошла по клиентам и в железяку была заложена функция перешивки по интерфейсам связи. И со временем проект развивался, обрастал фичами и только то, что изначально был выбран такой путь (кресты вместо чистых с), позволило ему отрасти до такой сложности. Сейчас уже думаем, что в следующую версию будем закладывать однопалатный компьютер. Тут проблема в том, что индустриальных однопалатных компьютеров, к тому же и дешёвых, нет или мы не нашли. А низкая цена железяки в этом проекте критична.
Таков рынок.
Было интересно
Доклад хороший. Но не убедительно. Сам использую scmRTOS (он под с++) впечатления только положительные, использую выделяемую память (кучу), с ней тоже нет проблем. Нет проблем и с дефрагментацией. Поскольку обычно память в процессе инициализации объектов выделяется последовательно, а затем в основном алгоритме выделяется и возвращается назад в кучу без лишних дыр (если программист,конечно, не устроил утечки памяти). Один из главных плюсов с++ по сравнению с чистым си, это аккуратная компоновка кода, позволяющая писать гораздо более сложные алгоритмы. Программа на си к этому моменту обычно превращается в нечитаемую кашу из переваренного спагетти. Но этот факт довольно сложно объяснить ардуинолюбителям и любителям чистого си, поскольку для "поморгать светодиодами" плюсы действительно не нужны. А сложные программы они не пишут.
Есть пример программы, где отражена, описанная Вами, красота с++ ?
Чисто на Си разве что терморегулятор сделать либо реле времени. Если же что-то серьезное - например измеритель комплексного импеданса цепи (RLC метр) то применение Си++ может помочь разбить программу на части - ибо число строк тут уже более 1000.Это на мой взгляд...
11:26 лучше говорить "машинный код"