* 개요 


트랜스포트 계층 프로토콜은 서로 다른 호스트에서 동작하는 애플리케이션 프로세스들 간의 논리적 통신을 제공한다.


송신 측의 트랜스포트 계층은 송신 애플리케이션 프로세스로부터 수신한 메시지를 인터넷 용어로는 트랜스포트 계층 세그먼트인 트랜스포트 계층 패킷으로 변환한다. 이러한 변환은 애플리케이션 메시지를 트랜스포트 계층 세그먼트로 만들기 위해 작은 조각으로 분할하고, 각각의 조각에 트랜스포트 계층 헤더를 추가함으로써 수행된다. 그런 후에 트랜스포트 계층은 송신 종단 시스템에 있는 네트워크 계층으로 세그먼트를 전달하고 여기서 세그먼트가 네트워크 계층 패킷안에 캡슐화되어 목적지로 전달된다.


* 트랜스포트 계층과 네트워크 계층 사이의 관계 


트랜스포트 계층은 서로 다른 호스트에서 동작하는 프로세스들 사이의 논리적통신을 제공하지만, 네트워크 계층 프로토콜은 호스트들 사이의 논리적 통신을 제공한다. 미묘하지만 이러한 차이점은 중요하다. 


* 인터넷 트랜스포트 계층의 개요 


인터넷에서 트랜스포트 계층 패킷을 세그먼트로 일컫는다. 


인터넷, TCP/IP 네트워크는 애플리케이션 계층에게 두가지 구별되는 트랜스포트 계층 프로토콜들을 제공한다.



하나는 비연결형 서비스를 제공하는 UDP이고, 다른 하나는 애플리케이션에게 신뢰적이고 연결지향형 서비스를 제공하는 TCP이다.


인터넷의 네트워크 계층 프로토콜은 '인터넷 프로토콜' 줄여서 IP라고 부른다. IP 서비스 모델은 호스트들 간에 논리적 통신을 제공하는 '최선형' 전달 서비스이다. 이것은 IP가 통신하는 호스트들 간에 세그먼트를 전달하기 위해서 최대한 노력하지만, 어떠한 보장도 하지 않는다는 것을 의미한다. 



 

 UDP

 TCP

 공통점

1. 종단 시스템 사이의 IP 전달 서비스를 종단 시스템에서 동작하는 두 프로세스 간의 전달서비스로 확장하는 것, 두 프로세스 간의 전달 서비스. 트랜스포트 계층 다중화 & 역다중화


2. 헤더에 오류 검출 필드를 포함함으로써 무결성 검사를 제공한다. 

 TCP의 추가적인 기능

 x

1. 신뢰적인 데이터전달


Flow Control, 순서번호, 확인응답, 타이머등을 사용해서 송신하는 프로세스로부터 수신하는 프로세스에게 데이터가 순서대로 정확하게 전달되도록 한다.


2. 혼잡제어(Congestion Control)


TCP연결이 과도한 양의 트래픽으로 통신하는 모든 호스트들 사이의 스위치와 링크를 폭주되게 하는 것을 방지하는 것이 TCP 혼잡제어이다. TCP는 혼잡한 네트워크 링크에서 각 TCP 연결이 링크의 대역폭을 공평하게 공유하여 통과하도록 해준다.



* 다중화와 역다중화 



네트워크 계층이 제공하는 호스트 대 호스트 전달 서비스에서 호스트에서 동작하는 애플리케이션에 대한 프로세스 대 프로세스 전달 서비스로 확장하는 것.


네트워크 어플리케이션의 한 부분으로서 프로세스가 소켓을 가지고 있다. 이를 통해 네트워크에서 프로세스로 데이터를 전달하며 또한 프로세스로 부터 네트워크로 데이터를 전달하는 출입구 역할을 한다. 그러므로 수신측 호스트의 트랜스포트 계층은 실제로 데이터를 직접 프로세스로 전달하지 않고, 중간에 매개자인 소켓에게 전달한다. 


이때, 트랜스포트 계층 세그먼트의 데이터를 올바른 소켓으로 전달하는 작업을 역다중화라고 한다. 출발지 호스트에서 소켓으로부터 데이터를 모으고, 이에 대한 세그먼트를 생성하기 위해서 각 데이터에 헤더 정보로 캡슐화하고 세그먼트들을 네트워크 계층으로 전달하는 작업을 다중화라고 한다.


호스트의 각 소켓은 포트번호를 할당받는다. 그리고 세그먼트가 호스트에 도착하면, 트랜스포트 계층은 세그먼트 안의 목적지 포트번호를 검사하고 상응하는 소켓으로 세그먼트를 보내게 된다. 그러면 세그먼트의 데이터는 소켓을 통해 해당되는 프로세스로 전달된다. 



다중화 역다중화 방식 

 UDP

TCP 

