Почему Embedded Strictly C / C ++ [закрыто]

Мне не понравился этот вопрос, так как на него нелегко ответить, но, возможно, я могу перефразировать: «Что мешает Embedded менять языки?»

Например, мы в значительной степени видим C / C ++ для встроенных (я думаю, что я уже слышал об ADA, упомянутом ранее? Поправьте меня, если я ошибаюсь)

Но что именно удерживает мир Embedded от смены языков? Это просто, что C слишком прост в использовании или просто нет «необходимости» для изменений, так как C все делает хорошо?

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

Я понимаю, что это своего рода субъективный вопрос, однако, мой главный вопрос - «Почему», а не «ЕСЛИ / КОГДА»

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

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

• Большинство «недавних» новых разработок в языках заполняют разрыв между доступной мощностью процессора и потребностями пользователя. Другими словами: они могут быть неэффективными по скорости, но компенсируют это, облегчая работу программиста. Подумайте о появлении таких языков, как Java, Python, Perl, Tcl, которые в основном выполняются интерпретатором (возможно, после некоторой компиляции) и активно используют динамическое управление памятью. Но это плохо согласуется с миром с ограниченными ресурсами, где мы хотим получить а) максимальную отдачу от доступных ресурсов даже за счет больших усилий по программированию и б) предсказуемое использование ресурсов.

• C и C ++ (или подходящее подмножество) по-прежнему являются языками высшего уровня, которые широко используются (достаточно, чтобы были доступны хорошие инструменты, достаточное количество обученных программистов и обширные библиотеки), которые могут удовлетворить предсказуемые требования к пространству и времени, которые не так уж и велики. из того, что возможно на текущем оборудовании. Я думаю, что единственным претендентом на это является Ада, но она пострадала от неудачного начала: первые реализации были (воспринимаются как?) Слишком медленными и неэффективными, и теперь (хотя хорошие реализации доступны) язык немного отстал в особенности (по сравнению с C ++). Лично я думаю, что это жаль, при прочих равных условиях я предпочел бы летать на самолете, который запрограммирован в Аде, чем тот, который был сделан в C или C ++.

Благодаря встроенным системам на основе 8- и 16-разрядных микроконтроллеров становится проще разрабатывать программное обеспечение, которое может вписаться в ограниченные ресурсы этих очень скромных ограничений хранилища (возможно, несколько 100 байт ОЗУ для низкоуровневых 8-разрядных микроконтроллеров , с 2-8 КБ ROM или EPROM / Flash для хранения кода).

В этих случаях небольшие языки, такие как C или ассемблер, как правило, являются наиболее часто используемыми языками разработки. В качестве очень грубого относительного сравнения, полный ассемблер и компилятор C99 могут поместиться на одну дискету, в то время как для современной системы разработки C ++ (с STL и т. Д.) Вам понадобится несколько MiB .

Когда вы смотрите на высокопроизводительные микросхемы (высококлассные 16-битные, и в основном 32-битные, с довольно редкими 64-битными) и DSP во встроенных средах, тогда ограничения ослабляются, и разработка программного обеспечения может составлять основную часть разработки усилия, поэтому имеет смысл использовать самые продуктивные инструменты разработки, включая более продвинутые языки с такими функциями, как языки объектно-ориентированного программирования (ООП), такие как C ++, и более новые языки (Java, Perl, Ruby, Python).

В ассемблере и C можно предсказать, сколько памяти будет использоваться, так что проект с ограниченным пространством возможен, но расширенные функции, такие как шаблоны, обработка исключений и привязка во время выполнения, не позволяют точно знать необходимый объем памяти. заранее для стандартной программы на С ++. Я недостаточно знаю о MISRA C ++ , который является подмножеством C ++, чтобы комментировать его.

Языки, основанные на виртуальных машинах, на которых выполняется байт-код (Java, Perl, Python), являются менее зрелыми в опыте разработчиков встраиваемых систем, и поскольку эти языки предназначены для изоляции программиста от конкретного оборудования, это также усложняет понимание совести. такие встроенные аппаратные ограничения системы и ограничения. Это не проблема для быстрых 32-битных процессоров (например, ARMv7) с MiB, если не GiB RAM.

Все известные мне реализации BASIC довольно упрощены по языковым возможностям, оставаясь в значительной степени верными наследию Dartmouth BASIC 1960-х годов. Это означает, что язык не имеет каких-либо сложных библиотек времени выполнения или обработки исключений, а интерпретатор или компилятор довольно прост в написании и также имеет небольшой размер файла. Большинство микроконтроллеров имеют по крайней мере один базовый компилятор для него.

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

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

