2017-04-22 8 views
0

내장 시스템에 C으로 개발 중이며 #define TESTING_ENABLED에 의해 활성화 된 대상 플랫폼없이 로컬에서 테스트 할 수있는 환경을 설정했습니다.임베디드 C 테스트 개발 관리

이것은 곧 프로젝트의 모든 측면을 포함하도록 확장 될 것이므로 플랫폼간에 전환 할 때 각 테스트 정의를 관리하는 것이 지루할 수 있습니다.

메이크 파일을 통해 #define directive을 설정하거나 다른 컴파일러의 사용을 감지 할 수 있습니까?

답변

1

#define#if을 사용하는 것은 여러 가지 이유로 보통 매우 나쁜 생각입니다. 코드는 다음과 같습니다. 1. 읽을 수 없습니다. 2. 휴대하기 어렵다. 3. 유지할 수없는;

일반적인 규칙은 헤더 파일에만 #define#if을 가질 수 있다는 것입니다. 전처리 기가 소스 파일에 들어가면 유지 관리 및 이식성 측면에서 프로젝트 실패에 대한 명확한 경로가됩니다. 이 코드는 위의 모든 프로젝트를 이끌어 갈

bool some_func(
    int index, 
#if SOME_DEFINE 
    bool flag, 
#else 
    struct exception* ex, 
#endif 
    void* buffer, 
    size_t size, 
) 
{ 
    ... 
} 

: 나는 코드를 본 적이 극단적 인 예를 들어

void foo() 
{ 
    ... 

#if TARGET_REAL_CPU 
    ... 
#endif 

    ... 
} 

:

그래서, 피하고은 모두 같은 코드를 비용 총 clasterfuck에!

이제 어떻게해야할까요?

추상화는 여러분의 친구입니다! 하드웨어, 플랫폼 및 컴파일러/툴 체인의 세 가지 주요 항목 간의 일반적인 구분. 어떤 사람들은 컴파일러와 플랫폼을 엉망으로 만든다.

그래서 프로젝트의 더미 예제를 만들었고 디렉토리 구조는 다음과 같아야합니다. 그것은 분리가 수행하는 방법을 당신에게 명확한 아이디어를 줄 것이다 :

firmware/ 
├── bin 
│   ├── arm 
│   ├── windows_x64 
│   └── windows_x86 
├── build 
│   ├── gcc 
│   │   └── arm 
│   ├── keil5 
│   │   └── arm 
│   └── vs2017 
│    └── windows 
├── include 
│   └── firmware 
│    └── frm.h 
├── src 
│   ├── arm 
│   │   ├── frm_init_impl.c 
│   │   └── frm_platform.h 
│   ├── frm_idle.c 
│   ├── frm_init.c 
│   ├── frm_state.c 
│   └── windows 
│    ├── frm_init_impl.c 
│    └── frm_platform.h 
└── test 
    └── firmware_test 
     ├── build 
     │   └── vs2017 
     │    └── windows 
     └── src 

1 쓰기 플랫폼 - 의존 가능한 한 많은 코드! 대부분의 경우 개발 및 디버깅이 쉬워집니다. 예를 들어, Visual Studio와 같은 편리한 환경에서 가능한 한 많은 코드로 & 디버그를 작성하는 것이 훨씬 쉽고 간단합니다. 그런 다음 vi와 gdb 또는 Keil을 사용하십시오. 이는 개인적인 견해로는 비싼 값 비싼 쓰레기입니다! 즉시 당신이이 경우 _platform.h 파일

FrmStatus frm_init() 
{ 
    // Platform in-depended code 
    ... 

    status = frm_init_impl(...); 
    if(FAILED(status)) 
    { 
     ... 
    }  

    // Platform in-depended code 
    ... 
} 

_impl.c 파일과 모든 플랫폼 특정 정의로 이동 할 수있는 플랫폼에 의존하는 기능을 가지고

2 당신이 frm_init_impl의 다른 구현을해야합니다 기능을 다른 폴더 및 파일에 Windows 시뮬레이션 코드 및 실제 칩 특정 하나라고 가정합니다. 하지만 플랫폼에 종속적 인 frm_init 기능은 언제나 동일하게 유지됩니다!

3.build 디렉터리의 다른 폴더를 사용하여 컴파일러와 도구 체인을 구분합니다. 그런 다음 해당 프로젝트 파일은 src의 해당 하위 폴더에서 특정 .c.h 개의 파일을 포함합니다.

이 접근법은 Windows 용 시뮬레이션 또는 Keil 용 에뮬레이션을 사용하여 펌웨어 용 테스트 스위트를 쉽게 개발하는 데 도움이됩니다. 그리고 실제 하드웨어를위한 테스트 프로젝트를 생성 할 수 있습니다.

내가 놓친 부분이 있으면 편집하고 커뮤니티 개발자가 도움이 될 것입니다.