임베디드 개발 환경에서 필요한 RS232 관련 지식

임베디드 개발 환경에서 아직까지도 가장 많이 사용되는 터미널 인터페이스는 RS-232이다. RS-232와 이와 관련된 내용을 모두 이해하는 것은 아주 어려운 일이므로 개발에 꼭 필요한 내용 위주로 정리한다.

임베디드 환경에서는 대부분의 경우 RX, TX, GND 3개의 연결을 사용한다. RS-232 연결에 사용되는 여러 종류의 커넥터가 있는데, 현재 가장 많이 사용되는 커넥터는 9 pin connector이다. 25 pin connector는 1990년대 이후 사용되는 것을 본 기억이 없다.  9 pin connector는  DE-9 혹은 DB-9 커넥터라고 불리는데 DE-9이 올바른 명칭이나 DB-9으로 더 많이 불린다.

9 pin connector에서 RX,TX, GND는 각각 2번, 3번, 5번 pin이므로 나머지 5핀은 대부분의 경우 사용되지 않는다. HW Flow Control이라는 기능이 필요할 경우 다른 핀을 사용 하지만 많이  사용되지는 않는다.

9 pin connector는 숫놈과 암놈이 있는데 보통 개발 호스트 컴퓨터에는 숫놈(Male) 커넥터가 타겟 보드에는 암놈(Female) 커넥터가 사용된다.  숫놈 커넥터는 (일반적으로) DTE 장치에 사용되고, 암놈 커넥터는 (일반적으로) DCE 장치에 사용한다.  즉 개발 호스트 컴퓨터를 DTE 장치로 생각하면 된다.  DTE/DCE는 전화기와 모뎀을 사용하여 아날로그 라인으로 통신하던 시절부터 사용해온 명칭으로 컴퓨터를 DTE (Data Terminal Equipment)장치, 모뎀등 통신 장치를 DCE(Data Communication Equiptment) 장치라고 불렀다.  이제와서는 별 의미 없는 명칭이지만, DTE인지 DCE인지에 따라 PIN의 데어터 방향이 결정이 되고 되고, 커넥터의 암수도 바뀌므로 개발 타겟 보드를 DTE로 설정할지 DCE로 설정할지 미리 고민해야 한다.

임베디드 개발 환경에서는 보통 타겟 보드를 호스트 PC와 연결하므로 호스트 PC가 DTE, 타겟보드를  DCE 장치로 설정하는 경우가 많다.  이 경우 DTE 장치에 사용되는 숫놈 커넥터의 3번 핀이 DCE장치의 3번 구멍에 연결되며 DTC to DCE 방향으로 데이터가 전달된다. 2번 핀은 반대 방향인 DCE to DTE로 데이터가 전달된다. (DTE-DCE 연결 시 2은 2번끼리 3번은 3번끼리 연결한다.)

DTE 장치끼리 통신이 필요할 경우 2번과 3번을 서로 꼬아서 연결해 주어야 하며 이렇게 서로 크로스하여 배선한 케이블을 널 모뎀 케이블이라고 부른다.  만일 타겟 보드가 DTE 장치로 설정되어 있다면, DTE인 호스트 PC와 연결하기 위해서 NULL모뎀 케이블이 필요하다. (타겟 장치에 숫놈 커넥터가 달렸다면 DTE장치가 달렸다고 생각하면 된다. 예전에는 이런 경우가 드물었지만, 요즘은 라즈베리 파이 같이 타겟보드에 리눅스등의 PC용 OS가 사용되는 경우가 많아 타겟의 serial포트가 DTE 로 설정된 경우가 많아졌다)

최근에는 PC에 serial port(COM포트)가 거의 장착되어 있지 않으므로 개발 보드에 연결하기 위하여 대부분의 경우 Usb2Serial 장치를 사용한다. Usb2Serial 장치는 일반적으로 커넥터가 숫놈이며 당연히 Host PC가 DTE 장치가 되지만, 암놈 커넥터를 가진 Usb2Serial장치를 사용하면 Host PC가 DCE 모드로 동작하게 된다. 따라서 개발 보드가 DTE 장치라면 널모뎀 케이블을 사용하여 Host PC와 연결(DTE to DTE) 하거나 Host PC에 DCE로 동작하는 (암놈 커넥터를 가진) Usb2Serial장치를 사용하면 된다.

