USB를 이용한 전원 공급 (1) - USB BC

-

USB는 데이터 전송을 목적으로 설계되었지만, 전원 공급 기능도 포함하고 있다. 이는 USB로 연결된 간단한 저전력 기기를 동작시키기 위한 것이다. 그래서 USB 2.0에서는 5V 전압과 0.5A의 전류를, USB 3.2에서는 5V 전압과 0.9A의 전류 공급이 가능하다. 하지만 이 스펙은 어디까지나 USB를 통한 데이터 통신을 하는 데 필요한 디바이스를 동작시키기 위함이지, USB를 전원 공급을 위해 이용하려는 목적은 아니었다. 따라서 저전력 기기가 아닌 외장 하드 같은 디바이스는 별도의 전원 공급을 필요로 했고, USB를 통한 전원 충전은 USB가 본래 의도했던 기능이 아닌 일종의 부작용에 가까운 일이었다.

하지만 iPod을 비롯한 많은 MP3 플레이어나 PMP 플레이어들이 이를 이용한 충전 기능을 가지고 나왔다. 어차피 데이터 통신을 위해 USB 포트가 필요하니 별도의 충전 포트를 만드는 것보다 USB 포트를 재사용하는 것이 기기를 싸고 가볍고 작게 만들 수 있었기 때문이다. 결국 브랜드마다 독자적인 USB를 통한 전원 충전 규격들이 만들어졌. 사람들은 이런 혼란스러운 상황이 해결되기를 원했고, 결국 2007년 USB-IF는 USB Battery Charging(a.k.a. BC)라는 표준을 만들어 USB 충전기를 표준의 영역으로 가지고 왔다.

SDP DCP CDP
데이터 전송 가능 데이터 전송 불가 데이터 전송 가능
최대 0.5A(USB 2.0)
최대 0.9A(USB3.x)		 최대 1.5A 최대 1.5A
별도 핸드셰이크 없음 D+/D- 쇼트 D+/D- 라인에 독립적으로 전압을 가해 핸드셰이크
데스크톱, 노트북 등에서 사용 USB 충전기에서 주로 사용 데스크톱, 노트북 등에서 사용

Standard Downstream Port

USB BC는 충전 포트를 크게 3가지로 분류해 정의한다. 우선 첫 번째 충전 포트는 기존 USB 표준에 따르는 충전 포트다. USB 2.0 표준에 따라 0.5A를, 3.X 케이블에서는 0.9A를 공급하도록 정의하고 있는데, 이와 같은 규격의 포트를 USB BC에서는 Standard Downstream Port(a.k.a. SDP)라고 부른다.

Dedicated Charging Port

대신 전원 공급을 위해 USB BC에서는 최대 1.5A까지 공급할 수 있는 Dedicated Charging Port(a.k.a. DCP)라는 포트를 새로 정의했다. DCP의 목표는 충전기를 만드는 것이다. 따라서 DCP 규격을 만족하는 포트에서는 데이터 통신을 할 수 없다.

DCP에 따라 1.5 A까지 지원할 수 있는 충전 포트는 D+ 라인과 D- 라인을 200 Ω 이하의 저항으로 연결시켜 자신이 DCP에 따라 더 많은 전원을 공급할 수 있다는 사실을 전원을 공급받는 Portable Device(a.k.a. PD)에게 알린다. 그러면 전원 공급을 받기 원하는 디바이스는 저항을 낮춰 더 많은 전류를 공급받는다. USB DCP에서 충전 포트는 언제나 5V의 전압을 유지하고 있기 때문에 저항을 낮추는 것으로 더 많은 전류를 공급받을 수 있다.

Charging Downstream Port

