'Cortex-M4'에 해당되는 글 3건

  1. 2018.01.13 STM32F4 시리즈 1
  2. 2018.01.12 Arduino vs. mbed 1
  3. 2017.12.19 Cortex-M4 환경에서 ChibiOS 사용한 기초 예제


STM32F4 시리즈는 ARM사의 Cortex-M4 코어를 사용한 ST사의 고성능 MCU로 음성신호와 같은 디지털 신호 처리에 필수적인 DSC(Digital Signal Controller)와 부동소수점 연산기(Floating Point Unit; FPU)를 내장하고 있어 기존 MCU가 가지고 있었던 약점을 극복하고, 많은 주변 장치들을 탑재하여 다양한 용도에 손쉽게 사용할 수 있도록 만들어졌습니다.


ARM Cortex-M4 기반의 STM32F4 MCU 시리즈는 180MHz 주파수까지 동작하는 플레시 메모리로부터 실행되는 최대 225 DMIPS/608 CoreMark를 갖는 Cortex-M 기반의 MCU를 위한 산업계 최고의 벤치마크 점수에 도달이 가능하게 한 ST의 NVT 기술과 ART 가속기의 지렛대 역할을 해 왔습니다.


동적 전력 스케일링으로 전류소모는 STM32F410에서 최소 89 µA/MHz으로부터 STM32F439의 260 µA/MHz까지의 플레시 범위에서 동작합니다. 다음은 STM32F4 시리즈의 중요 스펙입니다:


  • Cortex-M4 코어.

    • 최대 동작 클럭 : 168MHz

    • 최대 210DMIPS(1.25DMIPS/MHz)

    • DSP instruction

    • 16bit FPU 내장

  • Memory

    • 512KB Flash

    • 192KB SRAM + 4KB Backup SRAM

    • MPU

    • DMA

  • Peripherals

    • 16 채널 12 bit ADC. 최대 2.4MSPS

    • 2 채널 12 bit DAC

    • 16/32 bit Timer

- Advanced Control Timer

- General Purpose Timer

- Capture/Compare/PWM

    • RTC

    • Watchdog Timer

    • 6 UART/USART

    • 3 SPI, 3 I2C, SDIO

    • USB Full-speed, High-speed

    • CAN. 최대 1Mbps

    • 10/100 Ethernet

    • True Random Number Generator


다음의 STM32F4 시리즈의 ST사의 일복요연한 구분입니다. 참고하시기 바랍니다:



'Embedded Programming > STM32 Cortex-M4' 카테고리의 다른 글

NUCLEO-F446RE 보드 설정(1)  (0) 2018.01.13
NUCLEO-F446RE 보드 스펙  (0) 2018.01.13
STM32 MCU 누클레오 보드  (0) 2018.01.12
Discovery vs. Nucleo board  (1) 2018.01.11
STM32F4 시리즈의 소자 구별 방법  (0) 2018.01.03
Posted by Nature & Life


영국의 ARM사가 주도하는 mbed는 ARM-cortex기반의 MCU를 사용하여 IoT제품이나 여러 전자제품의 프로토타이핑(prototyping)을 쉽게 제작하고 Cloud 서비스 테스트까지 할수 있는 플랫폼으로, Arduino와 같은 해에 시작하고 2009년에 베타서비스를 시작했지만 2013년에야 mbed를 오픈하기로 결정하고 주변 디바이스, API, 기판 설계 데이터, 펌웨어 등을 공개하면서 주목받기 시작하였습니다.



사실 기존에는 Arduino라는 가볍고 쉬운 AVR이 존재했지만 ARM 계열에서는 Arduino Due 제외하고는 가볍고 쉬운 AVR은 없었고 대부분 전문 컴파일러를 사용하여 제작하였기 때문에 전문가가 아니면 사용하기가 어려웠었습니다. 그렇기 때문에 ARM에서도 Arduino와 같이 접근성이 좋고 빠르게 개발이 가능하도록 만든 소프트웨어가 바로 "mbed"라는 것입니다. 아직까지 국내에서는 Arduino보다 인지도가 적은 편이지만 Ardunio보다 더 좋은 성능으로 IoT개발 보드 시장 영역을 넓혀가고 있다는 것입니다.


참고로 ARM사의 cortex-M4를 MCU의 경우에는 IoT에서 가장 중요한 화두인 전력문제에 있어서 저전력기술을 활용함으로써, 100~180MHz로 동작하는 동안 매우 낮은 동적 전력 사용량을 제공하며, 경쟁사 유사제품에 비해 7배 낮은 정적 소비 전력을 보여줍니다. 


