Чому C домінує на ринку вбудованого програмного забезпечення? [зачинено]

14

Закрито . Це питання ґрунтується на думці . Наразі відповіді не приймаються.

Хочете вдосконалити це питання?Оновіть питання, щоб на нього можна було відповісти фактами та цитатами, відредагувавши цю публікацію .

Закрито 5 років тому .

Зараз майже кожен скаже благословення:

виконання !

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

programming-languages c embedded-systems

— лози
джерело

1

FWIW, Arduino можна керувати за допомогою C #: arduino.cc/playground/Interfacing/Csharp

— FrustratedWithFormsDesigner

@ Frustrated: Так, але це один приклад, і більшість людей, що будують пристрої, використовують Arduino.

— Ед С.

2

Пов’язано: stackoverflow.com/questions/1601893/…

— Стів S

2

Дивіться також: stackoverflow.com/questions/812717/…

— Стів Мельников

1

@ dan04, у переважній більшості випадків це насправді не було проблемою. Група з імітації 6DOF в Texas Instruments Defense Systems and Electronics Group зробила невеликий експеримент приблизно в 1988 році. До цього часу вони проводили всі свої симуляції в FORTRAN. Вони спробували написати один у PASCAL, щоб побачити, як це погано зашкодить. Вони виявили, що PASCAL приніс їм невеликий показник продуктивності, але збільшення надійності та простота налагодження БОЛЬШЕ, ніж для цього зроблено. Безпосередньо вони виявили, що сильна перевірка типу PASCAL - це ДОБРА річ. (І так, вони робили масиви.)

— Джон Р. Стром

41

Зараз майже кожен скаже благословення:

виконання!

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

Прямий доступ до апаратних API низького рівня.
Ви можете знайти компілятор С для переважної більшості цих пристроїв. Це не вірно для жодної мови високого рівня в моєму досвіді.
C (час виконання та створений виконаний файл) "невеликий". Вам не потрібно завантажувати в систему купу матеріалів, щоб запустити код.
API / драйвер для апаратних засобів, ймовірно, будуть записані на C або C ++.

— Ед С.
джерело

14

+1 Наявність компіляторів. Ще тоді, коли ми писали все на зборах, компілятори першого роду були богом відправлення.

— Крістофер Біббс

8

+1, я вважаю, що детерміноване використання ресурсів є однією з найважливіших причин. У вас немає багато пам’яті, щоб робити всілякі вигадливі збирання сміття в посудомийній машині.

— користувач281377

4

+1 також для "детермінованого використання ресурсів". У багатьох вбудованих системах ця вимога навіть виключає використання динамічного розподілу пам'яті. Багато інших мов значною мірою покладаються на динамічне розподілення пам'яті (навіть багатьом корисним аспектам C ++ потрібна динамічна пам'ять).

— Майкл Берр

2

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

— Майкл Берр

1

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

— Ред С.

18

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

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

Примітка: C був розроблений близько 1970 року, тоді процесор був простішим.

3

+1: Це, безумовно , причина. Можливо, люди спробували розробити новіші мови високого рівня, які захоплюють особливості сучасних процесорів, але ніхто не розробив мову для того, на що потрапив.

— Кен Блум

2

@vines, C - це невелика мова з великою бібліотекою виконання. Все це можна зробити в бібліотеці виконання. Він просто не переміщуватиметься автоматично у стандартну бібліотеку С, тому це залежить від платформи.

3

+1. C був створений для і спочатку використовувався на PDP-7, який максимум 64кілограми 18-бітних слів. Багато інших "сучасних" мов мають більші труднощі з вміщенням у такий простір. Особливо для написання ОС на зразок Unix.

— greyfade

2

@greyfade: не так. UNIX зародився на PDP-7, але C не став. Цитую з передмови до мови програмування C : "C спочатку був розроблений і впроваджений в операційній системі UNIX на PDE PDP-11 DEC Деннісом Річі."

— Джеррі Труну

1

@vines: хоча, безумовно, доцільно розглянути можливість прямої підтримки мовлення в мові (cf, Concurrent C), значна частина кешу полягає в тому, що він робить все швидше без будь-якого втручання з боку програміста чи мови.

— Джеррі Труну

11

Однією з причин панування є те, що він має правильний інструмент для виконання завдання. Розробивши вбудовані платформи як в Java, так і в C / C ++, я можу вам сказати, що підхід C ++ до голих кісток є просто більш природним. Врятувати розробника від відчуття, що він або вона стрибає через обручі, оскільки мова на занадто високому рівні - це дуже дратівлива річ. Хорошим прикладом є відсутність непідписаних змінних у Java.

А зручні функції VM / мов, що інтерпретуються, як правило, нездійсненні і залишаються поза реалізацією, наприклад, збирання сміття.

— знаменитості
джерело

3

"і Java, і C / C ++" - сподіваюся, ви мали на увазі "всі три: Java C і C ++", оскільки C і C ++ - це різні мови.

— BЈович

1

@ BЈовић: Відповідаючи через роки, щоб підтвердити, що так, що я мав на увазі всіх трьох. Мене приписали обидва наступного визначення: "використовується як функціональне слово для позначення та підкреслення включення кожної з двох або більше речей" (дві або більше речей) :-)