간혹 대책없이 DTE 장치에 암놈 커넥터를 달거나 DCE 장치에 숫놈 커넥터를 다는 경우가 있으니 골탕먹지 않도록 주의하자.

printf와 시스템 성능 그리고 UART baud rate

CPU 사용율이 높지 않음에도 불구하고 이유없이 프로그램 수행 속도가 극도로 느려지는 문제가 발생. 예상되는 원인은 과다한 로그 출력. 임베디드 환경에서는 로그 출력이 UART를 통하여 이루어 지는 경우가 많은데, 이 때 UART의 baud rate이 프로그램 동작의 병목으로 작용하는 것이다. 비록 버퍼가 있다고 하지만, 로그양이 버퍼양을 넘어서면 printf등의 함수도 바로 리턴하지 못하고, 대기할 수 밖에 없을 것이다.  하지만 로그가 많다고 무턱대도 이를 줄이는 것도 쉽지 않은 일이다. 각각의 로그는 각 개발자들이 문제 발생을 확인하고 해결하기 위하여 최적화하여 넣어놓은 것으로 이를 제거하면 나중에 디버깅이 어려워지거나 불가능해 지기 때문이다.

가설 검증을 위해 로그 출력에 사용되는 stderr/stdout용 serial(UART)장치 즉 /dev/ser1의 baud rate을 올려보았다. 문제 해결!!!  수정된 이미지를 배포하지만 얼마 지나지 않아서 생산기술에서 연락이 온다. Baud rate 변경으로 인해 생산 테스트 장비를 모두 바꿔야하고, Baud rate 상승으로 인한 통신 에러 증가가 예상되어 절대로 Baud rate를 변경하면 안된단다.   다시 원점.

Baud rate이 115200 bps라면 대충 계산해도 115,200/8=14,400 character 이상의 로그는 (1초에)출력이 불가능하다. 실제로는 UART 전송 시 설정에 따라  Start/Stop bit 및 1 char당 bit수 그리고 char간 delay 등을 고려해야하고 이 경우 실제 전송 가능한 char수는 14,400보다 훨씬 적어지게 된다.

따라서 Baud rate을 올리는 방법으로 문제 개선이 가능하지만, 예상치 못한 문제로 인하여 Baud rate는 올리지 못하는 것으로 결론.

어림 계산으로 1초에 10,000 글자가 전송 가능하다고 하고, 라인당 100글자를 넘지 않는다고 하면, 1초에 100줄 정도의 로그가 출력 가능. 로그가  1초에 100줄이 넘지 않는다는 가정하에 로그 출력을 담당하는 전담 thread를 만든다면 다른 thread는 baud rate과 상관 없이 동작 가능할 것 이다.

로그를 출력하는 매크로를 사용하여 printf 대신 매크로를 사용하여 메모리에 로그를 기록하고, 메모리는 mutex로 보호한다.  로그 출력 thread에서는 계속해서 메모리에서 로그를 읽어와 puts로 출력하도록 하여 문제 해결. (단 1초에 100줄 이상의 로그가 지속적으로 발생한다면, 로그용 메모리 버퍼가 full나면서 mutex block이 걸리는 시간이 늘어나 다시 시스템 성능이 느려질 수 있다. )

H4/HCI Protocol 이란 ?

"H4"는 HCI  commnads(Bluetooth chip과 host 사이의 event와 data)를 전송하기 위해 사용되는 UART protocol을 지칭하는 용어이다.

H4는 아주 간단한 프로토콜로 Bluetooth 스펙에 정의되어 있기 때문에 Bluetooth 엔지니어가 아니라면 UART H4란 용어를 만났을 때 뒤에 붙은 "H4"를 이해할 수 없다.  H4라 불리는 이유는 Bluetooth specification의 section 번호가 H4이기 때문이다.

H2는 HCI USB Transport Layer
H3는 HCI RS232 Transport Layer
H4는 HCI UART Transport Layer

