PIC32 vs dsPIC vs ARM vs AVR, 어쨌든 C 언어로 프로그래밍 할 때 아키텍처가 중요합니까? [닫은]

현재 32 비트 PIC32 마이크로 컨트롤러를 사용하고 있습니다. 그것은 우리의 요구에 잘 작동하지만 우리는 더 잘 어울릴 수있는 다른 마이크로 컨트롤러를 탐구하고 있습니다. 우리는 MCU를 선택하는 다른 프로젝트가 있습니다. 이를 위해 32 비트는 동일하지만 ARM을 기반으로하는 ARM 기반 SAM DA 마이크로 컨트롤러를 선택했습니다 (PIC32보다 업계에서 널리 사용됨).

이제 PIC32에는 MPLAB을 사용하지만 ARM cortex-M0에는 Atmel Studio를 사용합니다. 두 플랫폼 모두에서 C 언어를 사용할 것입니다. 내가 염려하는 것은 (같은 회사의) 두 개의 32 비트 마이크로 컨트롤러를 사용하지만 다른 아키텍처를 사용한다는 것입니다. 이를 위해서는 두 가지 장치를 배우고 "학습 곡선"+ 배달 시간을 늘릴 것입니다. 그러나 다른 한편으로는 두 경우 모두 C 언어를 사용할 것이기 때문에 ARM의 학습 곡선은 들리지 않아야하며 해당 프로세서를 탐색 할 가치가 있습니다.

저의 주요 질문은 C- 언어에서 프로그래밍 할 때 아키텍처가 마이크로 컨트롤러의 내부를 추상화하기 때문에 얼마나 큰 차이가 있는지입니다. 그리고 MPLAP 및 아트멜 Studio의 주요 차이점 무엇입니까 C 언어 프로그래밍을 고려은.

이것은 꽤 의견이 많은 주제입니다. 나 자신을 위해 말할 수 있습니다 (AVR, ARM, MSP430).

차이 1 (가장 중요한)은 주변 장치에 있습니다. 각 MCU에는 유사한 UART, SPI, 타이머 등이 ​​있습니다. 레지스터 이름과 비트 만 다릅니다. 대부분의 경우 칩간에 코드를 이동할 때 처리해야하는 주요 문제였습니다. 해결 방법 : 공통 API로 드라이버를 작성하여 응용 프로그램을 이식 가능하게 만드십시오.

차이점 2는 메모리 아키텍처입니다. AVR에 상수를 플래시로 저장하려면 특수 속성과 특수 함수를 사용하여 읽어야합니다. ARM 세계에서는 단일 주소 공간이 있기 때문에 포인터를 역 참조합니다 (작은 PIC가 처리하는 방법을 모르지만 AVR에 더 가깝다고 가정합니다).

차이점 3은 인터럽트 선언 및 처리입니다. avr-gcc이 ISR()매크로를. ARM은 함수 이름 (예 : CMSIS 헤더 및 시작 코드를 사용하는 경우 someUART_Handler ()) 만 있습니다. ARM 인터럽트 벡터는 어디든지 (RAM 포함) 배치하고 런타임에 수정할 수 있습니다 (예를 들어 전환 할 수있는 두 개의 서로 다른 UART 프로토콜이있는 경우 매우 유용합니다). AVR에는 "메인 플래시"또는 "부트 로더 섹션"에서 벡터를 사용하는 옵션 만 있습니다 (따라서 인터럽트를 다르게 처리하려면 if명령문 을 사용해야합니다 ).

차이점 4-절전 모드 및 전원 제어. 가장 낮은 전력 소비가 필요한 경우 MCU의 모든 기능을 활용해야합니다. 이는 MCU마다 크게 다를 수 있습니다. 일부는 더 거친 절전 모드가 있고 일부는 개별 주변 장치를 활성화 / 비활성화 할 수 있습니다. 일부 MCU에는 조정 가능한 레귤레이터가있어 느린 속도 등으로 낮은 전압으로 작동시킬 수 있습니다 .3 가지 글로벌 전원 모드와 7 가지 전원 모드 및 개별 주변 장치 클록 제어.

이식성을 고려할 때 가장 중요한 것은 코드를 하드웨어 종속 (드라이버) 및 하드웨어 독립적 (응용 프로그램) 부분으로 명확하게 분할하는 것입니다. 모의 드라이버 (예 : UART 대신 콘솔)가있는 일반 PC에서 후자를 개발하고 테스트 할 수 있습니다. 프로토 타입 하드웨어가 리플 로우 오븐에서 나오기 전에 애플리케이션 코드의 90 %가 완료되어 여러 번 절약했습니다. :)