DCP는 충전 전용 포트다. 이는 USB 충전기에서는 유용하지만, 데이터 통신을 필요로 하는 컴퓨터의 포트에서는 일반적인 SDP만 사용해야한다. 이는 스마트폰 같이 충전과 데이터 통신을 동시에 진행해야 할 경우 불편함을 초래한다. 이를 해결하기 위해 나온 것이 Charging Downstream Port(a.k.a. CDP)다. CDP는 데이터 전송도 허용하면서 1.5A의 전류를 공급할 수 있다. CDP를 지원하는 포트는 자신이 CDP를 지원한다는 사실을 D+ 라인과 D- 라인을 이용해 알린다. 구체적인 과정은 다음과 같다.

  1. 싱크 디바이스가 D+ 라인에 약 0.6 V의 전압을 가한다.
  2. 충전 포트는 D- 라인에 0.6V의 전압을 가해 응답한다.
  3. 싱크 디바이스가 D- 라인에 약 0.6V의 전압을 가한다.
  4. 충전 포트는 D- 라인에 추가적인 전압을 인가하지 않는다.(즉, 약 0.3 V의 전압 유지)
  5. 싱크 디바이스는 D- 라인의 전압이 0.3V로 유지되는 것을 확인하면 USB 데이터 전송을 시작 + 1.5A 이내의 전류를 공급받을 수 있도록 저항을 낮춤

이 절차가 문제 없이 끝나면 PD는 연결된 포트가 1.5A의 전류를 공급하고 데이터 통신도 허용하는 CDP라는 것을 인지하게 된다. PD는 연결된 포트가 CDP라는 것이 인지되면 DCP에 연결됐을 때와 마찬가지로 1.5A이내에서 원하는 전류를 받을 수 있도록 저항을 조정하여 전력 공급을 조절한다.

Port Detection

PD in USB BC
USB BC에 따른 PD의 핸드셰이크

USB BC를 지원하는 디바이스가 임의의 포트에 처음 연결했을 때 진행하는 핸드쉐이크는 위와 같이 정리할 수 있다. 우선 첫 번째 절차는 연결된 포트가 SDP인지 아닌지 구분하는 것이다. 이를 Primary Detection이라고 부른다. 연결 직후 D+/D- 라인에 아무런 신호를 보내지 않는 SDP와 달리 DCP는 D+ 라인과 D- 라인이 쇼트되어 있기 때문에 같은 전압을 유지하게 되고, CDP를 지원하는 포트는 D+ 라인에 전압이 걸린 것을 확인하면 바로 D- 라인에 전압을 걸기 때문에 SDP와 구분할 수 있다.

그 다음 절차는 DCP와 CDP를 구분하는 절차로 Secondary Detection이라고 부른다. Secondary Detection에서는 PD가 D- 라인에 전압을 가한다. DCP는 앞서 말한 것과 마찬가지로 D+ 라인과 D- 라인이 쇼트되어 있기 때문에 D-에서 가한 전압을 D+에서 확인할 수 있다. 하지만 CDP는 D-에 걸린 전압에 대해 아무런 응답을 하지 않기 때문에 D+ 라인에 전압이 걸리지 않는다.

여기서 확인에 사용하는 0.6V는 USB에서 데이터 통신에서 high voltage로 사용하는 3.3V보다는 낮고, low voltage로 사용하는 0.3 voltage보다는 높기 때문에 데이터 통신과 헷갈릴 일은 없다. 무엇보다 USB는 D+/D- 라인을 이용해 데이터 전송을 할 때 high voltage와 low voltage가 적절히 섞이도록 하는 8b/10b 인코딩을 사용하기 때문에 연속된 D+ 라인이나 D- 라인에 고정된 전압을 가했을 때 이를 데이터 신호로 잘못 해석할 일은 없이 USB BC를 위한 핸드셰이킹이라고 인지할 수 있다.

그리고 행복하게 살았습니다(?)

USB BC는 파편화되어가던 USB 충전기를 하나의 표준으로 통일하기 위한 노력이다. 하지만 USB BC가 나왔어도 여전히 문제는 남아 있었다. 근본적인 원인은 USB BC는 기존에 생산된 포트와 호환성을 유지해야 한다는 것이다.

D+/D-를 쇼트시킨 케이블
D+/D-를 쇼트시킨 케이블

첫 번째 문제는 충전 포트를 DCP를 지원하는 포트라고 속이는 케이블을 쉽게 만들 수 있다는 것이다. DCP에서 D+ 라인과 D- 라인의 쇼트는 충전 포트에서 이루어져야 한다. 하지만 위 사진 같이 실제로는 VCC와 GND핀만 연결하고 내부적으로 D+ 핀과 D- 핀을 쇼트시킨 케이블이 고속 충전용 케이블이라고 팔리기도 한다. 이런 케이블을 사용하면 디바이스는 충전 포트가 DCP를 지원하는 줄 알고 과한 전류를 요청하기 때문에 충전 포트를 망가트릴 수 있다.