세그먼트 헤더 정보

출발지 포트번호, 목적지 포트번호, 길이, 체크섬

 출발지 포트번호, 목적지 포트번호, 출발지 IP 목적지 IP, 길이, 체크섬

동작

UDP 소켓 19157을 가진 호스트A의 프로세스가 호스트 B의 UDP 소켓 46428을 가진 프로세스에게 애플리케이션 데이터 전송.


각 포트번호와 길이, 체크섬을 포함하는 헤더를 가지는 세그먼트를 생성하고 네트워크 계층으로 전달한다. 네트워크 계층은 세그먼트를 IP데이터 그램으로 캡슐화하고 최선형 전달 서비스로 세그먼트를 수신호스토 전달한다. 수신호스트는 세그먼트 헤더의 목적지 포트번호를 검사하고 그 세그먼트를 포트 46428로 식별되는 소켓에 전달한다. 호스트 B에 여러 프로세스가 수행될 수 있다는 것에 유의.


UDP 소켓은 목적지 IP주소와 목적지 포트번호로 구성된 두요소로 된 집합에 의해 구별, 

 TCP 서버 어플리케이션은 TCP 클라이언트로 부터 연결설정 요청을 기다린다


연결 설정요청은 목적지 포트 번호와 TCP 헤더에 특별한 연결설정 비트를 가진 TCP 세그먼트에 지나지 않는다. 이 출발지 포트 번호는 클라이언트에 의해서 선택된 번호이다. 


서버 프로세스로 동작하는 컴퓨터의 호스트 운영체제가 목적지 포트를 포함하는 연결 요청 세그먼트를 수신하면 이 세그먼트를 포트너머로 연결수락을 기다리는 서버 프로세스로 보낸다.


서버는 연결요청 세그먼트의 다음과 같은 네 가지 값을 주목한다 (1) 출발지 포트넘버 (2) 출발지 IP주소 (3) 목적지 포트번호 (4) 목적지 IP주소, 새롭게 생선된 연결 소켓은 이들 네가지 값에 의해서 식별된다. 




* 신뢰성 있는 데이터 전송의 원리(rdt) 


신뢰적인 채널에서는 전송된 데이터가 손상되거나 손실되지 않고 순서대로 전달된다.


데이터 전송 프로토콜의 송신 측은 rdt_send() 호출에 의해서 위쪽으로부터 호출될 것이다. 수신 측에서는 상위 계층으로 전달될 데이터를 넘길 것이다.


rdt_rcv()는 패킷의 채널의 수신 측으로부터 도착했을 때 호출된다. rdt 프로토콜이 상위 계층에 데이터를 전달하려고 할 때 deliver_data()를 호출한다. 



* 완벽하게 신뢰적인 채널 상에서의 신뢰적인 데이터 전송 : rdt 1.0



rdt의 송신측은 rdt_send 이벤트에 의해 상위 계층으로 부터 데이터를 받아들이고 데이터를 포함한 패킷을 생성한다. 그리고 패킷을 채널로 송신한다. 

수신측에서는 rdt는 rdt_rcv(packet) 이벤트에 의해 하위의 채널로 부터 패킷을 수신하고, 패킷으로부터(extract) 데이터를 추출한 후 데이터를 상위계층으로 전달한다 (deliver_data(data)) rdt_rcv(packet)는 하위 계층 프로토콜 프시저의 호출에 의해서 발생한다.


* 비트 오류가 있는 채널 상에서의 신뢰적 데이터 전송 rdt 2.0 


패킷 안의 비트들이 하위 채널에서 손상되는 모델이다. 


ACK, NAK 둘다사용한다. 재전송을 기반으로 하는 신뢰적인 데이터 전송 프로토콜은 ARQ(자동재전송요구) 프로토콜로 알려져 있다.


송신자 프로토콜은 수신자로부터 ACK 또는 NAK 패킷을 기다린다. ACK 패킷이 수신된다면 송신자는 가장 최근에 전송된 패킷이 정확하게 수신되었다는 것을 알게된다. 만약 NAK가 수신되면 프로토콜은 마지막 패킷을 재전송하고 재전송된 데이터 패킷에 대한 응답으로 수신자에 의해 응답되는 ACk, NAK를 기다린다.


ACK 또는 NAK를 기다리는 상태에 있을 때 application layer 로 부터 더이상의 데이터를 전달받을 수 없다는 것에 유의한다. 즉 rdt_send() 이벤트는 발생할 수 없다. 오직 송신자가 ACK를 수신하고 이 상태를 떠난 후에만 발생한다. 


이러한 행동 때문에 rdt2.0과 같은 프로토콜은 전송-후-대기(stop and wait) 프로토콜로 알려져있다.


rdt2.0은 ACK또는 NAK 패킷이 손상될 수 있다는 가능성을 고려하지 않았다.


