Будет ли возможно написать код на C ++ для PIC микроконтроллеров в будущем?

8

Будет ли когда-нибудь возможно использовать C ++ для кодирования PIC? Существуют ли какие-либо аппаратные ограничения, которые мешают нам использовать C ++? Насколько увеличивается размер сгенерированного файла .hex и время выполнения программы, когда мы используем C ++ вместо C? Возможно ли практически использовать C ++ для текущих PIC? Есть ли какие-либо планы на будущее или постоянное развитие в этом направлении?

hkBattousai
источник
Я думаю, что это возможно и останется возможным, но AFAIK не рекомендуется, поскольку он реализует высокоуровневые структуры и функции, которые не подходят для сильно аппаратного программирования
clabacchio
3
Для обсуждения пригодности - electronics.stackexchange.com/questions/3027/…
Тоби Джаффи
2
Поскольку ответ «Да, компиляторы C ++ уже существуют», я собираюсь оставить это в силе, но в будущем вы должны знать, что вопросы Stack Exchange должны касаться проверяемых фактов, а не предположений о будущем.
Кевин Вермеер
2
@clabacchio: не обязательно правда. В C ++ вы платите только за то, что используете. Смотрите мой ответ по адресу: electronics.stackexchange.com/questions/3027/…
Ракетный магнит
«ПИК» - бесполезное обобщение. На некоторых low-end PIC (например, 10F200) C практически невозможно использовать. На некоторых высокопроизводительных PIC (серии 32MX), по слухам, C ++ будет использоваться прямо сейчас, и, безусловно, нет технической причины, по которой он не может. Таким образом, некоторая лучшая фокусировка может дать более полезный ответ, в настоящее время каждый фактически отвечает на другой вопрос.
Wouter van Ooijen

Ответы:

17

Будет ли когда-нибудь возможно использовать C ++ для кодирования PIC?

Да, это возможно сейчас. Для dsPIC есть компилятор IAR Systems C ++ (хотя он очень старый и не поддерживается).

Другой вариант - использовать конвертер C ++ в C. Используя шаг перед сборкой, преобразуйте C ++ в C, затем передайте (неприятно выглядящий) C обычному компилятору C. Взгляните на LLVM или компилятор Comeau's C ++, которые оба делают это. Comeau's стоит всего 50 долларов, но, возможно, потребуется некоторое усилие, чтобы весь инструментарий и библиотеки работали должным образом.

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

Короткий ответ, нет, аппаратных ограничений нет. Длинный ответ, C ++ определенно поощряет использование кучи и / или стека, с которыми будут бороться меньшие микроконтроллеры с ограниченным объемом ОЗУ.

Почему они борются с кучей / стеком? По двум причинам: A) многие микроконтроллеры имеют ограниченную оперативную память, которой явно недостаточно для кучи и едва хватает для стека. Б) многие микроконтроллеры плохо обрабатывают указатели, поэтому использование переменных в стеке действительно снижает производительность.

Когда люди спрашивают об использовании C ++ на MCU, я считаю, что конструктивно сравнивать C ++ с C. Точно такие же вопросы задавались (и остаются) по поводу C на MCU. Люди возражали против этой идеи. Язык высокого уровня, на 256-байтовой памяти MCU ?? Невозможно. Но теперь мы все знаем, что это возможно. Я написал C для PIC12. Нет проблем. Это возможно, потому что A) разработчики программного обеспечения знают, что они должны быть немного осторожнее: не используйте malloc () и т. Д. И B) компилятор был написан специально для MCU. Компилятор также будет очень осторожен с распределением памяти, он не будет пытаться создать кучу и может не создавать стек. Некоторые компиляторы C просто не позволяют писать реентерабельный (рекурсивный) код, для которого абсолютно необходим стек.

Зная, что можно написать C для MCU, те же ответы применимы к вопросу написания C ++ на MCU. Пока компилятор понимает ограничения целевого устройства, а пользователь также понимает язык, проблем на самом деле нет. В C ++ вы платите только за то, что используете. Вполне возможно написать C ++ (с объектами и всем остальным), который производит точный вывод asm, который вы получили бы, если бы использовали C.

Теперь PIC32, безусловно, может справиться с C ++. Они имеют до 64 КБ ОЗУ и основаны на ядре MIPS, которое является правильно выращенным 32-разрядным процессором. Он может иметь дело с указателями и стеком, а также с ПК. Действительно, есть компьютеры на базе MIPS (или, по крайней мере, раньше).

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

Насколько увеличивается размер сгенерированного файла .hex и время выполнения программы, когда мы используем C ++ вместо C?

Как я уже сказал, не может быть никакой разницы. Бьярн Страуструп провел сравнение группы компиляторов C / C ++, чтобы сравнить производительность по времени и пространству для ряда операций. Результаты сильно различались. В некоторых случаях C ++ выходил медленнее и больше, в некоторых случаях медленнее и меньше, или быстрее и больше, и даже быстрее и меньше! Итак, ответ на ваш вопрос заключается в том, что он сильно зависит от компилятора, но в общем случае это вообще не должно иметь никакого значения. Для получения дополнительной информации см. Технический отчет о производительности C ++.