웹브라우저를 통한 온라인 컴파일 및 소스 버전 관리 기능(Web-IDE)을 제공하여 어떤 OS에서든 웹브라우저에서 온라인으로 컴파일이 가능하고, 프로그램 업로드는 별도 장비없이 USB에 연결만 하면 가능하도록 되어 있다는 것입니다. 게다가 커뮤니티를 통한 라이브러리 공개 및 방대한 개인 위키 페이지 제공으로 협업에 유익하고 무엇보다, 모든 사용자가 기본적으로 같은 하드웨어를 이용하고 있기에 확장 보드가 아닌 이상 바로 적용 가능하다는 것입니다.



mbed의 장점으로는 기본적으로 MCU의 성능이 Arduino보다 좋기 때문에 고성능으로 더 높은 사양대를 커버할 수 있지만, Ardunio에 비해 상대적으로 사용자가 적다는 단점이 있습니다. 온라인 컴파일러에서 브레이크 포인터를 사용하여 스텝별 실행 및 내부 레지스터, 변수 등의 디버깅은 불가능하고 프로그램 업로드 방식에 있어서도 파일을 추출하고 이 파일을 다시 보드에 업로드 시켜야하는 상대적으로 Arduino에 비해 귀찮은 과정도 단점으로 여겨질 수 있습니다.


Arduino와 mbed 차이점으로, 모든 Arduino는 Atmel MCU 사용하여 작은 메모리와 제한된 기능을 가지고 있으며 느리다는 것입니다. 대부분의 Arduino 보드들은 ATmega328이고, Mega보드는 ATmega2560이며, 새로운 Due보드는 ARM Cortex-M3를 사용한다. 반면에 mbed 플랫폼은 더 빠르고, 메모리도 크고, 더 많은 기능을 가진 ARM Cortex MCU를 사용합니다. 사실 공식적인 mbed 플랫폼들은 Cortex-M0, M3와 M4를 기반으로 만들어진다는 것입니다.


프로토타입을 만드는데는 둘 다 우수하지만 프로토타입을 만든 후에 생산을 하고자 할 때는 mbed가 더 scalable한 플랫폼이기 때문에 더 낮고, 아주 간단한 응용제품을 제외하고는 ARM MCU들이 같거나 더 싼 가격에 더 낮은 전력 소모를 하며, 더 많은 기능을 가지고 있기 때문에 그 입지가 점점 좁아지고 있다는 것입니다.



Posted by Nature & Life
Embedded Programming/ChibiOS2017. 12. 19. 19:29


http://www.playembedded.org/blog/en/2017/08/24/demos-chibios-stm32/

http://www.playembedded.org/blog/en/2016/10/29/explanation-multithreading-chibios/


Cortex-M4 MCU(ST32F4)를 환경에서 Real Time OS(RTOS)인 ChibiOS를 이용한 임베디드(embedded) 시스템의 코딩의 예제입니다. 참고하시기 바랍니다.

 

주요 헤더 파일입니다.

chconf.h

Kernel에 관련된 세팅이 포함되며 예를 들어 시스템 Timer와 Kernel 파라미터, 디버깅에 연관된 스위치 등입니다.

/*===========================================================================*/
/**
* @name Debug options
* @{
*/
/*===========================================================================*/
 
/**
* @brief   Debug option, kernel statistics.
*
* @note    The default is @p FALSE.
*/
#define CH_DBG_STATISTICS                   FALSE
 
/**
* @brief   Debug option, system state check.
* @details If enabled the correct call protocol for system APIs is checked
*          at runtime.
*
* @note    The default is @p FALSE.
*/
#define CH_DBG_SYSTEM_STATE_CHECK           FALSE
 
/**
* @brief   Debug option, parameters checks.
* @details If enabled then the checks on the API functions input
*          parameters are activated.
*
* @note    The default is @p FALSE.
*/
#define CH_DBG_ENABLE_CHECKS                FALSE
 
/**
* @brief   Debug option, consistency checks.
* @details If enabled then all the assertions in the kernel code are
*          activated. This includes consistency checks inside the kernel,
*          runtime anomalies and port-defined checks.
*
* @note    The default is @p FALSE.
*/
#define CH_DBG_ENABLE_ASSERTS               FALSE
 
