Tại sao nhúng C / C ++ nghiêm ngặt [đóng]

Tôi không thích câu hỏi này vì nó không thể trả lời dễ dàng nhưng có lẽ tôi có thể viết lại: "Điều gì khiến cho nhúng không thay đổi ngôn ngữ?"

Chẳng hạn, chúng ta thấy khá nhiều C / C ++ được nhúng (Tôi nghĩ rằng tôi cũng đã nghe ADA được đề cập trước đây rồi? Hãy sửa cho tôi nếu tôi sai)

Nhưng chính xác thì điều gì khiến thế giới Nhúng không thay đổi ngôn ngữ? Có phải C quá dễ sử dụng hay thực sự không có "nhu cầu" cho một sự thay đổi vì C làm mọi thứ đều ổn?

Điều này đã luôn luôn gây trở ngại cho tôi, không phải là tôi phàn nàn. Kể từ khi giữ nó cho một vài ngôn ngữ giữ cho mọi thứ được tiêu chuẩn hóa. Nhưng câu hỏi vẫn còn.

Tôi nhận ra đây là một câu hỏi chủ quan, tuy nhiên Câu hỏi chính của tôi là "Tại sao" chứ không phải "NẾU / KHI NÀO"

Trước hết: hãy quên "nhúng" vì đó không phải là một sự phân biệt hữu ích. Các tài sản quan trọng là "hạn chế tài nguyên". Tài nguyên quan trọng nhất thường là thời gian, trong trường hợp chúng ta nói về các hệ thống thời gian thực, nhưng nó cũng có thể là bộ nhớ hoặc sức mạnh.

• Áp dụng ngôn ngữ mới là khó khăn và hiếm. Nó đòi hỏi phải đào tạo lại, các công cụ mới và tìm ra cách tốt để làm việc với ngôn ngữ mới. Điều này là tốn kém, đặc biệt là cho những người chấp nhận sớm. Đây cũng là một vấn đề trứng gà: không có cơ sở người dùng lớn thì sẽ không có công cụ chất lượng tốt và những kẻ nói dối, nhưng không có những người đó sẽ không có một cơ sở người dùng lớn. Do đó, một ngôn ngữ mới phải có lợi thế lớn so với ngôn ngữ hiện có, nếu không, ngôn ngữ đó sẽ không có cơ hội.

• Hầu hết các phát triển mới "gần đây" trong các ngôn ngữ đã và đang lấp đầy khoảng cách giữa sức mạnh CPU có sẵn và những gì người dùng cần. Nói cách khác: chúng có thể không hiệu quả về tốc độ, nhưng bù lại bằng cách dễ dàng hơn với lập trình viên. Hãy nghĩ về sự phát triển của các ngôn ngữ như Java, Python, Perl, Tcl về cơ bản được điều hành bởi một trình thông dịch (có thể sau khi biên dịch) và sử dụng rất nhiều quản lý bộ nhớ động. Nhưng điều này không phù hợp với thế giới bị hạn chế về tài nguyên, nơi chúng ta muốn tận dụng tối đa các tài nguyên có sẵn, thậm chí phải trả giá bằng nhiều nỗ lực lập trình và b) sử dụng tài nguyên có thể dự đoán được.

• C và C ++ (hoặc một tập hợp con phù hợp) vẫn là các ngôn ngữ cấp cao nhất được sử dụng phổ biến (đủ công cụ tốt, lập trình viên được đào tạo đầy đủ và thư viện rộng lớn đều có sẵn) có thể đáp ứng các yêu cầu về không gian và thời gian có thể dự đoán được từ những gì có thể trên phần cứng hiện tại. Đối thủ duy nhất là tôi nghĩ Ada, nhưng nó đã phải chịu một khởi đầu tồi tệ: những triển khai đầu tiên là (nhận thức được?) Quá chậm và không hiệu quả, và bây giờ (mặc dù có triển khai tốt), ngôn ngữ đã bị tụt lại một chút tính năng (so với C ++). Cá nhân tôi nghĩ rằng điều này thật đáng tiếc, những thứ khác tương đương tôi thà bay trong một chiếc máy bay được lập trình ở Ada hơn là một thứ đã được thực hiện trong C hoặc C ++.

Với các hệ thống nhúng dựa trên bộ vi điều khiển 8 và 16 bit, việc phát triển phần mềm có thể phù hợp với nguồn lực hạn chế của những hạn chế lưu trữ rất khiêm tốn này có thể dễ dàng hơn (có thể là vài byte RAM cho bộ vi điều khiển 8 bit cấp thấp , với 2-8 KiB ROM hoặc EPROM / Flash để lưu trữ mã).

