임베디드 소프트웨어 시장에서 C가 지배적 인 이유는 무엇입니까? [닫은]

이제 거의 모든 사람들이 축복을 말할 것입니다.

성능 !

좋아, C는 운동 코드를 작성할 수 없습니다. 그러나 결국 그렇게 할 수있는 다른 언어가 있습니다! 그리고 현대 컴파일러의 최적화 능력은 대단합니다. 합니까 C는 다른 언어가없는 몇 가지 장점이있다? 아니면 단순히 도메인에서 더 유연한 기기가 필요하지 않습니까?

이제 거의 모든 사람들이 축복을 말할 것입니다.

공연!

그것의 일부입니다. 결정적인 리소스 사용은 리소스가 제한적인 장치에서 시작하는 것이 중요하지만 다른 이유가 있습니다.

1. 저수준 하드웨어 API에 직접 액세스
2. 이러한 장치의 대부분에 대한 C 컴파일러를 찾을 수 있습니다. 이것은 내 경험상 어떤 고급 언어에도 해당되지 않습니다.
3. C (런타임 및 생성 된 실행 파일)는 "작습니다". 코드를 실행하기 위해 시스템에 많은 것들을로드 할 필요가 없습니다.
4. 하드웨어 API / 드라이버는 C 또는 C ++로 작성 될 것입니다.

C는 CPU를 모델링하도록 설계되었습니다. C는 어셈블리 언어를 작성하는 대신 플랫폼에서 Unix를 이식 가능하게 만들었 기 때문입니다.

이는 C 프로그램이 실제 CPU와 매우 가까운 추상화 수준을 필요로하는 프로그램의 프로그래밍 언어로 잘 작동한다는 것을 의미합니다. 이는 임베디드 하드웨어의 경우입니다.

참고 : C는 1970 년경에 설계되었으며 CPU는 더 단순했습니다.

지배의 한 가지 이유는 그것이 작업에 적합한 도구를 가지고 있기 때문입니다. Java 및 C / C ++의 임베디드 플랫폼에서 개발 한 후 C ++의 기본 접근 방식이 더 자연 스럽다고 말할 수 있습니다. 언어가 너무 높기 때문에 개발자가 농구를 뛰어 넘고 있다는 느낌을 피하는 것은 상당히 성가신 일입니다. 한 가지 좋은 예는 Java에 부호없는 변수가없는 것입니다.

VM / 통역 언어의 편리한 기능은 일반적으로 실현 가능하지 않으며 가비지 콜렉션과 같이 구현에서 제외됩니다.

C는 그 자체로 런타임 지원이 거의 필요하지 않으므로 오버 헤드가 훨씬 적습니다. 런타임 지원에 메모리 또는 스토리지를 소비하거나, 지원을 최소화하기 위해 시간 / 노력을 소비하거나, 프로젝트 설계에서이를 지원하지 않아도됩니다.

다른 답변에서 언급했듯이 C는 1970 년대 초 미니 컴퓨터 아키텍처에서 어셈블리 언어를 대체하기 위해 개발되었습니다. 당시이 컴퓨터는 일반적으로 메모리와 주변 장치를 포함하여 수만 달러가 들었습니다.

요즘에는 내장 RAM 및 I / O 컨트롤러를 포함하여 단일 수량으로 4 달러 이하의 16 비트 임베디드 마이크로 컨트롤러를 사용하여 동일하거나 더 큰 컴퓨터 성능을 얻을 수 있습니다. 32 비트 마이크로 컨트롤러는 1 ~ 2 달러가 더 비쌉니다.

이 작은 녀석을 프로그래밍 할 때, 그들이 앉아있는 보드를 설계하지 않을 때 90 %의 시간을 할 때 프로세서가 무엇을 할 것인지 시각화하고 싶습니다. 어셈블러에서 충분히 빨리 프로그래밍 할 수 있다면 그렇게 할 것입니다.

나는 모든 종류의 추상화 계층을 원하지 않습니다. 나는 종종 화면에서 디스 셈 블러 목록을 단계별로 디버깅하여 디버그합니다. C로 프로그램을 작성할 때 시작하는 것이 훨씬 쉽습니다.

컴파일러가 향상되고 하드웨어 성능이 향상됨에 따라 C ++이 점점 더 많이 사용되고 있기 때문에 완전히 지배적이지는 않습니다. 그러나 C는 몇 가지 이유로 여전히 매우 인기가 있습니다.

1. 폭 넓은 지원. 거의 모든 칩 벤더가 ac 컴파일러를 제공하며 예제 코드와 드라이버는 c로 작성 될 것입니다. C ++ 컴파일러는 점점 일반화되고 있지만 특정 칩에 대한 인증서는 사라지지 않으며 종종 버그가 있습니다. 또한 모든 임베디드 엔지니어가 c.에서 작업 할 수 있음을 알고 있습니다. 업계의 링구아 프랑카입니다.