H4와 유사한 프로토콜로 CSR사의 BCSP(BlueCore Serial Protocol)등이 있으며, BCSP는 "H4" 프로토콜에 bit error checking, wakeup중 drop된 data를 처리하기 위한 재전송, flow control 등의 기능이 추가 되었다. 즉,  H4는 Bluetooth데이터를 UART로 전송하는 "표준" 방법이고, BCSP는 CSR사가 소유한 기술이다.
BCSP도 기본적으로 UART를 사용하는데, RTS/CTS(HW flow control)은 선택 사양이다.

Bluetooth 스펙의 최신 버전에는, 3-wire 프로토콜 이라고 불리는 Section H5가  추가되었는데, 따라서 이 프로토콜을 "H5"라고도 하며, H4에는 없는 bit errors, overrun errors, burst errors checking등이 추가 되어 있다. 즉, H4와 동일하게 UART를 사용하는데,  3-wire라는 이름에서 알 수 있듯이  TXD/ RXD/ GND 3선만 연결한다.   반면에 "H4" 에서는 TXD/ RXD/ RTS/ CTS/ GND를 연결한다. RTS/ CTS를 연결한다는 것은 UART의 HW flow control을 사용한다는 말씀.

HCI(Host Controller Interface) protocol은 transports 프로토콜(H4,H5, BCSP, USB...) 위에 정의되며, Bluetooth chip과 host사이의 기본적인 commands, events 와 data packets 전송을 위해 사용된다.  HCI 역시 Bluetooth 스펙(Vol 2, Part E in BT4.0)의 일부다.

예를들어 SPP(Serial Port Profile)은 Bluetooth전송을 통하여 기존의 RS-232 serial 전송을 simulation하는 Bluetooth profile이다. 이를 구현하기 위한 프로토콜 계층 구조는 아래와 같다.

RFCOMM
-------------------------
L2CAP
-------------------------
ACL                            :BT chip간 무선으로 전송될 데이터
-------------------------
HCI                             : host와 BT chip사이
-------------------------
H4 or H5 or BCSP...   : host와 BT chip사이
-------------------------
UART ...

HCI protocol을 사용하여 아래 4가지 종류의 데이터가 전달된다.
 - Command packet : host -->  Bluetooth chip . Bluetooth chip 제어용
 - Event packet : Bluetooth chip --> host. 특정 event발생 시 BT chip이 host에 알림.
 - ACL data packet :  실제 무선으로 전송될 user 데이터
 - Synchronous data packet : 무선 으로 전송될 audio data.


참고 자료
- UART HOST transport summary (구글 검색으로 쉽게 찾을 수 있음. )

UART로 연결된 두 보드에서 PPP 프로토콜 사용하여 통신하기.

일반적으로 PPP은 dial-up connection을 위해서 사용되는 프로토콜로,  가가호호 인터넷 연결을 위한 ADSL이 도입되기 이전인 8-90년대에 가정에서 모뎀과 전화를  사용하여 인터넷에 연결하기 위해서 많이 사용되던 프로토콜이다.

그만큼 오래되고 내용도 자못 복잡하여 해당 기술의 역사와 내용을 완전히 이해하기 쉽지 않지만 (항상 그러하듯) 실제로 사용하기 위해서 모든 것을 알 필요는 없다.

일단 서버와 클라이언트상에 PPP연결은 아래와 같이 이루어진다.

서버-모뎀----------------------------모뎀-클라이언트

여기서 서버는 인터넷 제공업체의 컴퓨터, 클라이언트는 가정집의 컴퓨터라고 생각하면 된다.

모뎀을 외장 모뎀이라고 가정하면, 서버-모뎀 혹은  모뎀-클라이언트는 시리얼 포트(COM포트)를 통하여 연결되어 있을 것이고, 시리얼 포트는 내부적으로 레벨 쉬프터를 거쳐 UART 장치에 연결될 것이다.  즉 아래와 같을 것이란 얘기.

서버의 UART 장치 - 레벨 쉬프터 - COM포트 - 외장 모뎀 ------------------>>>>

>>>>-----------------외장모뎀 - COM포트 - 레벨 쉬프터 - 클라이언트의 UART장치.

먼거리의 서버와 클라이언트를 연결하기 위하여 중간에 여러가지 장치를 거치지만 결국은 서버의 UART 장치와 클라이언트의 UART 장치간의 통신을 위한 프로토콜 되겠다. 뭐가? PPP가.