Trong những trường hợp đó, các ngôn ngữ nhỏ như C hoặc lắp ráp có xu hướng là ngôn ngữ phát triển được sử dụng phổ biến nhất. Là một so sánh tương đối thô sơ, một trình biên dịch hoàn chỉnh và trình biên dịch C99 có thể vừa với một đĩa mềm, trong khi bạn cần một vài MiB cho một hệ thống phát triển C ++ hiện đại (với STL, v.v.).

Khi bạn đang tìm kiếm micros micros cao cấp hơn (16 bit cao cấp và chủ yếu là 32 bit, với 64 bit khá hiếm) và DSP trong môi trường nhúng thì các hạn chế sẽ yếu đi và sự phát triển phần mềm có thể chiếm phần lớn sự phát triển vì vậy, thật hợp lý khi sử dụng các công cụ phát triển hiệu quả nhất, bao gồm các ngôn ngữ nâng cao hơn với các tính năng như ngôn ngữ lập trình hướng đối tượng (OOP) như C ++ và các ngôn ngữ mới hơn (Java, Perl, Ruby, Python).

Có thể lắp ráp và C để dự đoán dung lượng bộ nhớ đang được sử dụng, do đó thiết kế bị giới hạn không gian là khả thi, nhưng các tính năng nâng cao như mẫu, xử lý ngoại lệ và ràng buộc thời gian chạy khiến không thể biết chính xác dấu chân bộ nhớ cần thiết cho một chương trình C ++ tiêu chuẩn trước. Tôi không biết đủ về MISRA C ++ , một tập hợp con của C ++, để bình luận về nó.

Các ngôn ngữ dựa trên các máy ảo chạy mã byte (Java, Perl, Python) kém trưởng thành hơn trong trải nghiệm của nhà phát triển nhúng và vì các ngôn ngữ này được thiết kế để cách ly lập trình viên khỏi phần cứng cụ thể, điều đó cũng gây khó khăn hơn cho lương tâm những hạn chế và hạn chế của hệ thống phần cứng nhúng. Đây không phải là vấn đề với bộ xử lý 32 bit nhanh (ví dụ ARMv7) với MiB nếu không phải là GiB của RAM.

Tất cả các triển khai BASIC mà tôi biết là khá đơn giản trong các tính năng ngôn ngữ, phần lớn vẫn đúng với di sản của Dartmouth BASIC từ những năm 1960. Điều này có nghĩa là ngôn ngữ không có bất kỳ thư viện thời gian chạy hoặc xử lý ngoại lệ phức tạp nào và trình thông dịch hoặc trình biên dịch khá đơn giản để viết và cũng có kích thước tệp nhỏ. Hầu hết các bộ vi điều khiển đều có ít nhất một trình biên dịch BASIC cho nó.

Tôi hy vọng rằng những phác thảo rộng rãi về lý do bạn sẽ tìm thấy C và lắp ráp chủ yếu được sử dụng trên các hệ thống nhúng nhỏ hơn hoặc cũ hơn và với những hạn chế của các hệ thống nhúng từ trung bình đến cao cấp mới hơn chỉ khác một chút so với máy tính cá nhân để bàn truyền thống.

Hầu hết các câu trả lời đã nêu lý do lịch sử (nổi tiếng, mọi người đều sử dụng nó, sẽ không dễ để thay đổi thói quen, v.v.). Trong khi tôi đồng ý với họ, chúng ta nên nhớ rằng có một lý do quan trọng khác.

Không phải là "C là một lựa chọn tồi hoặc lỗi thời nhưng chúng tôi vẫn sử dụng nó theo thói quen" (như bàn phím QWERTY).

Bản thân C là một lựa chọn rất tốt cho phát triển nhúng, đặc biệt là trong các ứng dụng quan trọng về thời gian. Tại sao?

• nó ở mức độ thấp đủ để dễ dàng sử dụng để thực hiện các chương trình thời gian thực. Nếu bạn cần đo thời gian tính bằng nano giây, phải bắt gián đoạn cứ sau 5 micro giây hoặc phải sử dụng chính xác 64 byte tổng RAM, thì với ngôn ngữ cấp độ cao, thường sẽ không thể hoặc rất khó để giải quyết nó . C cung cấp cho bạn quyền kiểm soát phần cứng tốt hơn nhiều so với các ngôn ngữ cấp cao hơn, đây là một trong những khác biệt quan trọng nhất giữa phát triển cho nhúng so với PC.

• Nó là cấp độ cao đủ để nhanh chóng và dễ dàng để viết mã, so với hội.

Vì vậy, C là sự thỏa hiệp tốt nhất (hoặc một trong những điều tốt nhất) giữa tốc độ và khả năng truy cập phần cứng trực tiếp của hội, và việc đọc và hiểu dễ dàng các ngôn ngữ cấp cao.

Đó chính xác là lý do tại sao trong lập trình thông thường, các ngôn ngữ (được sử dụng nhiều nhất) không (thực sự) thay đổi:

