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


15

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

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

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

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

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


2
Есть ли конкретный язык более высокого уровня, который вы хотели бы видеть во встроенных системах? РЕДАКТИРОВАТЬ: или, скорее, какие языковые функции вы заинтересованы в том, что С не предоставляет?
Джон Л

1
@JonL - Есть куча низкоуровневых функций, которые я бы хотел иметь в C. Например, лучше обрабатывать бит / клев / байт / слово в больших целых. Лучшая поддержка безопасности, например, типы функций, которые имеет Ада.
Ракетный магнит

3
Встраивание не является строго C. Вот несколько языков высокого уровня для встраиваемых систем: electronics.stackexchange.com/questions/3423/…
Kellenjb

1
«Встроенный» имеет разные значения. 4-битный микроконтроллер с тостером отличается от ЭБУ или телеприставки. Этот спектр затрудняет ответ на ваш вопрос.
Тоби Джаффей

1
И, как и ожидалось, это было закрыто. Я надеялся, что на этот вопрос будут получены качественные ответы, и люди будут работать над тем, чтобы этот вопрос был отличным, это не так. Вместо этого мы получаем много ответов, которые являются одним предложением, которое получает несколько голосов "за", у нас есть ответ, который является прозой, в которой идет война против голосовавших с флагами в изобилии, а другие ответы сгенерировали больше флагов за 1 день, чем остальная часть сайта вместе взятых , Проблема в том, что для многих людей есть много разных правильных ответов о том, почему они не изменились.
Кортук

Ответы:


18

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

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

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

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


+1 - хороший ответ. Ada кажется интересным языком, есть ли компиляторы Ada для маленьких микро?
Оли Глейзер

Есть GNAT, компилятор GCC Ada. Но AFAIK он не использовался много на микро, поэтому вам будет трудно найти что-то для чтения для запуска.
Воутер ван Ойджен

Да, я видел GNAT, упомянутый на вики-странице. Вы правы, не так много для маленьких микро, но, кажется, есть достаточная поддержка (как и следовало ожидать) для критически важных вещей на 68k, x86, MIPS и т. Д. (Например, DDCI )
Оли Глейзер

Я вижу, что есть SPARK Ada, как упомянуто Диком ниже. Я должен проверить это, когда у меня есть кое-что из того неуловимого материала, который они называют временем ...
Оли Глейзер,

2
Ада, в форме Гнат, прекрасно работает на микропроцессоре AVR, как видно на Arduino. Самый маленький исполняемый файл Gnat, который я построил, был 65 байтов. По общему признанию все, что это сделало, было мигать светодиодом, хотя эквивалентный эскиз Arduino был больше чем 1 КБ. К тому времени, когда мой исполняемый файл достиг 600 байт, он управлял 2-мя шаговыми двигателями независимо ... Вам не нужен SPARK - если только вы не хотите доказать, что ваш светодиодный индикатор мигает формально!
Брайан Драммонд

9

Благодаря встроенным системам на основе 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 и сборка в основном используются в небольших или старых встроенных системах, а ограничения новых встроенных систем среднего и высокого класса отличаются незначительно от традиционного настольного персонального компьютера.


5

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

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

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

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

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

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


1
Я думаю, что главный аспект в пользу C состоит в том, что он позволяет оптимизировать код для конкретной платформы, в то же время позволяя такому коду запускаться (возможно, не так эффективно) на других. На чем-то похожем на PIC многие инструкции на C будут предсказуемо преобразовываться в машинные инструкции; цикл вроде unsigned char i=63,j=128; do {something;} while(--j); while(--i);не будет таким же читаемым, как он unsigned int i=16000; do {something;} while(--i);, но он будет работать быстрее и будет более эффективным на PIC. Если бы код был перемещен в ARM, второй подход был бы более эффективным, но первый все равно работал бы.
суперкат

4

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

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

4

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

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

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

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

PHP двойной молоток.


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

Вы всегда можете использовать Pascal - похоже, у вас есть дополнительные ограничения, которые вы ищете :-). Или какая-то форма Супер-Линт.
Рассел МакМахон

2
Вероятно, очень существенная причина для C состоит в том, что НАМНОГО проще написать базовый компилятор C, чем компилятор C ++. Я работал над одним какое-то время, прежде чем меня ушли более важные задачи. Прикольные вещи! Написание компилятора C ++? Тьфу. Хотя я предпочитаю C ++ как пользователя.
Даррон

1
@RussellMcMahon - я не могу использовать Pascal, потому что для используемых MCU нет компилятора Pascal.
Ракетный магнит

@ Даррон - Это очень хороший момент. Однако есть очень хорошие компиляторы C ++ с открытым исходным кодом, такие как gpp. Им просто нужно написать бэкэнд для этого.
Ракетный магнит

4

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

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

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

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

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

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

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

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

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

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

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


Интересно, спасибо - я не слышал об SPARK, проверим это.
Оли Глейзер

Некоторые исследования показывают ускорение по сравнению с существующим приложением в C - посмотрите на DNS-сервер «Ironsides» ...
Брайан Драммонд

3

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

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

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

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

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


1
C популярен, потому что C популярен? :-)
stevenvh

2
@stevenvh Да, это правда. Это своего рода положительная обратная связь. Чем оно популярнее, тем популярнее оно становится.
AndrejaKo

3

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

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

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

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


3

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

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

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



1

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

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

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

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


4
C ++ может создавать большие накладные расходы, но полностью совместимый компилятор C ++, который я использовал для MSP430, не требовал времени выполнения, C ++ действительно компилировал в нативный код. Прошу прощения, я говорю другим, что это плохая услуга, и я вас обыграл. Вы можете удалить понижение, предоставив ссылки, которые убеждают меня в том, что я не прав (что будет сложно, я прочитал список сборок скомпилированного C ++ для своих проектов, чтобы убедиться, что он компилируется эффективно), или вы можете удалить свой ответ, который удалит влияние на вашу репутацию (хотя в этот момент вы получаете +8 чистых повторений)
Кортук

3
Я полностью согласен с Кортуком. Некоторые части C ++ требуют обширной поддержки во время выполнения, но часть, которая этого не делает, все еще намного лучше C (и полностью OO). Ограничение на это подмножество легко применяется некоторыми переключателями компилятора и компоновщика. В некоторых частях (например, страшный printf) C ++ обладает, по крайней мере, языковым потенциалом, требующим гораздо меньшей поддержки во время выполнения (если бы только std :: cout был реализован с учетом небольших систем ...)
Wouter van Ooijen

1
@Kortuk, извините за непонятность, но когда я сказал, что «C - единственный язык, который ...» не означал, что C ++ не имеет обе эти вещи, я имел в виду, что C имеет комбинацию двух и C ++ имеет один из них. Мой акцент был сделан на части времени выполнения. Я также не говорю, что использование C ++ без времени выполнения совершенно невозможно, но это довольно необычно. Я не понимаю, как у вас могут быть такие вещи, как обработка исключений и RTTI, например, без времени выполнения, и это довольно важные функции. Но я прошу прощения, если то, как я это выразил, привело к возможным заблуждениям.
fceconel

@fceconel, я никогда не использовал C ++ со средой выполнения, и мы обсуждаем здесь встроенные системы, я никогда не использовал среду выполнения на своих микроконтроллерах. Этот вопрос немного отличается от того, который вы, возможно, читали, он спрашивает, почему C / C ++ являются единственными распространенными вариантами, а не почему C вместо C ++. Я признаю, что использование чего-то такого простого, что cout никогда не произойдет в моем микро, у меня есть несколько свободных пинов, а не экран.
Кортук
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.