오래된 비디오폰 수리 및 컬러 LCD 개조

살고 있는 아파트에 20년이 넘은 비디오폰이 설치되어 있다.
당시에는 상당히 획기적이고 고가의 장비였을 것이다.
그 당시를 살아보지 않은 사람이라 잘 모른다. 크크크...
현관 카메라는 흑백이며, 비디오 디스플레이도 역시 흑백에 무려 브라운관 모니터.
고장이난듯 동작도 하지 않고 누렇게 변색된채로 거실벽에 큼지막하게 자리를 차지하고 있어 미관상 좋지도 않다. 하다 못해 외부 카메라 만이라도 동작해주면 좋으련만...
그래서 컬러 카메라에 LCD 모니터를 달아주는 개조를 해보기로 했다. 개조와 더불어 수리가 가능한 부분이 있으면 수리도 해주었다.


[참고 이미지]

뜯기전 사진을 찍지 않았는데 대충 분위기가 위 사진과 같다. 우리집은 벽지가 하얀색이라 누렇게 변색된게 나이 많이 먹은걸 그대로 보여주고 있었다.
수리 및 개조를 하려면 일단 뜯는다.


[비디오폰 탈거]

배선이 예상했던 것보다 무지하게 복잡하다. 신형으로 설치된 인터폰 배선과 얽혀있어 더 복잡해 보인다. NTSC용 동축 케이블을 제외하고 나머지는 모두 같은 종류의 선재를 사용해 구분이 되지도 않는다. 모든 선마다 라벨을 붙여주고 뜯어 낸다.


[비디오폰 본체]


[비디오폰 본체 메인보드]


[비디오폰 본체 단자대]


[현관 설치 카메라]

현관 밖에 설치되어 있는 카메라를 뜯어봤다. 카메라가 동작 되는지 전원 넣고 별도 모니터로 확인해 보니 게슴츠레 흑백 영상이 나오는가 싶더니 이내 화면이 깨지고 지글지글거린다. 다행히 카메라 모듈과 음성 모듈이 분리되어 있어 작업이 수월 했다. 기존에 붙어 있는 흑백 카메라 모듈을 들어 내고 컬러 카메라를 달아 준다.


[컬러 카메라 모듈]

일전에 아파트 CCTV 교체하면서 버려 놓은 카메라를 주워 놓았던걸 재 사용했다. 아파트 현관 천장에 반구 모양으로 달려있는 그 카메라에서 뜯은 것이다. 렌즈만 닦아 주니 잘 나오는데 왜 교체를 했는지 모르겠다. HD급으로 바뀌었나?...
여튼 아래와 같이 달아 준다.


[카메라 모듈 교체]

비디오폰 본체에는 아래 사진과 같이 상당히 컴팩트하게 잘 만들어진 브라운관 모니터가 달려 있다. 브라운관 모니터를 그 작은 공간에 잘 우겨 넣었다. 역시 공돌이들은 대단해...


[흑백 브라운관 모니터]

컬러 LCD 모니터는 비디오폰 연령대에 맞춰 'GoldStar' 할아버지를 달아 줬다. 그래도 나이대가 맞아야 잘 어울리겠지 하는 마음에서다.


[비디오폰과 비슷한 연세로 보이는 컬러 LCD 모니터]

LCD모니터는 오래된 캠코더에 모니터용으로 달려있던 것이다. 최근 기종을 달아 주려고 했으나 최근 LCD 모니터는 전원 및 입력 소스 선택이 리모컨 방식이거나 소프트 스위치 방식이라 전원이 들어 가자 마자 바로 동작 해야 하는 비디오폰 모니터 용도로 사용하기에 적합하지가 않다.
다만 좀 아쉬운건 LCD 크기가 작다는거...
이제 모두 가조립 하고 배선연결 후 동작 시험을 해본다.


[비디오폰 및 카메라 연동 시험]


[카메라 연동 확인]

잘 되는군...
어렸을적 내가 그림을 좀 잘 그렸었다.
잘 되는 것을 확인 했으니 다시 달아 준다.
달아 주기 전에 비디오폰 프레임을 모두 탈거하여 세제로 다시 닦아 준다. 닦아 주고 나니 누런끼가 살짝 줄어 들면서 좀 나아 졌다.


[재 장착]


[현관 카메라 모니터]

조립은 분해의 역순.
볼트가 몇개 남아도 당황하지 말고 침착하게 처음부터 다시...