* 순서번호를 반영하는 신뢰적인 데이터 전송 rdt 2.1 


rdt 2.1에서는 ack및 nak의 손실은 없고 손상은 있다.


순서가 바뀐 패킷이 수신되면 수신자는 이미 전에 수신한 패킷에 대한 긍정 확인 응답을 전송한다. 손상된 패킷이 수신되면 수신자는 부정 확인응답을 전송한다.


같은 패킷에 대해 2개의 ACK를 수신한 송신자는 수신자가 두 번 ACK한 패킷의 다음 패킷을 정확하게 수신하지 못했다는 것을 안다. 






* rdt 2.2 


rdt 2.2는 nak가 없고 ack에 순서번호를 포함한다. 


rdt 2.1과 rdt 2.2 사이의 미묘한 차이는 수신자가 반드시 ACK 메시지에 의해서 확인응답하는 패킷의 순서번호를 포함해야 한다는 것이다. 







* 비트 오류와 손실이 있는 채널 상에서의 신뢰적 데이터 전송 : rdt 3.0 


패킷 손실을 어떻게 검출? -> 타임아웃 


송신자가 어떤 패킷을 손실했다는 것을 확신하기 위해 얼마나 오랫동안 기다려야 할까? 송신자는 적어도 송신자와 수신자 사이의 왕복시간 지연에 수신 측에서 패킷을 처리하는 데 필요한 시간을 더한 만큼 기다린다.



'

이렇게 Stop&Wait 프로토콜 rdt 1.0, 2.0~2.2, 3.0을 다루어 보았다. 하지만 Stop&Wait 프로토콜의 문제점은 링크 이용률이 낮다는 것이다. 이러한 성능 문제대한 해결책은 전송 후 대기방법으로 동작하는 대신에 송신자에게 확인응답을 기다리지 않고 여러 패킷을 전송하도록 허용하는 것이다. 이것을 파이프라이닝 이라고 한다. 


파이프라이닝을 쓰는 프로토콜을 슬라이딩 윈도우 프로토콜이라하며 슬라이딩 윈도우 프로토콜에는 Go-Back-N과 Selective-AND-Repeat 방식이 있다. 




확인 응답이 안된 가장 오래된 패킷의 순서번호를 base로 정의하고 사용되지 않은 가장 작은 순서번호를 nextseqnum으로 정의한다면, 순서번호의 범위에서 4개의 간격을 식별한다.


[0,base-1] 에서 순서번호는 이미 전송되고 확인 응답이 된 패킷에 대응된다.

[base, nextseqnum-1]은 송신은 되었지만 아직 확인응답되지 않은 패킷에 대응된다.

[nextseqnum,base+N-1]은 상위 계층으로부터 데이터가 도착하면 바로 전송될 수 있는 패킷을 위하여 사용.

[base+N] 이상의 순서번호는 파이프라인에서 확인응답이 안 된 패킷의 확인응답이 도착될 때까지 사용될 수 없다. 


* 슬라이딩 윈도우 프로토콜 - Go-Back-N(N부터 반복)


상위로부터 호출 : rdt_send()가 어플리케이션 레이어로 부터 호출되면, 송신자는 첫째로 윈도우가 가득찼는지, 즉 N개의 아직 확인응답되지 않은 패킷이 있는지 확인한다. 만약 윈도우가 가득 차 있다면, 송신자는 윈도우가 가득 차 있다는 것을 가리키는 함축적인 의미로 단지 데이터를 상위 계층으로 반환한다. 상위 계층은 나중에 다시 시도할 것이다. 실제적인 구현에서 송신자는 이 데이터를 버퍼링한다.


ACK의 수신 : GBN 프로토콜에서 순서번호 n을 가진 패킷에 대한 확인응답은 누적확인 응답으로 인식된다.sliding 윈도우가 한꺼번에 한칸이상 밀려갈 수 있다. 프레임이 0,1,2 를 전송한 후 ack3가 온 경우 프레임 2까지 잘 전송된 것으로 판단하여 sliding window가 세간 이동.



타임아웃 이벤트 : GBN 프로토콜의 이름은 손실이 있거나 아주 긴 지연된 패킷이 있을 때의 송신자의 동작으로부터 유래되었다. 전송 후-대기 프로토콜에서와 같이, 타이머는 손실된 데이터 또는 손실된 확인응답 패킷으로부터 회복하는 데 사용된다. Go-Back-N에서의 타이머는 한개뿐이다. 만약 타임아웃이 발생한다면 송신자는 이전에 전송되었지만 아직 확인응답되지 않은 모든 패킷을 다시 송신한다. 예를들어 6번 프레임을 보냈는데 3번 프레임의 타이머가 만료된 경우 3,4,5,6을 다시 전송.


