'avr-gcc'에 해당되는 글 3건

  1. 2014.06.14 Assembler의 장점
  2. 2014.04.23 C 언어로 개발시 유의사항
  3. 2014.04.20 변수 vs. 메모리



과거에는 PC DOS 응용프로그램 개발시 어떻게 메모리를 효율적으로 관리하느냐가 관건이었던 적이 있습니다. 당시에는 메모리 집적기술의 한계로 PC에 1Mbyte를 설치하였다면 큰 자랑꺼리였으며 가격도 비쌌던 시절였습니다. 그러므로 응용프로그램은 DOS가 사용하는 영역의 나머지인 상위메모리를 사용하곤 하였습니다.


하지만 근래에는 메모리가 부족하여 응용프로그램을 실행하지 못하는 경우는 거의 없습니다. CPU의 속도와 메모리 용량 그리고 대용량 하드디스크의 발전은 더이상 가독성이 떨어지는 낮은 수준(low level)의 언어 사용은 물론 엄격한 메모리 관리의 부담을 덜어주게 되었습니다.


그러므로 언제부턴가 어셈블러(ASM)나 C-언어가 아닌 사용자에 즉, 사람에게 친숙한 높은 수준(high level)의 언어인 비쥬얼베이직(Visual Basic), C++ 언어 등이 대세가 되었습니다. 그럼에도 불구하고 AVR이나 PIC계열의 마이크로콘트롤러(MCU)에서는 여전히 낮은 수준의 프로그램 언어를 사용하고 있습니다.


MCU의 속도나 메모리 용량 등과 같은 성능의 발전과 avr-gcc와 같은 컴파일러의 지속적인 향상에 힘입어 요즈음은 어셈블러보다는 C-언어를 선호하게 된 것도 사실입니다. C-언어로 작성해 굳이 오버헤드(overhead)가 있을지라도 속도와 메모리 같은 개선된 MCU 성능으로 적용하는데 크게 문제가 되지 않은다는 것입니다.


하지만 아직도 상업적인 용도의 AVR 펌웨어(firmware)는 여전히 어셈블러를 사용하고 있습니다. 고성능의 MCU를 사용하여 단가를 높이기 보다는 합리적인 성능의 자원에 펌웨어를 어셈블러로 정교하게 작성하고 최적화하여 시장 경쟁력을 얻는다는 것입니다.





그러므로 어셈블러는 적어도 한번은 다루어봐야 하는 언어로 C-언어와 비교하여 다음과 같은 장점을 갖습니다.


1) 새로운 언어를 배운다는 스트레스는 문법을 익혀야 한다는 부담일 것입니다. 하지만 어셈블러는 문법이 C-언어에 비해서 매우 간단하다는 것입니다. 어셈블러는 원하는 코드 구현 자체가 까다로운 것이지 문법을 처음 익히기는 매우 쉽다는 것입니다. 


구현이 까다롭다는 것은 하드웨어에 대해 일일이 알아야 한다는 것과 아마도 120여개에 이르는 다양한 AVR 명령어가 존재하기 때문일 것입니다. 그러나 다양한 명령어는 기능이 유사한 소위 파생된 명령어로 인하여 용도별로 분류하면 사실상 몇 종류가 되지 않으며, 필요시 그때 그때 가져다 사용하면 됩니다.


2) 어셈블러를 다루면 특히 메모리 영역과 같은 하드웨어를 자세하게 익힐 수 있으며 이러한 지식은 향후 C-언어로 구현시 최적화된 코드를 생성할 수 있는 기회를 제공한다는 것입니다.


기존의 C-언어에서는 하드웨어를 자세히 다룰 필요는 없었습니다. 왜냐하면 사용코자 하는 AVR를 지정하면 컴파일러가 알아서 해주기 때문입니다. 메모리가 부족하면 컴파일러는 이를 사용자에게 일러주고 사용자는 불필요한 변수를 삭제해주면 되었기 때문입니다.


3) 정밀한 타이밍을 요구하는 펌웨어를 작성할 수 있습니다. 


