題:
為什麼嚴格嵌入C / C ++
user3073
2012-07-05 02:06:34 UTC
view on stackexchange narkive permalink

我不喜歡這個問題,因為它不容易回答,但也許我可以改寫:“是什麼使嵌入式語言無法更改語言?”

例如,我們幾乎看到了C / C ++嵌入式(我想我也聽說過ADA?如果我錯了,請糾正我)

但是究竟是什麼使嵌入式世界免於更改語言?僅僅是C太容易使用還是因為C一切都很好,所以真的沒有改變的“需求”嗎?

這總是讓我感到困惑,而不是因為我抱怨。由於將其保留為幾種語言,因此可以使事情標準化。但是問題仍然存在。

我意識到這是一個主觀問題,但是我的主要問題是“為什麼”而不是“ IF / WHEN”

您是否希望在嵌入式系統上看到特定的高級語言?編輯:或者更確切地說,您對C不提供的語言功能感興趣?
@JonL-我希望C有很多底層功能。例如。大整數內部更好的位/半字節/字節/字操作。更好的安全支持,例如Ada具有的功能類型。
-1
嵌入式並不是嚴格意義上的C語言。這裡有許多用於嵌入式系統的高級語言:http://electronics.stackexchange.com/questions/3423/survey-of-high-level-language-interpreters-compilers-for-microcontrollers ?rq = 1
“嵌入式”具有不同的含義。運行烤麵包機的4位微控制器不同於ECU或​​機頂盒。這種頻譜使您的問題難以回答。
還有一些圖靈不完整的語言:https://en.wikipedia.org/wiki/IEC_61131-3 https://en.wikipedia.org/wiki/Simulink通常它們生成C代碼。
並且,正如預期的那樣,此操作已關閉。我曾希望這個問題能得到高質量的答案,並且人們會努力將其保留為一個好問題,但事實並非如此。取而代之的是,我們得到的答案很多,一個句子得到多個投票,一個散文的答案帶有誇張的旗幟,另外一個答案在一天之內就產生了更多的旗幟,而其餘站點合在一起。問題是,對於許多人來說,為什麼他們沒有改變,有許多不同的正確答案。
這是關於“為什麼C?”的最新[article](http://mortoray.com/2012/06/11/whats-to-love-about-c/)。學科。
@Kortuk-為什麼在獲得所有這些好的答案之後立即將其關閉,並且顯然是受歡迎的問題視圖/投票明智的選擇?對我來說沒有多大意義...
@OliGlaser,是因為[主觀好壞]的大多數衡量標準實際上都是基於答案的。我立刻知道這將是一個問題,但我確實希望它能很好地遵循這些規則。取而代之的是,用戶發布了許多非常簡單的答案,並且大多數答案都只是在接受投票支持。標誌的數量也是一個大標誌,存在問題。我希望在聊天中進行更多討論。
@Kortuk-很好,請在第一次被問到是否不符合準則時將其關閉(無需等待-我認為從一開始它就很明顯,將給出給出的答案),但是在這種情況下,它一直處於打開狀態,現在有很多非常有用的信息(我不會說答案很簡單)為什麼至少不使其成為Wiki?這對所有想問類似問題的人有沒有幫助?你們都做得很好,但我只是感到偶爾嚴格遵守規則會勝過“常識” ;-)
@OliGlaser,社區可能會自己執行標準,以高質量回答並否決那些不符合該標準的產品,因此討論可能會保持清晰。少於20小時5個標誌?正在進行投票表決嗎?如果您想聊天,我希望繼續在聊天中進行討論,該討論將永久存在以供參考,但不會混淆這個問題。我不能在那裡立即關閉事物,社區只能投票決定關閉或舉報,但如果沒有鑽石主持人花費時間,則不是我們的工作。
@OliGlaser,雖然這些準則在這些方面有點模糊,但是很難僅從一個問題就知道答案是否具有建設性,當我記得看到它看起來真的很好並且我以為這個問題可能會解決時,前幾個答案就很難說清楚好。過去以購物為導向的問題現在只能獲得鏈接,而現在他們可以獲得完整的答案,我們大多數情況下可以保留邊界問題,而只需要關閉那些完全是在尋找鏈接的情況下即可的問題。我希望隨著我們社區的發展,這不再是一個問題。
我認為這是因為C(++)是製造商向其平台移植的第一語言*,並且*因為大多數高級語言實際上都是用C(++)編寫的。因此,除了彙編之外,C幾乎總是在任何平台上都存在。這使得代碼可以在平台和庫之間合理移植,並且很快就可以使用。移植其他語言(及其庫)需要時間,第三方,...
如果C / C ++代表“靜態分配”,則它不是主觀的,其原因甚至在大學中也暴露出來。
十一 答案:
Wouter van Ooijen
2012-07-05 02:32:14 UTC
view on stackexchange narkive permalink

