?????

--- 모드별 핀사양

--- USBISP MK2 Supported Devices

<ISP Mode>

ATmega1280 ATmega1281 ATmega1284P ATmega1284 ATmega128A ATmega128RFA1 ATmega128 ATmega162 ATmega164A ATmega164PA ATmega164P ATmega165A ATmega165PA ATmega165P ATmega168A ATmega168PA ATmega168P ATmega168 ATmega169A ATmega169PA ATmega169P ATmega16A ATmega16HVBrevB ATmega16HVB ATmega16M1 ATmega16U2 ATmega16U4 ATmega16 ATmega2560 ATmega2561 ATmega324A ATmega324PA ATmega324P ATmega3250A ATmega3250P ATmega3250 ATmega325A ATmega325P ATmega325 ATmega328P ATmega328 ATmega3290P ATmega3290 ATmega329A ATmega329PA ATmega329P ATmega329 ATmega32A ATmega32C1 ATmega32HVBrevB ATmega32HVB ATmega32M1 ATmega32U2 ATmega32U4 ATmega32 ATmega48A ATmega48PA ATmega48P ATmega48 ATmega640 ATmega644A ATmega644PA ATmega644P ATmega644 ATmega6450A ATmega6450P ATmega6450 ATmega645A ATmega645P ATmega645 ATmega6490A ATmega6490P ATmega6490 ATmega649A ATmega649P ATmega649 ATmega64A ATmega64C1 ATmega64M1 ATmega64 ATmega8515 ATmega8535 ATmega88A ATmega88PA ATmega88P ATmega88 ATmega8A ATmega8U2 ATmega8 ATtiny13A ATtiny13 ATtiny1634 ATtiny167 ATtiny2313A ATtiny2313 ATtiny24A ATtiny24 ATtiny25 ATtiny261A ATtiny261 ATtiny26 ATtiny4313 ATtiny43U ATtiny44A ATtiny44 ATtiny45 ATtiny461A ATtiny461 ATtiny48 ATtiny828 ATtiny84A ATtiny84 ATtiny85 ATtiny861A ATtiny87 ATtiny88 AT90CAN128 AT90CAN32 AT90CAN64 AT90PWM161 AT90PWM1 AT90PWM216 AT90PWM2B AT90PWM316 AT90PWM3B AT90PWM81 AT90USB1286 AT90USB1287 AT90USB162 AT90USB646 AT90USB647 AT90USB82 ATA6285 ATA6286

<PDI Mode>

ATxmega128A1U ATxmega128A1 ATxmega128A3U ATxmega128A3 ATxmega128A4U ATxmega128B1 ATxmega128B3 ATxmega128C3 ATxmega128D3 ATxmega128D4 ATxmega16A4U ATxmega16A4 ATxmega16C4 ATxmega16D4 ATxmega192A3U ATxmega192A3 ATxmega192C3 ATxmega192D3 ATxmega256A3BU ATxmega256A3B ATxmega256A3U ATxmega256A3 ATxmega256C3 ATxmega256D3 ATxmega32A4U ATxmega32A4 ATxmega32C4 ATxmega32D4 ATxmega384C3 ATxmega384D3 ATxmega64A1U ATxmega64A1 ATxmega64A3U ATxmega64A3 ATxmega64A4U ATxmega64B1 ATxmega64B3 ATxmega64C3 ATxmega64D3 ATxmegaD4

<TPI Mode>

ATtiny4 ATtiny5 ATtiny9 ATtiny10 ATtiny20 ATtiny40

Blocking

I/O 작업은 유저레벨에서 직접 수행할 수 없다. 실제 I/O를 수행하는것은 커널레벨에서만 가능하다. 따라서 유저 프로세스(또는 쓰레드)는 커널에게 I/O를 요청해야한다. I/O에서 블로킹 형태의 작업은 유저 프로세스가 커널에게 I/O를 요청하는 함수를 호출하고, 커널이 작업을 완료되면 함수가 작업 결과를 반환한다.

http://www.masterraghu.com/subjects/np/introduction/unix_network_programming_v1.3/ch06lev1sec2.html

I/O 작업이 진행되는동안 유저 프로세스는 자신의 작업을 중단한채 대기해야한다. I/O작업이 CPU자원을 거의 쓰지 않기 때문에 이런 형태의 I/O는 리소스 낭비가 심하다.

