Чи буде можливість у майбутньому писати код у C ++ для мікроконтролерів PIC?

Чи коли-небудь можна буде використовувати C ++ для кодування PIC? Чи є якісь апаратні обмеження, які заважають нам використовувати C ++? На скільки збільшується розмір генерованого .hex-файлу та час роботи програми, коли ми використовуємо C ++ замість C? Чи практично можливо використовувати C ++ для поточних ПІК? Чи є якісь плани на майбутнє чи поточний розвиток щодо цього?

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

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

Інший варіант - використовувати перетворювач C ++ до C. Використовуючи крок попереднього збирання, перетворіть C ++ на C, а потім переведіть (неприємно виглядає) C у звичайний компілятор C. Погляньте на LLVM або компілятор C ++ Comeau, які обидва роблять це. Кома коштує лише 50 доларів, але, мабуть, знадобиться певні зусилля, щоб весь ланцюжок інструментів і бібліотеки працювали належним чином.

Чи є якісь апаратні обмеження, які заважають нам використовувати C ++?

Коротка відповідь, ні, обмежень щодо апаратних засобів немає. Якщо відповісти, C ++, безумовно, заохочує використання купи та / або стека, з яким будуть боротися менші MCU з обмеженою оперативною пам’яттю.

Чому вони борються з купою / стеком? З двох причин: A) багато MCU мають обмежену оперативну пам'ять, звичайно, недостатньо для купи, і ледве достатньо для стека. Б) багато MCU не працюють з покажчиками добре, тому використання змінних на стеку дійсно вбиває продуктивність.

Коли люди запитують про використання 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?

Як я вже сказав, різниці може бути і немає. Bjarne Stroustrup зіставив купу компіляторів C / C ++ для порівняння продуктивності часу та простору для ряду операцій. Результати були різними. У деяких випадках C ++ виходив повільніше і більше, в деяких випадках повільніше і менше, або швидше і більше, а ще швидше і менше! Отже, відповідь на ваше запитання полягає в тому, що це сильно залежить від компілятора, але в цілому, це взагалі не має значення. Більш детально див. Технічний звіт щодо продуктивності C ++

Чи є якісь плани на майбутнє чи поточний розвиток щодо цього?

Що я не знаю. Я знаю, що компілятор Microchip C32 відкритий, і ви можете завантажити джерело. Я також знаю, що хтось, з ким я працював, насправді знайшов в Інтернеті деякі вказівки і вдалося змусити компілятора зібрати код C ++. Але він покинув компанію ще до того, як зміг налагодити мене належним ланцюжком інструментів.

ОНОВЛЕННЯ

Microchip тепер має компілятор C ++ для своєї серії вбудованих MCU.

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

Залежить від того, які функції ви використовуєте. Якщо ви використовуєте основні об'єктно-орієнтовані функції (клас + методи), швидше за все, вони матимуть дуже незначний ефект (імена змінених змін / функцій довші, тому таблиця символів, ймовірно, дещо збільшиться). Шаблони також не повинні додавати багато з хорошим компілятором.

Якщо ви з глузду з’їхали і втягуєте в себе такі речі, як Бібліотека стандартних шаблонів, і використовуєте динамічне розподілення пам’яті та винятки, то ви, ймовірно, зіткнетеся з роздувом коду.

У Pic вже є компілятори c ++, наприклад, http://www.sourceboost.com/Products/BoostCpp/Overview.html

Я цього не використовував і нічого про нього не знаю, крім того, що існує ...

Дещо узагальнивши своє запитання, існують процесори ARM, створені для вбудованого ринку, які містять MMU (блок управління пам'яттю). Розмір пам’яті та розподілення пам’яті зробили такі мови, як java та c ++ поганий вбудований вибір. Оскільки вбудовані процесори продовжують ставати швидшими та потужнішими, а оскільки пам'ять стає все щільнішою і дешевшою, вибір мови, доступний вбудованим інженерам, різко змінюється. 32-розрядний процесор ARM з частотою 600 МГц з MMU та 64G флеш-карткою є прекрасним кандидатом для додатків c ++. Чи відповідає воно визначенню класичного вбудованого процесора - інше питання.

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

• якщо ви знаєте, як використовувати функціональні покажчики тощо. Ви можете кодувати, як C ++, там немає жодної проблеми.