Используйте подходящий инструмент для задания: встроенное программирование

Question

Я заинтересован в языках программирования, хорошо подходящих для встроенного программирования. В частности:

Возможно ли программировать встроенные системы на C++? Или лучше использовать чистый C? Или C++ OK, только если некоторые функции языка (например, RTTI, исключения и шаблоны) исключены?

Что относительно Java в этом домене?

Спасибо.

Answer 1

Возможно ли программировать встроенные системы на C++?

Да, конечно, даже на 8-битных системах. C++ имеет несколько иные требования к инициализации во время выполнения, чем C, поскольку перед вызовом main() создаются конструкторы для любых статических объектов. Накладные расходы (не включая сами конструкторы, которые находятся под вашим контролем) для этого крошечные, хотя вы должны быть осторожны, так как порядок строительства не определен.

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

Или лучше использовать чистый C?

Возможно, в некоторых случаях. Некоторые более мелкие 8 и даже 16-битные цели не имеют компилятора C++ (или, по крайней мере, не являются какими-либо репутациями), использование кода C даст большую переносимость, если это будет проблемой. Более того, при ограниченных ресурсах с небольшими приложениями преимущества, которые C++ может принести C, минимальны. Дополнительные возможности на C++ (в первую очередь те, которые позволяют ООП) делают его подходящим для относительно большой и сложной разработки программного обеспечения.

Или C++ OK только если некоторые особенности языка (например, RTTI, исключения и шаблоны) являются исключены?

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

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

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

Я всегда рекомендую копаясь в архивах Embedded.com на любой вложенным предмет, он имеет множество статей, в том числе ряд только этот вопрос, в том числе:

• Poor reasons for rejecting C++
• Real men program in C
• Dive in to C++ and survive
• Guidelines for using C++ as an alternative to C in embedded designs
• Why C++ is a viable alternative to C in embedded systems design
• Better even at the lowest levels

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

[править] Concidentally Я только что получил это в бюллетене TechOnline: Using C++ Efficiently in Embedded Applications

Answer 2

Чаще всего во встроенных системах язык, на котором вы программируете, определяется тем, какой компилятор действительно доступен.
Если у вас аппаратное обеспечение, есть компилятор C, вот что вы собираетесь использовать. ЕСЛИ он имеет достойный компилятор C++, чем нет причин предпочитать C над C++.
Я бы посмел сказать, что Java не очень популярный выбор во встроенных системах.

Answer 3

Оба C и C++ могут использоваться во встроенных системах. Если вы ограничиваете возможности C++, которые вы используете, тогда он будет использовать примерно ту же скорость и пространство, что и C. Что касается использования этих дополнительных функций, это действительно зависит от ваших ограничений. Например, если вы создаете систему в режиме реального времени, исключения могут быть не очень хорошей идеей, просто потому, что, учитывая время распространения для исключений и все пути, через которые могут распространяться исключения, могут сделать жесткие гарантии в реальном времени довольно жесткими (хотя, опять же, реализация CORBA в режиме реального времени ACE/Tao использует исключения). Хотя шаблоны и RTTI могут привести к более крупным программам, во встроенных системах много изменчивости, и поэтому в зависимости от ваших ограничений ресурсов это может быть совершенно нормально или неприемлемо. То же самое касается Java. Java (ну, технически, язык программирования Java с подмножеством Java API) работает на Android, например, используя VM Dalvik. J2ME работает на различных встроенных устройствах. Будет ли он работать или не будет работать для вашего приложения, зависит от ваших конкретных ограничений.

Answer 4

c - наиболее распространенный язык, используемый во встроенных системах.

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

Answer 5

Встраиваемые программы в настоящее время охватывают широкий спектр приложений.
Грубо, он идет от датчиков/переключателей до полных систем безопасности.
Вы должны основывать свой язык на сложности и аппаратных ресурсах.
Это один из вариантов рядом с HW (CPU, ...), ОС, протоколы, ...
возможные варианты:

• переключатели: ассемблер
• маршрутизатор типа устройств: C и/или C++
• наладонник: Java или QT/C++
• полных систем: комбинации C и/или C++ с питоном

Answer 6

Это действительно сводится к тому, что аппаратной платформе вы ОПУ рейтинг и, следовательно, какие программные платформы открыты для вас. Для большого количества недавно встроенного набора, разработанного вокруг системы на кристалле, мегабайта или двух оперативной памяти, нескольких устройств, вы действительно хотите, чтобы небольшая операционная система управляла оборудованием низкого уровня, когда вы концентрируетесь на своем приложении.Ваш выбор ОС затем ограничивает доступный набор языков.

Возможно использовать C++ во встроенном пространстве, но полный набор функций требует много работы для правильного порта. Например, eCos реализован в смеси C и что вы можете назвать структурными аспектами C++; поддержка RTTI, исключения и STL отсутствуют в бесплатной версии, хотя есть люди, работающие над этим (и доступный коммерческий порт).

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