Есть ли какие-либо планы на будущее или постоянное развитие в этом направлении?

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


ОБНОВИТЬ

Теперь у Microchip есть компилятор C ++ для его встроенного микроконтроллера PIC32.


Rocketmagnet
источник
с веб-страницы IAR: «Устаревший продукт: IAR Embedded Workbench для dsPIC является устаревшим продуктом. IAR Systems не обновляет его, и для него невозможно приобрести Соглашение о поддержке и обновлении».
Джейсон С
Я знаю, что продукты IAR великолепны, но, к сожалению, очень дороги и кажутся «старыми». Я знаю, что C ++ возможен на любой платформе, если вы не используете все функции. Тем не менее, это добавляет возможность для дополнительного уровня абстракции с классами. Я не часто использую шаблоны, а также не использую динамическое распределение памяти вообще. Кто-нибудь случайно знает другого конкурента C ++ на PIC24 / PIC32?
Ганс
Да, извините, это была не очень хорошая находка. Позвольте мне добавить еще несколько вещей к моему ответу.
Ракетный магнит
1
Я бы посчитал C конкурентом для C ++ на микроконтроллере. Я не могу думать о том, что я хотел бы сделать в C ++, что я не могу сделать в C, и там меньше вызовов невидимых функций (конструкторы, деструкторы и т. Д.). Делает код более детерминированным и простым. Какие особенности C ++ являются обязательными, которые нельзя обойти с помощью C?
AngryEE
1
Кто-то может спросить: «Какие особенности языка С должны быть непонятными в ASM?» Ответьте: «Ничего». Преимущества - расширенные возможности дизайнера определять дизайн и компилятор проверяет правильность реализации. См. Мой ответ electronics.stackexchange.com/questions/3027/… для получения списка реальных и непосредственных преимуществ C ++ в этом отношении.
Ракетный магнит
5

Насколько увеличивается размер сгенерированного файла .hex и время выполнения программы, когда мы используем C ++ вместо C?

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

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

Джейсон С
источник
Просто предупреждая об OP, будьте очень осторожны с распределением памяти на небольших архитектурах памяти и встроенных постоянно работающих системах.
Кенни
Может ли "-1" прокомментировать, почему он / она не согласен?
Джейсон С
Я не -1er, но шаблоны - это функция, которую нужно использовать с большой осторожностью, чтобы избежать раздувания кода. Вы можете легко получить множество копий алгоритма, когда этого будет достаточно.
Питер Грин
Для этого вам действительно придется использовать шаблон с несколькими различными типами данных, и одной копии НЕ БУДЕТ достаточно, если вы не используете полиморфный код, имеющий общий базовый класс. (В этом случае затраты времени выполнения.) Шаблоны магическим образом не вызывают вздутие вашего кода, они вызывают раздутый код только тогда, когда вы используете их с несколькими типами данных, когда вы не знаете о последствиях.
Джейсон С.
1

Несколько обобщая ваш вопрос, есть процессоры ARM, созданные для рынка встраиваемых систем, которые содержат MMU (блок управления памятью). Объем памяти и распределение делали такие языки, как java и c ++, плохим выбором. Поскольку встроенные процессоры продолжают становиться быстрее и мощнее, а память становится более плотной и дешевой, выбор языка, доступный для инженеров по встраиванию, резко меняется. 32-разрядный процессор ARM с тактовой частотой 600 МГц с MMU и картой памяти 64G является отличным кандидатом для приложений c ++. Подходит ли он под определение классического встроенного процессора - это другой вопрос.

spearson
источник
0

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

  • если вы знаете, как использовать указатели на функции и т. д. Вы можете кодировать как C ++, там нет никаких проблем.
Ktc
источник
5
Позволю себе не согласиться. Вы можете использовать многие функции C ++ (классы, шаблоны, перегрузка операторов, ссылки) практически без затрат времени выполнения. Да, вы можете делать все это в простом C с помощью хакерских конструкций, но это затягивает мозг, и я бы предпочел использовать C ++. (конечно, я бы предпочел использовать лучший язык, но я бы выбрал компилятор C ++ в мгновение ока над простым C.)
Jason S
1
Classes = structs (без встроенных методов, но, если хотите, вы можете сохранить указатель на функцию в структуре и вызвать ее). Шаблоны = вы используете те ??? Перегрузка оператора = да, я бы тоже этого хотел. Ссылки = указатели, нет? По крайней мере, с C вы можете использовать только те «возможности» C ++, которые вам нужны, не беспокоясь о лишней генерации кода или необходимости включать случайную большую библиотеку, чтобы получить что-то для компиляции.
AngryEE
1
Я также позволю себе не согласиться.
Ракетный магнит
3
Да, шаблоны - это чрезвычайно мощный способ создания надежного и высокопроизводительного кода. Ссылки являются более надежным указателем. С C ++ вы также платите только за те функции, которые используете. Я думаю, вам действительно нужно больше понимать C ++.
Ракетный магнит
3
Я не знаю, что вы подразумеваете под "C - это язык вложений". Конечно, это очень популярно. Вы говорите, что это лучший язык? Конечно нет.
Ракетный магнит