감사합니다.

2017년, 전자제품을 개발할때, 특히 ITO 관련 제품 개발시,

심심하면 나오는것이 블루투스입니다.

스마트폰에서 블루투스를 지원하니, 보편화가 되고 있다고 봅니다.

그러나, 블루투스에 대한, 잘못된 이해(?)로 인하여, 

불필요한 제품에 블루투스를 넣는 경향이 큽니다.

"ITO는 무조건 블루투스가 되야한다"는 식입니다.

블루투스는 목적은 좋지만, 사실상, 크게 활용도가 없습니다.

스마트폰과 연결하지 않는다면, 거의 쓸데가 없죠.

물론, 블루투스 스피커등 많은 제품이 있습니다만,

써보시면 알겠지만, 큰 매리트가 없습니다.

블루투스 제품은 충전해야 사용할 수 있는 경우가 대부분입니다.

제품사서, 몇달 쓰고, 그 이상은 안씁니다.

저 같은 경우에는, 아예 블루투스 기능을 끕니다.

블루투스 기능이 되는제품을 사기위해, 돈을 지출합니다.

이어폰 같은 경우, 블루투스 없어도, 문제 없습니다.

블루투스가 더 좋은 음질을 들려준다는것은 장점입니다만,

거의 매일 충전해야하고, 잃어 버리기 쉬우며, 방해전파등에 취약하여,

소리가 끊어지는 경우도 발생합니다.

또한, 무선이다보니, 잃어버리기 쉽습니다.

물론, 한번 사서, 자주, 오랫동안 잘 쓰시는 분들도 있습니다.

"블루투스가되면, 크게 좋아질거다"라는 인식이 강합니다.

그러나, 현실은 대부분, 나빠집니다.

좋아지긴 해도, 꾸준하기가 어렵습니다.

블루투스는 좋은 통신장치이나, 실생활에서는 필수기능이 아닙니다.

물론 필수 기능이 되는 제품도 있긴 합니다.

현실적으로, 블루투스보다는 인터넷(wi-fi)이 되는 제품이 더 실용성있습니다.

블루투스는 근거리에서만 사용이 가능한데 반해, 인터넷(wi-fi)는 지구 어디에서나 사용할 수 있습니다.

물론, wi-fi가 더 비싸고, 더 복잡합니다.

그러나, 기능성면에서는 블루투스보다 훨씬 뛰어납니다.

블루투스가 좋을거라는 막연한 기대감으로, 제품을 만드는 분들도 많고,

블루투스 기능을 넣어달라는 소비자들도 많습니다.

제가 알고 있는 업체에서도, 수년간 수십번 제품에 적용 또는 검토를 했지만,

정작 제대로 만들어진 제품도 별로 없고, 제대로 사용하는 사용자도 별로 없습니다.

(넣을 수 있는 제품이라면) 블루투스 기능을 넣을거면, 차라리, wi-fi기능을 넣으세요.

물론, 블루투스로만 해야되는 제품도 있습니다.

요약 : 막연한 기대감으로, 무조건 넣고보자는 식

html방식은 기존의 이미지, <div>등을 사용하여, 화면을 그리는 방식이고,

canvas방식은 canvas안에 그래픽함수로 화면을 그리는 방식이다.

2번째 도전

gcc컴파일러로 C소스파일을 컴파일 할 수 는 있지만, 링크와 APK파일에 넣는것은 할 수 없어, 안드로이드 스튜디오 설치.

이클립스 개발환경도 있으나, 안드로이드 스튜디오가 대세인듯함.

그러나, 설치부터, 실행까지, 너무나 무겁다.

(이클립스는 더이상 업데이트 안되니, 안드로이드 스튜디오를 사용하란다.)

1) 컴파일러(개발환경) 다운로드

지난번에는 이클립스로 해서, 용량이 작았는데, 

안드로이드 스튜디오로 하려니, 용량이 너무 크다.(약 1.7G)

https://developer.android.com/studio/index.html?hl=ko

https://developer.android.com/studio/index.html?hl=ko#win-bundle

2) JDK 설치

안드로이드 스튜디오 실행하면, 나오는 에러 메세지

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

윈도우 XP에서 설치하면 아래의 메세지가 나옴.

설치는 계속할 수 있음.

설치가 다 될때쯤, 또 에러 메세지가 나옴.

계속 진행.

JDK설치후, 안드로이드 스튜디오 실행 -> 안드로이드 스튜디오 Setup, 다운로딩 진행.

처음 실행해서 설치(다운로드)하는데, 왜이리 오래걸리는지...ㅠ ㅠ

3) NDK(라이브러리) 다운로드

https://developer.android.com/ndk/downloads/index.html