— celebdor

10

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

— гекозавр
джерело

1

Чи справді ніколи не буває, що вам потрібна ця функціональність і винаходити її самостійно? Наприклад, великі державні машини, побудовані за допомогою switches, - жахливі, а ті ж машини, побудовані за ієрархіями класів, приємні та ремонтопридатні.

— виноградні лози

1

@vines - у вас, як правило, визначений набір входів, державні машини, побудовані на комутаторі / якщо сходи чіткіші та документальніші, ніж нападкові чари поліморфних дзвінків.

— Мартін Беккет

2

@Martin: для когось з невеликим досвідом розробки OO поліморфні дзвінки не є ні "магічними", ні "за кадром", а уявлення про те, що величезний перемикач / якщо висловлювання чіткіші і документальніші, здається відвертим химерним.

— Майкл Боргвардт

3

Знайдіть, що відбувається, коли pin27 піднімається на висоту. Варіант 1, пошук "PIN PIN27": Варіант 2 простежте ітератор на карті функторів, щоб виявити, який з них буде викликаний для об'єктів PIN, призначених для контакту 27 під час виконання. Проблема з великим кодом OO полягає в тому, що єдиний спосіб її прочитати - це по суті запустити його. На платформі без налагодження часу роботи або навіть консолі, що означає відстежувати код на папері або в голові.

— Мартін Бекетт

2

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

— geekosaur

9

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

Сьогодні ви можете отримати однакову або більшу потужність комп’ютера за допомогою 16-бітового вбудованого мікроконтролера, який коштує чотири долари або менше в одиничних кількостях - включаючи вбудовані контролери оперативної пам'яті та вводу / виводу. 32-бітний мікроконтролер коштує, можливо, долара або двох більше.

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

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

— tcrosley
джерело

1

Для деяких вбудованих додатків цей "долар чи два більше" є дуже важливим. Ніхто не помітить вплив ціни на їхню машину, але вони будуть на їх термостаті або CD-програвачі.

— Девід Торнлі

3

@David Thornley, так, згоден повністю, тому зараз у мене є проекти, що мають 8, 16 та 32-бітні мікросигнали одночасно для різних клієнтів. (Споживання електроенергії - ще одна причина для роботи з меншими пристроями.)

— tcrosley

1

Ціна визначається меншою вартістю процесора, ніж кількість контактів. Дошки коштують набагато дорожче, ніж чіпи.

— Іттріл

7

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

Широка підтримка. Практично кожен постачальник чіпів надає компілятор змінного струму, а будь-який приклад код та драйвери, ймовірно, будуть написані на c. Компілятори C ++ все частіше зустрічаються, але це не мертвий сертифікат для даного чіпа, і вони часто буггір. Ви також знаєте, що будь-який вбудований інженер зможе працювати на c. Це lingua franca галузі.
Продуктивність. Так, ти це сказав. Продуктивність все ще є кращою, і в умовах, коли основні підпрограми все ще часто записуються в асемблері або принаймні оптимізуються в c з посиланням на результати складання, ніколи не недооцінюючи важливість цього. Часто вбудовані цілі будуть дуже низькими і матимуть дуже маленькі спогади та кілька миль.
Розмір C ++, як правило, більше. Звичайно, все, що використовує STL, буде більше. Як правило, і з точки зору розміру програми, і в пам'яті.
Консерватизм. Це дуже консервативна галузь. Почасти тому, що витрати на відмову часто вищі, а налагодження часто менш доступне, частково тому, що його не потрібно змінювати. Для невеликого вбудованого проекту c виконує цю роботу добре.