제 생각에 ARM에 대한 좋은 점은 많은 컴파일러 (gcc, Keil, IAR ...), 자유롭고 공개적으로 지원되는 IDE (적어도 NXP, STM32, Silicon Labs, Nordic), 많은 디버그 도구 (SEGGER-특히 Ozone, ULINK, OpenOCD ...) 및 많은 칩 공급 업체 (이름조차도 밝히지 않습니다). PIC32는 대부분 Microchip으로 제한되지만 도구를 좋아하지 않는 경우에만 중요합니다.

C 코드에 관해서. 99 % 동일하고 if명령문이 동일하며 루프가 동일한 방식으로 작동합니다. 그러나 기본 단어 크기에주의해야합니다. 예를 들어 카운터에 for사용 uint8_t하는 경우 AVR 의 루프가 가장 빠르지 만 ARM의 uint32_t경우 가장 빠른 유형 (또는 int32_t)입니다. 더 작은 유형을 사용하는 경우 ARM은 매번 8 비트 오버플로를 확인해야합니다.

일반적으로 MCU 및 / 또는 공급 업체 를 선택하는 것은 주로 정치 및 물류에 관한 것입니다 (예 : 고온-MSP430 또는 Vorago 사용과 같은 명확한 엔지니어링 제약이없는 경우). 응용 프로그램이 무엇이든 실행될 수 있고 제품 수명 동안 5 %의 코드 (드라이버) 만 개발 및 지원 해야하더라도 여전히 회사의 추가 비용입니다. 내가 일했던 모든 장소에는 좋아하는 벤더와 MCU 라인이있었습니다 (예 : "다른 것을 선택해야 할 이유가없는 한 원하는 Kinetis를 선택하십시오"). 다른 사람이 도움을 요청하는 경우에도 도움이되므로 관리자는 모든 사람이 완전히 다른 칩을 사용하는 5 인 개발 부서를 피하는 것이 좋습니다.

저는 4 개의 다른 제조업체의 여러 MCU를 사용했습니다. 매번 다시 주요 작업은 주변 장치에 익숙해지는 것입니다.

예를 들어 UART 자체는 너무 복잡하지 않으며 드라이버 포트를 쉽게 찾을 수 있습니다. 그러나 마지막으로 시계, I / O 핀 인터럽트, 활성화 등을 얻는 데 거의 하루가 걸렸습니다.

GPIO는 매우 복잡 할 수 있습니다. 비트 세트, 비트 클리어, 비트 토글, 특수 기능 활성화 / 비활성화, 3 상태. 다음으로 모든 에지, 상승, 하강, 레벨 하한, 레벨 상한, 자체 클리어링 여부에 따라 인터럽트를받습니다.

그런 다음 I2C, SPI, PWM, 타이머 및 각각 고유 한 클럭 기능을 갖춘 24 개 이상의 주변 장치 유형이 있으며 레지스터가 새로운 비트와 다를 때마다 있습니다. 이러한 모든 상황에서 어떤 상황에서 어떤 비트를 설정하는 방법에 대한 데이터 시트를 읽는 데 많은 시간이 걸립니다.

마지막 제조업체에는 사용할 수없는 많은 코드 예제가 있습니다. 모든 것이 추상화되었습니다. 그러나 내가 추적했을 때 코드는 6을 통과 했습니다! GPIO 비트를 설정하기위한 함수 호출 레벨. 3GHz 프로세서는 있지만 48MHz MCU에는 적합하지 않습니다. 결국 내 코드는 한 줄이었습니다.

GPIO->set_output = bit.

더 일반적인 드라이버를 사용하려고 시도했지만 포기했습니다. MCU에서는 항상 공간과 클럭 사이클로 어려움을 겪고 있습니다. 10KHz라는 인터럽트 루틴에서 특정 파형을 생성하는 경우 추상화 계층이 창을 가장 먼저 나가는 것으로 나타났습니다.

이제 모든 것이 작동하고 있으며 아주 좋은 이유가 아니라면 다시 전환하지 않을 계획입니다.

위의 모든 사항은 판매 한 제품 수와 저장 한 제품에 대해 상각되어야합니다. 백만 판매 : 다른 유형으로 전환하기 위해 0.10을 절약하면 소프트웨어 작업 시간에 100.000을 소비 할 수 있습니다. 1000을 판매하면 100 만 지출 할 수 있습니다.

