감사합니다.

상용프로그램을 제작하려고하는데, 사용할만한 코드/라이브러리가 매우 적어, 쉽지 않다.

GPL 같은 라이센스에 "몇년후에 소스 공개" 조항을 달면, 엄청난 효과가 있을듯한데...아쉽다.

BSD 라이센스

소스공개 안해도 됨. BSD 사용했다는 광고 금지.

BSD 라이센스 사용여부는 표기해야함.(원 저작권자 표기해야함)

상용소프트웨어 제작에 좋음.

MIT 허가서(라이센스)

BSD와 매우 유사.

LGPL 라이센스

라이브러리 소스코드만 공개.

C언어는 표준라이브러리가 기본으로 들어 있다.

예)stdlib.h, string.h, ..

그러나, 이런 함수들만으로는 프로그램하기가 어렵다.

그래서, 이 함수들을 이용하여, 프로그램이 자주 사용하는 기능을 함수로 만든다.

자주 사용하는 함수들은 여러 프로젝트에서 공용으로 사용할 수 도 있다.

이런 함수들을 얼마나 많이 가지고 있느냐가, 프로그래머의 재산이라고도 할 수 있다.

특정 기능을 하는 함수 하나를 만드는데는, 상당한 시간과 노력이 필요하다.

단순해도, 성능도 좋아야하고, 범용성도 있어야 하고, 코드 사이즈도 작아야 한다.

예를 들면, line과 같은 직선 그리기 함수를 제대로 만들려면, 상당히 어렵다.

물론, 인터넷에서 소스 복사해서 사용해도 된다.

그러나, 무조건 복사해서 사용할 수 없는 경우가 대부분이다.

어쨌든, 이런 함수들을 모아서 개인용 라이브러리를 제작할 수 있다.

물론 *.lib로 만들어서 사용해도 되나,

소스코드 수정이 자주 발생하기 때문에, 큰 도움은 안된다.

소스수정 -> lib로 컴파일 -> 실행파일 재 컴파일

위와같이 라이브러리 컴파일 과정이 추가된다.

이는 실제 프로그램 작성할때는 상당한 시간을 소비한다.

그래서, lib로 만들지 않고, 응용프로그램에 소스코드로 추가하기도 한다.

당연히, 재컴파일하면, 시간이 상당히 많이 소모된다.

그러나, 라이브러리의 소스코드를 수정하고, 확인하기가 용이하기때문에, 나는주로 이 방식을 사용한다.

개인이 만든 공용라이브러리의 장단점

-----------------------------------------------------------

장점

- 자주 사용하는 전용 함수가 있어, 프로그램 개발이 빨라진다.

- 라이브러리 함수의 오류 수정으로, 관련된 모든 프로그램의 오류도 수정된다.

단점

- 공용이기때문에, 마음대로 수정할 수 없다.

  작은 수정으로도, 다른 프로그램에는 문제가 될 수 도 있다.(가장 큰 문제)

- 관리가 어렵다.

  공용이라, 함수, 파일의 개수는 작은 기능차이로 인해, 점점 많아진다.

- 간단한 프로그램도, 소스파일 백업할때, 라이브러리까지 포함해야 해서, 배보다 배꼽이 큰 경우가 많다.

  백업파일의 크기가 매우 크게 증가

개인용 공용라이브러리를 만들경우,

여러 프로그램에서 공용으로 사용하는 경우가 생긴다.

간혹, 기능추가나, 변경등을 해야할 경우가 생긴다.

원칙적으로하면, 함수명을 바꾸어 사용해야하나,

그렇게 되면, 공용 라이브러리의 의미가 없어지는 경우도 있다.

여러 프로그램이 하나의 라이브러리를 사용하여, 라이브러리 수정으로, 예상치 못한 오류가 발생하기도 한다.

해결방법

----------------------------

각 프로그램별로, 전용 라이브러리로 복사하여 사용.

장점

- 해당 프로그램용, 전용 라이브러이므로, 라이브러리 수정으로, 다른 프로그램에는 영향이 없다.

단점

- 동일한 기능을 가진 프로그램이 여러개일 경우, 각각 수정해주어야 하는 번거로움이 있다.

- 백업파일의 크기가 매우 크게 증가한다.

현재는 상용프로그램이라서, 버그 수정이 필요하지만, 공용으로 라이브러리를 사용할 경우, 예기치 못한 버그가 발생하기도 하여, 각 프로그램 별로 라이브러리를 복사하여 사용하고 있다.

백업 파일의 크기는 라이브러리의 크기가 매우커서, 자주 백업하는것이 어렵다.

임베디드용 io 라이브러리 설계 계획

avr, pic, arm등의 작은 마이컴칩에 프로그램을 하다보면,

eeprom, uart,spi,i2c,can,...등의 많은 장치와 통신 또는 데이터를 읽고, 쓰는 기능이 필요하다.

그런데 문제는 각 장치들의 특성이 동일하지 않다는 것이 문제.

단순히, write, read함수로 통일할 수 있을것 같지만, 그렇지 않다.

윈도우의 Write함수도 내부적으로 장치별로 verify기능을 가지고 있을 수 있지만, 확실하게 하려면, verify기능도 넣어야 한다. 또한, 내부적으로 verify기능이 있다고 해도, 전체적으로는 각 장치마다 verify코드가 필요하다.

코드 사이즈 감소는 어려워 보인다.

io라이브러리로 추상화 했을때의 장단점을 비교해보자.

io_read/io_write로 추상화하면

--------------------------------------------------------

장점

- write-verify기능을 공용으로 사용할 수 있다.

- 모든 io에 대해 동일한 기능 적용

  각각의 전용 write-verify함수를 작성하는것과의 차이는?

- 약간 코드 수정으로 다양하게 사용할 수 있다.

- 다양한 장치를 하나의 코드를 사용하여, 코드 사이즈 감소가 될 수 도 있다.(거의 불가능)

단점

- 복잡해짐

- 코드사이즈 증가

- 느려짐

verify

----------------------------

- UART와 같은 포트에서는 write-read-cmp가 아닌, crc, check-sum을 데이터에 포함해서 전송하고, 처리 결과 응답을 받아서 확인해야한다.

  (write-read-cmp 적용불가. 능동장치. 속도가 느려, 대역폭에 제한이 큼)

- flash, eeprom등은 write-read-cmp적용가능(수동장치. 속도가 빨라, 대역폭에 제한이 별로 없음)

결론

---------

임베디드 환경에서는 추상화는 다소 무리가 있다.

불편하더라도, 전통적인 방식의, 장치별로 제작된 전용 함수를 사용하는것이 좋을듯 싶다.