두 번째 문제는 전압이 5V로 고정돼있다는 것이다. 이 때문에 공급받을 수 있는 최대 전력이 7.5W로 제한된다는 것이다. USB BC가 처음 나왔던 시절에는 이정도 전력으로도 큰 문제 없을 것이라 생각했지만, 기술의 발전은 생각보다 빨랐고, 이제 스마트폰 등에서도 7.5W는 급속 충전이라고 부를 수 없는 속도가 됐다. 결국 스마트폰 칩셋 제조사들은 퀄퀌 퀵차지, 미디어텍 펌프 익스프레스, 삼성 AFC 같은 비표준 구현체를 만들어 사용했다. 즉, USB BC는 파편화되던 충전 포트를 통일하고자 하던 기존의 목표 달성은 실패했다고 볼 수 있다.

이런 문제를 해결하기 위해서는 기존과 전혀 다른 구조의 포트를 만들 필요가 있었다. 결국 Type A나 Type B 컨넥터는 이런 문제를 해결할 수 없었고, Type C 컨넥터의 USB Power Delivery라는 새로운 표준이 만들어질 수밖에 없었다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

USB 2.0 케이블의 내부 구조

-
아이폰도 USB-C를 사용하면서 온 세상이 USB 로 통일됐지만 실제로는 너무 다양한 USB가 존재한다. 기본 형태인 USB-A나 최근 많이 사용되는 USB-C 뿐 아니라, 보통 5핀이라고 불리는 micro-B를 포함한 다양한 USB-B 컨넥터들이 존재한다. 그래도 컨넥터는 모양이 다르기 때문에 쉽게 구분할 수 있는데 케이블은 답이 없다. 겉으로는 똑같아 보이는 케이블이라도 어떤 케이블은 데이터 통신이 안 되고 어떤 케이블은 데이터 통신이 가능하다. 이런 차이는 케이블 내부 구성에 따라 발생한다. 이번 글에서는 USB 2.0 케이블의 내부를 통해 USB 케이블에 대해 자세히 알아보겠다. Micro-B 케이블의 편조 차폐와 호일 차폐 위 사진은 집에서 돌아다니던 A - Micro-B USB 2.0 케이블의 피복을 벗겨낸 것이다. 절연체 아래로 금속 선이 있는 것을 알 수 있다. 이 선들은 금속 선이지만 전선은 아니다. 이 선은 전자기 차폐를 목적으로 들어간 금속 선이다. 실제 전선은 이 금속 선을 벗겨야 나온다. 이번에 자른 케이블에는 두 종류의 차폐가 사용됐다. 하나는 얇은 금속 호일이고, 다른 하나는 얇은 도체의 가닥으로 이루어져 있다. 전자는 보통 호일 차폐(Foil Shielding)라고 부르고 후자는 편조 차폐(Braided Shielding)라고 부른다. 이 둘은 다 외부 전자기장으로부터 전선을 보호하기 위해 사용되지만, 특성이 약간 다르다. 보통 편조 차폐가 저주파수 전자기파를 차단하는 것에 효과적이고, 호일 차폐가 고주파수 전자기파를 차단하는 데 효과적이다. USB 3.0의 고속 전송 케이블은 이 두 차폐를 사용하는 것이 필수적이고, 그 외의 경우에는 필수는 아니고 권장 사항이다. 하지만 어지간한 싸구려 케이블을 쓰지 않는 한 요즘은 USB 2.0 케이블에도 이 두 가지를 같이 사용한다. 차폐 선이 쉴드와 연결되지 않았다 하지만 고속 전송을 지원하는 케이블이 ...
Read more »

[C++] enum class - 안전하고 쓰기 쉬운 enum