수신측 : 수신측의 슬라이딩 윈도우 크기는 1이다. 받고자 하는 프레임의 번호만 가리키고 있는다. 기다리고 있는 프레임의 번호에 해당하는 패킷이 아닌경우 패킷들을 버린다.



* 슬라이딩 윈도우 프로토콜 - Selective-and-Repeat



GBN은 패킷 하나의 오류 때문에 많은 패킷을 재전송하므로, 많은 패킷을 불필요하게 재전송하는 경우가 발생한다. 


- Timer는 각 프레임당 한개씩 동작한다. 


- 송신자와 수신자의 윈도우 사이즈가 동일하다.(수신자의 윈도우 사이즈가 1이 아니다)


-중요한건 수신자가 sliding window 범위 안의 프레임이 순서가 뒤바뀌어 온경우 버리지 않고 저장하고 ack를 보낸다.


- 송신자는 타임 아웃이 발생한 패킷에 대해서만 다시 보낸다. 









 








































'이론 > 컴퓨터통신' 카테고리의 다른 글

Network Layer(L3)  (0) 2015.10.17
Transport Layer(L4)  (0) 2015.10.17
Application Layer(L7)  (0) 2015.10.14
컴퓨터 네트워크 개론  (0) 2015.10.13
블로그 이미지

종환 Revolutionist-JongHwan

github.com/alciakng 항상 겸손하자.

댓글을 달아 주세요

* 크로스 개발환경 및 툴체인 


임베디드 시스템의 개발을 위해서는 호스트 컴퓨터에 타깃시스템 용의 프로그램 작성을 위한 각종 프로그램 개발 관련 도구가 설치되어야 한다. 이와 같은 타깃시스템 프로그램 개발을 위해 호스트에 설치되는 각종 패키지를 크로스개발환경이라고 한다.



크로스 개발환경에서 호스트와 임베디드 시스템의 기본 연결이다.


시리얼 연결은 호스트와 타깃 시스템 사이에서 가장 기본적인 저속 통신 기능을 제공한다. 개발 과정에서 호스트 측에서 임베디드 시스템에 대한 부팅 명령이나 리눅스 명령을 주거나 임베디드 시스템에서 발생한 출력 메시지를 호스트 측에서 보는데 주로 사용된다. 임베디드 시스템은 개발 단계에서 기본 통신을 위해 보통 시리얼 포트를 갖추고 있다. 이를 호스트의 시리얼 포트와 서로 연결한다.


호스트가 pc인 경우 뒷면에 시리얼 포트가 하나 또는 두개 있다.


이후 minicom과 같은 시리얼 통신프로그램을 이용해 타깃시스템과 서로 통신한다.


개발자가 임베디드 시스템에 주는 각종 명령 및 임베디드 시스템에서 출력하는 각종 실행 결과 및 커널 메시지들은 모두 시리얼 포트를 통해서 이루어짐.


이더넷 연결은 100/1000mbps의 고속 전송이 가능하므로 개발단계에서는 주로 호스트와 임베디드 시스템사이의 파일 전송에 사용


jtag(joint test action group)은 하드웨어 수준의 디버깅 및 호스트에서 작성된 부트로더를 임베디드 시스템의 플래시메모리에 쓰는 역할을 한다. 



* 툴체인


호스트의 프로세서와 개발 대상인 임베디드 시스템의 프로세서는 대부분 다른 경우가 많다. 호스트의 프로세서는 대부분 인텔 80 * 86 계열인데 이 프로세서가 임베디드 시스템에 사용되는 경우는 거의 없다. 


임베디드 시스템용 프로세서로는 스마트폰이나 고성능 제어 기기에 많이 사용되는 32/64비트 ARM 계열과 저전력 센서 네트워크 등에 많이 사용되는 마이크로컨트롤러인 AVR 시리즈 등이 있다. 이들을 위한 크로스 어셈블러 및 크로스 컴파일러는 모두 공개되어 있어 쉽게 구할 수 있다. 


rpm 패키지를 구해 설치하는 경우는 간단히 rpm -ivh 패키지 파일명 식으로 rpm 명령을 사용하면 된다. rpm 패키지 설치 시는 패키지 파일에 따라 실제로 설치되는 디렉터리가 달라진다. 예로 /opt/cdt/xscale/bin 디렉터리에 설치되었다면 이 디렉터리에 다음 파일들이 생성된다.


arm-linux-as : ARM 프로세서용 크로스어셈블러

arm-linux-gcc : 크로스컴파일러

arm-linux-ld : 링커

arm-linux-strip : 실행파일에서 심벌 등을 제거하여 실행파일 크기를 줄이는 프로그램


