Tại sao C chiếm ưu thế trong thị trường phần mềm nhúng? [đóng cửa]

Hầu như mọi người bây giờ sẽ nói lời chúc phúc:

hiệu suất !

Được rồi, C không cho phép viết mã thể thao. Nhưng có những ngôn ngữ khác có thể làm như vậy, sau tất cả! Và sức mạnh tối ưu hóa của trình biên dịch hiện đại là tuyệt vời. Liệu C có một số lợi thế mà không có ngôn ngữ khác có? Hoặc đơn giản là không cần các công cụ linh hoạt hơn trong miền?

Hầu như mọi người bây giờ sẽ nói lời chúc phúc:

hiệu suất!

Đó là một phần của nó; sử dụng tài nguyên xác định là quan trọng trên các thiết bị có nguồn lực hạn chế để bắt đầu, nhưng có những lý do khác.

1. Truy cập trực tiếp vào API phần cứng cấp thấp.
2. Bạn có thể tìm thấy trình biên dịch C cho phần lớn các thiết bị này. Điều này không đúng với bất kỳ ngôn ngữ cấp cao nào theo kinh nghiệm của tôi.
3. C (thời gian chạy và thực thi được tạo của bạn) là "nhỏ". Bạn không phải tải một loạt các công cụ vào hệ thống để chạy mã.
4. API / trình điều khiển phần cứng có thể sẽ được viết bằng C hoặc C ++.

C được thiết kế để mô hình hóa CPU, bởi vì C được tạo ra để làm cho Unix di động trên các nền tảng thay vì chỉ viết ngôn ngữ lắp ráp.

Điều này có nghĩa là các chương trình C hoạt động tốt như một ngôn ngữ lập trình cho các chương trình cần có mức độ trừu tượng rất gần với CPU thực tế, đó là trường hợp của phần cứng nhúng.

Lưu ý: C được thiết kế vào khoảng năm 1970 và CPU thì đơn giản hơn.

Một lý do cho sự thống trị là nó có loại công cụ phù hợp cho nhiệm vụ. Sau khi đã phát triển trong các nền tảng nhúng trong cả Java và C / C ++, tôi có thể nói với bạn rằng cách tiếp cận từ trần đến xương của C ++ hoàn toàn tự nhiên hơn. Cứu nhà phát triển khỏi cảm giác rằng anh ta hoặc cô ta đang nhảy qua vòng vì ngôn ngữ quá cao là một điều khá khó chịu. Một ví dụ điển hình là sự vắng mặt của các biến không dấu trong Java.

Và các tính năng tiện dụng của VM / ngôn ngữ thông dịch thường không khả thi và bị loại khỏi triển khai, ví dụ: Bộ sưu tập rác.

C yêu cầu rất ít hỗ trợ thời gian chạy trong chính nó, vì vậy chi phí thấp hơn nhiều. Bạn không dành bộ nhớ hoặc lưu trữ cho hỗ trợ thời gian chạy, dành thời gian / nỗ lực để giảm thiểu hỗ trợ đó hoặc phải cho phép nó trong thiết kế dự án của bạn.

Như đã đề cập trong các câu trả lời khác, C được phát triển vào đầu những năm 1970 để thay thế ngôn ngữ lắp ráp trên kiến ​​trúc máy tính mini. Trước đó, các máy tính này thường có giá hàng chục nghìn đô la, bao gồm bộ nhớ và thiết bị ngoại vi.

Ngày nay, bạn có thể có được sức mạnh máy tính tương đương hoặc lớn hơn với bộ vi điều khiển nhúng 16 bit có giá bốn đô la trở xuống với số lượng duy nhất - bao gồm bộ điều khiển RAM và I / O tích hợp. Một bộ vi điều khiển 32 bit có giá một hoặc hai đô la trở lên.

Khi tôi lập trình cho những anh chàng nhỏ bé này, đó là điều tôi làm 90% thời gian khi tôi không thiết kế bảng họ ngồi, tôi muốn hình dung những gì bộ xử lý sẽ làm. Nếu tôi có thể lập trình đủ nhanh trong trình biên dịch chương trình, tôi sẽ làm như vậy.

Tôi không muốn tất cả các loại trừu tượng. Tôi thường gỡ lỗi bằng cách bước qua một danh sách người phát tán trên màn hình. Làm điều đó dễ dàng hơn nhiều khi bạn viết chương trình bằng C để bắt đầu.

Nó không hoàn toàn thống trị khi C ++ ngày càng được sử dụng nhiều hơn khi trình biên dịch được cải thiện và hiệu suất phần cứng tăng lên. Tuy nhiên C vẫn rất phổ biến vì một vài lý do;

1. Hỗ trợ rộng rãi. Khá nhiều nhà cung cấp chip cung cấp trình biên dịch ac và bất kỳ mã ví dụ và trình điều khiển nào có thể sẽ được viết bằng c. Trình biên dịch C ++ ngày càng phổ biến, nhưng không phải là chứng chỉ chết cho một con chip nhất định và chúng thường là buggier. Bạn cũng biết rằng bất kỳ kỹ sư nhúng nào cũng sẽ có thể làm việc trong c. Đó là ngôn ngữ chung của ngành công nghiệp.