-
C++ 03 까지의 enum 은 여러 가지 문제를 가지고 있었다. 그래서 그 문제들을 해결하기 위해 C++ 11은 enum class 라는 것을 새로 만들었다. 이제부터 기존의 enum 에 어떤 문제가 있었고, 이것을 enum class 에서 어떻게 해결하였는지 살펴볼 것이다. 우선 기존의 enum 은 전방 선언할 수 없었다. 그 이유는 enumerator에 어떤 값이 들어있을지 알 수 없으면 그 크기를 정할 수 없기 때문 이다. 하지만 enum class 는 underlying type을 명시하지 않으면 int 타입과 같은 크기의 변수로 선언되고, int 값 안에 들어가지 못할 값을 지정하면 컴파일 에러를 발생시킨다. 만약 int 를 벗어난 범위의 값을 사용하고 싶다면, underlying type을 명시해주어야 한다. 기존 enum 의 또 다른 문제는 enumerator의 이름의 범위가 한정되지 않는다는 것이다. 예를 들어 아래와 같은 코드를 보자. IO 함수의 결과와 Parse 함수의 결과를 enum 으로 표현해 보았다. 하지만 이 코드는 컴파일되지 않는다. IOResult 의 Error , Ok 가 ParseResult 의 Error , Ok 와 겹치기 때문이다. 이를 해결하기 위해서는 다음과 같이 enumerator의 이름을 다르게 하거나 아래와 같이 namespace 를 이용해야 했다. 하지만 enum class 는 enumerator의 이름이 enum class 안으로 한정되기 때문에 이런 복잡한 과정이 필요 없이 그저 enum class 를 선언하여 사용하면 된다. 무엇보다 기존 enum 의 가장 큰 문제는 정수형 변수로 암시적으로 변환되는 약 타입(weak type) 변수라는 것이다. 하지만 enum class 는 정수형 변수로 암시적 변환이 되지 않는다. enum class 를 정수형 변수처럼 사용하려고 하면 컴파일 에러를 발생시킨다. 만약 정수형 변수로 사용하고 싶으면 static_cast 를 이용해...
Read more »

Log Aggregator 비교 - Scribe, Flume, Fluentd, logstash

-
https://docs.google.com/presentation/d/12A5RlMCVDN6tA_zUnLrZ0TN5v08gz2GhlRdzxy3T3mU/edit?usp=sharing 회사에서 최근에 Log aggregator system으로 무엇을 사용해야 할지 조사해본 자료다. 우선 log aggregator가 무엇인지 한 문장으로 설명하면, 여러 머신에서 쌓인 로그들을 한 번에 분석할 수 있도록 수집하여 주는 시스템을 말한다. 요새는 특히나 클라우드 시스템이 유행하면서 같은 일을 하는 시스템임에도 다른 머신에서 돌아가는 일이 많아지면서 필요성이 크게 증가하였다. 이번 조사로 알게 된 것들을 적어보도록 하겠다. Scribe 우선 scribe 는 Facebook에서 제작하고 사용하던 log aggregator system이다. scribe: https://www.cnblogs.com/brucewoo/archive/2011/12/13/2285482.html 다른 로그 수집 시스템들을 보면 알겠지만, Scribe는 다른 시스템보다 간단한 구조로 되어 있다. Scribe는 일종의 message queue와 message queue에 쌓인 message를 DB에 저장해 주거나, DB가 실패하였으면 local에 저장하였다가 DB가 복구되었을 때 다시 DB에 저장해 주는 것만을 책임진다. 다시 말하면, message queue에 실제로 메시지를 보내는 부분은 사용자가 직접 작성하여야 한다는 것이다. 흔히들 말하는 scribe의 장점은 성능이다. C++로 만든 만큼 다른 시스템들의 3~5배 정도의 성능을 보여준다는 것이다. 하지만 실제 scribe 사용자들은 무엇보다도 Facebook이 실제로 사용하였던 솔루션인 만큼 성능과 안정성에서 신뢰도가 있다는 것을 장점으로 뽑는다. 하지만 나는 scribe를 사용하는 것을 추천하지는 않는다. 일단 가장 큰 문제는 더이상 Facebook이 Scribe를 사용하지 않는다는 것이다. Facebook은 이미 Ja...
Read more »

[Web] SpeechSynthesis - TTS API