이것은 답변보다 의견 / 의견입니다.

당신은 C로 프로그래밍하고 싶지 않으며 그렇게해서는 안된다. C ++ 은 올바른 방식으로 사용될 때 훨씬 우수하다. (좋아요, 잘못된 방식으로 사용하면 C보다 훨씬 나쁩니다.) AVR을 포함하여 GCC에서 지원하는 거의 모든 (현대) C ++ 컴파일러가있는 칩으로 제한합니다. 일부 제한 사항에서 filo는 비 균일 주소 공간의 문제를 언급하지만 거의 모든 PIC를 제외합니다 (PIC32는 지원 될 수 있지만 아직 괜찮은 포트는 보지 못했습니다).

C / C ++에서 알고리즘을 프로그래밍 할 때 언급 한 선택 사항의 차이는 작습니다 (여러분이 16, 32 또는 그 이상의 비트 산술을 수행 할 때 8 또는 16 비트 칩이 심각한 불리 함을 제외하고). 마지막 성능의 온스가 필요할 경우 어셈블러 (공급 업체 또는 타사에서 제공 한 코드 또는 자체)를 사용해야합니다. 이 경우 선택한 칩을 다시 고려할 수 있습니다.

하드웨어를 코딩 할 때 일부 추상화 계층 (주로 제조업체에서 제공)을 사용하거나 데이터 시트 및 / 또는 예제 코드를 기반으로 자체 추상화 계층을 작성할 수 있습니다. IME 기존 C 추상화 (mbed, cmsis, ...)는 종종 기능적으로 (거의) 정확하지만 성능에 크게 실패합니다 (핀 세트 작업을 위해 6 개의 간접 레이어가 간접적인지 확인), 유용성 및 이식성. 그들은 특정 칩의 모든 기능을 당신 에게 노출하려고합니다 . 거의 모든 경우에 당신은 필요하지 않고 신경 쓰지 않을 것이며, 코드를 특정 벤더 (그리고 아마도 특정 칩)에 고정시킵니다.

이것은 C ++이 훨씬 더 잘 할 수 있다는 것입니다. 올바르게 설정하면 핀 세트가 6 개 이상의 추상화 계층을 통과 할 수 있습니다 (더 나은 (휴대용!) 인터페이스와 더 짧은 코드를 가능하게 하기 때문에) 대상과 독립적 인 인터페이스를 제공합니다 간단한 경우에 , 그리고 당신이 어셈블러로 작성하는 것처럼 여전히 같은 기계 코드 발생 .

내가 사용하는 코딩 스타일의 스 니펫은 당신을 열정적으로 만들거나 공포에서 벗어날 수 있습니다.

// GPIO part of a HAL for atsam3xa
enum class _port { a = 0x400E0E00U, . . . };

template< _port P, uint32_t pin >
struct _pin_in_out_base : _pin_in_out_root {

   static void direction_set_direct( pin_direction d ){
      ( ( d == pin_direction::input )
         ? ((Pio*)P)->PIO_ODR : ((Pio*)P)->PIO_OER )  = ( 0x1U << pin );
   }

   static void set_direct( bool v ){
      ( v ? ((Pio*)P)->PIO_SODR : ((Pio*)P)->PIO_CODR )  = ( 0x1U << pin );    
   }
};

// a general GPIO needs some boilerplate functionality
template< _port P, uint32_t pin >
using _pin_in_out = _box_creator< _pin_in_out_base< P, pin > >;

// an Arduino Due has an on-board led, and (suppose) it is active low
using _led = _pin_in_out< _port::b, 27 >;
using led  = invert< pin_out< _led > >;

실제로는 추상화 계층이 더 있습니다. 그러나 LED의 최종 사용은 전원을 켜고 대상의 복잡성이나 세부 사항을 보여주지 않습니다 (아두 인 우노 또는 ST32 파란색 알약의 경우 코드가 동일 함).

target::led::init();
target::led::set( 1 );