2. Hiệu suất. Yup, bạn đã nói nó. Hiệu suất vẫn là vua và trong một môi trường mà các thói quen cốt lõi vẫn thường được viết bằng trình biên dịch, hoặc ít nhất là được tối ưu hóa bằng c có liên quan đến đầu ra lắp ráp, không bao giờ đánh giá thấp tầm quan trọng của việc này. Thông thường các mục tiêu nhúng sẽ có chi phí rất thấp và có những ký ức rất nhỏ và vài mips.

3. Kích thước. C ++ có xu hướng lớn hơn. Chắc chắn bất cứ điều gì sử dụng STL sẽ lớn hơn. Nói chung cả về kích thước chương trình và dấu chân bộ nhớ.

4. Bảo thủ. Đó là một ngành rất bảo thủ. Một phần vì chi phí thất bại thường cao hơn và việc sửa lỗi thường khó tiếp cận hơn, một phần vì không cần thiết phải thay đổi. Đối với một dự án nhúng nhỏ c làm công việc tốt.

Đối với các hệ thống nhúng, điều quan trọng là hiệu suất . Nhưng như bạn đã nói, tại sao C mà không phải một số ngôn ngữ biểu diễn khác?

Nhiều người cho đến nay đã đề cập đến sự sẵn có của trình biên dịch , nhưng không ai đề cập đến sự sẵn có của các nhà phát triển . Rất nhiều nhà phát triển đã biết C hơn, nói, OCaml.

Đó là ba ông lớn.

Phần mềm nhúng rất khác nhau.

Trên một ứng dụng máy tính để bàn, trừu tượng và thư viện giúp bạn tiết kiệm rất nhiều thời gian phát triển. Bạn có thể sử dụng một vài megabyte hoặc gigabyte RAM hoặc một số lõi CPU 64-bit 2 + GHz, và một người khác (người dùng) đang trả tiền cho phần cứng đó. Bạn có thể không biết ứng dụng sẽ chạy trên hệ thống nào.

Trong một dự án nhúng, tài nguyên thường rất hạn chế. Trong một dự án tôi đã làm việc trên (bộ xử lý sê-ri PIC 17X), phần cứng có 2Kwords bộ nhớ chương trình, 8 cấp độ ngăn xếp (trong phần cứng) và 192 byte (<0,2kB) RAM. Các chân I / O khác nhau có các khả năng khác nhau và bạn đã cấu hình phần cứng khi cần bằng cách ghi vào các thanh ghi phần cứng. Gỡ lỗi liên quan đến một máy hiện sóng và phân tích logic.

Trong nhúng, các khái niệm trừu tượng thường cản trở và sẽ quản lý (và chi phí) tài nguyên mà bạn không có. Ví dụ, hầu hết các hệ thống nhúng không có hệ thống tập tin. Lò vi sóng là hệ thống nhúng. Bộ điều khiển động cơ xe. Một số bàn chải đánh răng điện. Một số tai nghe chống ồn.

Một yếu tố rất quan trọng đối với tôi trong việc phát triển các hệ thống nhúng là biết và kiểm soát những gì mã dịch theo hướng dẫn, tài nguyên, bộ nhớ và thời gian thực hiện. Thông thường trình tự chính xác của các điều khiển hướng dẫn, ví dụ thời gian cho dạng sóng giao diện phần cứng.

Trừu tượng và 'ma thuật' đằng sau hậu trường (ví dụ: công cụ thu gom rác) rất phù hợp cho các ứng dụng trên máy tính để bàn. Công cụ thu gom rác giúp bạn tiết kiệm rất nhiều thời gian để tránh rò rỉ bộ nhớ, khi bộ nhớ được / có thể được phân bổ động.

Tuy nhiên, trong thế giới nhúng thời gian thực, chúng ta cần biết và kiểm soát mọi thứ mất bao lâu, đôi khi xuống đến nano giây và không thể ném thêm vài meg RAM hoặc CPU nhanh hơn vào một vấn đề. Một ví dụ đơn giản: khi thực hiện phần mềm làm mờ đèn LED bằng cách điều khiển chu kỳ nhiệm vụ (CPU chỉ có điều khiển bật / tắt đèn LED), bộ xử lý không tắt và thực hiện việc thu gom rác trong 100ms vì màn hình hiển thị rõ ràng đèn flash sáng hoặc đi ra ngoài.

Một ví dụ giả thuyết hơn là bộ điều khiển động cơ bắn trực tiếp bugi. Nếu CPU đó tắt và thu gom rác trong 50ms, động cơ sẽ bị cắt trong giây lát hoặc bắn vào vị trí trục khuỷu sai, có khả năng làm cho động cơ bị đình trệ (trong khi vượt qua?) Hoặc làm hỏng cơ học. Bạn có thể khiến ai đó bị giết.