— Люк Грем
джерело

11

Дивіться, саме №3, здається, є одним з найпоширеніших міфів навколо C ++. Напишіть безпечний тип контейнера для 5 різних типів на C, і ви викликали принаймні стільки ж "роздуття", як використання одного контейнера STL на 5 різних типах. Програмісти C обходять це, записуючи контейнери на непрозорі типи (void *). Порівняння ТО з шаблоном STL - це помилка категорії. Треба визнати, хоча це справді одна з найпоширеніших «причин» віддати перевагу С.

— Едвард Странд

Я повністю погоджуюся, що для тиражування повної функціональності в c ви отримуєте той самий слід, що і c ++. «Перевага» c полягає в тому, що він дозволяє бути виборчими. У будь-якому значущому проекті я вважаю за краще використовувати c ++, але іноді цільове обладнання обмежується до того моменту, коли це не практично. Сказавши, що №1 - це справді головна причина мого досвіду.

— Люк Грем

6

Для вбудованих систем велика річ - продуктивність . Але, як ви сказали, чому C, а не якась інша мова виконавця?

Багато людей досі згадували про доступність компіляторів , але ніхто не згадував про наявність розробників . Набагато більше розробників вже знають C, ніж, скажімо, OCaml.

Це три великі.

— BlueRaja - Danny Pflughoeft
джерело

6

Вбудоване програмне забезпечення дуже відрізняється.

У настільному додатку абстракції та бібліотеки заощаджують багато часу на розробку. У вас є розкіш викидати ще пару мегабайт або гігабайт оперативної пам’яті або якихось 64 + бітових 64-бітних процесорних ядер 2 + ГГц, і хтось інший (користувачі) платить за це обладнання. Ви можете не знати, в яких системах працюватиме додаток.

У вбудованому проекті ресурси часто дуже обмежені. В одному з проектів, над якими я працював (процесори серії PIC 17X), апаратне забезпечення мало 2 клів програмної пам'яті, 8 рівнів (вбудованого) стека та 192 байти (<0,2 кБ) оперативної пам'яті. Різні штифти вводу / виводу мали різні можливості, і ви налаштовували обладнання за потребою, записуючи до апаратних регістрів. Налагодження передбачає осцилоскоп і логіку-аналізатор.

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

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

Абстракції та "чарівна" магія (наприклад, сміттєзбірник) чудово підходить для настільних програм. Сміттєзбірники економлять багато часу, зменшуючи витоки пам’яті, коли пам’ять / можна динамічно розподіляти.

Однак у вбудованому світі в реальному часі нам потрібно знати і контролювати, скільки часу займає річ, іноді аж до наносекунд, і не можна закидати ще пару мег оперативної пам’яті або більш швидкого процесора при проблемі. Один простий приклад: коли ви робите програмне затемнення світлодіодів, керуючи робочим циклом (процесор мав лише керування світлодіодним контролем), НЕ нормально процесор вимикатися і робити, наприклад, збирання сміття на 100 мс, оскільки дисплей буде видимо спалахнути яскраво або вимкнути.

Більш гіпотетичний приклад - контролер двигуна, який безпосередньо спрацьовує свічки запалювання. Якщо цей процесор вимикає і збирає сміття за 50 мс, двигун на хвилину вимкнеться або вистрілить у неправильному положенні колінчастого вала, потенційно затуливши двигун (під час проходження?) Або пошкодивши його механічно. Ви могли когось вбити.

— Технофіл
джерело

Це так само правдиво, як це не має значення для C - проблема, на яку ви посилаєтесь, полягає лише у поведінці GC ... У C ++ немає ніяких GC, і знаєте, що? Я особисто використовую його через коментарі до рядків та суворішу безпеку типу =)

— лози