IoT 진행 방향은 점점 말을 못하는, 의사 표현을 할 수 없는, 지능이 낮은, 치매에 걸린, 장애가 있는, 어린, 아기 또는 유아의, 병이 있는 사람들을 대상으로 가고 있는 분위기다.


현재 IoT 분야에서 가장 많이 보급된 것은 헬쓰케어용 팔찌와 클립, 자전거용품 분야이고 최근들어 가장 큰 이슈를 부르고 있는 것은 애플 와치인것 같다.


IoT와 웨어러블의 결합이면서 헬쓰용 센서와 BLE의 노티를 결합한 제품인 애플 와치는 현재 사람들이 시계의 관점에서 바라보고 있다. 이름이 와치니 애플 와치라고 부르는게 당연할지도 모르지만 스마트 폰과 피처폰의 관계, 기존 산업용 PDA와 아이패드의 관계를 보았을 때 그렇게 보는 시점이 맞는지를 모르겠다.


애플 와치를 사면서 사람들이 우려하는 점은 1년 또는 2년마다 애플와치가 나왔을 때, 과연 그 때마다 새 디바이스를 사면서 업그레이드를 할 수 있겠는가? 정확히는 그 비용이 감당이 되는가가 되는것 같다.


애플 와치 자체가 좋아보이고, 아이폰과 연계해서 무궁무진한 활용분야가 있을 것도 같지만, 디지털 기기라는 특성과 속도 문제, 업그레이드 문제, 센서 개선 문제 등으로 인해서 이렇게 비싸게 산 장비가 애플 와치 2, 애플 와치 3가 나왔을 때 무용지물이 되는게 아닐지가 우려스려운 것이다.


이미 완성품으로 나오는 제품이기에 추후 개선 사항이 발생하면 다시 살 수 밖에 없기 때문이다. 애플이 일정 금액을 보상해주는 프로그램을 운영하지 않는 이상은 60만원 정도는 가볍게 쓸 수 있는 사람이 아니라면 망설일 수 밖에 없다.


스포츠 버전은 너무 저렴하고, 스틸 밴드 버전이 가볍고 좋아 보이기 때문에 스포츠 버전 대신에 스틸 밴드 버전을 살 수 밖에 없는 상황이기 때문이다.


하지만 또다른건 과연 애플이 언제마다 새로운 애플 와치 제품을 갱신해서 내놓을까 하는 것이다.


사실 애플 제품이 다 잘팔리는 것이 아니다. 쓸모가 어느정도 있음에도 불구하고 안팔리는 제품은 공유기, 애플 TV 등의 제품이 있고 아이패드 미니도 제품 변화가 거의 없는 편이다. 레티나로 바뀌고, 지문인식된게 아이패드 미니 2와 미니 3니까.


애플에서는 매번 아이폰을 꺼낼 필요가 없도록 애플 와치를 만들었다고 한다. 이전 아이폰 5S에 비해서 커진 6과 6 plus라는 전략과 같이 도입한 것으로 보인다. 


하지만 손목을 걷어올려 그 작은 화면을 조작하는 것과 주머니에서 폰을 꺼내서 잠금을 풀고 앱을 구동하는 것 중에서 과연 어느게 더 불편할지는 잘 모르겠다.


아마 대부분의 사람을은 애플와치 2를 노리겠지만 내 생각은 차라리 1세대를 사고 차라리 3세대를 다시 사는게 나을지도 모른다. 과젼 두번째 세대 제품은 완전하게 나올까? 난 그것도 의문이다.

'업무' 카테고리의 다른 글

환율이 쉬지 않고 오르는군요.  (4) 2008.10.06

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,

이틀에 걸쳐 안드로이드에서 나오는 로그를 파일로 저장하기 위한 삽질을 수행하였다. –_-;;

분명히 헤메는 사람이 있을테니 그런 사람들을 위해 기록을 남겨 놓는다.

logback은 log4j와 같은 건데 안드로이드 용 log4j가 동작이 잘 안되서 이걸 썼다.

 

참고 싸이트는 아래와 같다.

 

http://ismydream.tistory.com/145

http://tony19.github.io/logback-android/

http://logback.qos.ch/manual/appenders.html

http://mantdu.tistory.com/entry/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%EC%A0%80%EC%9E%A5%EC%86%8C-%EA%B2%BD%EB%A1%9C-%EC%96%BB%EC%9D%84%EC%8B%9C-emulater0-%ED%95%B4%EA%B2%B0%EB%B2%95

 

위 글에 적힌 대로 다 따라 하면 된다.

 

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

 

이거 맨 위에 넣어주고

 

org.slf4j.Logger Log = LoggerFactory.getLogger(getClass());

 

