Drone's DIYer

1. 오픈 소스 소프트웨어

오픈소스 플랫폼은 결국 크게는 두 가지로 분류 해볼 수 있다. Non-OS 기반의 펌웨어로 구성된 소프트웨어와 그에 맞는 FC 보드가 있고, OS(Embedded Linux, RTOS) 기반의 소프트웨어와 그에 맞는 FC 보드가 있습니다.

1. ArduPilot(https://ardupilot.org/)

ArduPilot은 세계 최대 아마추어 자작 드론 커뮤니티 DIY Drones(http://diydrones.com)에서 2007년부터 시작된 GNU GPL v3 라이선스의 오픈 소스 드론 프로젝트이다. 하드웨어로는 APM(ArduPilot Mega), pixhawk, pixhawk2이라 하여 Arduino 기반의 하드웨어를 자체 개발하여 사용하고 있습니다. 3D Robotics와는 자작 드론 커뮤니티 설립부터 함께 해왔기 때문에 3D Robotics 제품에 ArduPilot 기술이 포함되어 커뮤니티와 함께 성장하고 있다. ArduPilot은 드론용 제어 펌웨어는 물론 APM 미션 플래너(APM Mission Planner)라고 하는 그라운드 스테이션용 프로그램도 오픈 소스로 개발/제공하고 있습니다. 뿐만 아니라 ArduPilot은 드론 외에도 일반적인 헬리콥터, 고정익 비행기, 자동차 형태의 로버도 제어할 수 있게 제작되었습니다.

소스코드 https://github.com/diydrones/ardupilot

B. 드론코드(https://www.dronecode.org)

3D Robotics, 퀄컴, Walkera, 패럿, 바이두, Intel, 유닉 등등의 1,200개 이상의 업체가 참여하며 산업용 드론을 포함한 드론 코드로 발전하였습니다. 리눅스 재단이 2014년 Ardupilot, Pixhawk를 체계화 하여 독립적인 오픈 소스, 오픈 하드웨어를 갖는 Dronecode 프로젝트의 하나로서 취리히 연방 공과대학교(ETH Zurich) 출신의 Lorenz Meier가 중심이 되어 진행 중인 자동항법 시스템으로 학계와 마니아 커뮤니티에 표준화된 자동 조종 장치를 제공하는 것을 목표로 하고 있습니다. 2007년부터 DIY Drones(http://diydrones.com)에서 오픈 소스로 진행 중인 프로젝트인 Ardupilot과 양대 산맥을 이루는 오픈 소스 프로젝트라고 볼 수 있습니다. 대표적인 하드웨어로는 Pixhawk와 같은 제어기가 있으며 거의 모든 종류의 비행기 뿐만 아니라 고급 기술이라고도 할 수 있는 수직이착륙형(VTOL) 기체에도 사용할 수 있도록 개발되었습니다.

DroneCode에서는 APM과 더불어, PX4 프로젝트도 통합할 예정으로 알려지며, Pixhawk3 이하 버전에서는 Ardupilot과 PX4가 모두 지원되었지만 Pixhawk4에서는 Ardupilot가 완벽하게 지원할지 모릅니다.

C. PX4 Autopilot(http://px4.io/)

Pixhawk 이후에 하드웨어 소프트웨어적으로 완전한 오픈 소스를 제공하는 Platform으로 다른 오픈 소스와의 가장 큰 차이점은 BSD 3-clause라는 라이선스를 사용하고 있다는 것인데, 이는 GNU GPL 류의 라이선스와는 달리 상업적으로 사용하고 수정하여도 공개할 의무가 없어 예를 들어, 퀄컴(Qualcomm)의 경우 스마트폰용 스냅드래곤 칩을 내장한 Snapdragon Flight를 내놓았으며, 강아지 목줄과 비슷한 형태의 Fotokite, 3DR사의 신제품 Solo drone, 액션 스포츠 촬영용 무인 항공기로 유명세를 치르고 있는 하늘을 나는 개 에어도그(Airdog), 연구용으로 많이 사용되는 AR. Drone 등의 보조 제어기로 사용되어집니다.

민간용 드론에는 각 사가 개발한 Embedded OS가 사용되었습니다. Embedded OS는 한정된 임무만 수행할 수 있었으며, 소프트웨어가 제각각이기 때문에 다른 드론 여러 대를 한번에 조종하는 데 한계가 있었습니다. 최근 드론이 수행하는 역할의 범위가 확대되고 소프트웨어가 관리할 센서와 부품수가 많아지면서 전용 OS의 필요성이 절실해진 상황이 되었고 개발을 진행 중에 있습니다.

소스코드 https://github.com/PX4/Firmware

D. MultiWii(http://www.multiwii.com)

MultiWii는 Multi-rotor RC 모델을 제어하기 위한 범용의 소프트웨어으로 초기에는 Nitendo Wii 콘솔의 자이로와 가속도 센서를 이용하는 것으로부터 시작되었으며 Arduino 환경에서 개발 가능한 8-bit 기반의 AVR 시리즈 마이크로컨트롤러를 사용하는 GNU GPL v3 라이선스의 오픈 소스 FC가 탄생하였습니다.

소스코드 https://code.google.com/p/multiwii

E. Afroflight32(https://github.com/multiwii/baseflight)

BaseFlight로 불리는 Multiwii에 STM32 시리즈 MCU를 채용한 32비트 펌웨어 버전입니다.

F. Cleanflight(http://cleanflight.com)

Cleanflight는 오리지날 8비트 MultiWii 코드의 32비트 버전인 BaseFlight가 이후에 다시 정리된 오픈 소스 비행제어 소프트웨어이고 레이싱 드론을 위한 소프트웨어로 자리매김 하였습니다. 그 이후 더 나아가 자이로센서의 정보를 동기화하는 기술을 접목시켜 BetaFlight를 완성하게 됩니다. 애시당초 CleanFlight에도 GPS 기능이나 RTH(Return to Home) 기능, Waypoint 기능이 있었지만 레이싱 드론의 특성상 진화의 수순이라는 것입니다. 이와 같은 기능들을 유지하고 강화한 iNav는 고정익 드론에서 널리 사용하게 되었습니다. 이외에도 연장선에서 변속기(ESC)도 32-bit STM32 시리즈를 이용한 FC 내부에 포함하는 RaceFlight가 탄생하였고 Kiss와 같은 완성도가 높은 유료 FC가 예입니다.

G. OpenPilot(http://www.openpilot.org)

OpenPilot은 일반 민간인과 연구용으로 사용할 목적으로 OpenPilot 커뮤니티에서 생성된 GNU GPL v3 라이선스의 오픈 소스 UAV Autopilot입니다. 멀티 콥터, 헬리콥터, 고정익 항공기 및 기타 차량을 위한 고성능 플랫폼입니다. 전세계 6,000여 명의 개발자가 모인 드론 OS 개발을 위한 큰 축 중 하나로 관련 기업들 중심인 드론코드와 달리 개발자 중심의 드론 OS 프로젝트입니다. 개발자들 중심으로 운영돼 커뮤니티 성격이 강하며, OS 뿐 아니라 드론 관련 하드웨어를 함께 개발하고 있습니다.

OpenPilot은 2009년에 시작된 FC 펌웨어(On-board firmware)와 지상 조종 스테이션(Ground Control Station)으로 구분해서 개발된 FC입니다. BaseFlight보다 더 다양한 확장성을 가진 LibrePilot을 탄생시켰고 로보틱스까지 다양한 하드웨어를 지원하였지만 2015년 사라지게 되었습니다. 이후 드론 연구와 드론을 이용한 연구에 적합한 소프트웨어인 TauLabs로 발전하였고 비행 본연를 즐기기 위해 오픈 소스인 dRonin이 개발되기도 하였는데, 손쉬운 설정과 함께 골치 아픈 PID 설정을 위한 자동 튜닝(Auto Tune) 기능을 자랑합니다.

H. AeroQuad(http://aeroquad.com)

AeroQuad는 GNU GPLv3 라이선스의 오픈 소스 하드웨어와 소프트웨어 프로젝트입니다. STM32 기반의 AeroQuad32 FC 보드와 AVR Arduino 기반의 보드로 구성되어 있다. 최신 버전은 2013년 1월 이후 개발이 중지된 상태입니다.

소스코드 https://github.com/AeroQuad/AeroQuad

I. Emlid(https://emlid.com)

RaspberryPi 보드에 확장보드 형태로 연결하여 Linux 기반으로 드론을 제어할 수 있도록 한 것입니다.

소스코드 https://github.com/emlid

J. Crazyflie(http://www.bitcraze.io)

GNU GPL v3 라이선스로 다른 오픈 소스 프로젝트들이 대부분 30cm 이상의 중/대형을 목적으로 만들고 있으나, Crazyfly의 경우는 Parrot의 나라 프랑스에서 2003년에 시작된 Paparazzi 등, 작은 소형 기체를 목적으로 하고 있습니다.

소스코드 https://github.com/bitcraze

2. 비 오픈 소스 소프트웨어

A. KK 보드

ATmega644PA MCU를 사용합니다.

B. NAZA

DJI사의 제품입니다.

나. Airware 드론 OS(https://www.airware.com)

Airware 비행제어 시스템은 가상의 어떤 상용 비행체에도 설치가 가능하게 하는 유연하고 확장가능한 모듈라 아키텍처 구조를 지향하는 드론 OS의 개념입니다. 그리고, 안전 민감한 비행 제어부분과는 별도로 어플리케이션 개발이 분리되어 있습니다. 구글벤처스, 인텔캐피탈, GE로부터 자금을 투자받았습니다.

4. 오픈 소스 하드웨어

가. Ardupilot 계열 콘트롤러

오픈 소스 FC 보드의 계열 중에 많이 사용하는 것 중에 하나로서, Arduino기반의 APM(ArduPilot Mega) 계열이 있고, 32비트 ARM 프로세서를 사용하는 Pixhawk 계열이 있습니다. 이들의 확장 버전으로 Dronecode가 있습니다.

나. MultiWii 계열 콘트롤러

가장 많은 사용자들이 사용하고 있는 오픈 소스 프로젝트 중의 하나입니다. 8비트 AVR MCU 기반의 CRIUS나 Flexbot이 있으며, 32비트 ARM 기반의 NAZE32가 있고, 그중 Cleanflight 펌웨어는 상당히 작고 안정된 펌웨어로 알려집니다.

다. OpenPilot 계열 콘트롤러

OpenPilot 계열은 32비트 ARM 기반의 CC3D가 있습니다.

라. Crazyflie 계열 콘트롤러

비트크레이즈사의 Crazyfly는 32비트 ARM 계열의 콘트롤러입니다.

ChibiOS/RT는 Giovanni Di Sirio에 의해서 개발하였으며, 임베디드(embedded) 애플리케이션을 위한 무료이자 효율적이고, 컴팩트하며 빠른 RTOS(Real Time Operating System)입니다. Kernel primitive의 이해가 쉬운 세트를 제공하며 다양한 아키텍처(ARM7, Cortex-M0, Cortex-M3, Cortex-M4, PowerPC e200z, STM8, AVR, MSP430, ColdFire, H8S, x86)를 지원합니다. ChibiOS/RT는 RTOS로 GPL3 라이센스 하에서 배포됩니다.

ChibiOS/RT는 8, 16, 32-bit 마이크로컨트롤러의 임베디드 애플리케이션을 위해서 설계되었습니다; 사이즈와 실행 효율이 주요 프로젝트의 목표입니다. 참고로 커널 사이즈는 STM32 Cortex-M3 프로세스에서 활성화된 모든 서브시스템에서 최소 1.2KB에서 최대 5.5KB입니다. 커널은 초당 220,000 이상의 스레딩을 생성시키거나 종료할 수 있고, 72MHz의 STM32에서 1.2ms 내에 컨텍스트 스위칭(context switch)을 실행할 수 있습니다.

특징

• Tiny memory footprint, 고성능, 쉬운 이식성(portable), 깔끔하고 이해가 쉽습니다.

• 선점형 마이크로커널이자 멀티스레딩(multithreading), 128 우선 순위 레벨, 신뢰성 있고 정적 아키텍처.

• Semaphores, Mutexes, CondVars, Messages, Event Flags, Mailboxes, Virtual Timers를 위한 커널 지원.

• Counting semaphores

• Mutexes with support for the priority inheritance algorithm

• Condition variables

• Synchronous and asynchronous Messages

• Event flags and handlers

• IRQ abstraction, non-OS fast IRQ sources(zero latency buzzword) 지원.

• ARM, ARM-CM0, ARM-CM3, ARM-CM4, PowerPC, STM8, MSP430, AVR, ColdFire, H8S, Linux/Win32/MacOS 시뮬레이터를 지원.

• HAL(Hardware Abstraction Layer) 컴포넌트는 지원되는 플랫폼 간에 애플리케이션의 이식이 가능.

• Port(GPIO), Serial, ADC, CAN, DAC, EXT, GPT(general-purpose timer), I2C, I2S, ICU, MAC, MMC/SD, PAL, PWM, RTC, SDC, SPI, UART, USB, WDG 디바이스 드라이버 모델을 위한 HAL 지원.

• uIP과 lwIP TCP/IP stacks(demo 포함)를 위한 지원.

• FatFS 파일 시스템 라이브러리(demo 포함)를 지원.

• 동일한 우선 순위 레벨에서 스레드를 위해서 Round-robin 스케쥴링

• Software timers

• Queues

• Synchronous and asynchronous I/O with timeout capability

• Thread-safe memory heap and memory pool allocators.

스레드, semaphore, 타이머와 같은 모든 시스템 객체는 실행 중에 생성되고 삭제될 수 있습니다. 가능한 메모리를 제외하고 어떤 상한이 없습니다. 시스템 신뢰성을 개선하기 위해서, 커널 아키텍처는 전체적으로 정적이고, memory allocator가 요구되지 않습니다(그러나 옵션으로 가능합니다). 그리고 테이블 혹은 배열과 같은 상한 사이즈 제한과 함께 어떠한 데이터 구조가 존재하지 않습니다. 시스템 API는 에러 코드나 예외와 같은 에러 조건을 갖지 않도록 설계되었습니다.

RTOS는 임베디드 디바이스 애플리케이션을 위해서 설계되었고 다양한 마이크로컨트롤러를 위한 데모 애플리케이션을 포함합니다:

• ST STM32F1xx, STM32F2xx, STM32F3xx, STM32F4xx, STM32L1xx, STM32F0xx

• ST STM8S208x, STM8S105x, STM8L152x

• ST/Freescale SPC56x / MPC56xx

• NXP LPC11xx, LPC11Uxx, LPC13xx

• NXP LPC2148

• Atmel AT91SAM7S, AT91SAM7X

• Atmel Mega AVR

• TI MSP430x1611

• TI TM4C123G and TM4C1294

• Microchip PIC32MX

소프트웨어 I/O 에뮬레이션(emulation) 모드로 Win32 프로세스에서 커널을 실행시키는 것이 가능합니다. 이는 물리적인 하드웨어의 요구 없이 쉬운 애플리케이션 개발을 허용합니다.

실시간 시스템(real time system)은 임의의 정보가 시스템 내/외부에서 이벤트 혹은 인터럽트(interrupt)의 형태로 시스템에 입력되었을 때 주어진 시간 안에 작업이 완료되어 결과가 주어져야 하는 시스템입니다. 즉, 이벤트 발생과 처리가 실시간으로 이루어지는 시스템입니다. 물론 CPU의 처리 속도를 증가시킬 수도 있지만 속도는 느리더라도 이벤트 처리 시간을 보장할 수 있도록 하여야 한다는 의미입니다.

RTOS(Real Time Operating System) 없이 펌웨어를 제작하여도 모든 작업을 할 수는 있습니다. 예전의 시스템에서 펌웨어(firmware)는 비교적 간단해서 OS의 개념을 적용하지 않고 순차적인 프로그램만으로 작성했어도 그리 문제가 되지 않았습니다. 하지만 최근에 점점 더 소형기기에 들어가는 기능이 다양해지고 Windows OS처럼 이벤트가 수ms 정도에 처리되어도 가능한 상황과 달리, 임베디드 시스템(embedded system)에서는 훨씬 빠른 응답을 요구하여 순차적인 프로그래밍 방식으로는 기능을 구현하기에 어려워졌고 시간도 많이 걸려 다음의 장점으로 여러개의 태스크(task)로 분할하여 개발할 필요가 있다는 것입니다. 왜냐면 여러가지 일을 할 수 있는 순차적인 프로그램 방법으로 구현하면 프로그램의 복잡도가 일의 갯수의 승수에 비례하기 때문입니다.

1. 코드의 개발, 수정, 유지, 보수가 보다 용이합니다.

2. 이벤트에 대해 보다 신속하게 응답할 수 있습니다. - 인터럽트가 발생하면, 진행 중인 태스크 대신 인터럽트를 처리할 태스크를 우선적으로 실행할 수 있습니다.

3. 시스템의 신뢰도와 성능을 높일 수 있습니다.

한편 우선 순위 방식에는 2가지가 있는데, 우선 순위가 높은 태스크가 우선 순위가 낮은 태스크를 잠시 멈추게 하고 프로세서를 차지할 수 있는 권한이 부여되면 최근 대부분 OS가 그렇듯 선점형 우선순위(Preemptive)가 됩니다. 반면에 우선 순위가 높다 하더라도 우선 순위가 낮은 태스크가 완료할 때까지 기다려 주는 방식을 Windows 95이전의 OS와 같은 비선점형 우선순위(Non-preemptive)라 부릅니다.

임베디드 시스템에서는 주로 선점형을 사용하는데, 우선 순위에 따라 프로세서의 사용 권한을 조정하는 것을 스케줄링(Scheduling)라고 부릅니다. 이와 같이 진행 중인 태스크가 바뀌게 되면 컨텍스트(Context)라고 불리는 기존의 태스크에 대한 정보를 저장하고 새로운 태스크를 불러오는 동작을 해야 하는데 이를 컨텍스트 스위칭(context switching)이라고 합니다. 또한 진행 중인 태스크들의 각종 정보를 태스크 컨트롤 블럭(TCB: Task control block)이라고 부릅니다. 다음은 선점형 OS에서 사용하는 스케줄링 방식입니다.

1. Priority Scheduling Algorithm

2. Round-Robin Scheduling Algorithm

이처럼 예전에는 하드웨어 성능과 크기의 제약으로 OS 없이 단순한 기능만 수행 가능했던 것이 하드웨어 성능의 향상으로 다양한 일이 요구되었습니다. 이에 RTOS라는 OS 개념을 도입하여 각각의 태스크에 대한 스케줄링으로 자원을 효율적으로 사용할 수 있게 하고 복잡한 일들을 태스크로 나눔으로써 일을 단순화 시킬 수 있다는 것입니다. 뿐만 아니라 다음과 같은 까다로운 문제가 발생하는데, 이들 문제를 직접해결하기 보다는 멀티태스킹(multi-tasking; 엄밀하게 multi-threading) OS를 도입하는 것이 훨씬 효과적이라는 것입니다. 근래에는 멀티태스킹 뿐 아니라 Network, File System, GUI도 구현하고 있습니다.

1. 태스크간 경쟁의 관리

2. 데드락(deadlock)

3. 우선 순위 역전(priority inversion)

4. 재진입 문제(reentrancy)

5. 태스크간 통신

※ 일반적인 OS vs. RTOS

• 효율성 / 시간 제약성 : 일반 OS 경우에 태스크들 사이에 효율성을 유지하려고 하지만 real-time OS에서는 태스크에 시간 제약성이 존재하고 이런 시간 제약성 때문에 효율성을 무시하는 경우가 발생하며 효율성은 고려하지 않습니다.

• 공평성 / 우선순위 : 일반 OS 경우 여러 명의 사용자가 쓰는 경우에는 각 사용자들이 실행하는 프로그램이 태스크로서 수행이 되고 대개의 경우에는 각 태스크가 공평성을 유지하려고 한다. 그러나 real-time OS에서 태스크는 대개 우선순위가 차이가 있도록 하며 이때 태스크 사이의 공평성은 고려하지 않습니다.

결론적으로 RTOS는 시간의 정확성을 보장하는 멀티태스킹 호출과 인터럽트에 대한 반응시간의 최대값을 보장할 수 있고 실행시간의 편차가 작아야 하는데 즉, 작업의 소요시간을 예측할 수 있어야 합니다. 우선순위가 높은 일이 우선적으로 자원을 분배하여 시간제한 내에 끝날 수 있도록 해야 합니다.

1. 다수의 작업에 우선 순위를 두어 멀티태스킹을 지원합니다.

2. 짧은 interrupt lattency - interrupt latency는 인터럽트가 걸려서 인터럽트 핸들러에 도착하기까지의 시간이며 이벤트에 의한 반응 속도가 빠릅니다.

3. 적은 용량의 kernel 사용 - 작고 유연한 구조(10 ~ 50 KB 수준)

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 파라미터, 디버깅에 연관된 스위치 등입니다.

halconf.h

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

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에 선언되어 있습니다.

Makefile

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

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

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

main.c

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

위 함수는 루프 이전에 단 한번 실행됩니다. 이 함수는 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)합니다.

위의 스레드의 생성 함수는 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의 소유권을 다음의 우선순위 스레드에 넘기게 됩니다.

비교적 무거운 환경인 ChibiStudio 혹은 Eclipse IDE나 제한이 많은 Keil, IAR 등의 상용 IDE를 사용하지 않고 Windows 환경에서 무료로 사용할 수 있는 Embitz 환경으로, 오픈 소스 RTOS인 ChibiOS를 사용한 VESC 펌웨어의 컴파일 방법입니다. 참고로 Embitz는 emblocks의 새로운 이름입니다.

VESC firmware compile step for Embitz v1.11

VESC firmware : https://github.com/vedderb/bldc

Embitz : https://www.embitz.org/

Msys : http://downloads.sourceforge.net/mingw/MSYS-1.0.11.exe

1. Settings->Tools... , Toolchain executables , additional paths.

- enter path to Msys/bin

1. 'Tools' 메뉴의 'Toolchain executables' 탭을 클릭하고 'additional paths' 눌러 Msys/bin 경로를 찾아 추가합니다. 여기서 Msys를 설치하지 않으며 'make.exe'파일을 이용할 수 없게 됩니다.

2. Create new project.

- choose Empty template

- name project title as 'BLDC_4_ChibiOS', will make things easier.

- untick debug checkbox

- change create release configuration to 'upload'

- change ouput dir to 'build\'

- change objects output dir to 'build\obj\'

2. 'new project'를 생성합니다.

- 'Empty template' 를 선택합니다

- 'project title'을 'BLDC_4_ChibiOS'으로 입력하는데 이는 makefile에 이미 정의된 것으로 후에 생길 오류들을 없애기 위함입니다.

- 'debug checkbox'를 체크 해제합니다

- 'release'대신 'upload' 폴더로 생성하도록 'release'를 'upload'로 변경합니다

- 'output dir'를 'build\'로 변경합니다

- 'objects output dir'를 'build\obj\'로 변경합니다

3. copy all files from bldc-master to BLDC_4_ChibiOS

3. github에서 다운로드하여 압축해제 한 'bldc-master' 폴더 내에 모든 파일을 새롭게 생성된 'BLDC_4_ChibiOS' 폴더 안으로 복사합니다

4. right click on your project choose 'add files recursivly'

- choose folder 'BLDC_4_ChibiOS'

4. project를 오른쪽 클릭하여 'add files recursivly'를 선택합니다.

- 'BLDC_4_ChibiOS' 폴더를 선택합니다

5. right click on your project choose 'properties'

- check checkbox 'this is a custom Makefile'

5. project를 오른쪽 클릭하여 'properties'를 선택합니다.

- 'this is a custom Makefile'의 체크 박스를 체크합니다. 즉 기존의 makefile를 사용함을 의미합니다.

6. Build target

6. Build target을 클릭하여 컴파일 합니다.

7. Clean target을 클릭하여 생성된 파일을 삭제할 수 있는데 삭제되지 않으면, 'Project'의 'Build options' 메뉴를 클릭하여 '"Make commands' 탭을 선택하고 'Clean project/target'란 '$make -f $makefile clean $target'라는 정보가 올바로 입력되어 있는지 확인합니다.

during build there is no response or status.

컴파일하는 동안에 어떤 응답이나 상태를 보이지는 않습니다.

제 경우에는 15분 26초 정도 걸렸습니다.

Intel Atom CPU Z3735F @1.33GHz / 2GB 메모리 / Windows 10 Home(32bit)

VESC는 Unix 환경에서 작성되어 비록 Windows 환경에서 Embitz IDE를 사용하더라도 Compile과 Link에 사용되는 Toolchain과 Makefile을 사용하기 때문에 Unix 기반의 'make.exe', 'rm.exe' 등이 포함된 [Msys와 같은] Build 유틸이 설치되어야 합니다. GNU ARM Embedded Toolchain과 Debugger로는 오픈 소스인 OpenOCD를 사용합니다.

임베디드(Embedded)나 펌웨어 궁극적으로는 둘다 작은 시스템 내에 하드웨어 제어를 위해 EEPROM 등에 기록되는 일종의 프로그램입니다. 거의 같다라고 봐도 무방합니다. 하지만 근래 들어서 시스템의 복잡화로 인해 기존의 펌웨어를 제작할 때 사용되는 프로그래밍 방식 '슈퍼루프 방식'은 프로그래머의 체계적인 프로그램 설계와 짜임세 있는 구성이 프로그래머를 피곤하게 할 만큼 복잡하게 되었습니다.

이에 대한 대안으로서 나온 것이 RTOS(Real Time OS)라는 것인데 ROM에 기록되는 펌웨어 중에서도 특히 이런 RTOS를 이용한 것을 임베디드(내장형 시스템)라 칭하는 경우가 많습니다. RTOS를 사용하게 되면 ROM에 기록되어야 할 펌웨어의 크기가 커지고, 시스템 오버해드라 하여 불필요한 부하를 가져다 주게 됩니다. 하지만, 펌웨어 개발의 융통성과, 안정성, 정확성을 고려할 때 펌웨어의 크기나 시스템 오버해드는 충분이 무시할 수 있는 요소가 된다는 것입니다.

대표적인 RTOS인 ChibiOS

RTOS를 이용한 임베디드 시스템은 꼭 ARM같이 거대한 프로세서에만 사용되는 것은 아닙니다. 상당히 유명한 uCOS-II경우 구식 8051부터 Intel 32bit까지 다양한 플랫폼을 지원합니다. 8051계열에도 얼마든지 임베디드 시스템을 펌웨어로 올릴 수 있습니다.

펌웨어는 일반적으로 롬(ROM)에 저장된 하드웨어를 제어하는 마이크로 프로그램을 의미합니다. 프로그램이라는 관점에서는 소프트웨어와 동일하지만 하드웨어와 밀접한 관계를 가지고 있다는 점에서 일반 응용 소프트웨어와 구분되어 펌웨어는 소프트웨어와 하드웨어의 특성을 모두 가지고 있다고 할 수 있습니다.

예를 들어 어떤 기능을 발휘하는 하드웨어를 만든다고 할 때, 그것을 제어하는 모든 회로를 하드웨어로만 만들면, 그 구조도 대단히 복잡해지고 심지어는 논리적인 표현을 하기가 어려운 부분도 발생합니다. 이런 경우 상당부분을 소프트웨어로 대체하되 그 소프트웨어가 저장된 기억장치를 하드웨어의 제어회로 중의 중심부분으로 구성하면, 매우 간단하면서도 적은 비용으로 문제를 해결할 수 있게 됩니다. 이렇게 만든 하드웨어적인 소프트웨어를 펌웨어라 합니다.

이렇게 할 경우 하드웨어의 입장에서는 별도의 논리회로를 가진 것이 아니기 때문에 소프트웨어적인 특성을 가지고 있지만, 소프트웨어 입장에서는 마이크로 프로그램이 하드웨어를 제어하기 때문에 하드웨어적인 특성을 가진다고 설명할 수 있습니다.

소프트웨어의 기능을 펌웨어로 변경할 수 있으면 속도가 현저하게 증대되어 고속 처리가 필요한 프로그램은 펌웨어로 만들어 사용하기도 합니다. 또한 하드웨어의 기능을 펌웨어로 변경하면 속도는 느려지지만, 그 기능을 위한 논리회로를 설계하여 사용하는 것보다 저렴하고, 편리하게 구현하여 사용할 수 있는 장점을 가지기도 한다는 것입니다.