-
SpeechSynthesis 는 Web Speech API의 하나로 주어진 텍스트를 소리로 바꿔주는 TTS API이다. SpeechSynthesis 이전에도 TTS 서비스가 있었지만, 이들은 유료이거나 웹에서 사용하기 불편한 경우가 대부분이었는데 SpeechSynthesis 의 경우 브라우저에 내장되는 API이므로 무료로 쉽게 사용할 수 있다는 장점이 있다. 물론 Web Speech API 자체가 아직 draft 에 해당하기 때문에 브라우저가 지원해야만 사용 가능하다는 문제는 있지만, 2016년 8월 15일 현재 데스크탑에서는 크롬과 사파리, 안드로이드 기본 브라우저인 크롬, 아이폰의 기본 브라우저인 사파리에 지원하고, 파이어폭스는 9월에 지원할 예정이므로 대부분의 모던 브라우저에서는 사용할 수 있다. speechSynthesis 는 5개의 함수를 가지고 있다. 그중 4개는 speak , cancel , pause , resume 이다. 이를 이용해서 재생할 음성을 추가하거나 취소하거나 일시 정지할 수 있다. 이 중 speak 함수는 SpeechSynthesisUtterance 를 인자로 받는다. speak 함수를 호출했을 때, 이미 재생 중인 utterance 가 없고 speechSynthesis 가 pause 되어 있지 않으면, 요청된 utterance 는 즉시 재생된다. 하지만 이미 재생 중인 utterance 가 있거나 speechSynthesis 가 pause 되어 있다면, utterance 는 바로 재생되지 않고 queue에 저장되었다가 후에 재생된다. 따라서 실제로 언제 재생되는지는 utterance 의 콜백을 통해서만 알 수 있다. 이벤트의 종류에 따라서 onstart , onend , onerror , onpause , onresume 등의 콜백을 등록할 수 있다. 또한, SpeechSynthesisUtterance 는 6개의 속성을 가지고 있다. 첫 번째 속성은 text 로 읽을 텍스트를 지정한다. 객체를 생성할 ...
Read more »

터미널 출력 제어를 위한 termios 구조체 이해하기

-
지난 글 에서 설명했듯이 OS X, 리눅스를 포함한 Unix를 이어받은 운영 체제는 LF (line feed, 0x0A , \n )를 개행 문자, 즉 커서를 다음 줄의 시작으로 옮기는 문자로 이용한다. 하지만 표준에 정의 된 LF 의 동작은 커서를 다음 줄로 내리는 것일 뿐, 커서를 줄의 처음으로 이동하지 않는다. 파일을 항상 운영 체제에 종속적인 애플리케이션을 통해서만 접근한다면 표준과 다른 동작은 문제되지 않는다. 하지만 파일과 입출력의 구분이 없는 유닉스 계열에서 파일과 프로세스의 입출력이 상호작용할 때 이 차이는 문제될 수 있다. 이 차이를 다루기 위해서 터미널은 출력에 적절한 가공을 하여 출력한다. 이를 제어하기 위한 플래그가 POSIX.1 표준이 정의 하는 termios 구조체의 c_oflag 다. c_oflag 는 터미널이 받은 문자를 출력하기 전에 어떤 후처리를 할지에 대한 플래그다. c_oflag에서 가장 중요한 플래그는 OPOST 다. 이는 입력에 대한 후처리를 할지 말지에 대한 플래그로 OPOST 가 꺼져있으면 다른 플래그와 상관없이 터미널은 받은 문자열을 그대로 보여준다. 이 플래그를 끄는 경우는 거의 없다. 하지만 터미널을 텍스트를 보여주기 위한 용도가 아닌 바이너리 데이터를 전송하기 위해 사용하는 경우 끄는 것이 좋다. 터미널이 Unix 계열 운영 체제에서 원하는대로 동작할 수 있게 해주는 플래그는 ONLCR 이다. ONLCR 이 켜져 있으면 터미널은 출력을 해석할 때 NL 을 CRNL 로 해석한다. 즉, Unix에서도 ONLCR 이 꺼져있다면, LF 를 만났을 때, 다음 줄의 처음으로 이동하는 것이 아닌, 현재 위치의 다음 줄로 이동한다. Unix 계열 운영 체제에서 윈도우에서 만들어진 파일을 출력해야 할 경우, CRNL 을 NL 로 바꾸지 않고도 ONLCR 플래그를 끄는 것 만으로도 간단하게 출력할 수 있다. 이외에도 구형 Mac OS 처럼 동작하게 해주는 OCRNL 플래그나 탭문자( 0x09 , \t )를...
Read more »