임베디드 개발에 C++가 아닌 C를 사용해야 하는 이유가 있습니까?
질문.
하드웨어 C++와 C89에는 2개의 컴파일러가 탑재되어 있습니다.
C++를 클래스에서 사용하려고 합니다만, 다형성은 사용하지 않습니다(vtables를 피하기 위해서).C++를 사용하는 주된 이유는 다음과 같습니다.
- 매크로 정의 대신 인라인 함수를 사용하는 것이 좋습니다.
- 코드를 복잡하게 만들 때 네임스페이스를 사용하고 싶습니다.
- C++ 비트 타입은 템플릿과 상세 캐스팅으로 인해 더 안전하다고 생각합니다.
- 저는 과부하 기능이나 컨스트럭터(자동 캐스팅에 사용)를 매우 좋아합니다.
매우 한정된 하드웨어(4KB의 RAM)로 개발할 때 C89를 고수할 이유가 있습니까?
결론
답변 감사합니다, 정말 도움이 되었습니다!
나는 이 문제를 끝까지 생각해 보았고, 주로 다음과 같은 이유로 C를 고수할 것이다.
- C에서 실제 코드를 예측하는 것이 더 쉬우며, RAM이 4kb밖에 없다면 이것은 매우 중요합니다.
- 저희 팀은 주로 C developers로 구성되어 있기 때문에 고급 C++ 기능을 자주 사용하지 않습니다.
- C 컴파일러(C89)에서 함수를 인라인화하는 방법을 찾았습니다.
당신이 너무 많은 좋은 대답을 했기 때문에 하나의 답을 받아들이기 어렵다.아쉽게도 Wiki를 만들고 받아들일 수 없기 때문에 가장 생각나는 답을 하나 고르겠습니다.
4KB의 RAM과 같이 리소스가 매우 제한된 타겟의 경우, 순수한 ANSI C 구현으로 쉽게 되돌릴 수 없는 많은 노력을 하기 전에 샘플로 테스트합니다.
Embedded C++ 작업 그룹은 언어의 표준 서브셋과 표준 라이브러리의 표준 서브셋을 제안했습니다.불행히도 C User's Journal이 죽었을 때 나는 그 노력을 놓쳤다.위키피디아에 글이 있는 것 같고, 위원회는 여전히 존재하는 것 같습니다.
임베디드 환경에서는 메모리 할당에 매우 주의해야 합니다.이 관리를 실시하려면 , 글로벌을 정의할 필요가 있습니다.operator new()사용하지 않는다는 걸 알 수 있도록 링크조차 할 수 없는 무언가에 친구가 있다는 거죠.배치new한편, 안정적이고 스레드 세이프하며 레이텐시가 보장된 할당 방식과 함께 현명하게 사용한다면, 당신의 친구가 될 가능성이 높습니다.
인라인 함수는 애초에 진정한 함수가 되어야 할 만큼 크지 않으면 큰 문제가 되지 않습니다.물론 교체한 매크로에도 같은 문제가 있었습니다.
템플릿도 인스턴스화가 실행되지 않는 한 문제가 발생하지 않을 수 있습니다.사용하는 템플릿에 대해 생성된 코드(링크 맵에 충분한 단서가 있을 수 있음)를 감사하여 사용하려는 인스턴스화만 발생했는지 확인합니다.
디버거와의 호환성도 발생할 수 있습니다.사용 가능한 하드웨어 디버거가 원래 소스 코드와의 상호 작용을 매우 제한적으로 지원하는 것은 드문 일이 아닙니다.어셈블리에서 실제로 디버깅을 해야 하는 경우 C++의 대상 이름 망글링으로 인해 작업이 더 복잡해질 수 있습니다.
RTI, 동적 캐스트, 다중 상속, 무거운 다형성 및 예외는 모두 사용 시 일정량의 런타임 비용이 수반됩니다.이러한 기능 중 일부는 프로그램 전체에 걸쳐 비용이 들지만 다른 기능들은 필요한 클래스의 가중치를 증가시킵니다.그 차이를 이해하고 적어도 대략적인 비용/편익 분석에 대한 완전한 지식을 바탕으로 고급 기능을 현명하게 선택하십시오.
소규모 임베디드 환경에서는 실시간 커널에 직접 연결하거나 하드웨어에서 직접 실행됩니다.어느 쪽이든 실행 시 스타트업 코드가 C++ 고유의 스타트업 잡무를 올바르게 처리하는지 확인해야 합니다.이것은, 적절한 링커 옵션을 사용하는 것만으로 간단하게 실시할 수 있습니다만, 전원 온 리셋의 엔트리 포인트에 대해서, 소스를 직접 제어할 수 있는 것이 일반적이기 때문에, 모든 것을 확실히 하기 위해서, 감사할 필요가 있는 경우가 있습니다.예를 들어 ColdFire 플랫폼에서는 CRT0과 함께 제공되는 개발 툴이 있습니다.C++ 이니셜라이저가 존재하지만 코멘트 아웃된S 모듈만약 내가 그것을 처음부터 바로 사용했다면, 나는 컨스트럭터가 전혀 가동되지 않은 전지구적인 물건들에 의해 어리둥절해졌을 것이다.
또, 임베디드 환경에서는, 하드웨어 디바이스를 사용하기 전에 초기화할 필요가 있는 경우가 많습니다.OS나 부트로더가 존재하지 않는 경우는, 고객의 코드로 할 수 있습니다.글로벌 객체의 컨스트럭터는 다음 시간 전에 실행된다는 것을 기억해야 합니다. main()가 호출되기 때문에 글로벌컨스트럭터 자체가 호출되기 전에 하드웨어 초기화를 실시하려면 로컬 CRT0.S(또는 동등한 것)를 변경해야 합니다.확실히, 의 꼭대기는main()너무 늦었어요
C++보다 C를 사용하는 두 가지 이유는 다음과 같습니다.
- 많은 임베디드 프로세서의 경우 C++ 컴파일러가 없거나 추가 비용을 지불해야 합니다.
- 제 경험으로는 임베디드 소프트웨어 엔지니어의 상당수는 C++에 대한 경험이 거의 없거나 전혀 없다는 것입니다.그 이유는 (1) 때문인지, 전자공학 학위로는 가르치지 않는 경향이 있기 때문입니다.따라서 자신이 알고 있는 것을 그대로 사용하는 것이 좋습니다.
또, 원래의 질문이나 코멘트에는, 4 Kb의 RAM이 기재되어 있습니다.일반적인 임베디드 프로세서의 경우 코드가 저장 및 실행되기 때문에 RAM의 양은 (대부분) 플래시와 무관합니다.
확실히 코드 스토리지 공간의 크기는 염두에 두어야 할 사항이지만, 보다 용량이 큰 새로운 프로세서가 시장에 출시됨에 따라 가장 비용에 민감한 프로젝트를 제외한 모든 프로젝트에서 예전보다 문제가 덜하게 되었습니다.
임베디드 시스템과 함께 사용하기 위한 C++의 서브셋 사용: MISRA C++ 표준이 있습니다.이 규격은 참조할 가치가 있을 수 있습니다.
EDIT: 이 질문도 참조해 주세요.이 질문으로 인해 임베디드 시스템의 C와 C++에 대한 논쟁이 벌어졌습니다.
C++ 퍼포먼스에 관한 테크니컬 리포트는, 이러한 점에 있어서 훌륭한 가이드입니다.임베디드 프로그래밍에 관한 섹션이 있습니다.
또, 임베디드 C++에 대한 회답에 기재되어 있는 경우는, ++를 참조해 주세요.기준이 100% 내 취향은 아니지만, C++의 어떤 부분을 떨어뜨릴지 결정할 때 참고가 된다.
소규모 플랫폼용으로 프로그래밍하는 동안 예외와 RTTI를 비활성화하여 가상 상속을 피하고 가상 기능의 수에 주의를 기울였습니다.
단, 친구는 링커 맵입니다.자주 체크하면 코드 소스나 스태틱메모리의 팽창을 금방 발견할 수 있습니다.
그 후, 표준적인 동적 메모리 사용상의 고려사항이 적용됩니다.즉, 말씀하신 것처럼 제한된 환경에서는 동적 할당을 전혀 사용하지 않는 것이 좋습니다.경우에 따라서는 소규모 동적 할당을 위한 메모리 풀이나 블록을 미리 할당하고 나중에 전체를 폐기하는 "프레임 기반" 할당을 피할 수 있습니다.
C++ 컴파일러를 사용할 것을 권장합니다만, C++ 고유의 기능의 사용을 제한합니다.C++에서는 C와 같이 프로그래밍할 수 있습니다(C 런타임은 C++를 실행할 때 포함됩니다만, 대부분의 임베디드 애플리케이션에서는 표준 라이브러리를 사용하지 않습니다).
C++ 클래스 등을 사용할 수 있습니다.
- 가상 기능 사용 제한(앞서 설명한 바와 같이)
- 템플릿 사용 제한
- 임베디드 플랫폼의 경우 연산자 new를 덮어쓰거나 메모리 할당에 placement new를 사용할 수 있습니다.
C가 심플하고 실제 생성될 코드를 예측하기 쉽기 때문에 임베디드 작업에 C를 선호하는 사람도 있다고 들었습니다.
개인적으로는 C스타일의 C++(타입 안전용 템플릿을 사용하여)를 작성하면 많은 이점이 있다고 생각합니다만, 실제로는 그렇지 않은 이유를 알 수 없습니다.
제한사항과 주의사항이 있는 C++를 추천합니다.
시장 투입 기간과 유지 보수성.C++의 개발은 보다 쉽고 신속합니다.따라서 설계 단계에 있는 경우 C++를 사용할 수 있는 컨트롤러를 선택하십시오(대용량 시장에 따라서는 가능한 한 저비용이 요구되기 때문에 이 선택을 할 수 없습니다.
속도. C는 C++보다 빠를 수 있지만, 이것은 속도 상승이 크지 않도록 주의해 주세요.그러니까 C++로 하면 돼요.알고리즘을 개발하고 테스트한 후 필요한 경우에만 고속화합니다(!).프로파일러를 사용하여 보틀 넥을 특정하고 외부 "C" 방식으로 다시 작성하여 C 속도를 달성합니다(ASM에서 아직 그 부분을 구현하지 못한 경우).
바이너리 사이즈C++ 코드는 더 크지만, 여기에 자세한 내용을 설명하는 훌륭한 답이 있습니다.특정 C 코드의 컴파일된 바이너리 크기는 C 또는 C++ 컴파일러를 사용하여 컴파일된 것과 동일합니다."실행 파일의 크기는 언어와 관련이 거의 없지만 프로젝트에 포함하는 라이브러리와 관련이 있습니다."C++를 사용하되 다음과 같은 고급 기능은 피하십시오.
streams,string,new,virtual기능 등크기 제한 때문에 최종 코드를 입력하기 전에 모든 라이브러리 기능을 검토하십시오(이 답변에 따라).
인간의 정신은 가능한 한 많은 것을 평가하고, 그 다음에 무엇이 중요한지 결정하고, 나머지는 버리거나 평가절하함으로써 복잡성을 다룹니다.이것이 마케팅에서의 브랜드화, 그리고 대부분 아이콘의 전체적인 토대입니다.
이러한 경향에 대처하기 위해서는 C++보다 C를 선호합니다.왜냐하면 코드와 하드웨어와의 상호작용에 대해 보다 면밀하게 생각할 수 밖에 없기 때문입니다.
오랜 경험으로 볼 때, C는 당신에게 문제를 해결하기 위한 더 나은 해결책을 제시하도록 강요하고, 일부 컴파일러 라이터가 좋은 아이디어라고 생각하는 제약을 충족시키기 위해 많은 시간을 낭비하지 않도록 하거나, 혹은 "숨어서" 무슨 일이 일어나고 있는지 알아내도록 강요한다고 생각합니다.
즉, C와 같은 낮은 수준의 언어는 하드웨어에 집중하여 우수한 데이터 구조/알고리즘 번들을 구축하는 데 많은 시간을 할애하고, 높은 수준의 언어는 그 안에서 무슨 일이 일어나고 있는지, 그리고 왜 특정 컨텍스트와 환경에서 완벽하게 합리적인 일을 할 수 없는지 궁금해하며 머리를 긁적이는 데 많은 시간을 할애하게 됩니다.로네이션컴파일러를 두드려 제출하는 것(강도의 타이핑이 가장 나쁜 경우)은 생산적인 시간 사용이 아닙니다.
나는 프로그래머 금형에 잘 맞을 것이다. 나는 컨트롤을 좋아한다.내 생각에 그것은 프로그래머에게 성격적인 결함이 아니다.통제는 우리가 돈을 받고 하는 것이다.좀 더 구체적으로 말하면, 완벽한 제어입니다.C는 C++보다 훨씬 더 많은 컨트롤을 제공합니다.
아니요. 임베디드 개발 중에는 문제를 일으킬 수 있는 C++ 언어 기능(런타임 다형성, RTI 등)을 피할 수 있습니다.임베디드 C++ 개발자의 커뮤니티(구 C/C++ Users' Journal에서 C++를 사용한 임베디드 개발자의 칼럼을 읽은 기억이 있습니다)가 있는데, 그 선택이 그렇게 나쁘다면 그들이 목소리를 낼 것이라고는 상상도 할 수 없습니다.
'무제한' 리소스를 가진 시스템은 존재하지 않는다는 것을 말하고 싶습니다.이 세상의 모든 것은 한정되어 있기 때문에, ASM, C, JAVA, JavaScript의 어느 쪽이든, 모든 애플리케이션은 자원 사용 상황을 고려해야 합니다.만약을 위해 몇 개의 Mbs를 할당하는 더미는 아이폰7, 픽셀 및 기타 기기를 매우 어렵게 만듭니다.4kb이든 40Gb이든 상관없습니다.
그러나 자원 낭비를 막기 위해서는 이러한 자원을 절약하는 데 걸리는 시간이 필요합니다.이미 실장되어 테스트되어 배포된 C++를 사용하는 대신 몇 개의 틱과 몇 바이트를 절약하기 위해 간단한 내용을 C에 쓰는 데 1주일이 더 걸리는 경우.왜 신경써요?USB 허브를 구입하는 것과 같습니다.네, 직접 만들 수 있지만, 더 나아질까요? 더 믿을 수 있을까요?시간을 계산하면 더 싸게 살 수 있나요?
한 가지 측면만 생각해도 콘센트에서 나오는 전력도 무제한은 아닙니다.그것이 어디에서 왔는지 조사해보라. 그러면 당신은 그것이 무엇인가를 태우는 것을 대부분 보게 될 것이다.에너지와 물질의 법칙은 여전히 유효합니다. 물질과 에너지는 나타나거나 사라지지 않고 오히려 변형됩니다.
펌웨어/임베디드 시스템 엔지니어로서 C가 여전히 C++보다 1위를 차지하고 있는 이유를 몇 가지 말씀드릴 수 있습니다.네, 저는 두 가지 모두에 능통합니다.
1) 개발 대상 중에는 코드와 데이터 모두에 64kB의 RAM이 탑재되어 있는 것도 있습니다.따라서 모든 바이트 수를 확인해야 합니다.네, 저는 코드 최적화에 대처하여 2시간이 소요되었습니다.그것은 2008년입니다.
2) 모든 C 라이브러리 함수는 크기 제한으로 인해 최종 코드에 넣기 전에 검토되므로 divide(하드웨어 분할기 없음), malloc(히프가 없기 때문에 모든 메모리는 512바이트 청크에서 데이터 버퍼에서 할당되어 코드를 검토해야 함) 또는 기타 객체 지향 프랙티스를 사용하지 않는 것이 좋습니다.모자는 큰 벌을 받는다.사용하는 라이브러리 기능은 모두 중요합니다.
3) 오버레이라는 말 들어보셨나요?코드 공간이 너무 적어서 다른 코드 세트와 교환해야 할 때가 있습니다.라이브러리 함수를 호출하는 경우 라이브러리 함수가 상주해야 합니다.오버레이 기능에서만 사용하면 너무 많은 객체 지향 메서드에 의존하여 많은 공간을 낭비하게 됩니다.따라서 C++는 말할 것도 없고 C 라이브러리 함수도 받아들일 수 없다고 가정하지 마십시오.
4) 하드웨어 설계(즉, 특정 방식으로 배선된 ECC 엔진)가 한정되어 있거나 하드웨어 오류에 대처하기 위해 주조 및 패킹(비정렬 데이터 구조가 워드 경계를 넘는 경우)이 필요합니다.너무 많은 것을 추측할 수는 없는데, 왜 객체가 너무 많은 방향을 잡았을까요?
5) 최악의 경우: 오브젝트 지향 메서드 중 일부를 삭제하면 데이터 버퍼가 아닌 스택에서 512바이트를 할당하는 자원을 사용하기 전에 개발이 이루어지게 됩니다.또한 코드 경로 전체를 테스트하지 않거나 모두 삭제하지 않는 최악의 시나리오도 발생할 수 있습니다.
6) 하드웨어가 소프트웨어로부터 보호되고 코드가 가능한 한 이동 가능하며 시뮬레이션이 용이하도록 하기 위해 많은 추상화를 사용하고 있습니다.하드웨어 액세스는 다른 플랫폼 간에 조건부로 컴파일된 매크로 또는 인라인 함수로 랩해야 합니다.데이터 타입은 특정 타깃이 아닌 바이트 크기로 캐스트해야 합니다.직접 포인터 사용은 허용되지 않습니다(일부 플랫폼에서는 메모리 매핑 I/O가 데이터 메모리와 동일하다고 가정하기 때문입니다).
난 더 생각할 수 있지만, 넌 알거야델의 펌웨어 담당자는 객체 지향 트레이닝을 실시하고 있습니다만, 임베디드 시스템의 태스크는 하드웨어 지향적이고 낮은 레벨이기 때문에 본질적으로 높은 레벨이나 추상화가 불가능합니다.
참고로, 제가 지금까지 해왔던 모든 펌웨어 작업은 소스 컨트롤을 사용합니다. 어디서 그런 아이디어를 얻었는지 모르겠네요.
- SanDisk에서 온 펌웨어 직원입니다.
C++ 대신에 C를 사용할 이유가 없습니다.C에서 할 수 있는 것은 C++에서도 할 수 있습니다.VMT의 오버헤드를 방지하려면 가상 메서드와 다형성을 사용하지 마십시오.
그러나 C++는 오버헤드가 없는 매우 유용한 관용구를 제공할 수 있습니다.내가 가장 좋아하는 것 중 하나는 RAII이다.메모리나 퍼포먼스 면에서 수업은 비싸지 않습니다.
IAR Workbench에 ARM7 내장 팰트폼 코드를 작성했습니다.컴파일 시간 최적화 및 경로 예측을 위해 템플릿을 사용하는 것이 좋습니다.페스트와 같은 동적 캐스팅을 피하십시오.Andrei Alexandrescu의 저서 Modern C++ 디자인에서 규정된 대로 특성/정책을 활용하십시오.
알고 있습니다. 배우기 어려울 수도 있지만, 이 방법을 통해 귀사의 제품이 혜택을 받을 수 있을 것이라고 확신합니다.
타당한 이유이며, 경우에 따라서는 유일한 이유는 특정 임베디드 시스템에 아직 C++ 컴파일러가 없기 때문입니다.예를 들어 마이크로칩 PIC 마이크로컨트롤러의 경우입니다.그것들은 쓰기 매우 쉽고 무료 C 컴파일러(실제로 C의 약간 변형)를 가지고 있지만 C++ 컴파일러는 보이지 않습니다.
RAM이 4K로 제한되어 있는 시스템에서는 C++가 아닌 C를 사용하여 모든 상황을 확인할 수 있습니다.C++의 특징은 코드를 흘끗 보는 것보다 훨씬 더 많은 리소스(CPU와 메모리 모두)를 사용하는 것이 매우 쉽다는 것입니다.(다른 BlerfObject를 만들어 보겠습니다)와! 메모리가 부족합니다!)
이미 설명한 바와 같이 C++에서는 실행할 수 있지만(RTI, vtables 등), C++ 사용률이 C에서와 같은 수준으로 떨어지지 않도록 하기 위해 많은 시간을 소비합니다.
개인적으로 4kb의 메모리는 C++에서 그다지 많은 마일리지를 얻을 수 없다고 생각합니다.그래서 그 일에 가장 적합한 컴파일러/런타임 조합으로 보이는 것을 고르세요.언어는 그다지 문제가 되지 않을 것입니다.
라이브러리도 중요하기 때문에, 어쨌든 언어의 전부는 아니라는 것을 주의해 주세요.Clibs의 최소 사이즈는 조금 작을 수 있지만, 임베디드 개발을 목적으로 한 C++lib는 잘려나간다고 생각할 수 있으므로 꼭 테스트해 보시기 바랍니다.
C는 언어 사양이 모호하지 않기 때문에 휴대성이 우수합니다.따라서 컴파일러별로 휴대성과 유연성이 대폭 향상됩니다(고장 없음).
요구를 충족시키기 위해 C++ 기능을 활용하지 않을 경우 C를 선택합니다.
매우 한정된 하드웨어(4KB의 RAM)로 개발할 때 C89를 고수할 이유가 있습니까?
개인적으로 임베디드 어플리케이션이라고 하면 winCE나 iPhone 등이 아닙니다.현재의 임베디드 디바이스는 비대합니다.리소스가 제한된 장치입니다.C++도 꽤 많이 일했지만, C를 선호합니다.
예를 들어, 말씀하신 디바이스는 4kb의 RAM을 탑재하고 있기 때문에 C++라고는 생각하지 않습니다.물론, C++를 사용하여 작은 것을 디자인하고 다른 게시물이 제안하는 것처럼 어플리케이션에서 사용하는 것을 제한할 수 있지만, C++는 잠재적으로 어플리케이션을 "복잡하게 하거나" 만들 수 있습니다.
정적으로 링크하시겠습니까?c++와 c를 사용하여 스태틱한 더미 어플리케이션을 비교할 수 있습니다.그 대신 C를 검토하도록 유도할 수 있습니다.한편, 메모리 요건내에서 C++ 애플리케이션을 구축할 수 있는 경우는, 그것을 실행해 주세요.
IMHO, 일반적으로 임베디드 어플리케이션에서는 일어나는 모든 것을 알고 싶습니다.메모리/시스템 리소스를 사용하는 사용자, 용량 및 이유는 무엇입니까?언제 풀어주죠?
X개의 리소스, CPU, 메모리 등이 있는 타깃을 위해 개발하는 경우향후 어떤 요건이 발생할지 알 수 없기 때문에 이러한 자원을 사용하는 것을 자제하려고 합니다.그 때문에, 「단순한 소규모 애플리케이션」으로 상정하고 있던 프로젝트에 코드를 추가해, 결과적으로 훨씬 더 커지게 됩니다.
제 개인적인 취향은 C입니다.
- 코드의 모든 행이 무엇을 하고 있는지 알고 있다(및 비용)
- C++에 대해 잘 모르기 때문에 모든 코드 행이 무엇을 하고 있는지(및 비용)를 알 수 없습니다.
왜 사람들이 이런 말을 하지?asm 출력을 체크하지 않으면 C의 모든 행이 무엇을 하고 있는지 알 수 없습니다.C++도 마찬가지입니다.
예를 들어, 이 무해한 스테이트먼트에 의해 생성되는 asm은 다음과 같습니다.
a[i] = b[j] * c[k];
매우 순수해 보이지만 gcc 기반의 컴파일러는 8비트 마이크로용으로 이 asm을 생성합니다.
CLRF 0x1f, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1f, F, ACCESS
MOVWF 0x1e, ACCESS
MOVLW 0xf9
MOVF 0xfdb, W, ACCESS
ADDWF 0x1e, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfa
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1f, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x1c
NOP
MOVFF 0xfef, 0x1d
NOP
MOVLW 0x1
CLRF 0x1b, ACCESS
RLCF 0xfdb, W, ACCESS
ANDLW 0xfe
RLCF 0x1b, F, ACCESS
MOVWF 0x1a, ACCESS
MOVLW 0xfb
MOVF 0xfdb, W, ACCESS
ADDWF 0x1a, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfc
MOVF 0xfdb, W, ACCESS
ADDWFC 0x1b, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0xfee, 0x18
NOP
MOVFF 0xfef, 0x19
NOP
MOVFF 0x18, 0x8
NOP
MOVFF 0x19, 0x9
NOP
MOVFF 0x1c, 0xd
NOP
MOVFF 0x1d, 0xe
NOP
CALL 0x2142, 0
NOP
MOVFF 0x6, 0x16
NOP
MOVFF 0x7, 0x17
NOP
CLRF 0x15, ACCESS
RLCF 0xfdf, W, ACCESS
ANDLW 0xfe
RLCF 0x15, F, ACCESS
MOVWF 0x14, ACCESS
MOVLW 0xfd
MOVF 0xfdb, W, ACCESS
ADDWF 0x14, W, ACCESS
MOVWF 0xfe9, ACCESS
MOVLW 0xfe
MOVF 0xfdb, W, ACCESS
ADDWFC 0x15, W, ACCESS
MOVWF 0xfea, ACCESS
MOVFF 0x16, 0xfee
NOP
MOVFF 0x17, 0xfed
NOP
생성되는 명령의 수는 다음 항목에 따라 크게 달라집니다.
- a, b, c 사이즈.
- 이러한 포인터가 스택에 저장되어 있는지 글로벌한지 여부
- i, j 및 k가 스택 상에 있는지 글로벌한지 여부
특히 프로세서가 C를 처리하도록 설정되어 있지 않은 작은 임베디드 기기에서는 더욱 그렇습니다.따라서 C와 C++는 항상 asm 출력을 조사하지 않는 한 서로 똑같이 나쁘다고 할 수 있습니다.이 경우, C와 C++는 서로 동등하게 됩니다.
휴고
메모리 할당 문제에 대해서는 초기화 시 필요한 모든 것을 할당하므로 Quantum Platform과 그 스테이트 머신의 접근방식을 사용할 것을 권장합니다.또한 경합 문제를 완화하는데도 도움이 됩니다.
이 제품은 C와 C++로 동작합니다.
컴파일러에 따라 다릅니다.
모든 임베디드 컴파일러가 C++를 실장하는 것은 아닙니다.실장한다고 해도 코드 블러트를 회피하는 것은 서툴 수 있습니다(템플릿에서는 항상 리스크가 됩니다).몇 가지 작은 프로그램으로 테스트하여 문제가 없는지 확인합니다.
하지만 좋은 컴파일러라면 C++를 사용하지 않을 이유가 없습니다.
C 컴파일러는 고도의 C++ 기능을 지원할 필요가 없기 때문에 보다 효율적인 코드를 생성할 수 있다는 의견도 있습니다.
물론 이 경우 2개의 특정 컴파일러를 테스트해 보는 것이 좋습니다.
그렇게 제한된 시스템에서.그냥 어셈블러로 가.모든 측면을 완벽하게 제어할 수 있으며 오버헤드를 발생시키지 않습니다.
많은 임베디드 컴파일러가 최적의 옵티마이저가 아니기 때문에 아마 훨씬 더 빠를 것입니다(특히 데스크톱용 컴파일러(인텔, Visual Studio 등)).
"그래, 그래...하지만 c는 재사용할 수 있고..." 이렇게 제한된 시스템에서는 다른 시스템에서 해당 코드를 재사용하지 않을 수 있습니다.같은 시스템에서 어셈블러도 마찬가지로 재사용할 수 있습니다.
일반적으로 사용하는 C 라이브러리는 디바이스의 동작에 따라 선택됩니다.그래서 9/10배..uclibc 또는 newlib 및 C가 됩니다.델이 사용하는 커널은, 이것에도 큰 영향을 줍니다.또, 독자적인 커널을 작성하는 경우에도 마찬가지입니다.
또한 공통점을 선택할 수 있습니다.대부분의 좋은 C 프로그래머들은 C++를 사용하는 데 아무런 문제가 없습니다(많은 사람들이 C++를 사용하는 내내 불평하지만).그러나 (내 경험상) 그 반대가 사실이라고는 생각하지 못했다.
현재 진행 중인 프로젝트(그라운드업 커널 포함)에서는 대부분의 작업이 C에서 수행되지만 소규모 네트워크 스택이 C++에서 구현되었습니다.이는 C++를 사용하여 네트워킹을 구현하는 것이 더 쉽고 문제가 적었기 때문입니다.
그 결과, 디바이스는 동작해, 승인 테스트에 합격하거나, 합격할 수 없게 됩니다.언어 z를 사용하여 xx 스택 및 yy 힙 제약에 foo를 구현할 수 있다면, 실행하세요.생산성이 향상되는 것은 무엇이든지 사용하세요.
제 개인적인 취향은 C입니다.
- 코드의 모든 행이 무엇을 하고 있는지 알고 있다(및 비용)
- C++에 대해 잘 모르기 때문에 모든 코드 행이 무엇을 하고 있는지(및 비용)를 알 수 없습니다.
네, C++는 편하지만 표준 C만큼 잘 모릅니다.
그 반대로 말할 수 있다면, 알고 있는 것을 사용해 주세요:) 동작하고 있는 경우, 테스트에 합격하는 경우 등.문제가 뭐죠?
ROM/FLASH는 얼마나 가지고 있습니까?
4kB의 RAM은 실제 코드와 정적 데이터를 저장하는 데 수백 킬로바이트의 플래시가 있음을 의미합니다.이 사이즈의 RAM은 변수만을 대상으로 하는 경우가 많기 때문에, 이러한 변수를 주의 깊게 다루면, 코드 라인의 관점에서 꽤 큰 프로그램을 메모리에 넣을 수 있습니다.
그러나 C++는 객체의 런타임 구성 규칙 때문에 코드와 데이터를 플래시에 넣는 것을 더 어렵게 만드는 경향이 있습니다.C에서는 FLASH 메모리에 고정 구조를 쉽게 삽입하여 하드웨어 고정 개체로 액세스할 수 있습니다.C++에서는 일정한 오브젝트는 컴파일러가 컴파일 시에 컨스트럭터를 평가해야 합니다.이것은 아직 C++ 컴파일러가 할 수 있는 수준을 넘어섰다고 생각합니다(이론적으로는 할 수 있지만 실제로는 매우 어렵습니다).
따라서 "작은 RAM"이나 "대형 플래시" 환경에서는 언제든지 C를 사용할 수 있습니다.비클래스 베이스 코드에 적합한 C++ 기능의 대부분을 갖춘 중급 옵션i C99에 주의해 주세요.
일반적으로는 아니다.C++는 C의 슈퍼 세트입니다.이는 특히 신규 프로젝트의 경우 해당됩니다.
CPU의 시간과 메모리의 풋 프린트에 있어서 비용이 많이 드는 C++구조를 회피하는 것은 올바른 방향입니다.
다형성 같은 것은 매우 가치가 있습니다.이는 본질적으로 함수 포인터입니다.만약 당신이 그것들을 필요로 한다면, 그것들을 현명하게 사용하세요.
또한 (잘 설계된) 예외 처리를 잘하면 기존 오류 코드가 있는 작업을 처리하는 앱보다 내장형 앱의 신뢰성이 향상됩니다.
사용하시는 플랫폼의 C++ 컴파일러 상태가 좋지 않은 경우(버그 있음, 최적화 불량 등)가 C IMHO를 선호하는 유일한 이유입니다.
C99는 인라인입니다.당신은 CTors를 좋아할지 모르지만, dtors를 제대로 맞추는 일은 복잡할 수 있습니다.C를 사용하지 않는 이유가 네임스페이스뿐이라면 C89를 정말 고수하고 싶습니다.이는 약간 다른 임베디드 플랫폼으로 포팅하는 것이 바람직하기 때문입니다.나중에 같은 코드로 C++로 쓰기를 시작할 수 있습니다.단, C++가 C의 슈퍼셋이 아닌 경우 다음 점에 주의해 주십시오.C89 컴파일러를 가지고 있다고 하셨는데, 이 C++와 C99의 비교는 K&R 이후 C의 첫 번째 항목이 해당됩니다.
C++가 아닌 C의 'a' > 1 크기.C에는 VLA 가변 길이 어레이가 있습니다.예: func(int i){int a[i]C에는 VAM 변수 배열 멤버가 있습니다.예: structure {int b;int m[];}.
질문의 다른 측면에 대한 답변 투고:
"초점"
이전 답변에서는 이에 대해 많은 것을 언급하고 있습니다.왜 그런 전화가 존재한다고 생각해?정말로 작은 플랫폼에서는 malloc을 사용할 수 없거나 옵션인 경우가 많습니다.동적 메모리 할당을 실장하는 것은 시스템 하부에 RTOS가 있을 때 의미가 있지만, 그 때까지는 전혀 위험합니다.
당신은 그것 없이도 멀리 갈 수 있어요.오래된 FORTRAN 프로그램을 생각해 보세요. 지역 변수를 위한 스택도 제대로 갖추지 못했습니다.
전 세계에는 다양한 컨트롤러 제조원이 있습니다.컨트롤러 제조원의 설계와 설정에 필요한 명령어 세트를 살펴보면 많은 문제가 발생할 수 있습니다.어셈블리 언어의 주요 단점은 기계/아키텍처에 의존한다는 것입니다.개발자가 다양한 컨트롤러에 대한 코딩을 수행하기 위해 정해진 모든 지침을 암기해야 하는 것은 정말 큰 요구입니다.이것이 C가 임베디드 개발에서 더욱 인기를 끈 이유이다.왜냐하면 C는 알고리즘과 데이터 구조를 하드웨어 의존적인 세부사항에서 추상화할 수 있을 만큼 충분히 높은 수준이기 때문에 소스 코드는 광범위한 대상 하드웨어, 아키텍처 독립 언어, 그리고 코드 변환과 유지보수가 매우 용이하기 때문이다.그러나 C, C++, Python, Java 등과 같은 고급 언어(개체 지향)는 임베디드 시스템 개발의 레이더에 잡힐 정도로 충분히 진화하고 있습니다.
언급URL : https://stackoverflow.com/questions/812717/is-there-any-reason-to-use-c-instead-of-c-for-embedded-development
'programing' 카테고리의 다른 글
| VueJs의 전체 애플리케이션에서 액세스할 수 있는 상수를 만드는 가장 좋은 방법은 무엇입니까? (0) | 2022.09.04 |
|---|---|
| 삭제되지 않는 Vue 구성 요소 찾기 (0) | 2022.09.03 |
| VueJS 프로펠을 변환하는 방법 (0) | 2022.09.03 |
| 어떻게 C에 구조를 배열할 수 있을까요? (0) | 2022.09.03 |
| 메서드 이름을 문자열로 지정했을 때 Java 메서드를 호출하려면 어떻게 해야 합니까? (0) | 2022.09.03 |