/**
* @brief   Debug option, trace buffer.
* @details If enabled then the trace buffer is activated.
*
* @note    The default is @p CH_DBG_TRACE_MASK_DISABLED.
*/
#define CH_DBG_TRACE_MASK                   CH_DBG_TRACE_MASK_DISABLED
 
/**
* @brief   Trace buffer entries.
* @note    The trace buffer is only allocated if @p CH_DBG_TRACE_MASK is
*          different from @p CH_DBG_TRACE_MASK_DISABLED.
*/
#define CH_DBG_TRACE_BUFFER_SIZE            128
 
/**
* @brief   Debug option, stack checks.
* @details If enabled then a runtime stack check is performed.
*
* @note    The default is @p FALSE.
* @note    The stack check is performed in a architecture/port dependent way.
*          It may not be implemented or some ports.
* @note    The default failure mode is to halt the system with the global
*          @p panic_msg variable set to @p NULL.
*/
#define CH_DBG_ENABLE_STACK_CHECK           FALSE
 
/**
* @brief   Debug option, stacks initialization.
* @details If enabled then the threads working area is filled with a byte
*          value when a thread is created. This can be useful for the
*          runtime measurement of the used stack.
*
* @note    The default is @p FALSE.
*/
#define CH_DBG_FILL_THREADS                 FALSE
 
/**
* @brief   Debug option, threads profiling.
* @details If enabled then a field is added to the @p thread_t structure that
*          counts the system ticks occurred while executing the thread.
*
* @note    The default is @p FALSE.
* @note    This debug option is not currently compatible with the
*          tickless mode.
*/
#define CH_DBG_THREADS_PROFILING            FALSE
 

/** @} */


halconf.h

ChibiOS/HAL 드라이버에 관련된 특성을 포함합니다. 예를 들어, PAL, CAN, ADC, DAC, PWM, Serial 드라이버 등이 해당됩니다. 참고로 사용하지 않는 드라이버는 disable 시켜야 합니다.


/**
* @brief   Enables the PAL subsystem.
*/
#if !defined(HAL_USE_PAL) || defined(__DOXYGEN__)
#define HAL_USE_PAL                 TRUE
#endif
 
/**
* @brief   Enables the ADC subsystem.
*/
#if !defined(HAL_USE_ADC) || defined(__DOXYGEN__)
#define HAL_USE_ADC                 FALSE
#endif
 
/**
* @brief   Enables the CAN subsystem.
*/
#if !defined(HAL_USE_CAN) || defined(__DOXYGEN__)
#define HAL_USE_CAN                 TRUE
#endif
 
/**
* @brief   Enables the DAC subsystem.
*/
#if !defined(HAL_USE_DAC) || defined(__DOXYGEN__)
#define HAL_USE_DAC                 FALSE

#endif


mcuconf.h

MCU에 관련된 모든 설정을 포함합니다. 따라서 MCU에 따라 다릅니다. Clock 트리, DMA, IRQ 우선순위 등이 예입니다.


ChibiOS의 가장 중요한 특성 중의 하나는 멀티스레딩(multi-threading)입니다. 이는 Kernel이 한가지 이상의 스레드를 독립적으로 나란히 동시에 실행하는 것입니다. 스레드는 실제의 함수이고 시작되었을 때 우선순위 레벨(priority level)과 working area에 연관됩니다. Working area는 스레드에 할당된 메모리의 부분이고 우선 순위는 상대적인 숫자로 나타냅니다.


모든 스레드는 그 루프 내에 sleep과 suspending 함수를 가져야 합니다. 이런 방식으로 CPU의 소유권은 여러 스레드 사이에서 스위치 되고 스케쥴은 진행될 수 있습니다. ChibiOS는 다른 sleep 함수를 제공합니다. 다음 함수는 XXX [ms] 시간 동안 스레드를 suspending 합니다. 이 함수는 ChibiOS 이하의 os\rt\include\chthreads.h에 선언되어 있습니다.


chThdSleepMilliseconds(<xxx>);


Makefile

Embitz와 같은 IDE 환경을 사용시 일일이 지정해야 하고 IDE 툴마다 다를 수 있지만, 전통적인 Unix 환경에서 Makefile을 이용한 방법이 일목요연하고 유지관리가 용이하기 때문에 Makefile을 이용한 빌드 기준으로 설명합니다.


ChibiOS를 사용하기 위해서는 ChibiOS가 설치된 상대 경로의 지정이 필요합니다. 