2. 공연. 예, 당신은 그것을 말했다. 성능은 여전히 ​​중요하며 핵심 루틴이 여전히 어셈블러로 작성되거나 어셈블리 출력과 관련하여 c에서 적어도 최적화 된 환경에서이 기능의 중요성을 결코 과소 평가하지 않습니다. 임베디드 타겟은 비용이 매우 저렴하고 메모리가 적고 밉이 거의 없습니다.

3. 크기. C ++는 더 큰 경향이 있습니다. 확실히 STL을 사용하는 모든 것이 더 커질 것입니다. 일반적으로 프로그램 크기와 메모리 풋 프린트 측면에서.

4. 보수주의. 매우 보수적 인 산업입니다. 부분적으로는 실패 비용이 높고 디버깅에 액세스하기가 쉽지 않기 때문에 부분적으로 변경이 필요하지 않기 때문입니다. 작은 임베디드 프로젝트의 경우 c가 잘 작동합니다.

임베디드 시스템의 경우 가장 중요한 것은 성능 입니다. 그러나 당신이 말했듯이, 왜 C와 다른 수행 언어가 아닌가?

지금까지 많은 사람들 이 컴파일러의 가용성에 대해 언급 했지만 아무도 개발자의 가용성에 대해서는 언급하지 않았습니다 . 예를 들어 OCaml보다 C를 알고있는 개발자가 훨씬 많습니다.

이것이 세 가지 큰 문제입니다.

임베디드 소프트웨어는 매우 다릅니다.

데스크탑 앱에서 추상화와 라이브러리는 많은 개발 시간을 절약 해줍니다. 문제가 발생하면 몇 메가 바이트 또는 기가 바이트의 RAM 또는 2 + GHz 64 비트 CPU 코어를 던질 수 있습니다. 앱이 실행될 시스템을 모를 수 있습니다.

임베디드 프로젝트에서 리소스는 매우 제한적입니다. 한 프로젝트에서 (PIC 17X 시리즈 프로세서) 작업 한 하드웨어에서 2Kwords의 프로그램 메모리, 8 레벨의 (하드웨어) 스택 및 192 바이트 (<0.2kB)의 RAM이있었습니다. I / O 핀마다 기능이 다르므로 하드웨어 레지스터에 쓰면 필요에 따라 하드웨어를 구성했습니다. 디버깅에는 오실로스코프 및 로직 분석기가 포함됩니다.

임베디드에서 추상화는 종종 방해가되고 필요없는 리소스를 관리 (및 비용)합니다. 예를 들어 대부분의 임베디드 시스템에는 파일 시스템이 없습니다. 전자 레인지는 임베디드 시스템입니다. 자동차 엔진 컨트롤러. 일부 전동 칫솔. 소음 제거 헤드폰.

임베디드 시스템을 개발할 때 매우 중요한 요소 중 하나는 명령, 리소스, 메모리 및 실행 시간 측면에서 코드가 무엇을 번역하는지 알고 제어하는 ​​것입니다. 정확한 명령 시퀀스는 예를 들어 하드웨어 인터페이스 파형의 타이밍과 같은 경우가 많습니다.

추상화 및 비하인드 스토리 '매직'(예 : 가비지 수집기)은 데스크톱 앱에 적합합니다. 가비지 콜렉터는 메모리가 / 동적으로 할당 될 수있을 때 메모리 누수를 추적하는 많은 시간을 절약합니다.

그러나 실시간 임베디드 세계에서는 시간이 오래 걸리고 때로는 나노초까지 걸리는 시간을 알고 제어해야하며 문제가 발생할 경우 몇 메가의 RAM이나 더 빠른 CPU를 넣을 수 없습니다. 간단한 예 : 듀티 사이클 (CPU에 LED의 온 / 오프 제어 만 있음)을 제어하여 LED의 소프트웨어 디밍을 수행하는 경우, 디스플레이가 눈에 띄게 표시되므로 프로세서가 꺼지고 100ms 동안 가비지 수집이 수행되는 것은 좋지 않습니다. 밝게 깜박이거나 외출합니다.

더 가상적인 예는 스파크 플러그를 직접 발사하는 엔진 컨트롤러입니다. 해당 CPU가 꺼지고 50ms 동안 가비지 수집을 수행하면 엔진이 잠시 동안 잘못된 크랭크 샤프트 위치에서 절단되거나 엔진을 정지 시키거나 (통과하는 동안) 기계적으로 손상시킬 수 있습니다. 누군가를 죽일 수 있습니다.