툴체인 설치를 모두 마치면 실행파일이 들어 있는 디렉터리의 위치를 리눅스 셸에 알려주어야 한다. 리눅스 기본 셸은 bash이므로 bash의 환경변수 PATH에 "/opt/cdt/xscale/bin"을 추가하면 된다. 이렇게 하기 위해서 자신의 홈디렉터리에서 .bash_profile 파일을 편집기로 열어 PATH 라인 뒤에 ";/opt/cdt/xscale/bin" 라고 추가하면 된다. 


* 부트로더 


부트로더는 파워 온 시 임베디드 시스템의 각종 하드웨어를 초기화하고 기본적인 통신 기능을 제공하며 플래시메모리나 ROM에 들어 있는 운영체제 커널 부분을 주 메모리(RAM)로 이동시켜 운영체제의 부팅을 시작하는 기능을 한다. 


부트로더 주요기능


타겟 하드웨어 초기화, 운영체제 부팅, 파일이동, 통신기능, 플래시메모리관리


* JTAG


임베디드 시스템 개발 초기에는 부트로더 자체가 없으므로 이를 임베디드 시스템 플래시메모리에 넣어주기 위한 방법이 필요한데, 보통 JTAG 인터페이스를 주로 사용한다. 


호스트 PC에서 개발한 부트로더를 임베디드 시스템으로 전송하기 위해서는 먼저 임베디드 시스템의 JTAG 커넥터와 호스트 PC의 프린터 포트를 JTAG 시리얼 케이블로 연결한다. 다음 호스트 PC에서 부트로더 전송 기능을 하는 명령어에 전송할 부트로더 파일명을 입력하면 된다. 



*부트로더에서의 TFTP 사용


부트로더는 네트워크 인터페이스를 통해 호스트에서 커널 이미지나 파일을 가져오는 기능을 제공한다. 이때 FTP기능을 축소한 간단한 파일 전송프로그램인 TFTP를 사용한다. TFTP는 FTP에 비해 사용자 인증과정이 없고 접속된 서버 내에서 디렉터리를 이동할 수 없고 서버에서 미리 설정한 디렉터리에만 연결된다. 또 서버 디렉터리 내의 파일명을 볼 수도 없다. TFTP는 실행 코드가 작아 부트로더에 넣기 쉽고 실행을 위한 명령어는 보통 'tftp'이다.



* NFS 


NFS 는 네트워크에 연결된 다른 컴퓨터의 하드디스크 일부(파일 및 디렉터리)를 자신의 로컬 하드디스크처럼 사용할 수 있게 한다. NFS는 유닉스/리눅스에서 기본적으로 지원하는 기능이다.  



* 부트로더에 의한 부팅 과정 


1. 임베디드 시스템의 부트로더는 리눅스 커널을 호스트에 요청한다. 이때 호스트는 압축된 리눅스 커널 이미지를 TFTP를 사용해 임베디드 시스템에 전송하고 수신된 리눅스 커널 이미지는 임베디드 시스템의 RAM 영역에 저장된다.

2. 부트로더는 RAM에 로드된 커널로 실행권을 넘겨 커널의 압축이 해제되고 리눅스 부팅과정이 시작된다.

3. 부팅 과정 중 NFS 기능을 사용하여 루트파일시스템을 마운트하여 부팅이 계속된다.

4. 부팅 완료후 호스트에서 시리얼 통신 프로그램(minicom)을 통해 임베디드 시스템에 로그인한다(로그인 이후 자기 것으로 보이는 루트 파일시스템은 실제는 호스트에서 NFS를 통하여 제공하는 것이다)



* 루트 파일시스템 


루트 파일시스템은 리눅스에서 최상위 파일시스템이며 리눅스 자체의 동작을 위해서는 반드시 필요하다. 임베디드 시스템 개발 과정에서 루트 파일시스템을 만드는 과정은 반드시 필요하다. 루트 파일시스템은 개발과정에서는 편의상 앞에서 설명한 호스트의 NFS 디렉터리에 두는 경우가 많지만 개발이 완료되면 반드시 임베디드 시스템 내부의 플래시 메모리로 옮겨야 한다.


우선 호스트 컴퓨터의 /test/nfs 디렉터리에 임베디드 시스템의 루트 파일시스템을 생성하고 이 디렉터리를 NFS를 사용하여 임베디드 시스템에 마운트시켜 동작하는 것으로 가정하였다. 머저 루트 파일시스템을 구축할 /test/nfs 디렉터리로 가서 리눅스에서 사용되는 필수 디렉터리를 생성한다.


이상의 과정에서 루트 파일시스템의 필수 디렉터리가 생성되었으면 다음 단계로 시스템 초기화를 수행하는 init 프로그램을 설치한다.


* busybox 


 루트 파일시스템 구축의 마지막 단계로 BusyBox를 사용하여 임베디드 시스템에 필요한 각종 리눅스 유틸리티 및 응용프로그램들을 설치하는 과정을 설명한다. 



* 램디스크 


 램 디스크(Ramdisk)란 메모리에 일반 하드디스크에서와 같은 파일시스템을 구축한 것이다. 