만약 여러 클라이언트가 접속하는 서버를 블로킹방식으로 구현한다고 가정해보자. I/O작업이 blocking 방식으로 구현되면 하나의 클라이언트가 I/O작업을 진행하면 해당 프로세스(또는 쓰레드)가 진행하는 작업을 중지하게 된다. 따라서 다른 클라이언트의 작업에 영향을 미치지 않게 하기 위해서 클라이언트 별로 별도의 쓰레드를 만들어 연결시켜주어야 할 것이다. 그러면 쓰레드 수는 접속자 수가 많아질 수록 엄청나게 많아지게 된다. 쓰레드가 많으면 CPU의 컨텍스트 스위칭 횟수가 증가할 것이며, 이때 사용되는 컨텍스트 스위칭 비용 때문에, 실제 작업하는 양에 비하여 훨씬 비효율적으로 동작하게 될 것이다.

Non-Blocking

Blocking 방식의 비효율성을 극복하고자 만들어진 것이 Non-Blocking 방식이다. Non-Blocking은 I/O작업을 진행하는 동안 유저 프로세스의 작업을 중단시키지 않는다. 유저 프로세스가 커널에게 I/O를 요청하는 함수를 호출하면, 함수는 I/O를 요청한 다음 진행상황과 상관없이 바로 결과를 반환한다.

http://www.masterraghu.com/subjects/np/introduction/unix_network_programming_v1.3/ch06lev1sec2.html

위 그림은 Non-Blocking 방식으로 구현된 I/O의 대표적인 사례를 잘 보여준다. 유저 프로세스는 recvfrom함수를 호출하여 커널에게 해당 소켓으로부터 데이터를 받아오고 싶다고 요청하고 있다. 커널은 이 요청에 대해서 상대방의 데이터를 전송 받아서 recvBuffer에 저장하고, 유저에게 그 내용을 복사해줘야 한다. 상대방으로 부터 데이터를 받는 중에 recvBuffer가 비어있다면 유저 프로세스가 커널에게 받아올 수 있는 정보는 없다. 따라서 recvfrom 함수는 아직 작업 진행중이란 의미로 "EWOULDBLOCK"을 리턴한다. 이 결과를 받은 유저 프로세스는 다른 작업을 진행할 수 있다. 만약 recvBuffer에 유저가 받을 수 있는 데이터가 있다면, 버퍼로 부터 데이터를 복사하여 받아온다. recvBuffer는 커널이 가지고 있는 메모리에 적재되어 있으므로 메모리간 복사가 일어나 I/O보다 훨씬 빠른 속도로 데이터를 받아올 수 있다. 이때 recvfrom함수는 빠른 속도로 읽을 수 있는 데이터를 복사해주고 복사한 데이터의 길이와 함께 반환한다. 위의 모든 반환이 I/O의 진행시간과는 관계없이 빠르게 동작하기 때문에, 유저 프로세스는 자신의 작업을 오랜시간 중지하지 않고도 I/O 처리를 수행할 수 있다.

Socket에서 Non-Blocking 구현

socket 프로그래밍에서 해당 소켓의 I/O Blocking/Non-Blocking 모드를 결정할 수 있다.

//ioctlsocket함수: 소켓의 I/O 상태를 변경하는 함수 //리눅스에서는 ioctl함수가 같은 기능을 지원한다. ULONG isNonBlocking = 1; ioctlsocket(socket, //Non-Blocking으로 변경할 소켓 FIONBIO, //변경할 소켓의 입출력 모드 &isNonBlocking //넘기는 인자, 여기서는 nonblocking설정 값 );

두 번째 인자에 어떤 값을 넣느야에 따라서 설정 값의 의미가 달라지긴 하지만, Non-Blocking으로 만드는데에는 이 호출만으로 충분하다. 소켓은 초기 설정이 Blocking으로 되어있으므로 Non-Blocking 모드로 진행하기 위해서는 이 함수 호출이 필수적이다.

char str[BUF_SIZE] = {0,}; //받을 버퍼 unsigned int strLen = 0; //받고싶은 데이터의 길이 unsigned int length = 0; //지금까지 받은 데이터의 길이 unsigned int recvLen = 0; //이번에 받은 데이터의 길이 ... while(TRUE){ if ( recvLen = recv( sock, str+length, strLen, 0) < 0 ){ //recvfrom 호출하여 결과값을 받는다. 0보다 작으면 받을 수 있는 데이터가 없는것 if ( WSAGetLastError() == WSAEWOULDBLOCK ){ //WOULDBLOCK이라면 대기시킨다. Sleep( 2000 ); /* Sleep for 2 milliseconds */ } else{ printf("No data Error.\n"); break; } } else { length += recvLen; if(length >= strLen) //다받았으면 중지 break; } }

