На чем все таки надо писать Embedded?

как же мы без этого живем, о ужас

примерно то же самое сказал чукча, впервые посетив метрополитен.

это всё можно держать в голове. Конечно зачем, когда есть языки, которые это всё делают - не понятно, но всё это можно написать вручную. Да и нет в этом всё ничего строго-необходимо. просто пишешь обёртку создания объекта, которая вызывает и аллокатор, вот тебе и конструктор. Обычно ты заранее знаешь будет ли этот объект аллоцироваться или нет. Забыл вызвать деструктор - сам виноват. В c++ же пустой деструктор бы сам сгенерировался и вызывался бы всегда, так что когда объекту понадобилось бы добавить что-то в деструктор - вызовы бы уже были на месте, в си же можно что-то забыть и допустить утечку ресурса
Из фич именно языка пожалуй можно тут назвать только запекание конструкторов в init array так, что оно при загрузке модуля будет вызываться неявно. На embedded это не сильно релевантно в принципе, а большинство тулчейнов имеют способ сделать это и в си

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

Надо писать на JS, истинно говорю!

Есть такой подход на Си, писать со счетчиком ссылок. ref/unref. Подход вполне стандартный, сложностей не вызывает. И деструктор вызвать забыть не получится. Если ты захватил объект, делаешь реф, когда закончил – анреф. Ничего сложного. Деструктор сам позовется, когда счетчик ссылок достигнет нуля. Я не знаю, как можно забыть сделать анреф. Если только специально.

И деструктор вызвать забыть не получится.

получится. методом обхода места с деструктором в виде exit, return, goto, signal.

а вот с плюсовым RAII - не получится.

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

Ранний выход из функции при несоблюдении условий - это важнейший метод обеспечения читаемости и понятности кода. Иначе нужно городить кучу goto в конец функции, где вызываются деструкторы, и ни в коем случае не перепутать при переходе метку, чтобы не освободить то, что еще не выделили.

в плюсах конструкторы/деструкторы вызывают их у предка, а также всех полей в структуре у которых они есть, порядке декларации.

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

опять же если есть виртуальные методы, конструктор/деструктор ставит сначала свою вируальную таблицу, чтобы не вызвать виртуальные методы потомка(ибо это некорректно).

ну вот и делай все это ручками.

Есть такой подход на Си, писать со счетчиком ссылок. ref/unref.

Это вообще о другом. Подсчет ссылок позволяет организовать совместное владение объектом (что нужно далеко не всегда), и вызов unref ничем по сути не отличается от вызова free() или функции-деструктора.

плюсах с шаблонами, прошивка ещё и становится меньше в разы.

далеко не всегда, шаблоны могут изрядно пожрать флеша (такова их природа). а вот быстрее - да, иногда даже банальный вывод в порт, работа с регистрами очень красиво оптимизируется (на хабре статейка была), плюс можно чудить полиморфизм без virtual/indirect call.

з.ы. пишем ембед только на плюсах, и все ок.

это как «зачем нужна коробка автомат, если есть механика?» (rust можно рассматривать как вариатор ))

Я вангую обычно в таких применениях C++ используется без STL и с -fno-exceptions. Ибо первое действительно слишком жирное и универсальное, а второе убивает риалтайм, усложняет проверку корректности кода и тоже кушает флеш. В итоге на плюсах пишут в первую очередь саму бизнес логику, а плюсовые библиотеки либо не используют, либо используют специальные для embedded.

Открою секрет: многие плюсовые библиотеки поддерживают сборку с -fno-exceptions -fno-rtti.

Как начнешь понимать, сразу и поймешь. Но потом. «Скорее вбросить» — это вообще не про что-то нормальное. Это про «программные продукты»(ТМ), которые отличаются от программ, как «кефирные продукты» (ТМ) от кефира. Но ты кушай-кушай, тебе же нормально :)

А какой там рантайм писать? Перегрузку new и delete вызывающую malloc и free? Это делается за минуту.

Они скорее всего завязаны на STL, а последний тащить в embedded обычно нежелательно.

Шаблоны, деструкторы. Шаблоны для эбдедеда вообще то что доктор прописал - конфигурировать какими ногами/интерфейсами пользоваться не через макропортянки. А ещё можно через constexpr делать всякие вычисления, которые не нужно делать на самом МК, таким образом уйдя от кодогенерации.

Банально какие-нибудь USB дескрипторы на шаблонах и constexpr описывать гораздо приятнее.

Так одна из фич плюсов в том, что можно использовать сишные либы без модификации.

Ну вот о том и речь - если нельзя использовать 90% от стандартной библиотеки и функций языка - то зачем, если по факту С++ вырождается в С?

Не вырождается, потому что даже при использовании сишных либ ТВОЙ код становится выразительнее по сравнению с Си. Больше вещей в твоём коде форсится компилятором, а не твоей памятью и внимательностью.

Я просто оставлю это здесь: http://www.stolyarov.info/books/asm_unix#comment-599

сжечь?

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

Я к тому, что хэдеров для эмбедных железяк под С много а под С++ мало.

P.S. У сбера был косяк в том что они написали extern C { … }, а внутри были С++ конструкции типа опускания слова struct, что С++ позволяет, а С нет.

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

если б все рассуждали как вы, то плюсы и делать не стоило б.

Но ты кушай-кушай, тебе же нормально :)

Ну если ты только в таком ключе способен вести диалог, то можно ответить разве что «пердолься дальше со своими адами, пока люди продукты делают» :))

между сортами сишек

ACSL?

Использую оську на плюсах, библиотечку доступа к периферии на плюсах, чувствую себя отлично :-)