1. Số lượng lớn mã hiện có (thư viện / triển khai hiện có)
2. Bộ công cụ lớn có thể hoạt động với các ngôn ngữ này (IDE, giả lập, ...)

Trong thế giới nhúng, việc cung cấp các bản cập nhật phần mềm có thể khó hơn rất nhiều (hoặc không thể), và do đó việc đảm bảo tính chính xác là rất quan trọng. Đáng buồn là C cung cấp rất ít trợ giúp về vấn đề này và cho phép lập trình viên chơi nhanh và lỏng lẻo.

Tôi cảm thấy khó chịu khi sử dụng C cho các hệ thống nhúng và ước gì tôi ít nhất có thể chuyển lên C ++ vì nhiều lợi ích mà nó mang lại dưới dạng các ràng buộc như const, tài liệu tham khảo, gõ stringer, v.v.

Tôi đoán câu trả lời đơn giản là chúng tôi bị mắc kẹt với C vì việc thay đổi không khả thi về mặt thương mại. Mọi người đều biết C, có rất nhiều trình biên dịch cho nó, các thư viện cho nó và các công cụ để tạo ra nó. Với một ngôn ngữ mới, chúng tôi sẽ bắt đầu lại từ đầu.

Tôi đoán đó là lý do tại sao mọi người vẫn sử dụng PHP .

Không có ai ở đây nghe nói về SPARK Ada?

Đây là phiên bản "nhỏ" của ngôn ngữ Ada và các công cụ phát triển có liên quan cho các hệ thống nhúng, ví dụ như hệ thống điện tử hàng không và các ứng dụng quan trọng khác về an toàn như thiết bị y tế.

Các nghiên cứu đã chỉ ra rằng mất 5-10% tốc độ xử lý so với C / C ++ với mã hóa SPARK đáng tin cậy hơn.

Tôi nghĩ rằng sự tăng sinh của C trong các hệ thống nhúng là do lý do kinh tế:

• Nó đã có sẵn và thường khả thi đối với hầu hết các ứng dụng - và hầu hết các ứng dụng trên cơ sở khối lượng đều không quan trọng, sẽ không có ai chết nếu máy giặt bị tràn ngập - vậy tại sao lại thay đổi?

• Bộ công cụ SPARK sẽ là một chi phí bổ sung cho chính nó và cho nhân viên đào tạo sử dụng nó.

• Các lợi ích bổ sung của SPARK (hoặc các ngôn ngữ không phải C khác) cho hệ thống quản lý / điều khiển nhúng có thể không đủ để chứng minh mức phí bảo hiểm cần thiết trong giá của sản phẩm - đặc biệt là khi họ thấy các thương hiệu đối thủ "tốt" rõ ràng với giá thấp hơn

• Công ty AdaCore cẩn thận không đi quá sâu vào các ứng dụng thị trường đại chúng vì những điều này chắc chắn sẽ đòi hỏi một sự gia tăng lớn trong đội ngũ hỗ trợ kỹ thuật để giải quyết các vấn đề không cốt lõi. AdaCore là một công ty chuyên môn cao, tự hào về điều đó và giới thiệu các sản phẩm và dịch vụ của mình tại các công ty công nghệ cao. Thật bất thường khi một ngôn ngữ thâm nhập vào các thị trường mới trừ khi các bên liên quan chính của nó thực sự muốn.

Vì vậy, @ Wouter, bạn không cần phải lo lắng về việc chết trên bầu trời vì muốn mã nhúng Ada!

Nó đã có trong các hệ thống máy bay trong nhiều năm. Tương tự như vậy cho máy tạo nhịp tim của bạn.

Nhưng đối với máy rửa chén, hệ thống điều khiển dịch vụ xây dựng, bộ điều khiển lò thí nghiệm và các đấu trường không được quy định chặt chẽ khác - nó có đáng để đi xa hơn không?

Tôi đoán rằng lý do chính cho sự phổ biến của C là thứ nhất: C là phổ biến và nhiều người biết đến nó và thứ hai: Không có ngôn ngữ phổ biến mới nào như Java, C # và thậm chí nhiều khía cạnh của C ++ phù hợp với công việc nhúng. Về cơ bản, 3 ngôn ngữ khác mà tôi đã đề cập phụ thuộc rất nhiều vào bộ nhớ động, mang lại sự thực thi chương trình không xác định với nó, các đối tượng mang bộ nhớ động với chúng, yêu cầu bộ nhớ lớn (vì một trong những khía cạnh quan trọng hơn của OO là sử dụng số lượng lớp lớn hơn), mức độ phổ biến ngày càng tăng của việc biên dịch đúng lúc (và nhiều nền tảng nhúng thậm chí không thể biên dịch mã C của riêng họ) ...

Ngoài ra còn có một thực tế là nhiều thư viện gửi Java hoặc C # là vô dụng đối với số lượng lớn các dự án nhúng.

