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

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

Не надо заниматься преждевременной оптимизацией ;)

Я скорее уперся не в рантайм, а в размер флеша, но это, я полагаю, из-за HAL и количества read-only данных

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

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

Про что это? Про меня с С или про рабочее место с плюсами?

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

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

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

потому что все книги и гайды пишут на сишке

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

А так-то сейчас уже имеет писать на rust. В эмбеддовке все его минусы для разработки прикладного софта, например cargo, становятся большими плюсами.

Но у него довольно внушительная стандартная библиотека и есть еще рантайм нагрузка

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

Я и на си могу написать все нужные мне функции. И тогда действительно разница сводится к тому, что передавать this или нет.

А зачем тогда нужны плюсы?

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

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

Надо писать на аде. Точнее, на SPARK, но кодить с формальной доказухой и верификацией могут не только лишь все, мало кто :) поэтому платиновые набросы все про плебейский выбор между сортами сишек-плюсишек в наколенном «эмбеде» и пионерскими «убийцами сишек», обреченными переизобретать аду (как растишка)... и оберон(как go).

Не используйте HAL, это костыль-переросток. Есть много других адекватных вариантов для STM. Что угодно будет лучше, чем HAL, хоть своя собственная реализация. Когда чтобы помигать лампочкой нужно 20 файлов которые макаронно друг на друга завязаны- это п-здец.

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

«Ну, не надо передавать ссылку на self в функции для работы со структурами».

Можно ещё интерфейсы использовать без возни с ручным заполнением vtable. Но это если в прошивке что-то должно конфигурироваться в рантайме.

Я и на си могу написать все нужные мне функции. И тогда действительно разница сводится к тому, что передавать this или нет.

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

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

закажи стм с большим размером флеша, у них обычно на один тип проца+окружение идет небольшой разброс онбоардных флешек.

В эмбеддовке все его минусы для разработки прикладного софта, например cargo, становятся большими плюсами.

Как же карго из программы, которая тянет половину пакетов из crates.io, аля npm, становится плюсом?

Да, про HAL я это уже понял – испытал на своей шкуре.

Так в изделии же заложен определенный МК, так то я уже выкрутился из этой ситуации.

А так-то сейчас уже имеет писать на rust. В эмбеддовке все его минусы для разработки прикладного софта, например cargo, становятся большими плюсами

В нормальном эмбеде, не в том где «поскорее вбросить», а в том где важнее пруфнуть годность и надежность, cargo и прочий модный карго-культизм директивно повыключают «профилем для критичных применений», как ravenscar в аде или misra в сишке-плюсишке :)

Плюс у С++ существуют проблемы с контролем переаллокации если бездумно использовать стандартные типы типа std::string. Памяти не так много, чтобы позволять ей фрагментироваться.

std::string на жестком эмбеде никто не пользует. пользуют обычную сишную строку и живут хорошо.

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

С++ > C > ASM

Пусть сначала рантайм напишет, а потом обгоняет.

И чего тогда мелочиться? Если железка способная, то почему б не вкорячить в ядро ARC, тогда пишем хоть на Swift и обгоняем кого угодно.

Ну любят некоторые люди глупые условия ставить, что с того то? Скоро отомрет, и можно будет не заниматься ерундой, а писать ПО для АЭС на node.js с npm, ада и фортран тому пример, новый код преимущественно на c++, дальше и его заменят новые языки.

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

А выделяторы не отвалятся?

Как понять выделяют? Речь вообще о каком режиме, защищённом? Тогда как понять всю что есть? Если в защищенном режиме доступно больше, чем есть.

Пусть сначала рантайм напишет, а потом обгоняет.

если поотключать всякую дурь навроде rtti, исключений, и stdlib, то рантайм для плюсов состоит из примитивного кода, самый сложный кусок из которого - менеджер кучи. остальное там строк 200-300, на тех же плюсах.

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

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

Нененене, дэвидблейн :) не скоро. Примерно никогда :) т.к. регуляторы не позволят и стандарты типа DO-178. А формальная доказуха это не «глупые условия», а именно пруфы. Ада и фортран никуда не делись (у ады стандарт новый на подходе). В домен-специфик областях нет никакого пускания слюней на «новый код», а вопросы какое новое знание создается переписыванием работающего кода на «плюсишки» и «модные языки», если переписывающие не знают предметной области.

Как понять

Начни с основ. Разберись как работает моск :)

Ада и фортран никуда не делись

Фортран заменен на С++, Python в науке

Ада заменена на C++

Конечно где то это используют, но меньше и меньше, в общем Cobolные язычки.

Примерно никогда :)

Да, ведь мир никогда не меняется. Как раньше писали на ассемблере, так и будут.

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

Да обычно - для эмбеддовщины, в отличие от прикладухи, тебе никогда не нужны зависимости от системы, но при этом нужно зависимости менеджить. Именно это cargo и делает.

На ржавом писать надо, во

А выделяторы не отвалятся?

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

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

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

с/c++
Возможно и rust когда-нибудь появится, хоть он и жирноватый, управление памятью там вполне может подойти под встройку, был бы подходящий рантайм

Фортран заменен на С++

Пытались заменять коммерсанты от науки, физики плевались от результатов и продолжают юзать фортран

Python в науке

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

Ада заменена на C++

Очередной маркетинговый булшит. Именно эта попытка замены с обмазыванием misra плюсишкой источник многочисленных проблем программы JSF/F-35.

Да, ведь мир никогда не меняется. Как раньше писали на ассемблере, так и будут.

Эволюционные изменнения имеются, революции только в головах хайпожоров.

Менеджер кучи наверно придется адаптировать под работу без ОС.

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

в c++ тут ключевое что не тащить его рантайм, а использовать лишь язык. Тебе не нужен STL чтобы писать на c++, нужна 1-2 внутренних функции компилятора и по желанию operator new/delete

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

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

Менеджер кучи наверно придется адаптировать под работу без ОС.

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

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

Окей. Придется от многого отказаться в С++. Что в итоге от него останется? И зачем оставлять это «что останется»? Чтобы что? Чтобы было? Ради самого факта?

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

не придется ничего писать. все написано 20 лет назад и надо просто все взять с интернета. 20 лет назад да, писали. а сейчас - только в порядке развлечения.

потому что эмбед пишут на плюсах давно и прочно, и все наработано.

Так и на си все это есть. Тоже все наработано. И даже больше.

в синтаксическом сахаре и шаблонах. В c++ ты можешь описать такие вещи как конструктор перемещения (stl для этого не нужен, ты можешь сам реализовать reference wrapper), есть constexpr, концепты. можно в каких-то случаях заменить генератор и макросню щаблоном.
Ничего принципиально нового это конечно не даст - всё это можно сделть на си с каким-нибудь внешним препроцессором, разые что в некоторых случаях c++ код компилятору будет проще оптимизировать.

Ну, я на плюсах эмбежу. Главное — виртуальные деструкторы не забывать определять, чтобы память не текла при динамическом выделении (хотя по MISRA динамика вообще не дозволяется, но, если очень надо…)

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

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