이거 선언하고

 

assets 폴더 밑에 logback.xml 파일 하나 만들어서 (확장자가 xml이어야 한다. 도스 창에서 파일 하나 루트에서 만든 다음에 파일 탐색기에서 끌어다 이클립스 해당 폴더로 던지면 복사되어서 들어간다.)

 

<configuration>
  <appender name="FILE" class= "ch.qos.logback.core.FileAppender" >
    <!-- lazy initialization: don't create the file until 1st write -->
    <lazy >true </lazy >

     <file > /storage/emulated/0/aaa/log.txt </file >
    <encoder >
      <pattern >%d{HH:mm:ss.SSS} %msg%n </pattern>
    </encoder >
  </appender >

  <root level="DEBUG">
    <appender-ref ref="FILE" />
  </root >
</configuration>

 

이 내용 집어 넣고

 

안드로이드매니피스트에

 

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>

 

이거 넣어주면

 

        //Log.debug("" + "\t" + "99999");

 

이런식으로 써주면 로그 파일이 생성되게 된다.

자 그럼 삽질의 포인트가 무엇이냐?

 

파일이 어디에 저장될 것이냐의 문제인데, 안드로이드 내부의 절대 경로를 얻어야 한다.

 

String storage = null;

storage = Environment.getExternalStorageDirectory().getAbsolutePath();

Log.debug(storage);*/

 

이렇게 해주면 안드로이드 외부저장소 절대 경로를 얻을 수 있다.

지금 logback.xml 이 파일 쓰기 상태니까 이걸 logcat으로 내보내기 위해

 

<configuration>

<!-- Create a logcat appender -->

<appender name="logcat" class= "ch.qos.logback.classic.android.LogcatAppender" >

<encoder >

<pattern >%msg </pattern>

</encoder >

</appender >

<!-- Write INFO (and higher-level) messages to logcat -->

<root level="DEBUG">

<appender-ref ref="logcat" />

</root >

</configuration>

 

이 내용으로 잠시 교채해주고 tag: (메인 액티비티 내용 중에서 일부 텍스트)를 이용해서 필터링 하면 외부 저장소 절대 경로를 얻을 수 있다.

 

그리고 로그 파일을 함부로 지우면 안된다.  해당 앱을 끄더라도 안드로이드 파일 탐색기에서 새로 고침하거나 상위 폴더 올라갔다가 내려오기를 반복하면서 파일 사이즈가 증가하는지 확인해야 한다. 만약 지우면 어떻게 되냐고? 파일이 안 써진다.

 

앱을 확실하게 끄려면 홈키를 길게 눌러서 끄기 바란다.

 

그리고 로그 파일 추출하고 나면, 로그 파일을 그냥 지우지 말고, 내용만 완전히 지워서 파일 사이즈를 0으로 나둬야 쓰기가 잘된다. 미리 파일 싸이즈가 0인 동일 이름의 파일을 준비해뒀다가, 바꿔치기 하는게 제일 좋다.

 

삽질한 이유는 어디에 저장을 해야 하는지 몰라서 : 외부 저장소의 절대 경로에 저장해야 한다.

그리고 앱이 완전히 꺼지지도 않았는데 지워서 : 앱 완전히 꺼야 한다.

지우더라도 내용만 지워야 하는데 파일까지 지워서 : 내용만 지우고 파일 남겨둬야 한다.

 

이러면 쉽게 logcat을 이용해서 안드로이드에서 로그 파일을 저장할 수 있다.


WRITTEN BY
가별이
내가 천사의 말 한다 해도

,

최근 출시된 안드로이드에서 TCP 소켓 통신을 하려다가 3가지 문제에 부딪혔다.


1. 소켓이 열리지 않는다.

2. 소켓은 열렸는데 죽는다.

3. 바이트 단위로 데이터를 보내고 싶은데 잘 모르겠다.




1. 소켓이 열리지 않는 것은, 참조한 샘플 소스가 대부분 옛날 소스이기 때문이다. 소켓을 생성할 때 쓰레드로 띄우지 않으면 소켓이 열리지 않는다.

//선언부

    private Socket socket;

    private BufferedReader networkReader;

    private BufferedWriter networkWriter;

    private DataOutputStream outStream;

    private String msg = "zxcf";    

    private String ip = "192.168.7.101"; // IP

    private int port = 1470; // PORT번호


    int tcp_flag = 0;

//OnCreate

        MainThread thread = new MainThread();

        thread.setDaemon(true);

        thread.start();