首先:忘記“嵌入式”,因為這不是有用的區分。最重要的屬性是“資源受限的”。最重要的資源通常是時間,在這種情況下,我們談論的是實時系統,但它也可以是內存或功能。

  • 採用新語言非常困難且罕見。它需要重新培訓,新工具,並找到一種使用新語言的好方法。這是昂貴的,特別是對於早期採用者。這也是一個雞與蛋的問題:沒有龐大的用戶群,就不會有高質量的工具和庫,但是沒有那些,就不會有龐大的用戶群。因此,一種新的語言必須比現有的語言具有更大的優勢,否則就不會有機會。

  • 大多數語言的“最新”新發展正在填補空白。在可用的CPU能力和用戶需求之間。換句話說:它們的速度效率低下,但是可以通過簡化程序員來彌補。考慮一下諸如Java,Python,Perl,Tcl之類的語言的興起,這些語言實際上是由解釋器運行的(也許經過一些編譯),並且大量使用了動態內存管理。但這與資源受限的世界並不十分匹配,在該世界中,我們希望a)充分利用可用資源,即使以更多的編程工作為代價,以及b)可預測的資源使用。

  • C和C ++(或合適的子集)仍然是可以滿足可預測的空間和時間使用的通用高級語言(足夠好的工具,訓練有素的程序員和豐富的庫都可用)要求與當前硬件的要求相差不遠。我認為唯一的競爭者是Ada,但它的起點很差:第一個實現(被認為是?)太慢且效率低下,而現在(即使有很好的實現可用),該語言也落後了一段時間。功能(與C ++相比)。我個人認為這很遺憾,在其他條件相同的情況下,我寧願乘坐Ada編程的飛機,也不願使用C或C ++進行飛機飛行。

+1-不錯的答案。 Ada似乎是一種有趣的語言,周圍是否有適用於小型微型計算機的Ada編譯器?
有GNAT,即GCC Ada編譯器。但是AFAIK在微尺上的使用並不多,因此您很難找到可以讀取的東西。
是的,我在Wiki頁面上看到了GNAT。您是對的,對於小型微控制器來說並沒有太多支持,但是似乎對68k,x86,MIPS等任務關鍵型產品(例如[DDCI](http:/ /www.ddci.com/index.php))
我看到也有SPARK Ada,如下面的Deek所述。當我有一些他們稱之為時間的難以捉摸的東西時,我將不得不檢查一下...
如Arduino所示,以Gnat形式存在的Ada在AVR微處理器上可以正常工作。我構建的最小的Gnat可執行文件為65個字節。誠然,儘管等效的Arduino草圖超過1K,但它所做的只是使LED閃爍。到我的可執行文件達到600字節時,它可以獨立驅動2台步進電機...您不需要SPARK-除非您想證明您的LED閃爍燈在形式上是正確的!
我認為嵌入式技術除了資源一致性之外,還有另一個主要方面-時間確定性。您需要實時進行操作。我注意到,在許多課程中,“實時通勤”甚至與“嵌入式計算機”都毫不費力地互換了。動態的東西往往打破了這一要求。
對我來說,時間確定性是資源約束的一種特例,資源是時間,約束是雙向的。你是完全正確的,動態的東西(尤其是通用內存分配/釋放)會搞砸這一點。我試圖告訴我的學生,儘管實時性和嵌入式性經常並存,但它們並不相同。
mctylr
2012-07-05 05:46:54 UTC
view on stackexchange narkive permalink

使用基於8位和16位微控制器的嵌入式系統,可以更輕鬆地開發適合這些有限存儲限制(可能只有幾百個字節)的有限資源的軟件。用於低端8位微控制器的RAM,帶有2-8 KiB的ROM或EPROM / Flash用於代碼存儲。)