윈도우용 NDK?? (NDK는 OS독립적이지 않은가?)
=> NDK는 C소스파일을 리눅스의 *.so(DLL)파일로 컴파일하는 역활을 함.(안드로이드는 리눅스로 만들어졌음)
    C소스파일을 *.so형태로 컴파일해서, APK파일에 넣는다.
    안드로이드 기기(휴대폰)마다 사용하는 CPU가 다르므로, 각 CPU별로 컴파일러가 있어야 한다.
    NDK에는 각 CPU별로 컴파일러(툴체인)도 들어 있다.
    참고 : 2016.11.29 APK파일

4) NDK 샘플 소스 다운로드

https://github.com/googlesamples/android-ndk

https://github.com/googlesamples/android-ndk/archive/master.zip

아트멜사는 ATMega128을 비롯하여, 공전의 히트 제품을 출시하여, ARM cortex시리즈가 나오기 몇년전까지만해도,

엄청난 인기를 끌었다.

보통 AVR칩, AVR컴파일러등으로 불렀다.

(비디오 기록장치인 AVR과 관련이 없다.)

EEPROM을 내장하고, 적당한 성능에, 적당한 가격과, 무료컴파일러 지원이라는 시스템으로,

많은 사용자를 만들어냈다.

그당시에는 대부분의 컴파일러는 유료였고, 크렉하여 사용하던 시절이다.

현재의 대세인 ARM cortex시리즈와 비교해보면, AVR칩은 8비트에 16MHz이 저사양(?) cpu이고,

ARM cortex는 32비트에 보통 48MHz이상을 대부분 지원한다.

또한, 가격을 대폭 낮추어, 2016년 현재에는 AVR칩이 더 비싼 경우도 있다.

(수요가 줄어서, 가격이 올라간것도 이유)

어쨌든, 2016년에는 ARM cortex가 대세이다.

많은 칩제조회사들이 ARM코어를 사다가 칩을 제조하며,

이들 칩들은 대부분 호환이 가능하다.

가격

========

ARM coretex는 수많은 제조사들이 경쟁하여, 가격이 매우 낮아졌다.

AVR칩은 수요감소로 인해, 가격이 올라가는 추세이다.

소스코드 호환성

================

 ARM coretex는 소스코드 조금만 손보면, 대부분의 칩에서 동작이 가능하다는 엄청난 메리트가 있다.

소스레벨에서는 어느정도 호환 가능하나, 사실상, 그냥 컴파일되는 경우는 없다.

또한, 32비트 CPU라서, 윈도우환경에서 개발하여, 포팅하는것도, 더욱 쉬워졌다.

AVR컴파일러는 1~2종류라고 봐도 된다.

2가지 컴파일러중 한가지에서 돌아가는 소스코드이다.

컴파일러 비교

==============

AVR컴파일로는 무료이나, ARM cortex 컴파일러는 gcc로 툴체인 구성하지않는한, 대부분 유료이다.

물론, 무료 컴파일러도 있으나, 많이 사용하지 않는다.

AVR컴파일러는 대표적인것이 2가지가 있다.

ARM컴파일러는 칩종류도 많고, 컴파일러 종류도 많다.

ARM은 소스문법에 따른 버그가 적으나,

AVR은 최적화시, 소스코드 작성을 어떻게 하느냐에따라, 알수없는 버그가 많은 편이다.

잘동작하는코드, 한두줄만 수정해도, 엉뚱한 상황이 벌어지는 경우가 생각보다 많다.

그냥 코드를 새로 다시 작성하다보면, 해결되는 경우도 있다.

코드의 순서를 어떻게 하느냐에 따라 문제가 생길 수 도 있고, 아닐 수 도 있다.

칩의 버그

=========

ARM칩은 각 제조사마다, 칩의 버그가 있는 경우가 있다.

아무래도, 초반이니 있을 수 있는 버그이나, 칩의 종류가 많기때문에, 해당버그는 수정되지 않고, 칩이 단종될 가능성도 있다.

예) STM사의 어떤칩은 UART인터럽트가 중간에 꺼져버린다.(호출이 안된다.)

AVR은 칩의 종류가 사실상 많지 않고, 10년넘게 사용되어, 많은 버그가 수정된 상태이다.

다음 프로젝트에 사용할 CPU는?

================================

당연히, ARM coretex이다.

AVR은 알수없는 컴파일러 문제가, 개발자들을 상당히 괴롭힌다.

이번에도 거의 다된 상태에서, 이상하게 동작을 한경우이다.

최적화 옵션을 끄니, 더 황당한 짓을 하기도 했다.

오히려, Os옵션으로 최적화 했을때, 그래도, 비교적 정상적인 동작을 했다.(어이 없음)