(참조:
 UART는 3.3V를 사용하는데 컴퓨터 외부의 외장모뎀으로 데이터 전송시 데이터가 확실히 전달되도록 12V로 전압을 높여준다. 바로 레벨 쉬프터는 이때문에 필요하다. 이렇게 12V로 승압된 데이터 신호는 RS232C 라고 불리는 케이블을 통해서 외장 모뎀에 연결된다. )

서버 UART <----->클라이언트 UART

이를 단순화 시키면 결국 두 장치간의 UART 통신이라는 것을 알 수 있다.  UART는 위와 같은 인터넷 연결뿐만 아니라 임베디드 기기안에서 여러 장치간의 통신에  아주 많이 사용되는 방법이다.  (기기안에서의 UART 통신에는 승압이 필요 없으므로 레벨 쉬프터를 사용할 필요가 없다.)

 보통 임베디드 기기 안에서의 UART 통신에서는 대부분의 경우 HDLC라는 프로토콜을 사용하거나 혹은 더 간단하게 개발자들이 자체적으로 프로토콜을  정의하여 사용한다.  사실 PPP도 표준 HDLC 프로토콜이 조금 변형된 형태이며, 여기에 클라이언트가 서버에 접속하기 위한 Authentication, Compression, Error detection, multilink 기능등이 추가된 프로토콜이다. 따라서 임베디드 기기안에서의 UART 통신을 위해서는 굳이 HDLC프로토콜을 놔두고 PPP를 사용할 필요는 없다.

HDLC에 대해서는 아래 사이트를 참조하자.
http://www.interfacebus.com/Design_HDLC.html

하지만 때로는 필요 없을 법 했던 것이 필요해지는 경우도 있는 법. 두 장치가 UART로 연결되어 있는 상황에서 HDLC와 PPP 연결 시 실측 throughput을 비교해 보아야 할 경우가 생겼다.
--- 꼭 이런 상황이 아니라도, UART로 연결 된 두 장치간에 IP를 할당하고 socket프로그래밍을 통해 통신을 하고자 한다면, HDLC대신 PPP를 사용해야 한다.

하여간 이런 경우에 PPP를 쓰는것은 위에서 예로든 인터넷 연결을 위한 Dial up 네트워크 연결 보다 훨씬 간단한데, 이유는 Authenticaiton등을 위한 설정이 필요 없기 때문이다.

아래는 QNX OS상에서 pppd을 실행시켜 연결하는 방법이다. 아마 리눅스나 다른 유닉스에서도 비슷하게 동작이 가능할 것이다.

Receiver(Server) :
 /usr/sbin/pppd debug defaultroute /dev/ser4 updetach -crtscts 1000000 netmask 255.255.255.0 10.10.10.13:10.10.10.12 &

Sender(Client) :
 /usr/sbin/pppt debug defaultroute /dev/ser4 updetach -crtscts 1000000 netmask 255.255.255.0 10.10.10.12:10.10.10.13 &



이와 같이 설정시 PPP의 Throughput 측정 결과는 Baud rate이 1Mbps일 때473Kbps로 측정되었다.
(동일 조건에서 HDLC는 685Kbps가 측정되었다. )

PPP를 사용했을 때는 그 위에 TCP/IP를 거쳐서 사용하게 되므로 HDLC를 사용하였을 때 보다 오버헤드가 클 것이라는 점에서 위 데이터는 쉽게 수긍이 가는 수치인 것 같다.

주의할 것은 UART 디바이스와 UART 디바이스 드라이버의 설정 그리고 HDLC 프로토콜의  구현 방법에 따라 Throughput과 CPU 점유율이 크기 달라질수 있다는 점이다. 보통 UART는 1Mbps와 같이 빠른 속도로는 잘 설정하지 않는데, 이는 UART가 다소 옛 기술이라 이런 고속 동작시 CPU 사용율이 높아지기 때문에다. 특히 CPU 사용율은 데이터를 read하는 횟수와 상관 관계가 큰데 이는 read가 unix시스템에서의 시스템 콜로, 시스템 콜이 불리는 횟수가 CPU 사용율과 관계가 무척 크기 때문이다. -- 시스템 콜이 불리면 user모드에서 kernel모드로 전환하기 위해 CPU가 할 일이 무척 많다.

