Чому вбудовано строго C / C ++ [закрито]

Мені це питання не сподобалось, оскільки на нього не можна легко відповісти, але, можливо, я можу перефразувати: "Що втримує Embedded від зміни мов?"

Наприклад, ми в значній мірі бачимо C / C ++ для вбудованих (я думаю, я раніше теж чув АДА? Виправте мене, якщо я помиляюся)

Але що саме утримує Вбудований світ від зміни мов? Це просто те, що C занадто простий у використанні або просто немає насправді "потреби" в зміні, оскільки C робить все добре?

Це завжди ніби мене бентежило, не те, що я нарікаю. Оскільки збереження його на кількох мовах зберігає речі стандартизованими. Але все ще залишається питання.

Я усвідомлюю, що це свого роду суб'єктивне запитання, однак моє головне питання "Чому", а не "ЯКЩО / КОЛИ"

Перш за все: забудьте про "вбудований", оскільки це не корисна відмінність. Найважливіша властивість - "обмежена ресурсами". Найважливішим ресурсом часто є час, і в цьому випадку ми говоримо про системи реального часу, але це також може бути пам'ять або потужність.

• Затвердження нової мови є важким і рідкісним. Це вимагає перепідготовки, нових інструментів та пошуку хорошого способу роботи з новою мовою. Це коштує дорого, особливо для раннього усиновлювача. Це також проблема з курячими яйцями: без великої бази користувачів не буде хороших інструментів та бібліотек, але без них не буде великої бази користувачів. Отже, нова мова повинна мати велику перевагу перед існуючою, інакше вона не матиме шансів.

• Більшість "останніх" нових розробок у мовах заповнюють розрив між наявною потужністю процесора та тим, що потрібно користувачеві. Іншими словами: вони можуть бути неефективними у швидкості, але компенсувати, легше програмісту. Подумайте про зростання таких мов, як Java, Python, Perl, Tcl, якими по суті керує інтерпретатор (можливо після деякої компіляції), і широко використовуйте динамічне управління пам’яттю. Але це не добре відповідає світу, обмеженому ресурсами, де ми хочемо отримати а) максимум використання наявних ресурсів, навіть за рахунок більше зусиль програмування, і б) передбачуваного використання ресурсів.

• C і C ++ (або підходящий підмножина) все ще є загальноприйнятими мовами найвищого рівня (достатньо, щоб були доступні хороші інструменти, достатньо підготовлених програмістів та широкі бібліотеки), які можуть відповідати передбачуваним вимогам щодо простору та часу, які далеко не далеко від того, що можливо на поточному обладнання. Єдиним претендентом є, я думаю, Ада, але це постраждало від поганого початку: перші реалізації були (сприймаються?) Занадто повільними та неефективними, а тепер (навіть якщо хороші реалізації доступні) мова трохи відстала в функції (порівняно з C ++). Особисто я думаю, що це шкода, а за інших рівних речей я б летів у літаку, який запрограмований на Ада, ніж той, що робився на C або C ++.