Answer 7

Или C++ OK только если некоторые особенности языка (например, RTTI, исключения и шаблоны) исключены?

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

С ++ облегчает класс/пространство имен модульности (например метод foo() более чем в одном контексте) и модульность экземпляра (поле членом bar, принадлежащее к более чем одному объекту), оба из которых являются большим преимуществом в разработке программного обеспечения. Существуют также такие функции, как const, ссылки, статические приведения и шаблоны, которые могут помочь в обеспечении ограничений и почти не требуют затрат времени исполнения.

Я бы не исключая шаблоны. Они сложны в том, чтобы думать, и вам нужен компилятор, который хорошо их обрабатывает, но стоимость ресурсов - это почти все время компиляции - то, что будет стоить вам, - это тот факт, что каждый раз, когда вы используете шаблон с разными параметрами класса, вы создаете новый набор кода для создания экземпляров функций-членов. Но вам почти наверняка придется делать то же самое без шаблонов. Кроме того, шаблоны позволяют создавать и тестировать библиотеки для общих обстоятельств, в отдельных файлах, которые создаются во время компиляции, а не времени ссылки. Просто уточнить, что: шаблоны позволяют вам иметь файл A.h, который вы тестируете. Затем вы используете его с файлом B.h или B.c для его экземпляра во время компиляции. (Библиотека будет связана, а не скомпилирована, и это делает ее менее гибкой - методы шаблонов могут быть оптимизированы, поэтому они не будут выполнять вызов функции.) Я использовал шаблоны во встроенных системах для реализации кода CRC и исправления, point math: я могу проверить общий код, поместить его в управление версиями, а затем повторно использовать его несколько раз, написав простой класс, который происходит из шаблона или имеет поле члена шаблона. Классическим примером, конечно же, является STL.

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

виртуальные функции: Я использовал, чтобы исключить их из-за затрат памяти + executiontime (минимальные, но все же есть), а также сложность отладки, но они позволяют отделить объекты друг от друга. Если вы не используете виртуальные функции, когда экземпляр одного класса (например, Foo) должен выполнить код, связанный с экземпляром другого класса (например, Bar), тогда первому классу нужно знать все о втором (компилировать Foo вам нужно иметь статическую привязку ко всем методам в Bar) - это добавляет много жесткой связи.

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

---

редактировать: Я бы любовь использовать Java вместо C++ во встроенном мире. К сожалению, мои варианты ограничены, а затраты ресурсов времени выполнения (размер кода, размер памяти, ограничения времени сбора мусора) слишком высоки в пространстве, в котором я работаю. Моя причина для использования Java меньше из-за его свойств времени выполнения и больше для факт, что его дизайн программного обеспечения намного чище, а инструменты намного лучше (OMG! refactoring! woohoo!) ... ключ ко мне, похоже, лежит в двух вещах, что делает C/C++ очень неудобным в сравнении:

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

2. Разделение интерфейса/реализации в Java не является этим неуклюжим уродливым .c/.h файлом, делящим вещи, что делает компиляторы такими медленными. В constrast я использую Java в Eclipse, и он автоматически компилирует код, когда я его редактирую. Это огромно! Я нахожу большинство своих ошибок сразу. В C/C++ я должен ждать целого цикла компиляции.

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

Answer 8

Я думаю, что у вас уже есть отличный ответ Клиффорда, но я добавлю свой опыт. Как уже указывалось, основным элементом является встроенная система. В Defense/Aerospace C и Ada - самые популярные встроенные языки, с которыми я сталкиваюсь. Хотя со временем я вижу больше C++, поскольку основанная на модели разработка становится популярной среди таких инструментов, как Rhapsody. В списке вакансий видение требований к объектно-ориентированному дизайну также заставляет меня поверить, что рынок медленно переходит, чтобы следить за тенденциями основного развития.

Если вы действительно заинтересованы в встроенной разработке, я бы начал с C. Это довольно универсально. Почти каждая ОС, в том числе ОС реального времени, такие как Integrity, Nucleus, VxWorks и встроенная Linux, имеет для нее компилятор и инструменты. То, что вы узнаете о указателях, управлении памятью и т. Д., Будет, по крайней мере, переводиться на C++-разработку во встроенном мире.

Что касается Java, если вы заинтересованы в разработке мобильных платформ, таких как смартфоны, это отличный выбор (Android приходит на ум). Но в мире операционных систем реального времени я этого не видел.

На этой ноте это приводит меня к моему последнему пункту и совету. Если бы я хотел перейти в встроенное программирование (что я сделал всего 4 года назад), я бы сосредоточился на изучении C с точки зрения низкого уровня, как упомянуто выше. Затем я также узнал, что делает программирование в реальном времени таким сложным/разным. Я нашел книгу, которая достаточно хороша, чтобы научить вас думать как встроенный программист против разработчика приложений. Удачи!

An Embedded Software Primer