한 포트에 계속적으로 write만 하게되면 (만약 반대쪽에서 받지 않을때)
운영체제내의 write 버퍼에 계속해서 차게되고, 이 버퍼가 다 차면
에러가 생기는걸로 알고 있는데요.
제 컴퓨터에서 한바이트를 계속 쓰는데도 에러가 나지 않고
쓰기만 하는것 같습니다.
이것도 옵션이 따로 있는건가요?
계속 데이타를 write하고 받지 않으면 버퍼 오버플로우가 나서 데이타는 깨질 것입니다.
그러나 실제로 이 부분이 프로세서의 다운을 야기 시키지는 않을 듯 한데요..
인터럽도 올라 오지 않을 것 같은데, 특별히 모드 셋팅을 하지 않으면...^^
이상 허접 답변이었습니다.
시리얼 통신 (그리고 기타 여러가지 통신 프로토콜) 에서 플로우 컨트롤 (flow-control) 이라는 것이 바로 수신측이 받을 준비가 되어있지 않을 때 이를 송신측에 알려주는 역활을 하는것입니다.
시리얼 통신에서는 하드웨어 플로우 컨트롤과 소프트웨어 플로우 컨트롤을 이용할 수 있습니다. 송신/수신측이 모두 같은 플로우 컨트롤 방식을 사용하기로 합의가 된 상태라면 송신측에서는 수신측이 받을 준비가 되어 있지 않으면 보낼 수 없고, 따라서 수신측이 문제가 생긴것을 알 수 있는 가능성도 있습니다. 물론 플로우 컨트롤을 위한 신호를 발생하는 메커니즘마저 고장나 있어서 계속 받고 있는 상태인척(?) 한다면 알 수 없지요.
플로우 컨트롤이 수신측의 문제를 완벽하게 파악하는 수단이 되지도 못하지만, 그나마도 귀찮아서 플로우 컨트롤 옵션을 다 끄고 시리얼 케이블도 플로우 컨트롤 신호를 하나도 연결하지 않거나 로컬 루프백으로 처리하는 경우가 많습니다.
윈도우즈인가요 리눅스인가요?...질문이 모호하네요...좀더 구체적으로..
윈도우즈인가요 리눅스인가요?...질문이 모호하네요...좀더 구체적으로...
시리얼
리눅스에서 프로그램 하고 있습니다.
제 질문의 요지는
시리얼 포트가 하나 있고, 이걸 다른데랑 연결하지 않고 계속 write를
하게 되면 어떻게 될까..
입니다.
제가 실험을 해보았는데 계속 써대기만 하고 에러가 안나는데 이게 무슨
문제가 있나 해서입니다.
계속 데이타를 write하고 받지 않으면 버퍼 오버플로우가 나서 데이타는
계속 데이타를 write하고 받지 않으면 버퍼 오버플로우가 나서 데이타는 깨질 것입니다.
그러나 실제로 이 부분이 프로세서의 다운을 야기 시키지는 않을 듯 한데요..
인터럽도 올라 오지 않을 것 같은데, 특별히 모드 셋팅을 하지 않으면...^^
이상 허접 답변이었습니다.
에러가 안나는게 당연한데요...시리얼로 write하는건 말그대로 wr
에러가 안나는게 당연한데요...
시리얼로 write하는건 말그대로 write만 합니다....
입력단에서는 들어오는 걸 처리하지 않는다면 버퍼가 꽉 차겠지만,
출력단은 그런게 없습니다...그냥 write로 끝나는거죠...
???
입력이든 출력이든
FIFO기 때문에 full나면 먼저 들어온 놈들은 그냥 내쫓겨집니다.
--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)
시리얼
네 모두들 답변 감사드립니다.
처음 생각으로는 만약 2대의 pc가 시리얼로 연결되어 있고, 한쪽은 보내고
다른 한쪽에서 받는 동작을 할경우, 받는쪽 pc가 문제가 생겨서 받지를
못하면 보내는 pc도 write동작에서 에러가 나는줄 알았는데요.
제가 잘못 생각하고 있었네요.
그렇담 read를 하는 pc가 문제가 생겨도 write하는 pc는 전혀 알수가
없다는 이야기인것 같은데요.
맞는이야기 일까요?
플로우컨트롤
시리얼 통신 (그리고 기타 여러가지 통신 프로토콜) 에서 플로우 컨트롤 (flow-control) 이라는 것이 바로 수신측이 받을 준비가 되어있지 않을 때 이를 송신측에 알려주는 역활을 하는것입니다.
시리얼 통신에서는 하드웨어 플로우 컨트롤과 소프트웨어 플로우 컨트롤을 이용할 수 있습니다. 송신/수신측이 모두 같은 플로우 컨트롤 방식을 사용하기로 합의가 된 상태라면 송신측에서는 수신측이 받을 준비가 되어 있지 않으면 보낼 수 없고, 따라서 수신측이 문제가 생긴것을 알 수 있는 가능성도 있습니다. 물론 플로우 컨트롤을 위한 신호를 발생하는 메커니즘마저 고장나 있어서 계속 받고 있는 상태인척(?) 한다면 알 수 없지요.
플로우 컨트롤이 수신측의 문제를 완벽하게 파악하는 수단이 되지도 못하지만, 그나마도 귀찮아서 플로우 컨트롤 옵션을 다 끄고 시리얼 케이블도 플로우 컨트롤 신호를 하나도 연결하지 않거나 로컬 루프백으로 처리하는 경우가 많습니다.
댓글 달기