어셈블러 명령어는 1~2 사이클의 클럭을 필요로 하며 사용자는 이를 직접 보면서 다루기 때문입니다. 하지만 C-언어를 사용할 때는 해당코드가 컴파일 후에 얼마의 클럭을 요구하는지 알 수가 없고, 알아낸다 하더라도 1us 정도의 정밀한 타이밍은 사실상 불가능하다는 것입니다. 예를 들어, 브러쉬리스(brushless) 모터를 제어시에 C-언어로 작성된 펌웨어는 고속 회전 영역에서 제어 불능상태가 될 수 있다는 것입니다.







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

Assembly어의 문장 형식  (6) 2014.06.26
식별자와 상수  (0) 2014.06.16
Posted by Nature & Life
Embedded Programming/C2014. 4. 23. 09:33


AVR은 C 언어로 개발하는 경우에도 assembler 못지 않게 최적화된 코드를 생성하기에 다양한 장점이 있습니다. 그 중에서도 avr-gcc라는 컴파일러를 사용하는 것으로 avr-gcc는 전 세계 다양한 사용자(소위 Hacker)들에 의해 개발되어 공유하는 것으로 시행착오를 통하여 결점이 최소화되었다는 것입니다.


AVR을 C 언어로 개발시에는 일반적인 O/S 환경에서가 아닌 AVR 하드웨어에 기반을 두기 때문에 몇 가지 유의사항들이 있습니다.

 

 

 

 

1) 일반적인 C 언어와는 달리 이진수(binary)를 사용할 수 있으며, Boolean 타입의 변수는 사용할 수 없습니다. 

이진수는 예를 들어 0b0100 식으로 표현하며 Boolean 타입 변수 대신에 int형의 0과 1로 대체하여 사용하면 됩니다.


2) 인터럽트 서비스 루틴은 가능한 한 간결하게 작성합니다.

일반적인 C 언어와는 달리 AVR 하드웨어는 외부 인터럽트나 Timer, USART, ADC 등의 주변장치들로부터의 인터럽트를 처리하기 위한 ISR() 함수로 반환값이 없으며 특별히 호출하지도 않습니다. 이러한 인터럽트 서비스 루틴(Interrupt Service Routine, ISR)은 다음과 같은 이유로 최대한 간결하게 작성해야 합니다.


첫째는 인터럽트 함수 내에서는 지역변수가 Register가 아닌 Stack에 저장되므로 처리가 느리기 때문이며, 

둘째는 하나의 인터럽트 처리가 길어지면 이어서 발생하는 다른 인터럽트 처리를 실행하지 못하기 때문입니다.


대부분의 인터럽트는 Timer의 overflow를 처리하기 위한 것으로 만일 인터럽트를 제때에 처리하지 못한다면 AVR 칩이 외부 시스템과 실시간으로 작동하는 경우에는 치명적인 오류가 생길 수 있게 됩니다. 그러므로 인터럽트 발생시 많은 작업을 요구하는 경우에는 인터럽트 루틴에서 Flag를 간단히 설정하여 개시하고 메인 루틴에서 이를 처리하게 해야 합니다.


3) 인터럽트 서비스 루틴 내에서 전역변수들은 volatile로 선언합니다.

컴파일시 최적화를 위해 컴파일러는 나름데로 그 상황에 맞는 상수값으로 처리하도록 하는 경우가 있는데, 이것이 인터럽트 서비스 루틴에서는 의도하지 않은 오류를 초래하기 때문입니다. 그러므로 인터럽트 서비스 루틴에서는 전역변수들은 volatile로 선언하여 컴파일러가 임의로 해석하지 못하게 방지합니다.

ex) volatile char k; 


4) 외부 메모리가 있는 경우가 아니라면 재귀호출(Recursive call)을 사용하지 않는 것이 좋습니다. 

연속되는 재귀호출은 한정된 메모리에 Stack을 쌓이게 하며 결국에는 Stack overflow를 발생시킬 수 있기 때문입니다.


5) 대용량을 갖는 상수 배열(array)은 const 키워드를 사용하여 프로그램 메모리(Flash Memory)에 저장합니다.