아래쪽에 붙일 것

    public void setSocket(String ip, int port) throws IOException {

        try {

        socket = new Socket(ip, port);

            networkWriter = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));

            tcp_flag = 1;

            outStream = new DataOutputStream(this.socket.getOutputStream()); 

            //networkReader = new BufferedReader(new InputStreamReader(socket.getInputStream()));

        } catch (IOException e) {

            System.out.println(e);

            e.printStackTrace();

        }

    }

    

    class MainThread extends Thread {

    public void run (){

    try{

    setSocket(ip, port);    

    } catch (IOException e1) {

    e1.printStackTrace();

    }

    }

    }




2. 보통 샘플들이 소켓을 열고 나서, 글자를 입력하고 버튼을 눌러야먄 동작한다. 그런데 만약 당신이 소켓을 열자마자 동시에 통신을 하려고 하면 앱이 뻗어버린다. (죽어버린다.) 한참 고민하다가 로그를 한줄마다 다 삽입해서 원인을 확인했다.


1번을 적용한 경우에 소켓은 쓰레드에서 열리고 onCreate는 별도로 진행하게 된다. 문제는 소켓이 열리기 전에 tcp 통신을 시도하려고 하면 죽게 된다. 그래서 소켓이 열린 후에 플래그를 바뀌고, 플래그에 따라 통신을 시도하면 된다.