while문을 사용하여 Blocking 모델과 다를바 없이 사용하고 있기 때문에 좋은 사용 방법이라고는 생각하지 않지만, 각 부분을 따로 놓고 생각하면 Non-Blocking형식으로 I/O를 구현하는 방식들을 잘 보여주는 예시이다. 논블럭 recv함수는 읽을 수 있는 데이터만 복사해서 가져오고 그 결과를 반환한다. 원하는 사이즈의 데이터를 받으려면 데이터를 축적하여 받아와야할 것이다. 함수가 반환하는 값에 따라서 적절하게 동작하도록 코딩하면 원하는 결과를 얻을 수 있을 것이다.

그렇다면 이제 Blocking 식 서버에서는 할 수 없었던 싱글 쓰레드 다중접속 서버를 만들 수 있다. accept된 소켓을 하나씩 클라이언트 세션으로 만들고 클라이언트 매니저가 연결된 클라이언트들을 관리한다. 클라이언트 매니저는 모든 클라이언트 세션들을 계속해서 순회하면서 recv를 호출하여 입력을 받는다. 그리고 받은 내용에 대한 처리를 해서 send로 응답해줄 수 있다. 이때 수행되는 작업이 Non-blocking이므로 따로 쓰레드를 만들지 않아도 충분히 잘 동작할 것이다. 이 구현방식의 문제는 클라이언트가 따로 입력을 하지 않아도 계속해서 recv로 확인을 해줘야한다는 점이다. 버퍼가 준비되었는지를 확인하는데 recv를 쓰는것은 리소스를 남용하는 것이다. recv말고 그냥 해당 소켓의 버퍼를 체크할 수 있는 방법이 있다면, 읽고 쓸 수 있는 상태에 처한 소켓들을 가려낼 수 있다면 더 효과적인 방법으로 서버를 만들 수 있을 것이다.

동기 비동기 I/O 통지모델

I/O 이벤트 통지 모델

이벤트 통지 모델은 Non-Blocking에서 제기된 문제를 해결하기 위해서 고안되었다. I/O처리를 할 수 있는 소켓(혹은 파일 디스크립터)을 가려내서 가르쳐준다면, 다시말해 입력 버퍼에 데이터가 수신되어서 데이터의 수신이 필요하거나, 출력버퍼가 비어서 데이터의 전송이 가능한 상황을 알려준다면, 위에서 이야기한 구조보다 더 단순하고 효과적으로 다중 I/O모델을 처리할 수 있을 것이다. I/O 이벤트를 통지하는 방법은 크게 동기형 통지모델과 비동기형 통지모델로 나눌 수 있다. 

동기형 통지모델

동기(synchronous)와 비동기(asynchronous)는 서로 메시지를 주고받는 상대방이 어떤 방식으로 통신을 하는가에 대한 개념이다. I/O 통지모델에서 대화하는 주체들은 커널과 프로세스이다. 프로세스는 커널에게 I/O처리를 요청하고,커널은 프로세스에게 I/O 상황을 통지한다. 우선 I/O 요청은 반드시 동일하게 처리될 수 밖에 없는 부분이고, 결국에 커널이 프로세스에게 어떤 방식으로 통지하느냐에 따라 동기형이냐 비동기형이 결정될 것이다. 

동기형 통지모델의 프로세스는 커널에게 지속적으로 현재 I/O 준비 상황을 체크한다. 즉 커널이 준비되었는지를 계속 확인하여 동기화 하는 것이다. 따라서 동기형 통지모델에서 Notify를 적극적으로 진행하는 주체는 유저의 프로세스가 되며 커널은 수동적으로 유저 프로세스의 요청에 따라 현재의 상황을 보고한다. 

비동기형 통지모델

이와 반대로 비동기형 통지모델은 일단 커널에게 I/O작업을 맡기면 커널의 작업 진행사항에 대해서 프로세스가 인지할 필요가 없는 상황을 말한다. 유저의 프로세스가 I/O 동기화를 신경쓸 필요가 없기에 비동기형이라고 부를 수 있다. 따라서 비동기형 통지모델에서 Notify의 적극적인 주체는 커널이 되며, 유저 프로세스는 수동적인 입장에서 자신이 할일을 하다가 통지가 오면 그때 I/O 처리를 하게 된다. 

출처: https://ozt88.tistory.com/20?category=123069 [공부 모음]

https://micro.rohm.com/kr/techweb/knowledge/

전원 설계 관련 사이트