Із вбудованими системами на основі 8 та 16 біт мікроконтролерів зводиться до цього простіше розробити програмне забезпечення, яке може вписатися в обмежені ресурси цих дуже скромних обмежень на зберігання (можливо, кілька 100 байт оперативної пам'яті для 8-бітових мікроконтролерів низького класу , з 2-8 KiB ПЗУ або EPROM / Flash для зберігання коду).

У цих випадках малі мови, такі як C або збори, як правило, є найбільш часто використовуваними мовами розробки. Як дуже грубе порівняльне порівняння, повний асемблер та компілятор C99 можуть вміститися на одній дискеті, тоді як для сучасної системи розробки C ++ (зі STL тощо) вам потрібно кілька MiB .

Якщо ви дивитесь на мікросети вищого класу (16-розрядні та здебільшого 32-розрядні, із досить рідкісними 64-бітовими) та DSP у вбудованих середовищах, обмеження слабшають, а розробка програмного забезпечення може становити основну частину розробки. зусиль, тому має сенс використовувати найпродуктивніші інструменти розробки, включаючи більш вдосконалені мови з такими функціями, як об'єктно-орієнтоване програмування (OOP), такі як C ++ та новіші мови (Java, Perl, Ruby, Python).

В зборах і на C можна передбачити, скільки пам’яті використовується, так що дизайн з обмеженим простором є здійсненним, але розширені функції, такі як шаблони, обробка виключень та прив'язка часу, унеможливлюють точно знати необхідний слід пам'яті за стандартну програму C ++ заздалегідь. Я не знаю достатньо про MISRA C ++ , який є підмножиною C ++, щоб прокоментувати це.

Мови, засновані на віртуальних машинах, на яких працює байт-код (Java, Perl, Python), менш зрілі у вбудованому досвіді розробника, і оскільки ці мови призначені для ізоляції програміста від конкретного обладнання, це також ускладнює сумління такі обмеження та обмеження вбудованої апаратної системи. Це менше проблеми зі швидкими 32-бітовими процесорами (наприклад, ARMv7) з MiB, якщо не GiB оперативної пам'яті.

Усі реабілітації BASIC, про які я знаю, досить спрощені в мовних особливостях, залишаючись значною мірою вірним спадщині Dartmouth BASIC з 1960-х. Це означає, що мова не має жодних складних бібліотек виконання часу чи обробку винятків, а інтерпретатор або компілятор пише досить просто, а також має невеликий розмір файлу. Більшість мікроконтролерів мають принаймні один компілятор BASIC.

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

Більшість відповідей уже заявляли про історичні причини (загальновідомі, всі користуються ним, змінити звички тощо) буде непросто. Хоча я згоден з ними, ми повинні мати на увазі, що є ще одна важлива причина.

Справа не в тому, що "C - це поганий або застарілий вибір, але ми все ще використовуємо його за звичкою" (як клавіатури QWERTY).

C сам по собі є дуже хорошим вибором для вбудованої розробки, особливо в критичних для часу додатках. Чому?

• це досить низький рівень, щоб його легко використовувати для реалізації програм у режимі реального часу. Якщо вам потрібно виміряти час у наносекундах, вибирати переривання кожні 5 мікросекунд або доводиться використовувати точно 64 байти загальної оперативної пам’яті, то з дуже високим рівнем мови це найчастіше буде або неможливо, або дуже важко вирішити це . C дає набагато кращий контроль над апаратним забезпеченням, ніж мови вищого рівня, це одна з найважливіших відмінностей між розробкою для вбудованого порівняно з ПК.

• це достатньо високий рівень, щоб бути швидким і легким для кодування, порівняно з складанням.

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

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

1. Величезна кількість існуючого коду (бібліотеки / існуючі реалізації)
2. Великий набір інструментів, який може працювати з цими мовами (IDE, симулятори, ...)

У вбудованому світі може бути набагато важче (або неможливо) забезпечити оновлення програмного забезпечення, і тому ще більш важливо гарантувати правильність. На жаль, С дуже мало допомагає в цьому плані і дозволяє програмісту грати швидко і вільно.

Мене болить використовувати C для вбудованих систем, і хотілося б, щоб я міг хоча б перейти до C ++ для багатьох переваг, які він надає у вигляді обмежень, таких як const, посилання, набір строфі тощо.

Я здогадуюсь, що відповідь полягає в тому, що ми застрягли з C, оскільки зміни не є комерційно можливими. Всі знають C, для нього є безліч компіляторів, бібліотеки для нього та інструменти для його генерації. З новою мовою ми б починали з нуля.

Я думаю, тому люди все ще використовують PHP .

Ніхто тут не чув про SPARK Ada?

Це "мала" версія мови Ada та пов'язані з нею інструменти розробки для вбудованих систем, наприклад, авіоніка та інші критично важливі для безпеки програми, такі як медичне обладнання.

Дослідження показують лише 5-10% втрати швидкості обробки порівняно з C / C ++ з більш надійним кодуванням SPARK.

Я думаю, що розповсюдження C у вбудованих системах обумовлено економічними причинами:

• Він уже є і зазвичай працює в більшості застосунків - і більшість застосувань на об’ємній основі не критичні, ніхто не загине, якщо пральна машина перезаряджена - так навіщо міняти?

• Набір інструментів SPARK стане додатковою витратою сам по собі і для того, щоб навчити персонал її використовувати.

• Додаткових переваг SPARK (або інших мов, що не належать до C) для вбудованої системи контролера / управління може виявитися недостатньо для виправдання необхідної премії в ціні товару в очах споживача - особливо, коли вони бачать, як видається, "хороші" конкуруючі бренди, що продають за нижчу ціну.

• Компанія AdaCore дбає про те, щоб не заглиблюватися в програми масового ринку, оскільки це неминуче вимагатиме значного збільшення персоналу технічної підтримки для вирішення непрофільних питань. AdaCore - компанія високого рівня експертизи, гордість себе такою і виставляє свої продукти та послуги у компанії з високими технологіями. Мова незвична для проникнення на нові ринки, якщо справді цього не хочуть її основні зацікавлені сторони.

Тож, @ Wouter, вам не потрібно турбуватися про те, щоб померти в небі на користь вбудованого коду Ада!

Це вже в літакових системах вже багато років. Так само і для вашого кардіостимулятора.

Але що стосується посудомийної машини, системи управління будівельними послугами, контролером лабораторних печей та іншими не настільки суворо регульованими аренами - чи економічно варто пройти додаткову милю?

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

Існує також той факт, що багато бібліотек, які постачаються з кажуть Java або C #, марні для великої кількості вбудованих проектів.

З іншого боку, у нас є більш старі мови, такі як Pascal або Basic. З моєї точки зору, вони не настільки популярні, оскільки C зробив себе "галузевим стандартом" мови і дуже велика кількість програмістів та інженерів вивчають C сьогодні. У деяких школах Pascal або Basic навіть не вивчаються. Існує також той факт, що багато популярних сьогодні мов мають C-подібний синтаксис, і використання Pascal буде дивно програмісту на C.

Що стосується FORTRAN, я гадаю, що він потрапив у нішеву сферу і в основному використовується інженерами та вченими, які працюють у районах, де є відповідна екосистема для його використання. Я не бачу жодної конкретної причини (крім тих, про які я згадував Pascal і Basic), вона не використовується у вбудованих системах.

Зауважте, що у цій відповіді я зосереджувався переважно на менших системах. Існує також багато вбудованих пристроїв, які використовують більш складні операційні системи, такі як GNU / Linux або інша похідна Unix, і для їх програмування можна використовувати більш-менш будь-яку мову popualr.

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

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

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

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

Деякі причини, про які інші не згадували:

• Проблемний простір: C підходить для невеликих і простих систем. Якщо все, що ви робите, - це реагувати на зовнішні сигнали і проштовхувати кілька цифр навколо, тоді C працює досить добре (немає складних структур даних, немає малоквору, немає складного поводження з помилками).

• Обсяг виробництва: Якщо у вас є великі обсяги виробництва, то економічно доцільно економити на кожному апаратному блоці і витрачати більше на програмістів, оскільки програмування - це разова вартість.

Я думаю, що це тому, що C / C ++ - це мови найнижчого рівня, високого рівня.

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

Окрім складання, C - єдина мова, яку я знаю, що компілюється у рідний код і для якої час виконання не є обов'язковим. Таким чином, це гарантовано найменший слід і найшвидший час виконання в обмеженому середовищі (за винятком випадків, коли ви використовуєте збірку).

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

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