在這種情況下,諸如C或彙編語言之類的小語言是最常用的開發語言。作為一個非常粗略的相對比較,一個完整的彙編器和C9​​9編譯器可以放在單個軟盤上,而對於現代C ++開發系統(帶有STL等),則需要多個 MiB

當您在嵌入式環境中查看高端微處理器(高端16位,大部分為32位,很少使用64位)和 DSP時,限制會減弱,軟件開發可能會佔據開發工作的大部分,因此使用最高效的開發工具是有意義的,其中包括具有諸如面向對象編程(OOP)語言(例如C ++)等功能的更高級的語言,以及更新的語言(Java, Perl,Ruby,Python)。

可以在彙編和C語言中預測正在使用的內存量,以便進行空間受限的設計是可行的,但是高級功能(例如模板,異常處理和運行時綁定)使其不可能提前準確了解標準C ++程序所需的內存佔用量。我對 MISRA C ++(它是C ++的一個子集)一無所知,無法對此發表評論。

基於運行字節碼的虛擬機(Java,Perl, Python)在嵌入式開發人員的經驗中還不那麼成熟,並且由於這些語言旨在使程序員與特定的硬件隔離,因此也更加難以意識到此類嵌入式硬件系統的局限性。如果不是RAM的GiB,對於帶有MiB的快速32位處理器(例如ARMv7)來說,這些問題就不那麼重要了。

我所知道的所有BASIC實現在語言功能上都非常簡單,在很大程度上保留了1960年代Dartmouth BASIC的傳統。這意味著該語言沒有任何復雜的運行時庫或異常處理,並且解釋器或編譯器編寫起來相當簡單,並且文件大小也很小,大多數微控制器至少可以使用一個BASIC編譯器。

我希望能粗略地概述您會發現C和彙編語言主要用於較小或較舊的嵌入式系統的原因,以及較新的中高端嵌入式系統的局限性與傳統台式個人計算機。

vsz
2012-07-05 11:18:42 UTC
view on stackexchange narkive permalink

大多數答案已經說明了歷史原因(眾所周知,每個人都在使用它,改變習慣並不容易,等等)。雖然我同意他們的觀點,但我們應該記住,還有另一個重要原因。習慣”(例如QWERTY鍵盤)。

C本身對於嵌入式開發(尤其是在時間緊迫的應用程序中)是非常好的選擇。為什麼?

  • 它的級別足夠低,可以輕鬆地用於實現實時程序。如果您需要以納秒為單位測量時間,必須每5微秒捕獲一次中斷,或者必須完全使用 64字節的總RAM,那麼使用高級語言時,通常是無法解決或很難解決。與高級語言相比, C使您可以更好地控制硬件,這是嵌入式與PC開發之間最重要的區別之一。

因此,C是速度之間最好的(或最好的一種)折衷並直接訪問Assembly的硬件,以及易於閱讀和理解高級語言。

我認為對C有利的一個主要方面是,它允許一個人為特定平台優化代碼,同時允許這種代碼在其他平台上運行(也許效率不高)。在諸如PIC之類的東西上,許多C指令將可預測地轉換為機器指令。像`unsigned char i = 63,j = 128;這樣的循環;做{something;} while(-j); while(-i);`的可讀性不如`unsigned int i = 16000; {something;} while(-i);`,但是它將在PIC上運行得更快,效率更高。如果將代碼移至ARM,則第二種方法會更有效,但第一種方法仍然有效。
Sam
2012-07-05 02:22:28 UTC
view on stackexchange narkive permalink

這與正則編程中(最常用的)語言不會(真的)更改的原因完全相同:

  1. 大量現有代碼(庫/現有實現)
  2. 可以使用這些語言(IDE,模擬器等)的大型工具集
  3. ol>
Rocketmagnet
2012-07-05 02:53:04 UTC
view on stackexchange narkive permalink

在嵌入式世界中,提供軟件更新可能更加困難(或不可能),因此,確保正確性就變得尤為關鍵。遺憾的是,C在這方面幾乎沒有提供幫助,並且允許程序員快速靈活地玩遊戲。

在嵌入式系統上使用C會讓我很痛苦,希望我至少可以升級到C ++,以獲得C以約束,常量,引用,字符串鍵入等約束的形式提供的許多好處。

我想答案很簡單,因為在商業上不可行,因此我們只能堅持使用C。每個人都知道C,C有很多編譯器,C有很多庫以及生成它的工具。有了新的語言,我們將從頭開始。