이 CPU 점유율 문제는 TX쪽 보다 RX쪽에서 크게 발생하는데 이는 보내는 쪽은 보내고 싶은 데이터를 한번에 write로 보낼 수 있지만, read쪽은 보내는쪽에서 한번에 보내는 크기를 모르면 여러차례에 걸쳐 read 시스템 콜을 호출하여야 하기 때문이다.

Read 쪽에서 CPU사용율을 최소화 하기 위해 시스템 콜이 자주 발생하지 않도록 한번에 많은 데이터를 읽는 것이 유리하지만, 이 경우 원하는 만큼의 데이터가 RX되지 않으면 읽기 함수가 Block되어 빠른 데이터 처리가 어렵다. 따라서 보통은 N byte 가 읽혀지거나 N byte가 RX되지 못해도 M msec이후에는 Read 함수가 return되도록 설정하여야 한다. -  readcon() 참조

또한 시스템에 따라 특정 데이터를 검출하여 해당 데이터가 RX될 때 Read함수를 return해주는 기능을 제공하기도 한다.(POSIX 호환은 아님)  이런 경우 보통 0x7E가 HDLC나 PPP에서 frame의 시작과 끝을 나타내는데 사용되므로, 0x7E를 지정하여 read 함수의 호출 횟수를 최적화하면 많은 성능 향상을 가져올 수 있다.

다양한 serial 통신 이해하기

UART
가장 대중적으로 사용되는 시리얼 통신은 UART device를 사용하는 것으로 보통 RS-232C transceiver와 함께 쓰인다. 하지만 RS-422이나 LIN등 다른 IF도 많이 사용된다. UART는 RX/TX 라인이 별도로 존재하고(full duplex) 별도의 clock라인은 사용하지 않는다. 따라서 양측이 서로 Baud rate를 맞추어야 통신이 가능하다. 즉 Asyn.통신이라는 말씀. 따라서 UART와 함께 사용되는 RS-232C도 동일한 특성을 가진다. 하지만 LIN transceiver를 사용할 경우에는 RX/TX선을 따로 가지는 대신 1개의 선만 사용하므로 full duplex가 아닌 half duplex로 동작하게된다. 또한 RS-232C는 1:1통신용으로만 사용되지만, 다른 IF 사용시 여러 장치간 통신에 사용이 가능하다.

UART에서 transceiver를 별도로 사용하는 이유는 무엇일까? 동일 보드에서 UART를 사용하여 통신할 경우 UART <-->UART 연결을 사용할 수 있지만, 외부 디바이스간의 통신에는 보다 멀리 전송하기 위해서 level shifter등을 사용하여 전압을 승압하는 것이다. 또한 다양한 전송 IF를 사용하여 1:1전송 뿐만 아니라 1:n 전송을 통한 네트워크 구현도 가능하다.

http://blog.naver.com/hjsnyh?Redirect=Log&logNo=80020142147

LIN- Local Interconnect Network
LIN은 자동차 업계에서 많이 사용하는 저속 차량용 네트워크로, UART를 사용한다. LIN transceiver를 통하여 network는 RX/TX구분없이 1 line을 사용하여 통신이 이루어 진다. 즉 RS232C에서는 RX/TX를 별도 라인으로 사용해서 full-duplex로 동작하는데 반하여 LIN 에서는 half-duplex로만 동작하는 Async. 통신방식이며 I2C, USB등과 유사하게 Master 기기가 통신을 시작하는 방식을 사용한다. 보통 20kbps이하의 저속 통신에 사용되며, 최근에는 CAN등에 자리를 내주고 있다. Master라는 것은 seiral통신에서 통신을 시작할 수 있는 권한이 있는 디바이스로, Slave장치는 Master장치가 통신을 요청할 때 까지 어떠한 통신도 시작할 수 없다. 각 serial통신 방법에 따라 Master가 1개만 존재하거나 여러개 존재할 수 있으며, CAN같은 경우 모든 장치가 Master/Slave구별 없이 원하는 시점에 메세지 전송이 가능하다. USB장치의 경우에는 Master/Slave라는 용어 대신 Host/Device라는 용어를 사용한다.