램 디스크를 이용하면 메모리에 파일들을 둘 수 있으므로 메모리를 하드디스크처럼 사용 할 수 있다. 물론 RAM상에 존재하므로 전원 OFF 시에는 내용이 소멸되나 속도가 매우 빠르며 임베디드 시스템에서는 플래시 메모리와 함께 사용되어 서로 보완하는 효과가 있다.


램디스크는 하드디스크가 없는 임베디드 시스템에서 루트파일시스템을 구축하는 데 필요하며 루트 파일시스템만이 아니라 일반 파일시스템도 여기에 둘 수 있다.


* JFFS


 JFFS는 전원이 갑자기 OFF될 경우에도 데이터를 안정적으로 보호할 수 있는 기능을 가진 플래시 메모리에 구축된 파일시스템이다. 임베디드 시스템에서의 파일시스템은 대부분 JFFS(JFFS2)를 사용한다. 저널링 파일시스템은 동작 시 파일시스템의 변화 내용을 별도의 로그 파일에 기록하며 따라서 갑작스런 전원 OFF등의 이상 발생 시 복구가 가능하도록 하는 기능을 제공한다.











블로그 이미지

종환 Revolutionist-JongHwan

github.com/alciakng 항상 겸손하자.

댓글을 달아 주세요

* 임베디드 시스템


임베디드 시스템은 내부에 CPU, 메모리, 입출력 포트를 가지고 있어 특정한 기능을 수행하는 시스템이다.


임베디드 시스템의 핵심인 프로세서는 단순한 기능을 가지는 경우 8비트 이하의 저기능 프로세서가 주로 사용되고 고급 기능의 임베디드 시스템 경우는 32비트 이상의 고기능 프로세서가 주로 사용된다. 


32비트급 임베디드 시스템용 프로세서는 ARM 계열 프로세서가 대표적이고 8비트급 프로세서로는 ATmel AVR 시리즈가 대표적이다.


AVR 시리즈는 칩 내부에 플래시 메모리가 있어 PC에서 작성한 프로그램 코드를 쉽게 칩 내부로 보내어 실행할 수 있다는 편리한 점이 있다.



* 임베디드 시스템용 운영체제 


실기간성이 필요한 임베디드 시스템의 경우 실시간 운영체제(Real time OS)가 사용되어야 하는데, 이는 정해진 시간 내에 주어진 작업을 처리하여 시스템이 결과를 출력 할 수 있도록 하는 운영체제 이다. 즉 주어진 작업을 단순히 빨리 처리하기 보다는 정해진 시간 안에 처리를 완료한다는 의미이다. 이를 위해 실시간 운영체제는 시스템 응답속도, 인터럽트 처리속도가 빠르고 선점형 멀티태스킹 및 스케줄링 등이 지원되어야 한다. 


* 리눅스 디렉터리 구조 





/ 최상위디렉터리


/bin 기본 명령어들이 위치하는 디렉터리.. 실행 명령어(예: cp, mv, vi)들이 이 디렉터리에 포함되어 있다.


/sbin 리눅스 시스템 관리에 필요한 명령어가 위치하는 디렉터리이다.


/dev 각 디바이스에 대한 디바이스 파일이 위치하는 디렉터리이다.


/etc 리눅스 환경 설정에 필요한 파일들이 위치하는 디렉터리이다.


/lib 리눅스 기본 라이브러리(커널 모듈)가 위치하는 디렉터리이다.


/opt 사용자가 나중에 추가로 설치하는 패키지가 위치하는 디렉터리이다.


/boot 부팅에 필요한 파일들이 위치하는 디렉터리이다.


/usr 리눅스 응용프로그램, 시스템 파일, 각종 패키지 및 이들을 위한 라이브러리 파일 등이 위치하는 디렉터리이다. 



* 리눅스 주요 명령어

 

cat : 텍스트 파일 내용을 화면에 출력한다. 


cat test.c -> test.c 파일 내용을 화면에 출력


cd : 디렉터리를 이동한다.


cd /usr/bin -> 현 디렉터리에서 /usr/bin 디렉터리로 이동


chmod :  파일이나 디렉터리의 퍼미션 설정(change mode) 이때 퍼미션은 소유자(owner), 그룹(group), 그 외 사용자(others) 


chmod 666 test.dat -> 파일 test.dat에 대해 퍼미션을 666으로 설정한다.(즉 모든 사용자가 해당 파일을 읽기/쓰기 할 수 있다)


chmod 700 exam2 -> 파일 exam2에 대해 퍼미션을 700으로 설정한다.


chgrp : 파일이나 디렉터리의 그룹을 변경한다.


chgrp project2 exam4 -> 파일 exam4의 그룹을 project2로 변경한다.