我想這就是人們仍然使用PHP的原因。

PHP double claw hammer.

如果您想討論問題,請使用評論或meta,如果您想拍打背面的好問題,請對該用戶進行投票或評論。
您始終可以使用Pascal-它似乎具有您正在尋求的附加限制:-)。或某種形式的超級皮棉。
使用C的一個可能非常重要的原因是,與C ++編譯器相比,編寫基本C編譯器要容易得多。在完成更重要的任務之前,我做了一段時間。好玩的東西!編寫C ++編譯器?啊。不過,我更喜歡C ++作為用戶。
@RussellMcMahon-我不能使用Pascal,因為沒有正在使用的MCU的Pascal編譯器。
@darron-很好。但是,有很好的開源C ++編譯器,例如gpp。他們只需要為此寫一個後端即可。
@Rocketmagnet:您確定您的MCU沒有Pascal編譯器嗎?它可能表明您的關注標籤是Arduino(即AVR)和PIC,所以我建議您看一下http://www.e-lab.de/index_en.html
@avara-感謝您提供的鏈接,看起來Pascal編譯器僅支持PIC16。我們使用PIC18和PIC32。另外,我們將很快遷移到PSoC5。
Deek
2012-07-05 18:06:20 UTC
view on stackexchange narkive permalink

這裡沒有人聽說過SPARK Ada嗎?

這是Ada語言和嵌入式系統相關開發工具的“小版本”,例如航空電子和其他對安全至關重要的應用(例如醫療設備)。

研究表明,與採用更可靠SPARK編碼的C / C ++相比,處理速度僅損失5-10%。

我認為C在嵌入式系統中的擴散是出於經濟原因:

  • 它已經存在並且通常可用於大多數應用程序-而且大多數應用程序在數量上都是非關鍵的,如果洗衣機超負荷,沒有人會死-那麼為什麼要更換?

  • SPARK工具集本身將是一項額外的支出,而且會培訓員工使用它。

  • SPARK(或其他非C語言)對嵌入式控制器/管理系統的附加好處可能不足以證明在消費者眼中產品價格有必要的溢價-尤其是當他們看到明顯的“好”競爭對手品牌以更低的價格出售時。

  • AdaCore公司非常注意不要太深入地進入大眾市場應用e將不可避免地要求大量增加技術支持人員來處理非核心問題。 AdaCore是一家高水平的專業公司,因此而引以自豪,並向高科技公司推銷其產品和服務。除非語言的主要利益相關者真的想要,否則它不會進入新市場。

所以,@ Wouter,您不必擔心會因為缺少Ada而死在天空中。嵌入式代碼!

它已經在飛機系統中使用了很多年。起搏器也是如此。

但是對於洗碗機,建築服務控制系統,實驗室爐控制器和其他設備則沒有。如此嚴格管制的競技場-在經濟上值得加倍努力嗎?

有趣,謝謝-我沒有聽說過SPARK,我們將檢查一下。
一些研究表明,相對於C中的現有應用程序,其速度有所提高-查看“ Ironsides” DNS服務器...
AndrejaKo
2012-07-05 02:28:27 UTC
view on stackexchange narkive permalink

我猜想C受歡迎的主要原因是:首先是C流行起來,而且很多人都知道它;其次:Java,C#甚至C ++的許多方面都不適合嵌入式工作。基本上,我提到的其他3種語言在很大程度上依賴於動態內存,這帶來了不確定的程序執行,對像也帶來了動態內存,因此對內存的需求也很大(因為OO最重要的方面之一是使用更多的類),及時編譯的流行度越來越高(許多嵌入式平台甚至根本無法編譯自己的C代碼)...

還有一個事實是,許多庫Java或C#附帶的代碼對於大量嵌入式項目是沒有用的。

另一方面,我們有較舊的語言,例如Pascal或Basic。從我的角度來看,它們並不那麼受歡迎,因為C本身已成為“行業標準”語言,並且當今有大量的程序員和工程師學習C。在某些學校,甚至沒有學過Pascal或Basic。還有一個事實是,當今流行的許多語言都具有類似C的語法,而使用Pascal會使C程序員感到奇怪。