Pure Single Precision Math-Library

  써 놓고 보니 제목이 그럴싸하다.
  ARM Cortex-M4 코어가 들어가는 STM32F429 보드를 가지고 놀던중 수학함수(sin(), cos(), sqrt() 등등)를 사용할 필요가 있어 sin() 함수를 호출 했더니 CPU가 죽는다.
  Cortex-M4 FPU는 double precision을 지원 하지 않는 다는걸 알았다. 그래서 이번엔 sinf()를 호출 해 봤더니 역시 또 CPU가 죽는다.
  나는 보통 Embedded System용 툴체인은 직접 빌드해서 사용한다. 내가 만든 툴체인에 문제가 있나 싶어 FPU관련 옵션을 이리저리 바꿔가면서 툴체인을 다시 빌드해봤으나 역시 증상이 동일 하다. 해본 사람은 알겠지만 툴체인 한번 빌드하는데 적게는 30분에서 많게는 2~3시간이 걸린다. 더 많은 옵션으로 테스트를 해보고 싶지만 툴체인 빌드하느라 시간을 다 까먹고 있어서 툴체인 빌드 삽질을 중지 하고 수학함수(libm) 소스를 열어 봤다. arm-unknown-eabihf(bare-metal)로 빌드 할 경우 newlib가 사용되고 arm-unknown-linux-gnueabihf로 빌드 할 경우 glibc가 사용된다(툴체인 뒤에 붙는 hf는 hardware FPU라는 뜻임). newlib의 경우 수학함수가 모두 double precision으로만 빌드 되고 sinf()나 cosf()와 같은 single precision 함수는 껍데기만 single precision일뿐 정작 함수 내부 구현시 double precision을 사용한다. 그러니 CPU가 죽을 수 밖에...
  glibc소스 확인 결과 삼각함수나 sqrtf(), powf()등은 함수 이름에 걸맞게 내부 구현도 pure single precision으로 구현되어 있었다. 그런데 왜 CPU가 죽는 것일까? 툴체인 빌드시 명확하게 single precision으로만 수학 함수가 빌드되도록 옵션을 설정 해야 한다. 또한 gcc 버전이 올라 갈 수록 하위 호환이 필요한 함수들의 경우 실제 테스트를 해보지 않는 이상 잠정적인 버그로 남아 있을 수 있다. 실제로 ARMv4로 빌드 옵션을 주고 컴파일 해도 최근 gcc의 경우 ARMv7로만 빌드 되는 경우도 있다. 아마 낮은 버전의 gcc와 glibc의 조합을 이용하면 Cortex-M4용 수학함수 툴체인을 만들 수 있을 것이나, 시간 소모가 많다.
  이번 문제는 툴체인을 다시 빌드하지 않고 필요한 수학 함수를 소스 수준에서 포팅하여 완전한 'pure single precision'으로 빌드 하여 사용하기로 하였다.
  openlibm, fdlibm, glibc, yeppp등을 검토하여봤다. openlibm의 경우 ***f()함수는 대부분 single precision으로 구성되어 있으나 삼각함수는 double precision으로만 구현되어 적용이 불가 하였다. sinf(), cosf()등이 있으나 함수 껍데기만 float이고 내부 상수 및 수치 연산은 모두 double로 구성되어 있었다. fdlibm은 오직 double precision만 사용 가능하다(readme에 언급되어 있음). yeppp의 경우 소스크기가 큰편이라 자세히 보지 못했다. architecture별로 FPU사용에 최적화가 되어 사용시 큰 잇점이 있을 것으로 보이나 일반적인 libm 형태 소스 구성이 아니라 분석하는데 시간이 걸려 pass함(나중에 속도 최적화시 다시 봐야 할거 같다). 마지막으로 glibc는 대부분 내가 필요로 하는 함수는 single precision으로 구현되어 있었다. 역시 구관이 명관이라... glibc의 libm중에도 expf()와 같은 일부 함수는 내부에 double precision 연산이 들어가 있는 것도 있었다. glibc 버전중에 찾아보면 single precision으로 구현된 소스가 있을 텐데 일단 지금은 필요한 함수가 아니라 우선 아래 함수만 포팅하여 사용하였다.

  - sqrtf()
  - sinf()
  - cosf()
  - tanf()
  - asinf()
  - acosf()
  - atanf()
  - atan2f()

  pure single precision으로 구성한 소스를 첨부합니다. 필요하신 분은 가져다 활용 하시기 바랍니다. libm 소스는 glibc-2.21에서 발췌 하였습니다. 첨부된 소스 이외 의존성은 없습니다. standalone으로 빌드하여 사용 하시면 됩니다. *.c 파일은 프로젝트에 포함 시켜서 빌드하면 되고 사용시 math.h 헤더파일만 포함하여 사용 하면 됩니다.
  IEEE754(부동 소숫점 연산 표준) 함수를 발췌 하여 사용하였으므로 각 architecture별 FPU가 가지고 있는 최대 성능이 나오지 않을 수 있습니다.

소스다운로드