chown : 파일이나 디렉터리의 소유자를 변경한다,


chown gildong exam5 -> 파일 exam5의 소유자를 gildong으로 변경한다.


cp : 파일이나 디렉터리를 복사한다. 


ifconfig : 네트워크 인터페이스의 각 항목을 설정하거나 설정된 상태를 보여준다.


more : 텍스트 내용을 한 화면씩 출력한다.


mount : mount 명령은 하드디스크, CD-ROM, USB 메모리 등 블록 디바이스에 있는 파일시스템을 리눅스 디렉터리에 연결해 사용자가 이에 접근할 수 있도록 해준다. 마운트 시킨 디바이스와의 연결을 끊을 때는 언마운트 동작 명령인 umount한다.


ping : 목적지까지의 TCP/IP 네트워크 연결 상태를 테스트하는 데 사용한다 일정 개수의 패킷을 보내어 돌아오는 시간, 손실된 패킷 수 등을 표시한다.


ps : 현재 프로세스의 상태를 보여준다.


rpm : RPM(RedHat Package Manager)형태의 파일을 풀어 설치하고 관리 할 수 있게 해주는 패키지 관리 프로그램이다. 레드햇 계열 리눅스에서 주로 사용한다. 이를 사용하면 rpm 형태의 파일로 묶여 있는 프로그램을 쉽게 설치/업데이트/삭제할 수 있다.


그런데 일반적인 rpm 패키지라면 yum 명령을 사용하는 것이 더 편리하다. yum도 rpm과 마찬가지로 레드햇 계열 리눅스에서 사용하는 패키지 자동 설치 및 업데이트 명령이다.


yum install '패키지 이름'


yum으로 설치가 안되는 패키지도 있으며 이런 경우는 직접 rpm 파일을 구해서 rpm으로 설치해야 한다.


shutdown : 리눅스 시스템을 종료한다.


su : subsitute user 의미로서 다른 사용자로 바꾸어 쉘을 새롭게 시작한다.


uname : 시스템 관련 정보를 화면에 출력한다.


vi : 리눅스 기본 텍스트 편집기 


tar : 여러 파일과 디렉터리를 하나의 파일로 묶는 용도 


tar cf test_dir.tar test_dir  -> test_dir의 모든 내용을 test_dir.tar 라는 파일로 묶어준다.


gzip과 gunzip : 파일 압축(gzip)과 해제(gunzip) 기능을 가지며 압축 효율이 초기 유닉스 압축 프로그램인 compress보다 높다.


* 리눅스 시리얼 통신 기능


임베디드 시스템 개발 시 사용하는 리눅스의 대표적인 시리얼 통신 프로그램으로 미니컴이 있다. 대부분의 리눅스 버전에 포함되어 있으며 없는 경우 추가로 설치하면 된다. 이 시리얼 통신 프로그램이 정상적으로 동작하려면 호스트와 임베디드 시스템 사이에 시리얼 포트끼리 서로 연결되어 있어야 하고, 통신 속도(bps), 포트 번호, 제어 방법 등 시리얼 통신을 위한 파라미터도 서로 일치해야 한다.


minicom -s configuration 옵션 메뉴가 나온다.


여기서 상하 화살표 키를 사용해 "serial port setup" 항목을 선택하면 시리얼 포트, 전송속도, 흐름제어(flow control) 등을 설정하는 화면이 나온다.


이 화면에서 먼저 'A'를 사용해 사용할 호스트의 시리얼 포트를 정해준다. 보통 /dev/ttyS1, 또는 /dev/ttyS0 로 준다. 'E' 키를 누르면 시리얼 통신 파라미터를 설정하는 화면이 나온다. 이 화면에서 Current : 38400 8N1 부분은 현재 전송속도가 38400 bps이고 데이터 전송 단위가 8비트씩이며 패리티비트는 사용하지 않고 스톱비트로 1트를 사용한다는 의미이다. 


* 리눅스 make 기능


리눅스 make 기능은 프로그램 개발 과정에서 수시로 수정되는 여러 소스 파일들의 연관관계를 파악하여 자동으로 컴파일 및 실행파일을 만들어 준다. 


Makefile은 make가 이해할 수 있는 일종의 쉘 스크립트 언어이며 기본 구조는 다음과 같이 target, dependency, command의 세 항목으로 이루어진다.


target : dependency

[tab] command

[tab] command


여기서 target 항목은 command가 수행된 이후 최종적으로 생성되는 결과 파일을 지정하며, command 항목이 컴파일 명령이라면 오브젝트 파일이나 실행파일이 target의 이름이 된다. dependency 항목에는 서로 연관관계가 있는 파일 이름들이 나열된다.


command 항목에는 일반 리눅스 명령들이 들어가고 제일 앞에 tab 문자로 시작해야 한다. dependency 항목의 파일들이 수정되었거나, 현 디렉터리에 target 항목이 가리키는 파일이 없을 때 command 항목의 명령들이 차례대로 수행된다.