對於FORTRAN,我想它進入了一個利基市場,主要由在適合使用其生態系統的地區工作的工程師和科學家使用。我沒有看到任何特殊原因(除了我在Pascal和Basic中提到的那些原因)沒有在嵌入式系統上使用。

請注意,在此答案中,我主要關注較小的系統。也有許多嵌入式設備使用更複雜的操作系統,例如GNU / Linux或其他Unix派生產品,並且對其進行編程,或多或少可以使用任何popualr語言。

C受歡迎是因為C受歡迎嗎? :-)
@stevenvh是的,是的。這是一種積極的反饋迴路。它越受歡迎,就越受歡迎。
tylerl
2012-07-05 08:18:14 UTC
view on stackexchange narkive permalink

C是一種非常簡單的語言,並且已經多次被稱為 fancy彙編語言。這幾乎是您可以在上面的彙編代碼上提供的最少抽象量,因為C構造直接映射到機器級構造。

由於這個原因和其他幾個原因,實現新芯片上的C編譯器。大部分工作已經完成,複雜性或出錯情況相對較少,低級控制使您可以輕鬆地處理硬件的任何怪癖。

C ++可以(實際上最初是)實現為C之上的源代碼翻譯層,這意味著您可以使用C編譯器免費獲得C ++(或至少它的某些版本)。新芯片還需要其他所有功能,因此這是一個合理的起點。

starblue
2012-07-05 14:14:53 UTC
view on stackexchange narkive permalink

其他人未提及的一些原因:

  • 問題空間:C適用於小型和簡單的系統。如果您要做的只是對外部信號做出反應,並向周圍推幾個數字,那麼C的效果就很好(沒有復雜的數據結構,沒有malloc,沒有復雜的錯誤處理)。

  • 生產數量:如果您的生產量很大,那麼從經濟上考慮,節省每個硬件單元並在程序員上花更多的錢,因為編程是一次性的成本。

Amit Tomar
2012-07-05 13:06:32 UTC
view on stackexchange narkive permalink

我認為這是因為C / C ++是最低級別的高級語言。

fceconel
2012-07-05 06:09:50 UTC
view on stackexchange narkive permalink

實際上,對於小型嵌入式系統,C比C ++流行得多。其原因與不使用其他語言的原因相同。 C ++需要一個運行時,除非您放棄了大多數使其不同於C的功能。

除彙編程序外,C是我所知唯一可編譯為本機代碼和 em的語言>對於它,運行時是可選的。因此,在有限的環境中(除非使用彙編程序,否則)保證了最小的佔用空間和最快的執行時間。

另一方面,在中型和大型嵌入式系統中(這意味著更多的內存)和時鐘,更大的字長)我不會說C(或C ++)如此流行。我見過支持Python,Forth甚至Java的系統。

但是,顯然,出於與我上面提到的相同的原因,您幾乎總是可以選擇使用C / C ++。有了選擇,並成為一個已經對小型嵌入式C感到滿意的人,為什麼還要選擇另一種語言?

C ++會產生大量開銷,但是我用於MSP430的完全兼容的C ++編譯器不需要運行時,C ++確實可以編譯為本機代碼。很抱歉,告訴其他人是有害的,我已經打敗了你。您可以通過提供能使我確信我不正確的引用來刪除下降表決(這很困難,我已經閱讀了我項目的已編譯C ++的程序集清單,以確保其有效編譯的一部分),或者您可以刪除答案將其刪除對您聲譽的影響(儘管此時您獲得+8淨收入)
我完全同意Kortuk。 C ++的某些部分需要廣泛的運行時支持,但是不需要的部分仍然是更好的C(以及完整的OO)。某些編譯器和鏈接器開關很容易強制執行對此子集的限制。在某些部分(例如令人恐懼的printf),C ++至少具有語言潛力,可以要求更少的運行時支持(如果僅在考慮到小型系統的情況下實現了std :: cout ...)
@Kortuk,很抱歉,您在那兒不清楚,但是當我說“ C是唯一的語言……”並不意味著C ++沒有這兩種東西時,我的意思是C具有兩者和C ++的結合有其中之一。我的重點是運行時部分。我也不是說沒有運行時就完全不可能使用C ++,但這是很不尋常的。我看不到如何在沒有運行時的情況下擁有異常處理和RTTI之類的東西,這些都是非常重要的功能。但我很抱歉,如果我的表達方式導致了可能的誤解。
-1


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...