Mặt khác, chúng ta có các ngôn ngữ cũ hơn như Pascal hoặc Basic. Theo quan điểm của tôi, chúng không phổ biến vì C tự biến nó thành ngôn ngữ "tiêu chuẩn công nghiệp" và rất nhiều lập trình viên và kỹ sư học C ngày nay. Ở một số trường, Pascal hoặc Basic thậm chí không học. Cũng có một thực tế là nhiều ngôn ngữ phổ biến ngày nay có cú pháp giống C và sử dụng Pascal sẽ cảm thấy lạ đối với một lập trình viên C.

Đối với FORTRAN, tôi đoán rằng nó đã đi vào một lĩnh vực thích hợp và chủ yếu được sử dụng bởi các kỹ sư và nhà khoa học làm việc trong các khu vực có hệ sinh thái phù hợp để sử dụng. Tôi không thấy bất kỳ lý do cụ thể nào (ngoài những lý do tôi đã đề cập cho Pascal và Basic) nó không được sử dụng trên các hệ thống nhúng.

Xin lưu ý rằng trong câu trả lời này, tôi tập trung chủ yếu vào các hệ thống nhỏ hơn. Ngoài ra còn có nhiều thiết bị nhúng sử dụng các hệ điều hành phức tạp hơn như GNU / Linux hoặc một số dẫn xuất Unix khác và để lập trình cho chúng, ít nhiều có thể sử dụng bất kỳ ngôn ngữ popualr nào.

C là một ngôn ngữ rất đơn giản và đã được nhiều lần gọi là ngôn ngữ lắp ráp lạ mắt . Nó gần như là số lượng trừu tượng tối thiểu bạn có thể cung cấp ở trên mã lắp ráp, vì cấu trúc C ánh xạ khá trực tiếp lên các cấu trúc cấp máy.

Vì lý do này và một số lý do khác, rất dễ thực hiện trình biên dịch C trên chip mới. Phần lớn công việc đã được thực hiện, tương đối ít phức tạp hoặc có sự cố xảy ra và điều khiển cấp thấp cho phép bạn xử lý khá dễ dàng bất cứ điều gì mà phần cứng của bạn có.

C ++ có thể (thực tế ban đầu là) được triển khai như một lớp dịch mã nguồn trên đầu C, nghĩa là bạn có được C ++ (hoặc ít nhất là một số phiên bản của nó) miễn phí với trình biên dịch C của bạn.

Với C và C ++, bạn là một bootstrap khá nhiều thứ khác bạn cần cho chip mới của mình, biến nó thành nơi hợp lý để bắt đầu.

Một số lý do mà những người khác không đề cập:

• Không gian vấn đề: C phù hợp với các hệ thống nhỏ và đơn giản. Nếu tất cả những gì bạn làm là phản ứng với các tín hiệu bên ngoài và đẩy một vài số xung quanh thì C hoạt động khá tốt (không có cấu trúc dữ liệu phức tạp, không malloc, không xử lý lỗi phức tạp).

• Khối lượng sản xuất: Nếu bạn có số lượng sản xuất lớn thì việc tiết kiệm cho từng đơn vị phần cứng và chi tiêu nhiều hơn cho các lập trình viên là rất hợp lý, bởi vì lập trình là chi phí một lần.

Tôi nghĩ đó là bởi vì C / C ++ là ngôn ngữ cấp thấp nhất, cấp cao.

Trong thực tế, đối với các hệ thống nhúng nhỏ C phổ biến hơn nhiều so với C ++. Và lý do cho điều đó cũng giống như việc không sử dụng các ngôn ngữ khác. C ++ yêu cầu thời gian chạy, trừ khi bạn cung cấp hầu hết các tính năng làm cho nó khác với C.

Ngoài lắp ráp, C là ngôn ngữ duy nhất tôi biết biên dịch thành mã gốc và có thời gian chạy là tùy chọn. Vì vậy, nó được đảm bảo là dấu chân nhỏ nhất và thời gian thực hiện nhanh nhất trong một môi trường hạn chế (trừ khi bạn sử dụng lắp ráp).

Mặt khác, trong các hệ thống nhúng trung bình và lớn (ý tôi là bộ nhớ và đồng hồ nhiều hơn, kích thước từ lớn hơn) tôi sẽ không nói C (hoặc C ++) quá phổ biến. Tôi đã thấy các hệ thống hỗ trợ Python, Forth ... thậm chí Java.

Nhưng tất nhiên bạn hầu như luôn có tùy chọn sử dụng C / C ++, rõ ràng, vì những lý do tương tự tôi đã đề cập ở trên. Và có tùy chọn, và trở thành một người đã sẵn sàng với C để nhúng nhỏ, tại sao bạn lại chọn ngôn ngữ khác?