컴파일러는 이러한 모든 계층에 위협을받지 않으며, 옵티마이 저가 모든 것을 통해 보는 가상 기능이 없기 때문에 (주변 클럭 활성화와 같은 일부 세부 사항은 생략)

 mov.w  r2, #134217728  ; 0x8000000
 ldr    r3, [pc, #24]   
 str    r2, [r3, #16]
 str    r2, [r3, #48]   

이것이 어셈블러에서 어떻게 작성했는지입니다. PIO 레지스터를 공통베이스의 오프셋과 함께 사용할 수 있다는 것을 깨달았습니다. 이 경우 아마도 그렇 겠지만 컴파일러는 나보다 그런 것들을 최적화하는 데 훨씬 좋습니다.

내가 대답하는 한 그것은 하드웨어에 대한 추상화 계층을 작성하지만 현대 C ++ (개념, 템플릿)로 수행하면 성능에 해를 끼치 지 않습니다. 이를 통해 다른 칩으로 쉽게 전환 할 수 있습니다. 당신은 당신이 누워있는 임의의 칩에서 개발을 시작할 수 있고, 친숙하고, 좋은 디버깅 도구를 가지고 있으며, 나중에 (필요한 메모리, CPU 속도 등에 대한 자세한 정보가있을 때까지) 최종 선택을 연기 할 수 있습니다.

임베디드 개발의 잇점 중 하나 인 IMO는 먼저 칩을 선택하는 것입니다 (이 포럼에서 자주 묻는 질문입니다. 어떤 칩을 선택해야하는지 .... 가장 좋은 대답은 일반적으로 중요하지 않습니다).

(편집- "현명한 성능, C 또는 C ++의 레벨이 같습니까?"에 대한 응답)

동일한 구성의 경우 C와 C ++은 동일합니다. C ++에는 도구와 마찬가지로 선이나 악에 사용될 수있는 추상화 (클래스, 템플릿, constexpr)에 대한 훨씬 더 많은 구성이 있습니다. 토론을 더 흥미롭게 만들기 위해 : 모든 사람이 좋고 나쁜 것에 동의하지는 않습니다 ...

올바르게 이해하면 C 언어 환경에서 플랫폼의 아키텍처 별 기능이 "팝업"되어 두 플랫폼 모두에서 유지 관리 가능하고 이식 가능한 코드를 작성하는 것이 더 어려워 지는지 알고 싶습니다.

C는 "휴대용 어셈블러"라는 점에서 이미 매우 유연합니다. 선택한 모든 플랫폼에는 C89 및 C99 언어 표준을 지원하는 GCC / 상업용 컴파일러가 제공되므로 모든 플랫폼에서 유사한 코드를 실행할 수 있습니다.

몇 가지 고려 사항이 있습니다.

• 일부 아키텍처는 Von Neumann (ARM, MIPS)이고 다른 아키텍처는 하버드입니다. C 프로그램이 ROM에서 데이터를 읽어야 할 때 (예 : 문자열 인쇄) "const"또는 이와 유사한 데이터가 정의 된 경우 주요 제한 사항이 발생합니다.

일부 플랫폼 / 컴파일러는이 "제한"을 다른 플랫폼보다 더 잘 숨길 수 있습니다. 예를 들어 AVR에서는 ROM 데이터를 읽으려면 특정 매크로를 사용해야합니다. PIC24 / dsPIC에는 전용 tblrd 인스트럭션도 있습니다. 그러나 일부 부품 에는 FLASH 페이지를 RAM에 매핑 할 수 있는 "프로그램 공간 가시성"(PSVPAG) 기능도있어 tblrd없이 즉시 데이터 주소 지정을 사용할 수 있습니다. 컴파일러는이를 매우 효과적으로 수행 할 수 있습니다.

ARM과 MIPS는 Von Neumann이므로 ROM, RAM 및 주변 장치를위한 메모리 영역이 1 개의 버스에 압축되어 있습니다. RAM에서 데이터를 읽는 것과 "ROM"사이에는 차이가 없습니다.

• C 미만으로 다이빙하고 특정 작업에 대해 생성 된 지침을 보면 I / O와 관련하여 큰 차이점이 있습니다. ARM 및 MIPS는 RISC 로드 저장소 레지스터 아키텍처 입니다. 즉, 메모리 버스의 데이터 액세스는 MOV 명령을 거쳐야합니다. 또한 주변 장치 값을 수정하면 RMW (read-modify-write) 작업이 수행됩니다. 비트 밴드를 지원하고 I / O 주변 공간에 세트 / clr 비트 레지스터를 매핑하는 ARM 부품이 있습니다. 그러나이 액세스를 직접 코딩해야합니다.

반면 PIC24를 사용하면 ALU 작업이 간접 주소 지정을 통해 (포인터를 수정하더라도) 직접 데이터를 읽고 쓸 수 있습니다. 이것은 아키텍처와 같은 CISC의 일부 특성을 가지므로 하나의 명령으로 더 많은 작업을 수행 할 수 있습니다. 이 디자인은 더 복잡한 CPU 코어, 더 낮은 클럭, 더 높은 전력 소비 등을 초래할 수 있습니다. 다행히도 부품은 이미 설계되었습니다. ;-)

이러한 차이는 PIC24가 유사하게 클럭 된 ARM 또는 MIPS 칩보다 "더 펀치감있는"Wrt I / O 작업 일 수 있음을 의미 할 수 있습니다. 그러나 동일한 가격 / 패키지 / 디자인 제약 조건에서 훨씬 더 높은 클럭킹 ARM / MIPS 부품을 얻을 수 있습니다. 실질적인 용어로, "플랫폼을 배우는 것"은 아키텍처가 할 수있는 것과 할 수없는 것, 몇 가지 작업이 얼마나 빠를 지 등을 파악하고 있다고 생각합니다.

• 주변 장치, 클록 관리 등은 부품 계열에 따라 다릅니다. 엄밀히 말하면 이는 NVIC 및 SysTick과 같은 몇 가지 Cortex m 바운드 주변 장치를 제외하고 ARM 에코 시스템 내에서 공급 업체간에 변경 될 것입니다.

이러한 차이는 장치 드라이버에 의해 다소 캡슐화 될 수 있지만 결국 임베디드 펌웨어는 하드웨어와 높은 수준의 결합을 갖기 때문에 때때로 사용자 정의 작업을 피할 수 없습니다.

또한 Microchip / former Atmel의 에코 시스템을 떠나는 경우 ARM 부품이 더 많은 설정이 필요하다는 것을 알 수 있습니다. 나는 측면에서 의미한다. 주변 장치에 클럭을 활성화 한 다음 주변 장치를 구성하고 "활성화"하고 NVIC를 별도로 설정하는 등의 작업은 학습 곡선의 일부일뿐입니다. 이러한 모든 작업을 올바른 순서로 수행해야한다는 것을 기억하면 이러한 모든 마이크로 컨트롤러에 대한 장치 드라이버 작성은 어느 시점에서 매우 유사하게 느껴질 것입니다.

• 또한 stdint.h, stdbool.h 등과 같은 라이브러리를 아직 사용하지 않은 경우 사용하십시오. 이 정수 유형은 폭을 명시 적으로 만들어 플랫폼간에 코드 동작을 가장 예측 가능하게 만듭니다. 이는 8 비트 AVR에서 32 비트 정수를 사용함을 의미 할 수 있습니다. 그러나 코드가 필요하다면 그렇게하십시오.

예, 아니오 프로그래머 관점에서는 명령 세트의 세부 사항을 숨기는 것이 이상적입니다. 그러나 그것은 프로그램을 작성하는 요점 인 주변 장치가 어느 정도 이미 관련되지 않았기 때문에 명령 세트의 일부가 아닙니다. 이제 동시에 C를 사용하는 경우 플래시 / 메모리 소비량이 명령어 세트와 컴파일러에 의해 크게 결정되는 경우 이러한 명령어 세트에서 4096Byte 플래시 부품을 비교할 수는 없습니다. 기침) 컴파일에 의해 소비되는 자원의 낭비로 인해. 다른 플래시 소비는 더 작은 오버 헤드입니다. MCU 애플리케이션에서 고급 언어 및 성능 문제를 사용할 때 성능도 문제가되므로 MCU 당 보드 당 3 달러 또는 1 달러를 소비하는 것 사이에 차이를 만들 수 있습니다.

프로그래밍의 편의성을 높이려면 (제품의 전체 비용으로) 명령어 세트 아키텍처가 전혀 볼 수없는 mcu 용 개발자 패키지를 다운로드 할 수 있어야합니다. 따라서 이것이 주요 관심사 인 경우 걱정하지 마십시오. 이러한 라이브러리를 사용하기 위해서는 제품 비용만큼 비용이 들지만 시장 출시 시간 은 이 짧을 있습니다. 라이브러리가 주변 장치와 직접 통신하는 것보다 사용 / 시간이 더 오래 걸립니다.

가장 중요한 것은 명령어 세트가 걱정할 필요가 없으며 실제 문제로 넘어가는 것입니다.