http://blog.naver.com/cybercall?Redirect=Log&logNo=120032068893


SPI - Serial Peripheral Interface Bus
SPI는 또 다른 serial장치로 CS, MISO, MOSI, SCK 4개의 선을 사용한다. RX/TX라인이 별도로 존재하고, CLK이 있으므로 full duplex, Sync.전송 방식이다. SPI는 Master/Slave 장치가 구별되며 Master에서 데이터를 보내는 양 만큼 Slave에서 데이터가 들어오게 된다. 이는 Master/Slave 양쪽에 shift register를 사용하기 때문으로 Master측에서 Tx만 필요한 경우 데이터를 보내는 순간 Slave에서 들어오는 데이터는 무시하면 된다. 반면 슬레이브에서 보내는 데이터를 읽어야 할 경우 Master는 dummy바이트를 보냄으로써 Slave로 부터 데이터를 받을 수 있다.
보통 1:1 통신용으로 많이 사용되지만, 1개의 Master에 여러개의 Slave를 붙일 수도 있다. Master에 CS를 여러개 사용하여 각각을 Slave의 CS로 사용하여 여러개의 Slave를 서로 독립적으로 control하도록 할 수도 있고, Master에 한개의 CS를 모든 Slave에서 공유하면서, 한 Slave의 MISO를 다음 Slave의 MOSI로 연결하여 daisy-chain을 구성하여 여러개의 Slave를 연결하기도 한다.

http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus


I2C- Inter Integrated Circuit
I2C는 2개의 선만을 사용하며 이는 각각 data와 clk에 해당한다. clk이 있으므로 Sync.이며 data를 위한 1라인만 사용하므로 TX/RX를 1선으로 처리해야 하므로 half duplex전송만 가능하다. I2C버스에서는 여러개의 Master와 Slave 장치가 연결될 수 있다. half duplex 특성 상 TX/RX가 동시에 발생할 수 없기 때문에 I2C는 Master가 모든 통신을 시작하며 Slave 장치는 여기에 응답만 가능하다. 이와 같은 통신 특징은 USB에서도 찾을 수 있다. (하지만 USB는 다중 Master를 지원하지 않는데 반하여 I2C는 다중 Master를 지원한다) I2C는 여러개의 Master를 허용하므로 이들이 동시에 메세지를 보내기 시작할 경우 bus는 0을 보낸쪽이 차지하게 되며 1을 보낸 쪽은 전송을 중단한다. 동일한 방법이 CAN bus에서도 사용되나 CAN의 경우 모든 장치가 Master로써 동작한다.(CAN에서는 모든 장치에서 Tx 시작이 가능하므로 Master/Slave를 굳이 구별하지 않는다.) 또한 CAN은 CLK이 없는 Asyc. 통신인 반면 I2C는 CLK을 사용한다. I2C에서는 다중 Master를 지원하지만 일반적으로 1개의 Master를 사용하여 시스템을 구현하는 경우가 많다. I2C는 표준 모드에서 100kbps, 고속 모드에서 400kbps로 동작한다. I2C는 SPI에서와 같은 CS가 존재하지 않으므로 각 장치마다 7bit address를 부여하여 이를 사용하여 target장치를 지정한다.

USB
USB장치도 I2C와 같이 Master(USB에서는 Host라는 용어를 사용)만이 트랜잭션을 시작할 수 있으며 Slave(USB에서는 device라는 용어를 사용)는 여기에 응답만 가능하다. 하지만 USB는 clk을 위한 선이 별도로 없다는 점에서 I2C와 다르게 Asyn. 통신이며 다중 Master(Host)도 허용되지 않는다. USB는 Frame이란 개념을 도입하여 한 Frame안에 여러 슬레이브 장치와 Master간의 통신이 포함될 수 있다. 하지만, Slave간의 통신은 불가능하며 Frame이 주기적으로 보내지지만 CLK이 따로 존재하지는 않기 때문에 Sync.통신은 아니다. 따라서 USB전송모드중 한가지인 isochronous를 사용하여 audio데이터를 전송할 경우, buffer가 충분히 크지 않다면 clock drift등으로 인한 buffer overrun이나 underrun이 발생 할 수 있다.