Пользуюсь только теми частями плюсов, которые не дают оверхеда и не тянут за собой динамического распределения памяти. Шаблоны, constexpr, атомики, array, варианты (с ограничениями), лямбды…

А причем тут десктопы, если мы говорим про эмбед, в котором до сих пор памяти хорошо если метр есть.

На расте конечно, ты что АНБ не уважаешь?

А как используете шаблоны? Есть какие-то приемы, что позволяют избежать комбинаторного взрыва?

Ну и да, а за счет чего на STM работают атомики? Чисто интересно.

я хватанул конечно… первый коммерческий с++ появился в 1985. а тогда для дескотопов даже 1Мб озу был роскошью.

Если у вас есть хэдеры для С для например STM32, то есть вероятность, что под С++ он либо не скомпилится либо будет работать не так как надо. С++ уже давно не надмножество С.

Если сишный хедер не компилится, то используют extern «C», и он компилируется по правилам C.

Я просто оставлю это здесь: http://www.stolyarov.info/books/asm_unix#comment-599

Жесть, ему лечиться надо, а не учебники писать.

Если сишный хедер не компилится, то используют extern «C», и он компилируется по правилам C.

Я уже привел пример когда большая компания не знает разницы между С и С++ и сует в extern C плюсовый код.

Значит им плевать на С (кроме стиля линковки), вот и весь секрет

А как используете шаблоны? Есть какие-то приемы, что позволяют избежать комбинаторного взрыва?

Шаблоны использую в основном для настройки поведения классов, отделения уровней логики. Не представляю, откуда взяться комбинаторному взрыву. Просто не надо писать огромные шаблонные функции и потом инстанцировать их с кучей типов:)

Атомики для простых типов размером в слово работают элементарно - запись плюс барьер. Для более сложных - там LDREX/STREX, но я такие не использую.

На Ada. Ну или на Haskell.

Сколько компиляторов Ada есть на pic32, Arm и MicroBlaze?

смотря какой ембеддед

некоторые и на питоне с яваскриптом умудряются

ну там на луа ещё

но по хорошему stm32f0 - это plain c + немного asm.

ASM там не нужен от слова совсем, это же ARM ядро. Стартап файл на асме, да, но это какой-то пережиток полнейший, фиг знает зачем это делают.

Лучше всего, конечно, на C++ писать, потому что шаблоны (да и просто классы даже удобнее намного). Лично я смысла под них писать на C не вижу вообще.

Стартап файл на асме, да, но это какой-то пережиток полнейший, фиг знает зачем это делают.

Я не уверен, что на си/си++ можно как то заставить компилятор положить таблицу векторов в нулевой адрес.

Я не уверен…

Это вообще не про aсм, си, плюсы и тп. это про скрипты для линкера.

https://www.opennet.ru/docs/RUS/gnu_ld/gnuld-3.html

Можно. Прямо на C++ даже. И за это, пожалуй, больше компоновщик отвечает. В коде надо только разметить секции, а дальше линковочный скрипт их развестит куда нужно.

… какие-то аргументы за C или С++ в embedded?

1. Моё твёрдое убеждение состоит в том, что прошивку микроконтроллера гораздо лучше напишет разработчик электронной аппаратуры ибо он узреет задачу шире изначально, подстрахуется где необходимо и допустит меньшей избыточности в целом.

2. Если с детских лет подолгу сидеть возле телевизора или проводить время в мировой вычислительной сети вместо общения со сверстниками, то мышление человека оказывается неспособным к изобретательству, а годится лишь к переиспользованию где-либо увиденного. Проще говоря, старпёры, выросшие на книгах, мыслят стратегически и пишут свой код в стремлении к минимализму, а «цифровая» молодёжь изначально рыщет в поиске нужной библиотеки и втаскивает в код кучи стороннего кода.

3. Какой подход предпочесть в итоге? Я бы смотрел как мыслит старший разработчик. Чтобы это понять нужно всего лишь узнать чем он занимается в свободное от работы время: сидит в «Инстаграмме», «В контакте» и «Твиттере» или читает книги и предпочитает общаться с людьми вживую.

Язык программирования тут вторичен.

Хм, ладно, просто я знаю как можно задать сектор для таблицы векторов в асме, но ни разу не видел как задают сектор для переменных в C и C++, поэтому не знал что там так можно

James_Holden

Проще говоря, старпёры, выросшие на книгах, мыслят стратегически и пишут свой код в стремлении к минимализму, а «цифровая» молодёжь изначально рыщет в поиске нужной библиотеки и втаскивает в код кучи стороннего кода.

В крайности впадать тоже не нужно, но в целом люто плюсую.

Такая штука как ардуино и соответствующая культура ваяния г из г библиотек на г платформе в г IDE - лично мне вообще не понятна. Потому что профессионалы это не используют, а самодельщики - им же должно быть интересно сделать самому, по определению. А не воткнуть непонятное нечто.

uint32_t vectors[] __attribute__((section(".isr_vector"))) = {
    STACK_START,
    (uint32_t)Reset_Handler,
    (uint32_t)NMI_Handler,
    (uint32_t)HardFault_Handler,
    (uint32_t)MemManage_Handler,
    (uint32_t)BusFault_Handler,
    (uint32_t)UsageFault_Handler,
    0, // reserved
    .
    .
    .
};

Всего-то, магическое attribute

Спасибо, буду знать

А тебе надо больше одного? Для arm и blaze есть, для pic без понятия.

USB дескрипторы на шаблонах и constexpr

Почему такие вещи не генерируют отдельно и просто не линкуют?