Дело не в том, что «C - плохой или устаревший выбор, но мы все еще используем его по привычке» (как клавиатуры QWERTY).

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

• это достаточно низкий уровень, чтобы его можно было легко использовать для реализации программ в реальном времени. Если вам нужно измерить время в наносекундах, перехватывать прерывания каждые 5 микросекунд или использовать ровно 64 байта общего объема ОЗУ, то при использовании языка очень высокого уровня это будет либо невозможно, либо очень трудно решить. , C дает вам гораздо лучший контроль над оборудованием, чем языки более высокого уровня, это одно из самых важных различий между разработкой для встраиваемых и ПК.

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

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

Это та же самая причина, по которой в обычном программировании (наиболее используемые) языки (действительно) не меняются:

1. Огромное количество существующего кода (библиотеки / существующие реализации)
2. Большой набор инструментов, который может работать с этими языками (IDE, симуляторы, ...)

Во встроенном мире может быть намного сложнее (или невозможно) предоставлять обновления программного обеспечения, и поэтому все более важно гарантировать правильность. К сожалению, C очень мало помогает в этом отношении и позволяет программисту играть быстро и свободно.

Мне больно использовать C для встраиваемых систем, и мне хотелось бы, по крайней мере, перейти на C ++ для многих преимуществ, которые он предоставляет в виде ограничений, таких как const, ссылки, тип stringer и т. Д.

Я думаю, ответ прост: мы застряли с C, потому что изменение не является коммерчески жизнеспособным. Все знают C, есть множество компиляторов для него, библиотеки для него и инструменты для его генерации. С новым языком мы бы начали с нуля.

Я думаю, именно поэтому люди все еще используют PHP .

Здесь никто не слышал о SPARK Ada?

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

Исследования показали, что скорость обработки составляет всего 5-10% по сравнению с C / C ++ с более надежным кодированием SPARK.

Я думаю, что распространение C во встроенных системах связано с экономическими причинами:

• Он уже есть и обычно работает для большинства приложений - и большинство приложений по объему некритичны, никто не умрет, если стиральная машина перегружается - так зачем менять?

• Набор инструментов SPARK станет дополнительным расходом сам по себе и для обучения персонала его использованию.

• Дополнительные преимущества SPARK (или других языков, отличных от C) для встроенного контроллера / системы управления могут оказаться недостаточными, чтобы оправдать необходимую премию в цене продукта в глазах потребителя, особенно когда они видят, что «хорошие» конкурирующие бренды продают по более низкой цене.

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

Итак, @ Wouter, вам не нужно беспокоиться о смерти в небе из-за отсутствия встроенного кода Ada!

Это уже в системах самолета в течение многих лет. Аналогично для вашего кардиостимулятора.

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

Я предполагаю, что главная причина популярности C заключается в том, что, во-первых, C популярен, и многие его знают, и, во-вторых, ни один из новых популярных языков, таких как Java, C # и даже многие аспекты C ++, не подходит для работы со встроенными системами. В основном три других языка, о которых я упоминал, во многом зависят от динамической памяти, которая приводит к недетерминированному выполнению программы с ней, объектов, которые несут с собой динамическую память, больших требований к памяти (поскольку одной из наиболее важных сторон ОО является использование большее количество классов), растущая популярность своевременной компиляции (и многие встроенные платформы вообще не могут даже скомпилировать свой собственный код C) ...

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

С другой стороны, у нас есть более старые языки, такие как Pascal или Basic. С моей точки зрения, они не так популярны, потому что C сделал себя языком «отраслевого стандарта», и очень большое количество программистов и инженеров изучают C сегодня. В некоторых школах Паскаль или Базовый даже не изучены. Существует также тот факт, что многие популярные на сегодняшний день языки имеют C-подобный синтаксис, и использование Pascal может показаться странным для программиста на C.

Что касается FORTRAN, я полагаю, что он ушел в нишевую область и в основном используется инженерами и учеными, работающими в областях, где есть подходящая экосистема для его использования. Я не вижу какой-либо конкретной причины (кроме тех, что я упомянул для Pascal и Basic), что она не используется во встроенных системах.

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

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

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

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

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

Некоторые причины, по которым другие не упомянули:

• Пространство задачи: C подходит для небольших и простых систем. Если все, что вы делаете, это реагируете на внешние сигналы и нажимаете несколько цифр, то C работает довольно хорошо (без сложных структур данных, без malloc, без сложной обработки ошибок).

• Объем производства: если у вас большие производственные циклы, экономически целесообразно экономить на каждом аппаратном блоке и тратить больше на программистов, поскольку программирование является единовременной.

Я думаю, это потому, что C / C ++ - это языки самого низкого уровня.

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

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

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

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