(물론, 윈도우에서 크로스컴파일 에뮬레이션까지 다해본 코드이다.)

AVR, ARM등의 CPU프로그램을 작성할때,

1) 프로그램 작성

2) 다운로드

3) 테스트

4) 1번 부터, 될때까지 무한 반복.

문제는 다운로드 시간이 1초든, 10초든, 시간이 걸린다는 점입니다.

다운로드가 마우스클릭만으로 되는 경우는 드물고,

CPU 리셋을 하고, 다운로드하는 과정이 적게는 수십초~몇분까지도 걸립니다.

프로그램코드가 크다면, 다운로드 시간은 더 많이 걸립니다.

오타 하나 고치려고, 수정하고, 다운로드하고, 테스트하는 시간이 생각보다 많이 소모됩니다.

그래서, 윈도우환경에서 프로그램코드를 검증하고, 나중에 CPU에 다운로드해서, 테스트해보는 방법이 빠를 수 도 있습니다.

윈도우 환경에서는 많은 메모리와, VC++ 같은 우수한 컴파일러 환경을 사용할 수 있습니다.

문제는 윈도우 환경에서 동작하기위해, 코드를 각각 작성해야 하므로, 약 1.5배 정도의 코드를 작성해야 합니다.

C언어의 장점은 함수만 동일하게 작성하면, 어떤 환경이든, 대부분 동작이 된다는 것입니다.

물론, 하드웨어 환경도 비슷하게 꾸며주어야 합니다.

예) EEPROM_write() => WIN_EEPROM_File_Write()

보통 아래와 같이 매크로를 사용하여, 함수를 각각 만들어 줍니다.

void LCD_putch(byte c)

{

#ifdef WIN32

printf("%c",c);

#else

LCD_send_data(c);

#endif

}

UART통신, EEPROM, LCD, KEY등도 각각 함수를 만들어 줍니다.

물론, 윈도우 환경에서 사용할 함수를 만드는 작업이 쉽지않고, 시간도 많이 걸립니다.

그러나, 잘 많들어 놓으면, CPU에 다운로드하고, 테스트하는 시간이 획기적으로 줄어들어, 전체 개발속도가 향상될 수 있습니다.

기존 장비의 프로그램에 문제가 있어, 수정하고 있습니다.

다른 사람이 만든거라, 거의 새로 작성해야합니다.

기존 프로그램 코드는 여러가지 문제가 많아,

도저히 "부분수정"이 안됩니다.

"블랙박스모델"처럼, 입출력 동작 데이터만으로

"재구현"이 필요합니다.

물론 시간이 많이 걸립니다.

"부분수정", "최소수정"을 하려고, 다각도로 검토해보았으나.

시간만 많이 소요되고, 별 진전이 없고, "어차피 전체 수정이 필요하다"는 결론이 나옵니다.

지난번 장비 수정에서 약 50%의 시간이, "부분수정, 최소수정 검토"하는데 시간이 소모되었습니다.

"어떻게 수정할것인지에 대한 검토"는 반드시 필요하나, 발견되지 않은(않는) 문제때문에, 불필요하게 시간이 소요되는 경우가 맣습니다.

그냥 차라리, 블랙박스 모델로 새로 만드는것이 더 확실하고, 깔끔합니다.

그런데말입니다. 여기서 또 문제가 있습니다.

기능이 복잡한 경우에는 시간이 많이 소요됩니다.

최소수정으로 하려고하나, 안되는 경우에는 울며겨자먹기로, "재프로그램"을 하게 됩니다.

물론, 이경우에는 더 많은 시간이 소요됩니다.

제품을 개발하는데는 보통 몇개월에서 1년 이상이 걸리기도 한다.

개발해놓고, 생산, 판매하려면, 최소 1년은 걸린다.

그런데, 많은 부품들이 1~2년안에 단종되기도 한다.

잘 사용하지 않는 부품들은 수요가 없기때문에, 부품 제조사에서, 불과 1~2년만에도 단종을 시킨다.

어쨌든, 개발해놓은 제품을 생산하려고 하는데, 부품이 단종되면, 여간 골치아픈게 아니다.

비슷한 대체품이 존재한다면, 다행이지만, 핀 배열이나 핀 숫자가 다르면, PCB를 새로 설계해야하고,

전자파 인증까지 새로 받아야하기때문에, 수개월이 걸린다.

또한, 특성이 거의 비슷하다면, 문제가 안되나, 조금 다를경우, 회로수정을 고려해야하고,

이렇게되면, 재개발이나 다름없게 된다.

그래서 제품개발시에는 가능하면, 많이 사용하고, 대체품이 많은 부품을 사용하는것이 좋다.

그러나, 이것은 생각만큼 쉽지 않다.