if ( tcp_flag == 1) {

PrintWriter out = new PrintWriter(networkWriter, true);

byte headerbuf[] = new byte[16];

byte[] serialbuf = Build.SERIAL.getBytes();

headerbuf[0] = (byte)0xaa;

headerbuf[1] = (byte)0xaa;

headerbuf[2] = (byte)0xF;

headerbuf[3] = (byte)Build.SERIAL.length();

headerbuf[4] = serialbuf[0];

headerbuf[5] = serialbuf[1];

headerbuf[6] = serialbuf[2];

headerbuf[7] = serialbuf[3];

headerbuf[8] = serialbuf[4];

headerbuf[9] = serialbuf[5];

headerbuf[10] = serialbuf[6];

headerbuf[11] = serialbuf[7];

headerbuf[12] =   (byte) (Integer.parseInt(CurrentZone) - 10000);

headerbuf[13] =   (byte) (10006 - 10000);

headerbuf[14] = (byte)0xfa;

headerbuf[15] = (byte)0xfa;

 

// Send Header

try {

outStream.write(headerbuf);

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

try {

outStream.flush();

} catch (IOException e) {

// TODO Auto-generated catch block

e.printStackTrace();

}

}


즉 플래그가 바뀐 상태에서 소켓 통신을 시도해야만 가능하다.


3. 대부분 TCP 통신 샘플 소스 코드는 println만 지원하므로 DataOutputStream을 이용하는 샘플을 찾아보면 쉽게 할 수 있다.

'업무 > 코딩' 카테고리의 다른 글

logback android 삽질 후기  (0) 2014.11.28

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,
테라텀은 오픈 소스 프로젝트로 업데이트가 빠르기 때문에, 가급적 홈페이지에서 받는게 좋다. 링크를 덧 붙인다.



'업무 > 기타' 카테고리의 다른 글

TBD, NA, NC 뜻  (0) 2009.12.04
복잡한 돌비 라이센스  (0) 2009.11.17
데이터시트란?  (2) 2008.09.08
개발자라면 전자 엔지니어를 정기구독 하는건 어떨까요?  (0) 2008.09.05
MiniPCI to PCI Adaptor  (4) 2008.08.05

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,
한빛미디어에서 나온 유닉스 리눅스 프로그래밍 필수 유틸리티라는 책은 제가 리뷰용으로 받은 아이템 중에서 가장 인상이 깊었고 충격을 받은 물건입니다.

일단 795페이지에 달하는 책의 페이지 수도 방대하지만 지금까지 읽어본 개발서와는 전혀 다른 느낌을 받았기 때문입니다. 임베디드 개발자인 저는 개발에 관련된 책들이나 관련 분야에 대한 해설서, 통계 자료, 소개서, 동향 자료, 브로셔, 사용설명서, 사용자 가이드, 데이터 시트 등의 문서를 많이 봅니다만 그 퀄리티가 천차만별입니다. 다른 건 다 제외 하더라도 개발 관련 책을 보더라도 내용이 붕 떠 있거나, 튜토리얼보다 못한 수준이거나, 뭔가 중요한 내용이 핀트가 틀려 있어서 사람을 혼동하게 하거나, 구성이 엉망이거나, 이건 꼭 알아야 한다고 생각되는 내용인데도 빠져 있는 경우가 많습니다.

예를 들어 작년에 구입했던 리눅스 커널 구조와 원리라는 책을 언급해보기로 하죠. 


위의 링크에서 소개글을 보실 수 있습니다. 하지만 이 책을 펼쳐서 읽어보면 정말 이해가 하나도 안될 정도입니다. 제가 커널을 한번도 들여다 본적이 없긴 하지만 당연히 잘 아는 사람이 재확인 하려고 사기보다는 그 구조와 원리를 알고 이해해서 써먹어보려고 사는게 당연하겠지요. 하지만 그런 입문자가 읽고 이해할 수 있는 배려가 하나도 되어 있지를 않습니다. 당연히 입문자니까 간단한 책을 봐야지 왜 이런 책을 사보냐고 하시면 곤란합니다. 이쪽 개발 일을 하다 보면 사실 물질적으로 형성되어서 손이 잡히는 게 하드웨어고, 코드로 되어 있는 게 소프트웨어 일뿐 쓰다 보면 그 기본적인 인터페이스나 원리는 유사한 경우가 많습니다. 다 개발자가 자기 쓰려고 만들다보니 기본적인 부분은 비슷할 수 밖에 없거든요. 그렇다면 개발에서 쓰이는 예를 들어가면서 설명하고 이게 어떤 식으로 중요하다는 언급을 하게 되면 쉽게 이해를 하게 되어 있습니다만 위에서 언급한 책은 그냥 소스코드를 보는 것보다 조금 나은 수준을 제공해 줍니다.

리뷰하고자 하는 책에 대한 링크를 걸겠습니다.


이 방대한 책을 설명할 엄두도 안나거니와 링크 아래쪽에 보시면 10개에 달하는 리뷰가 각 분야를 개발해본 사람들에 대한 입장에서 기술하고 있습니다. 따라서 저 리뷰를 읽어보시면 좀 더 자세한 느낌을 받으실 수 있을거라고 생각하고 이 리뷰에서는 저의 입장에서 느끼는 점들과 책에서 받은 느낌들을 이야기해보고 싶습니다.



1. 이 책은 개발자가 개발자를 위해서 쓴 배려 깊은 책입니다.

리뷰를 해서 칭찬을 하는게 아니라 이 책 자체가 정말 국내의 입문 개발자들을 위해서 쓴 책이라는걸 읽다보면 느낄 수 있습니다. 책 전반에 걸쳐서 이 툴이 어떤 식으로 쓰이고 툴이 어떤 환경에서 쓰이는지, 그리고 왜 쓰는지 어떻게 써야 하는지를 주로 짚고 있습니다.

VI 에디터라는 툴이 있습니다. 이 툴은 개발자라면, 그리고 코딩을 해야 할 일이 있는 사람이라면 기본적인 기능은 꼭 익혀두기를 권하고 있습니다. 개발자가 언제나 자기 작업 환경에서 코딩을 하면 좋겠지만 일을 언제나 리눅스 환경에서 일을 할 수 있는 것도 아니라서 윈도우에서 왔다 갔다 해야 하기도 하고, 멀리서 원격으로 일을 해야 하기도 하다보니 꼭 필요한 툴입니다. 제대로 못 쓰면 몸이 고생하겠지요. 이런 툴에 대해서 처음 개발하는 사람이 알려면 어떻게 해야 할까요? 대부분은 네이버 블로그나 구글링해서 쓰는 법에 대해서 참조를 하겠지요? 하지만 대부분의 문서들은 영문 설명서를 번역해놓은 수준일 뿐 어떤 경우에 어떻게 쓰라고 손에 잡히듯이 설명을 해주지는 않습니다. 어차피 취미로 하는 블로그 생활이고 수준 높은 개발자가 블로그를 그렇게 운영할리가 없는 이상 다 고만고만한 수준이죠. 그래서 명령어 몇개 찾아보고, 명령어표 인쇄해서 벽에 붙여놓고 봅니다만.. 네.. 저두 종이 몇변이나 잊어먹고 아는건 VI 여는 것. VI에서 편집 시작하는 것. 저장하는 것. 강제 종료밖에 못했습니다. 복사야 찾아보면 어찌 저찌 한다지만 쏙쏙 편리한 기능을 익하는건 참으로 난해한 일이지요. 하지만 이 책은 예를 들어가면서 설명을 잘 하고 있습니다. 그리고 다른 책과 차별되는 점이 예 자체가 실제로 개발에 쓰일만한 일들을 가지고 친절하게 예를 들고 있습니다. 사용자는 조금 인내심을 가지고 따라해보면 되고, 실제로 개발에 가까운 걸 바로 쓸 수 있게 가르쳐 주기 때문에 이걸 내가 왜 하고 있나, 이거 정말 쓸만한건가 하는 의구심을 지울 수 있습니다. 그리고 참 다행인것은 쓸만한걸 일하는 것처럼 연습 하고 있기 때문에 옆 자리 동료가 바라볼때 저 사람이 일은 안하고 책만 들여다보는 그런 게 아니라 뭔가를 하고 있는 것 같군이라고 인식 시켜준다는 점이 큽니다.

2. 구성 자체가 개발에 바로 쓸 수 있는 툴을 순서대로 쓸 수 있도록 가르쳐 주고 있습니다.

개발자가 개발에 필요한 일을 할 때 학교 다닐때나 강좌 배울 때처럼 하나하나 과목별로 찾아가면서 배울 수가 없습니다. 맨날 납땜만 하던 사람이 만져본거라고는 매트랩, pspice, 어셈블리, PIC, 8051용 C 정도나 만져봤으면 다행인데 갑자기 리눅스에서 BSP(Board support package)로 나온 부트로더와 커널, 드라이버, 응용 프로그램을 개발 환경을 옮겨서 코드를 수정하고 잘 돌아갈 수 있도록 컴파일 하고, 퓨징하고, 옵션 수정해가면서 개발하기란 참 어려운 일입니다. 상위와는 또 다른 일이지요. 막상 하라고 해서 페도라 깔고 나면 덩그라니 떠 있는 X 윈도우 환경을 보면 한숨밖에 안나옵니다. 소스 코드 풀어서 안에 봐야 뭔지도 모르겠고, 영문 메뉴얼은 천몇백 페이지인데 이거 뭐 어떻게 하라는지 답도 안나오죠. 하지만 이 책을 보고 한번 따라해보고 이해를 해보면 제조사에서 보내준 가이드대로 하다가 막혀서 안될때는 참으로 답답하고 한숨만 나오고 뭘 어떻게 해야 할지 답이 안섭니다. 하지만 이 책은 에디팅과 컴파일, 링킹. 디버깅에 대한 내용을 확실하게 시스템적 하위 레벨에서 개념을 머리에 심어줍니다. 그리고 여러가지 기술을 가르쳐주지요.

3. 저자가 하위 레벨에 대해서 잘 이해하고 있고 그걸 바탕으로 책을 썼습니다.

저자는 RTOS와 컴파일러, 디비거를 개발한 적이 있고 그 경험을 바탕으로 책을 썼습니다. 굳이 그 사실을 언급하지 않더라도 책을 읽다보면 노련함이 책 전반적으로 배어 나옵니다. 코딩이 되었던 개발이 되었든간에 도구 없이는 개발할 수가 없습니다. 그리고 이 책은 그 도구의 사용법에 대해서 훌륭하게 가르쳐 주고 있습니다. 하위 내용에 대해서 필요가 없는 사람들은 이 책의 내용중에서 일부는 필요가 없을지도 모릅니다. 하지만 사실 저에게 있어서는 그 시스템의 기본 원리를 꿰뚫어 설명해주는 내용이 더 반가웠습니다. 한달동안 틈나는 사이마다 따라해보려고 했지만 개발일이 지금도 발목잡고 있기에 틈틈히 펼쳐서 중간중간 구경하기를 더 많이 하고 진도는 많이 못 나간 상태입니다. 하지만 앞으로 계속 펼쳐보고 싶다는 마음이 절로 드는 책입니다. 이 한권 마스터하면 중급 개발자로서의 확신이 들 것 같달까요?

4. 구성이 잘 되어 있습니다.

편집은 한빛미디어의 실력이겠지만 폰트도 좋고, 종이질도 좋고 줄 간격도 좋습니다. 적재 적소에 그림이 잘 배치되어 있고 이해하기 쉬워요. 안의 편집도 이쁘게 잘 되어 있습니다. 이런 작은 요소들은 종종 무시되는 경우가 많습니다. 최근들어 계속 좋아지고 있습니다만 그래도 이책은 제법 잘 나와 있습니다. 또한 내부에 글의 흐름이 읽기 편하고 기억하기 좋게 되어 있습니다. 많이 가르쳐보신 솜씨가 팍팍 느껴져요.



이 책의 가장 큰 미덕은 술술 읽혀 내려간다는 점에 있다고 생각합니다. 그리고 머릿속에도 잘 들어오고 해본다는 재미도 쏠쏠하다는 점이 크네요. 이것 이상의 개발서의 미덕이 있을까요? ㅎㅎ





'업무 > Linux' 카테고리의 다른 글

vsftpd 설정하기  (0) 2008.08.22
Fedora Core 6에서 고정 IP 잡기  (2) 2008.07.10
Linux 설정 두번째  (0) 2008.07.10
Linux IP 설정 파일들  (0) 2008.07.08
Linux에서 path 잡는다고 삽질했습니다.  (0) 2008.05.19

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,

TBD, NA, NC 뜻

업무/기타 2009. 12. 4. 02:20
하드웨어 개발하다 보면 회로도에서 종종 보게 되는 단어가 있다.

TBD : to be determined or to be documented
NA : not available
NC : no connect

보통 이 단어는 구글에서 뒤져도 잘 안나온다. 일반적으로 위의 단어가 붙어 있는 부품들은 거의 붙어있지 않다. 물론 TBD는 다른 특정 부품일 경우도 있다.

'업무 > 기타' 카테고리의 다른 글

최신 TERA TERM 테라텀 4.67  (0) 2010.11.22
복잡한 돌비 라이센스  (0) 2009.11.17
데이터시트란?  (2) 2008.09.08
개발자라면 전자 엔지니어를 정기구독 하는건 어떨까요?  (0) 2008.09.05
MiniPCI to PCI Adaptor  (4) 2008.08.05

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,

돌비는 AC3이다.

내가 개발하는 보드에 있어서 돌비가 적용된 보드를 개발하려면, 기본적으로 돌비 라이센스를 가지고 있어야 샘플 칩을 살 수 있다. 기본적으로 다른 코덱 같은 경우는 양산 시에만 라이센스가 필요하고, 개발 시에는 라이센스가 필요 없는 경우가 많지만 돌비는 그렇지 않다.

그렇다면 어떻게 해야 돌비 라이센스 없이 샘플 칩을 얻어서 개발할 수 있는가?

내가 A사로부터 돌비가 적용된 칩셋을 받아서 개발할 예정이라고 하자. 그렇다면 A사는 이미 돌비 라이센스를 취득한 상태이다. A사에게 돌비 코리아에 요청해서 샘플 인가를 내달라고 하면 A사가 나에게 공급할 수량만큼에 대해서 샘플 인가를 신청하고, 그 수량만큼 인가가 떨어지면 샘플 칩을 나에게 공급할 수 있다.

즉 A사가 돌비 코리아에 샘플 인가를 신청해야 한다.

'업무 > 기타' 카테고리의 다른 글

최신 TERA TERM 테라텀 4.67  (0) 2010.11.22
TBD, NA, NC 뜻  (0) 2009.12.04
데이터시트란?  (2) 2008.09.08
개발자라면 전자 엔지니어를 정기구독 하는건 어떨까요?  (0) 2008.09.05
MiniPCI to PCI Adaptor  (4) 2008.08.05

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,

이전에 ARM 호환 코어 타입의 보드를 개발한 적이 있었다. 외국의 Reference 보드를 사오고 디자인 파일도 구해와서 그걸 가지고 만드는 일이었지만 RF 보드였기에 그리 쉬운 일만은 아니었다. 이래저래 애를 먹고 해결한 다음에 그 보드를 크게 만드는 작업에 착수를 했다.

같은 부룸을 쓴 보드였지만 보드가 커지게 되니 역시 문제가 다양하게 일어났다.

보드를 만들면서 정말 다양한 일들을 경험해봤지만 역시 가장 문제시 되는 건 커넥터를 써서 마더보드와 도터 보드 형태로 분리해서 만들게 되면 좋은 일이라고는 분리가 가능하다는 것 이외에는 하나도 없다는 것이다. 커넥터를 통하게 되면 일단 그라운드와 전원이 안정화 되기가 어렵고 커넥터 결합 자체도 문제가 되며, 커넥터라는 것이 핀 수가 많은 복잡한 형태일 경우 PCB에 마운트가 안 되는 경우가 종종 발생한다.

뭐 이외에도 패턴의 임피던스가 틀어지기에 직렬 저항의 값을 조절해서 사각파의 언더슈트나 오버 슈트 현상을 잡아줘야 할 때도 있고 크리스탈의 로드 캐패시턴스를 조절해줘야 하는 경우도 있다. 크리스탈 같은 경우 SMD 타입은 조금만 손납땜을 잘못하면 케이스가 그라운드이기에 쇼트가 나기 쉬운데 그럴 경우 진폭이 크게 줄어든다.

오늘 제목에 적은 리부팅이 자주 된다면 특히 유의해서 봐야 할 것은 전원 노이즈이다. 플래쉬 메모리 같은 경우는 오실로스코프로 관측했을 때 별다른 문제가 없다면 (사실 이 부분이 가장 힘든 부분 중에 하나이기도 하지만) 한번 읽고 그 후에는 동작 하지 않기 때문에 전원 쪽은 되던가 안되던가 둘 중에 하나이기도 하다. 일단 부팅이 시작했다는 것은 플래쉬에서 부트로더를 읽어와서 메모리에 적재하고 그것을 디코딩하여 동작하는데 성공했다는 이야기이기 때문이다. 하지만 이게 부팅을 하다가 리부팅을 한다면 왜 그럴까? 그것은 CPU 내의 와치독 타이머가 더이상 뭔가의 이유로 동작이 안되어서 리부팅을 시켰다는 이야기이다. 보통 DDR RAM은 2.5볼트로 동작을 하게 되고 그 중간 레퍼런스가 되는 1.25V가 들어가게 된다. 클럭에 맞춰서 데이터가 들어가게 되는데 이 리플이 허용되는 수치가 있는데 그걸 넘어서는 경우가 종종 보인다. LDO로 레귤레이터를 몽땅 꾸민다면 리플이 보일일도 사실 드물지만 대용량 LDO는 가격도 비싸고 필요로 하는 디커플링 캐패시터의 값이 크게 요구 되기 때문에 가격도 오르고 면적도 많이 잡아먹는다. 그리고 LDO는 가장 큰 문제가 전력 효율이 좋지 않고 볼트 드랍이 발생한다고 한다. 따라서 DC/DC 컨터버, 스위치 레귤레이터, 벅 콘트롤러 등이 사용되는데 결국 이것들은 DC를 사각파 형태의 펄스로 바꾸고 이걸 다시 고전류, 고용량의 인덕터에 통과시키게 된다. 펄스를 다시 DC로 바꾼다고 해도 리플은 없앨 수가 없다.  만약 없앤다고 하더라도 터무니 없이 큰 인덕터를 달아야 할것이다. 결국 이런 리플이 보드에 주는 문제를 최소화 하기 위해서는 비드를 통해서 각 전원부를 분리해야 하고 적절한 디커플링 캐패시터를 달아줘야 한다. 이건 설계 단계에서 하는 것이고 만약 문제가 된다면 어떻게 해결을 할 것인가?

일단 데이터 시트를 확인을 해보기 바란다. 보통 전력 효율을 극대화 하기 위해서 고효율모드와 고전류 모드 등 여러가지를 설정할 수 있는 경우가 있는데 그걸 손을 대보기 바란다. 또는 DC가 펄스로 바뀌는데 여기 달려 있는 캐패시터 들이 모두 내압을 버틸 수 있어야 한다. 캐패시터의 내압에 대해서 신경을 잘 안 쓰는 경우도 많은데 용량에 따라 내압이 모두 다르고 사이즈에 따라 다르고 고내압을 가진것과 저내압을 가진 것이 있어서 모두 신경을 써줘야 한다. 이래도 안되면 인덕터가 충분한 전류용량을 가졌는지 확인해보고 바꿔보던가 그래도 안되면 인덕터 또는 파워 초크 로 불리는 놈의 용량값을 올려보기 바란다. L은 로우패스 필터인데 L값을 키울수록 DC만 통과시킬 수 있고 고주파의 감쇄를 더욱 크게 시킨다.

이래도 리부팅이 된다면 DDR RAM과 CPU 상의 패턴이 꼬였거나 혹은 길이가 안 맞거나, 또는 클럭 버퍼나 클럭 라인 외부 인터페이스 라인 등 노이즈를 유발할 수 있는 녀석이 근처 데이터 패턴으로 지나가지 않았나 잘 살펴보기 바란다. 루프를 가지고 클럭이 돌아버리면 이상한 노이즈가 낄 수도 있다. 그래도 잘 안되면 램의 CAS 등의 타이밍을 확인해 볼 것.


WRITTEN BY
가별이
내가 천사의 말 한다 해도

,
안티패드라는 건 plane clearance라고도 한다. via는 금속 드릴 혹은 레이저를 쏴서 만드는데 그렇게 만든 구멍자체는 FR4를 뚫어서 만든 구멍밖에 되지를 않는다. 그래서 그 via 내부에 copper를 코팅하게 되는데 이 코팅이 PCB plae에서 충분히 도통하기 위해서는 그 비아를 금속으로 둘러싸줄 필요가 있다. 보통 원형이 되는데 이걸 안티패드라고 한다. 캐드 도면에서 보면 이 주변을 다시 둘러싼 것을 via clearance라고 하겠지.

이게 갑자기 왜 나오냐고? DDR2 라우팅을 할 때 시그널 패턴은 이 anitpad의 절반이하로 하라고 layout guide에 나오시는군..


첨부한 자료는 DDR2 Layout guide (routing rule)이다. 잠이 안 오시는 분은 읽어봐도 좋다.

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,

A Guide to Memory Timing

The performance and stability of any system depends in part on the memory being used and the settings for the RAM timing. Many users may prefer "xyz" brand, and certainly using brand name memory is a very good idea since low quality memory is often at the root of many stability issues. However, it is also important to pay attention to the timing settings of the memory used.

IMPORTANT: Setting memory timings incorrectly could result in lost or corrupted data (resulting in system instability) or boot/post failure. If a system fails to post, default settings can be restored by clearing the CMOS/BIOS via the clear real time clock jumper on the motherboard. Refer to the board manual for the correct procedure.

The topic of memory architecture is too detailed and complex to cover in a single brief article. We will attempt to simplify a portion of the topic that addresses memory timings and how they work.

Typical timing parameters appear as 2-3-2-6-T1 or some variant. So what do these numbers mean?

Before delving into these specific settings, let's first define some common terms used when discussing memory timings.
  • RAS - Row Address Strobe or Row Address Select
  • CAS - Column Address Strobe or Column Address Select
  • tRAS - Active to precharge delay; this is the delay between the precharge and activation of a row
  • tRCD - RAS to CAS Delay; the time required between RAS and CAS access
  • tCL - (or CL) CAS Latency
  • tRP - RAS Precharge; the time required to switch from one row to the next row, for example, switch internal memory banks
  • tCLK – ClocK; the length of a clock cycle
  • Command Rate - the delay between Chip Select (CS), or when an IC is selected and the time commands can be issued to the IC
  • Latency - The time from when a request is made to when it is answered; the total time required before data can be written to or read from the memory.
Some of the above terms are more important to system stability and performance than others. However, to understand the whole, it is important to understand the role of each of these settings/signals. Therefore, the numbers 2-3-2-6-T1 refer to CL-tRCD-tRP-tRAS-Command Rate and are measured in clock cycles.

tRAS
Memory architecture is like a spreadsheet with row upon row and column upon column, with each row being one bank. For the CPU to access memory, it first must determine which row or bank in the memory is to be accessed and then activate that row with the RAS signal. Once activated, the row can be accessed over and over, until the data is exhausted. This is why tRAS has little effect on overall system performance but could impact system stability if set incorrectly.

tRCD
tRCD is the delay from the time a row is activated to when the cell (or column) is activated via the CAS signal and data can be written to or read from a memory cell. When memory is accessed sequentially, the row is already active and tRCD will not have much impact. However, if memory is not accessed in a linear fashion, the current active row must be deactivated and then a new row selected/activated. In such an example, low tRCD's can improve performance. However, like any other memory timing, putting this too low for the module can cause in instability.

CAS Latency
Certainly, one of the most important timings is the CAS Latency, which is also the one most people understand. Since data is often accessed sequentially (same row), the CPU need only select the next column in the row to get the next piece of data. In other words, CAS Latency is the delay between the CAS signal and the availability of valid data on the data pins (DQ). The latency between column accesses (CAS) then plays an important role in the performance of the memory. The lower the latency, the better the performance. However, the memory modules must be able to support low-latency settings.

tRP
tRP is the time required to terminate one row access and begin the next row access. tRP might also be seen as the delay required between deactivating the current row and selecting the next row. So in conjunction with tRCD, the time required (or clock cycles required) to switch banks (or rows) and select the next cell for reading, writing, or refreshing is a combination of tRP and tRCD.

tRAS
tRAS is the time required before (or delay needed) between the active and precharge commands. In other words, how long the memory must wait before the next memory access can begin.

tCLK
This is simply the clock used for the memory. Note that because frequency is 1/t, if memory were running at 100Mhz, the timing of the memory would be 1/100Mhz, or 10nS.

Command Rate
The Command Rate is the time needed between the chip select signal and when commands can be issued to the RAM module IC. Typically, these are either 1 clock or 2.

This covers much of the basic settings for memory and how they work. As mentioned earlier, it is important to understand what timings your memory will support. Refer to your memory vendor’s website or datasheets for more information.

Cautionary Statement
Activities and projects described herein may involve the use of tools and materials that may present health and safety hazards. These must be handled carefully and all tools and products should be used strictly according to manufacturers' precautions and instructions for the safe use of the respective tool or product. The techniques described herein may result in the voiding of manufacturers' warranties. The user assumes all risks associated with the techniques described in this article/guide. THIS INFORMATION IS PROVIDED “AS IS” WITH NO WARRANTY, EXPRESS OR IMPLIED. AMD ASSUMES NO RESPONSIBILITY FOR ANY ERRORS CONTAINED IN THIS ARTICLE/GUIDE AND HAS NO LIABILITY OR OBLIGATION FOR ANY DAMAGES ARISING FROM OR IN CONNECTION WITH THE USE OF THIS ARTICLE/GUIDE. 

 출처 : AMD
http://www.amd.com/us-en/Processors/ComputingSolutions/0,,30_288_13265_13295%5E13335,00.html

WRITTEN BY
가별이
내가 천사의 말 한다 해도

,