# Imported source files and paths
PROJECT = build
CHIBIOS = ../../..
MCU = cortex-m4
TRGT = arm-none-eabi-


참고로 'build'는 프로젝트 이름이며 MCU는 cortex-m4이고 TRGT는 GNU Toolchain을 사용함을 의미합니다.

main.c

static THD_WORKING_AREA(waThread1, 128);
static THD_FUNCTION(Thread1, arg) {
 
  (void)arg;
  chRegSetThreadName("Thread1");
  while (true) {
    palTogglePad(GPIOA, GPIOA_LED_GREEN);
    chThdSleepMilliseconds(200);
  }
}
 
int main(void) {
  halInit();
  chSysInit();
 
  chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO + 1, Thread1, NULL);
  while (true) {
    palTogglePad(GPIOA, GPIOA_LED_RED);
    chThdSleepMilliseconds(375);
  }

}


위의 예제에서 128byte의 크기를 갖는 waThread1라는 이름의 working area를 선언하고 Thread1이라는 함수를 선언합니다. 위의 두 라인은 단지 메모리와 함수를 선언한 것이며 main() 함수에서 thread 생성을 시켜야 사용할 수 있습니다. THE_FUNCTION의 arg는 함수 내부 코드로 전달되는 인자입니다.


chRegSetThreadName("blinker");


위 함수는 루프 이전에 단 한번 실행됩니다. 이 함수는 ChibiOS 이하의 os\rt\include\chregistry.h에 선언되어 있습니다.



main()함수 내의 2가지 함수가 실행되는데 이는 시스템 초기화를 실행하는 것으로, hallnit()는 ChibiOS/HAL과 HAL 서브 시스템을 초기화 하는 것이며 chSysInit()는 ChibiOS/RT의 API와 Kernel을 초기화합니다. 이후에는 main() 함수의 스레드와 다른 모든 스레드가 실행될 준비가 되지 않았을 때 실행되는 idle 스레드가 생성됩니다. 또한 이들 초기화 이전에 어떤 API의 실행은 하지 말아야 합니다. ChibiOS/RT 그리고 ChibiOS/HAL에 근거한 모든 프로그램은 위와 동일한 방식으로 시작합니다. 여기서 halInit() 함수는 ChibiOS 이하의 os\hal\include\hal.h에 그리고 chSysInit() 함수는 ChibiOS 이하의 os\rt\include\chsys.h에 선언되어 있습니다.


palTogglePad() 함수는 ChibiOS 이하의 os\hal\include\hal_pal.h에 선언되어 있으며, 첫번째 인자는 포트이고 두번째 인자는 그 포트 내에서의 패드 숫자입니다. 따라서 이 함수는 해당 포트의 해당 패드에 그 논리적인 상태 즉, LED를 토글(toggle)합니다.



chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO + 1, Thread1, NULL);


위의 스레드의 생성 함수는 5개의 인자가 필요하며 첫번째는 working area의 포인트이며 마지막 인자는 Thread1 함수로 전달될 파라미터로 이 경우에는 아무것도 보내지 않습니다. 이 함수는 ChibiOS 이하의 os\rt\include\chthreads.h에 선언되어 있습니다.


이 경우에 3개의 스레드인, Thead1, main, idle가 있으며 즉, Kernel은 3가지 스레드를 관리게 되는데 개념적인 timing 플로우는 다음과 같습니다.



위 그림에서 스레드는 y축 상에 우선순위에 따라 실행되고 x축은 시간이 됩니다. chSysInit()이 실행될 때 main() 함수는 main이라는 스레드가 되고 Thread1의 생성될 때까지 실행됩니다. Thread1이 생성된 후에는 main와 Thread1이 준비된 상태가 됩니다. 


ChibiOS의 우선순위는 정수이고 LOWPRIO와 HIGHPRIO의 범위를 가지며 main 스레드는 NORMALPRIO의 우선 순위를 가지며 전체 범위의 중간 값을 가집니다. Thread1과 main() 함수 내에 chThdSleepMilliseconds() 함수는 시간을 지연시키지만 그 동안 CPU의 소유권을 다음의 우선순위 스레드에 넘기게 됩니다.



'Embedded Programming > ChibiOS' 카테고리의 다른 글

ChibiOS/RT 설치  (1) 2018.02.25
ChibiOS/RT의 특징  (0) 2018.02.25
Posted by Nature & Life