ex : ex1.o ex2.o ex3.o

  gcc -o ex ex1.o ex2.o ex3.o

ex1.o : ex.h ex1.c

  gcc -c ex1.c

ex2.o : ex.h ex2.c

  gcc -c ex2.c

ex3.o : ex.h ex3.c

  gcc -c ex3.c


 위는 3개의 파일(ex1.c, ex2.c, ex3.c)을 컴파일하여 실행파일을 얻는 예이다. 여기서 target 항목에 지정된 실행파일 "ex"가 생성되기 위해서는 ex1.o, ex2.o, ex3.o 파일이 필요함을 보여준다. 따라서 최초 make 명령을 주면, 컴파일 명령인 gcc -c ex1.c, gcc -c ex2.c, gcc -c ex3.c가 차례로 수행되어 오브젝트 파일 ex1.o, ex2.o, ex3.o 가 차례로 생성되고 마지막으로 링크 동작을 위해 gcc -o ex ex1.o ex2.o ex3.o 명령이 수행되어 실행파일 ex가 생성된다.


이후 ex2.c 와 ex3.c 파일이 수정되었다면 다시 make 라고 치면 자동으로 gcc -c ex2.c 와 gcc -c ex3.c 가 실행되고 이어 gcc -o ex ex1.o ex2.o ex3.o 가 실행되어 수정된 내용이 반영된 실행파일이 만들어진다. 


리눅스 make에서는 매크로를 사용할 수 있는데 이를 사용하면 정의된 문구를 대치하므로 긴 문구나 반복되는 문구를 대신하면 편리하다. 매크로 정의는 매크로이름 = 문구 식으로 하고 사용 시에는 $(매크로 이름) 식으로 한다. 


EXOBJ = ex1.o ex2.o ex3.o

EXHDR = ex1.h ex2.h ex3.h 

ex : $(EXOBJ)

 gcc -o ex $(EXOBJ)

ex1.o : $(EXHDR) ex1.c

 gcc -c ex1.c

ex2.o : $(EXHDR) ex2.c

 gcc -c ex2.c

ex3.o : $(EXHDR) ex3.c

 gcc -c ex3.c 


이외에 predefined 매크로도 있다.


리눅스 make에서는 레이블을 사용할 수 있다. Makefile 파일에서 target 부분 이후에 dependency 항목이 오지 않을 경우 해당 target은 레이블로 인식되며 이때 이 레이블은 make 명령의 파라미터로 사용될 수 있다.


delete : 

   rm $(EXOBJ)


위에서는 "delete" 다음에 dependency 항목이 없으므로 레이블이고 


make delete 와 같이 입력하면 rm $(EXOBJ) 명령이 실행되어 매크로에 의해 정의된 파일들이 삭제된다.



* 리눅스 커널 및 설치


리눅스의 핵심 기능을 제공하는 커널은 최초 버전 1.0부터 시작하여 현재 버전 3이 주로 사용된다.


리눅스 커널이란, 응용 프로그램을 대신하여 하드웨어를 제어하는 편리한 기능을 제공하며, 응용 프로그램의 처리를 요청받아 동작하는 이벤트 중심의 프로그램이다. 응용 프로그램으로 부터 시스템 콜이 요청되거나 하드웨어로 부터 인터럽트 요청이 들어오면, 그 요청에 대응하는 처리를 수행합니다. 다시 말해서 리눅스 커널은 자기 혼자서 동작하지 않는다.


커널 소스 주요 디렉터리별 기능들은 다음과 같다.


kernel 디렉터리 - 커널의 중심이 되는 소스(스케줄링, 프로세스 관리, 시그널 처리 등) 부분이 들어 있으나 일부 프로세서에 종속적인 커널 코드는 디렉터리 arch/'프로세서명'/kernel에 있다.


arm 프로세서 경우는 arch/arm/kernel에 있다. 이 디렉터리에는 커널의 기능별로 소스 파일이 분리되어 있고 예로 module.c, timer.c, signal.c, sched.c 등이 있다.


arch 디렉터리 - 프로세서 유형별로 서브디렉터리를 가지고 있으며 프로세서에 종속적인 커널 코드를 포함하고 있다. 


drivers 디렉터리 - 디바이스 드라이버 코드를 가지고 있으며 각 디바이스 드라이버에 대한 코드가 들어 있는 서비디렉터리를 가진다. 블록 디바이스 드라이버 코드가 들어 있는 block, 문자 디바이스 코드가 들어 있는 char, 네트워크 장치 디바이스 드라이버 코드가 들어 있는 net.. 







블로그 이미지

종환 Revolutionist-JongHwan

github.com/alciakng 항상 겸손하자.

댓글을 달아 주세요