AVR에서 변수는 SRAM에 저장하는데 고기능 AVR을 사용하지 않고 기능을 구현하려면 SRAM의 용량을 아껴야 합니다. 따라서 변하지 않는 대용량 상수들은 코드를 적재하는 Flash Memory에 저장하여 SRAM을 확보하는 것이 바람직합니다.

ex) const uint8_t value[64] = 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,

                                  29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,

                                  54,55,56,57,58,59,60,61,62,63,64};

  

 

 

Posted by Nature & Life
Embedded Programming/AVR 2014. 4. 20. 21:51



1) 전역변수(Global variable)


SRAM에 저장되어 있다가 이를 사용할 때마다 register로 읽혀지며 사용이 끝나면 다시 SRAM에 저장되므로 처리속도가 늦은 변수로, 특별히 속성을 정하지 않고 변수를 정의하면 SRAM 영역에 저장됩니다. 게다가 Compiler는 이를 변수로 처리하지 않고 그 상황에서 이 변수가 갖는 값에 해당하는 상수로 처리하는 경우가 있는데 이런 상황에서 여러 함수가 이 변수를 공유하여 사용하는데 문제를 야기하고 컴파일 시 최적화 옵션에 따라서도 영향을 받게 됩니다.


특히 인터럽트 서비스 루틴(Interrupt Serve Routine, ISR) 함수와 그 밖의 함수 사이에 공유하는 전역변수의 경우에 흔하게 발생하며 이를 방지하기 위해서는 전역변수에 'volatile'을 선언해 주어야 합니다.

ex) volatile unsigned char zc_count;


2) 지역변수(Local variable)


ATmega8의 경우, 다른 MCU에서처럼 지역변수를 Stack에 저장하는 것이 아닌 32개의 General Purpose Registers(GPFs)로 처리하므로 항상 처리속도가 빠릅니다. 하지만 ISR에 사용되는 변수는 특성상 Stack에 저장합니다.


3) 정적변수(static variable) 


함수가 시작될 때 register로 옮겨지고 함수가 종료될 때 SRAM으로 다시 옮겨져 저장되므로 만일 함수 내에서 여러 번 사용된다면 전역변수보다 정적변수가 처리속도가 증가하게 됩니다.





4) Flash Memory에 데이터의 저장


물론 메모리 용량이 크고 고성능의 MCU를 사용하면 문제가 되지는 않지만 가격대 성능비 등을 고려하여 그렇지 못한 경우, 변수로 사용해야 할 SRAM 용량을 절약할 필요가 있습니다. 만일 SRAM 용량이 부족하게 되면 Stack overflow가 발생하거나 프로그램이 오동작을 할 수 있습니다.


avr-gcc에서 상수 데이터를 프로그램이 적재되는 Flash Memory에 저장하기 위해서는 먼저 상수 데이터를 전역변수처럼 함수의 밖에서 정의하고 이때 상수가 byte 데이터라면 prog_char 또는 prog_uchar로 선언하며 읽을 때문 pgm_read_byte() 또는 pgm_read_word() 함수를 사용합니다.


참고로 비록 상수 데이터를 prog_char 또는 prog_uchar로 정의하더라도 이들이 함수 내에서 정의되면 컴파일 시 SRAM 변수로 처리되므로 주의가 요구되며, 일반적으로 Flash Memory는 SRAM에 비하여 용량이 훨씬 크므로 유용하게 사용할 수 있습니다.


5) EEPROM에 데이터의 저장


AVR에서 EEPROM을 I/O register를 사용하여야 접근할 수 있으므로 avr-gcc 에서는 EEPROM을 eeprom_read_byte() 혹은 eeprom_write_byte() 함수로 각각 읽기, 쓰기가 가능합니다.



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

다양한 AVR Package 비교  (0) 2014.06.14
AVR의 메모리 구조  (3) 2014.04.20
AVR이란?  (0) 2014.03.11
부트로더란?  (0) 2012.12.10
Posted by Nature & Life