UART가 외부 전송을 위해 RS-232C나 LIN등을 사용하듯이 USB는 처음부터 외부 전송을 목적으로 만들어졌다. 하지만 최근에는 내부 데이터 버스로도 사용되고 있으며 , 이를 위해서 HSIC라는 I/F가 정의되었다.  HSIC는 USB의 sub spec.으로 high speed 전송만 지원하고 전송 거리가 10cm등으로 제약되어 있다.

I2S
I2S는 오디오 신호 전송용 serial통신으로 TX, RX, CLK, Frame Sync. 4개의 선으로 이루어져 있다. I2S를 통해서 다양한 형식의 PCM 오디오 데이터가 전송될 수 있다. 시스템에서 오디오는 보통 한방향으로만 전송되는 경우가 많으므로 TX/RX 중 하나만 사용하여 3개의 선만 사용하는 경우가 많다.

CAN
CAN은 SWCAN과 DWCAN이 존재한다. SWCAN의 경우 low speed(33.3KBit/s ~ ) 전송용으로 사용되며 1 wire통신이다. DWCAN의 경우에는 고속 전송용으로(~1MBit/s) 사용되며 이를 위해 2 -wire를 사용하며, 두 선은 각각 +- 만 변경된 동일한 신호를 가진다. CAN bus에는 여러개의 모듈이 연결되고 Master/Slave 개념 없이 서로 동등하게 통신이 이루어진다. 이를 위해서 I2C에서 사용한 것과 같은 arbitration란 개념이 필요하다. 즉 두 개 이상의 모듈이 동시에 메세지를 보내기 시작할 경우 메세지 ID가 작은 값을 가진 메세지가 bus를 차지하게 된다. 즉 0과 1이 동시에 bus에 실리면 bus에는 0이 실리게 되고 1을 전송하는 모듈은 전송을 중단하여야 한다. 하지만 I2C와 다르게 모든 장치가 메세지를 보낼 수 있으며 별도의 CLK라이을 사용하지 않는 ASync. 통신이다.

MOST50
차량용 멀티미디어 데이터 전송용 버스로 MOST25/150에서는 광통신을 사용하지만 MOST50에서는 wire를 사용한다. MOST50의 경우 48kHz마다 1 frame - 128 byte데이터가 MOST ring을 통해 전송된다. 이와 같은 frame은 Timing Master기능이 있는 특정 모듈이 만들어 보내며, 차례로 MOST ring에 포함된 모든 장치를 지나가게 된다. 각 장치는 해당 frame의 빈곳에 자신의 데이터를 넣어서 다음 장치로 재전송하게 된다. MOST ring에는 Timing Master이외에 Network Master, Connection Master, Power Master등 다른 Master기능을 가진 장치가 존재한다. 하지만 USB나 I2C와 다르게 Master가능을 가지지 않는 장치들 사이에도 서로 통신이 가능하며 Master의 도움없이 메세지 전송을 시작할 수 있다. 128byte의 MOST frame은 크게 세 부분으로 나뉘는데 각각 control data, Stream data, Packet data 영역이 된다. Control data영역으로 일반적인 용도의 commend나 메세지를 정의해 서로 주고 받을 수 있으며, Packet data영역은 주로 대용량 데이터 전송에 사용된다. 이 영역을 통하여 TCP/IP 데이터등을 전송할 수도 있다. Stream data영역은 DVD나 CD데이터와 같이 Sync.데이터 전송을 위해 사용하며, 사용 전 Connection Master를 통해 Stream data 영역안의 특정 위치를 해당 용도로 미리 할당받도록 되어 있다. 따라서 이후 아무리 다른 영역의 bandwith가 부족해 져도, 미리 할당받은 영역을 통해서 Sync.한 데이터 전송이 가능하다. 하지만, 이 영역은 특성상 에러가 발생하여도 재전송을 할 수는 없다. 기본적으로 MOST ring은 Timing Master가 만들어내는 clk을 모든 장치가 공유하여 사용하므로 Sync.전송이 가능하며 이로 인하여 audio/video등 multi-media데이터 전송시 clock drift문제등을 걱정할 필요가 없다.