시스템 속도, 통신 속도, 전송할 데이터 양, 정확도(?) 등등에 따라서 적당히 정하시면됩니다.
속도가 빠를수록 에러율이 누적될 확률이 있으니 임베디드 장비라면 데이터시트 보시고 스펙을 확인하셔야되고
무조건 고정길이로 메시지를 주고받는다면 그리고 짧다면 없어도 문제가 되지 않을테구요
가변적인 길이의 메시지를 주고받거나 데이터양이 많다면 시작과 끝 데이터 길이 등등의 부가 정보가 더 들어가면되겠죠
추가적으로 CRC등도 생각해 볼 수 있을테구요....
극단적으로는 상호간에 통신 스펙만 정해놓고 서로 한바이트씩만 정해진 커멘드 날리는것도 프로토콜이고...
시작 커멘드 길이 끝 거기다가 추가적으로 ack 등등 다 주고받으면서 초고속으로 한번에 메가바이트 단위로 데이터 날려대며 통신해도 프로토콜입니다. (필요없어보여도 데이터 정확성이 중요하다면 할수도 있겠죠.. 이런경우라면 다른통신인터페이스를 사용할지도 ㅋㅋ)
프로토콜은 필요에따라 간단할수도 복잡해서 머리 뽀개질 수도 있습니다... =333
p.s. 아니면 관련 표준 스펙을 찾아보셔도 되구요... 몇몇 표준들에선 필요에 의해서 자신들의 기기끼리 사용할 프로토콜을 구현해 놓은 경우도 있습니다. 간단하게는 tinyos 에서사용하는 메시지 프로토콜 같은건 자료 찾아보기 편하실껍니다...
통신 자체야 통신속도( 9600, 19200, 115200bps 등등 ), 전송 비트수( 7. 8. 9bits), 패리티 비트( even odd non ), 정지비트(0, 1, 2? 던가...), 흐름제어 등등 세팅해주고 바이트단위로 쏘면 알아서 보내고 받고 합니다....
받은 데이터를 처리하는건 개발자 맘데로 하면 되구요...
라이브러리 따라서 콜백이나 이벤트 발생시키는 거도있고 그냥 직접 폴링으로 감시하다가 받아야하는경우도 있구요...
임베디드 장비라면 rs232 인터페이스 내장인지 외장인지 확인하시고 레지스터 맞게 세팅하시고 데이터 버퍼에 넣으면 날아갑니다... 좀더 손 많이 댄다는거빼면 별차이 없지요....
무엇을 하는데 어디까지 되어있고 어떤용도로 프로토콜을 설계하시는지를 밝혀주셔야 어떤걸 보라고 좀더 적절한 조언을 해드릴수 있습니다.... 아니면 rs232 통신을 아예 처음해서 어디서 부터 손대야하는지 모르시는건지..?
윗분들은 하드웨어 세팅부터 데이터 전송하는데까지 필요한 내용이고 제가 쓴부분은 소프트웨어적인부분입니다....
통신 프로그램이라는건 프로토콜 위에 엊혀진다고 생각하는데....
통신 프로그램을 짜시면 속도랑....뭐뭐 기본적인 셋팅만 해주시고 아래단에 있는 프로토콜을 이용하여 전송이 되는걸로 알고 있습니다.
그리고 프로토콜이라는걸 너무 어렵게 생각하시는거 같습니다.
규약에 없는 그러니까 stepper님께서 개인적으로 만든 프로토콜의 내용이 처음 시작비트는 '00001111' 이렇게 전송을 하고 끝비트를 '111110000'(그럼 중간에 데이타들이 들어가겠지요) 이렇게 정의하셨다면 이것도 프로토콜이라고 생각합니다. 단, 수신측에도 같이 해줘야겠지요. 한마디로 송신측과 수신측의 약속이죠.
프로토콜을 너무 어렵게 생각하지 마세요. 그냥 'RS232규약에 맞게 프로그램 한다' 라고 생각 하시면 쉬우실듯 합니다.
저도 프로토콜이란걸 처음에 접했을때(몇번 접하지도 않았습니다^^;;) 엄청 대단한거라 생각하고 어렵게만 생각 했었습니다. 그러나 어떤건지 이해하니깐 많이 쉬워지더군요.
저도 아직 학생이다보니깐 자세히 안다거나...틀린 부분이 있을 수 있습니다.
틀린부분이 있다면 댓글로 고쳐주시기 바랍니다.
stepper 님이 말슴하시는건 하드웨어 적인 레벨입니다... 이게 헷갈릴 수도 있는부분이 TCP/IP 통신같은경우는 하드웨어에서 상당부분을 처리해주기때문인데 rs232 통신 자체에는 기본적으로 주고받기밖에 없습니다 나머지 부분을 어떻게 처리해 주어야할까를 약속한게 프로토콜입니다.
그냥 릴레이 붙여서 on/off 해도 되지만 전등자체에 컨트롤러가 붙어서 rs232 통신으로 하려면 메인 서버쪽에서는 불켜라 불꺼라 명령을 줘야겠죠?
간단하게 여기서는 불켜는데 0x00, 불끄는데 0x0F 이렇게 한바이트로 명령을 줘 보죠...
이제 테스트를 해 봐야하니까 메인 PC에서 0x00을 날려봅니다 안켜집니다.. 통신속도를 안정했으니 받는쪽에서 못알아 먹습니다...
RS232는 동기신호가 없기때문에 통신속도를 서로 정해놓고 받는쪽에선 알아먹으리라 가정하고 무조건 날려버리는 방식입니다. 따라서 통신속도를 맞춰줘야겠죠..
별로 고속통신 필요없으니 전등 쪽에 붙은 컨트롤러가 9600bps로 통신이 된다고 가정해봅니다. 추가적인 가정으로 아래에서 정의하는 기능은 미리 전등쪽에 정의되있거나 매번 새로 추가한다고 치죠뭐...
다시 통신속도, 데이터비트 스톱비트 플로우컨트롤 기타등등 맞춰주고 0x00을 날립니다.
불 켜집니다.
0x0F를 날립니다. 불 꺼집니다.
이제 문서를 만듭니다.
buadrate: 9600bps
data bits: 8
stop bit: 1
parity: none
전등 제어 명령
전등 ON: 0x00
전등 OFF: 0x0F
제어명령에 따른 응답: 없음
프로토콜 정의 완료되었습니다 -_-a 이제 이걸 프로토콜 정의하라고 오더 내리신분께 이쁘게 문서 만들어서 쏴드리면됩니다.
너무 성의 없어보이나요... 추가로 쓸데없이 양을 불려봅니다(말이 그렇단거죠 -_-a)
이게 연결이 되어있는지 아닌지 알아보고 싶다면? 중간에 끊어질수도있고 천재지변으로 그 전등이 달린 천정만 무너질수도 있으니.... 확인을 해야겠죠
물어보는 코드를 추가합니다. 또다시 성의없이... (=3333) 0x07 로 정합니다. 응답도 있어야 살아있는줄 알겠죠 응답은 귀찮으니까 걍 받은거 모조리 리턴하도록 하겠습니다.
보낸 명령어가 돌아오면 동작은 하는거니까요.
다시정의하면
전등 제어 명령 제어명령에 대한 응답 방향
전등 연결 체크: 0x07 0x07 (1byte) PC -> Light
전등 ON: 0x00 0x00 (1byte) PC -> Light
전등 OFF: 0x0F 0x0F (1byte) PC -> Light
이 됩니다.
이제 한가지더 메인서버가 헤까닥 죽었습니다. 급하게 살렸는데 전등쪽 상태를 알 수가 없습니다. 응용프로그램에서 표시를 해 주어야하는데 알수가 없군요 찍어야하나요? 잘못찍었다가 걸리면?
물어봅니다. 0x44 (에라 그냥 맘편히 죽어라 하는심정에서... 四나 死나...)로... 응답은 명령어와 상태를 돌려주도록 하겠습니다. 귀찮으니 0x00과 0x0F를 돌려주죠뭐.....
다시정의하면
전등 제어 명령 제어명령에 대한 응답 방향
전등 연결 체크: 0x07 0x07 (1byte) PC -> Light
전등 ON: 0x00 0x00 (1byte) PC -> Light
전등 OFF: 0x0F 0x0F (1byte) PC -> Light
전등 상태 체크: 0x44 0x44 0x00 or 0x44 0x0F PC <-> Light
이 됩니다.
이벤트같은거... 사용자가 메인서버를 거치지 않고 잔인하게도 스위치를 눌러서 껐다면..? 0x18에 생태도 발생시키도록 해보지요... (...사심가득한 숫자 선택에 기분나쁘신분있다면 죄송합니다만.. 참을수 없는 충동이....)
계속 반복하기 귀찮으니 몰아서 처리하면 전등하나만 쓸께 아니니까 ID도 붙여봅니다. rs232는 무선통신처럼 개방형은 아니니까 256개만 써봅니다. 귀찮으니 한군데다 통합시킵니다.
생각해보면 상태변경 이벤트에서는 PC쪽에서 응답을 똑같이 줘야할까말까 고민되네요... 이거만봐서는 정리해줍니다.
다시정의하면
전등 제어 명령 제어명령에 대한 응답 방향 비고
전등 연결 체크: 0x07 0x07 0x?? (2byte) PC <-> Light 응답값은 전등의 ID
전등 ON: 0x00 0x00 (1byte) PC -> Light
전등 OFF: 0x0F 0x0F (1byte) PC -> Light
전등 상태 체크: 0x44 0x44 0x00 or 0x44 0x0F PC <-> Light
전등 상태 변경 이벤트: 0x18 0x18 0x00 or 0x18 0x0F Light -> PC PC로부터의 응답은 없음
이 됩니다. 앵무새처럼 돌아오는 응답은 무시하고 단방향으로 봤고 무언가 데이터가 붙어서 날아오는 응답은 양방향으로 정해보았습니다.
무언가 긴 데이터가 날아가야한다면 좀더 복잡해지겠죠. 네트워크 구조에 따라서 복잡해질테고...
시작과 끝, 커멘드종류, 데이터 길이, 오류처리용 CRC, 어느놈이 어느놈한테 보내는 명령어다 어느놈이 어느놈한테 보내는 데이터다 응답이다 요청이다 등등... 만드시면됩니다.
아.. 근데 rs232는 1:1이군요... OTL
p.s. 모든 시리얼 통신이 저렇게 대충가지는 않습니다 ㅎㅎ 그냥 on/off만 동작하기에간단히 했습니다.
p.s2. 선배 결혼식 가야되는데 꽃단장 포기하고 쓴글이니까 개판으로 써놨더라도 짱돌만은좀 자제해주시길바라며 도망갑니다!! 순식간에 양복 다려입고 뛰어야겠네요 ;;
1
1
<< 보시면 찾기라고
<< 보시면 찾기라고 있습니다.
프로토콜은 서로 데이터를 어떻게 주고 받겠다는 상호간의 약속입니다....
시스템 속도, 통신 속도, 전송할 데이터 양, 정확도(?) 등등에 따라서 적당히 정하시면됩니다.
속도가 빠를수록 에러율이 누적될 확률이 있으니 임베디드 장비라면 데이터시트 보시고 스펙을 확인하셔야되고
무조건 고정길이로 메시지를 주고받는다면 그리고 짧다면 없어도 문제가 되지 않을테구요
가변적인 길이의 메시지를 주고받거나 데이터양이 많다면 시작과 끝 데이터 길이 등등의 부가 정보가 더 들어가면되겠죠
추가적으로 CRC등도 생각해 볼 수 있을테구요....
극단적으로는 상호간에 통신 스펙만 정해놓고 서로 한바이트씩만 정해진 커멘드 날리는것도 프로토콜이고...
시작 커멘드 길이 끝 거기다가 추가적으로 ack 등등 다 주고받으면서 초고속으로 한번에 메가바이트 단위로 데이터 날려대며 통신해도 프로토콜입니다. (필요없어보여도 데이터 정확성이 중요하다면 할수도 있겠죠.. 이런경우라면 다른통신인터페이스를 사용할지도 ㅋㅋ)
프로토콜은 필요에따라 간단할수도 복잡해서 머리 뽀개질 수도 있습니다... =333
p.s. 아니면 관련 표준 스펙을 찾아보셔도 되구요... 몇몇 표준들에선 필요에 의해서 자신들의 기기끼리 사용할 프로토콜을 구현해 놓은 경우도 있습니다. 간단하게는 tinyos 에서사용하는 메시지 프로토콜 같은건 자료 찾아보기 편하실껍니다...
감사합니다만..
답변들은 감사합니다만.. 제가 이해를 잘..;
도대체 uart 통신 프로토콜 짜려면 어떻게 해야하는겁니까..ㅠ
어느 범위를
어느 범위를 말씀하시는건지 이해가 잘....
rs232 인터페이스야 표준이 있으니 그냥 그대로 연결하시면 되고...
통신 자체야 통신속도( 9600, 19200, 115200bps 등등 ), 전송 비트수( 7. 8. 9bits), 패리티 비트( even odd non ), 정지비트(0, 1, 2? 던가...), 흐름제어 등등 세팅해주고 바이트단위로 쏘면 알아서 보내고 받고 합니다....
받은 데이터를 처리하는건 개발자 맘데로 하면 되구요...
라이브러리 따라서 콜백이나 이벤트 발생시키는 거도있고 그냥 직접 폴링으로 감시하다가 받아야하는경우도 있구요...
임베디드 장비라면 rs232 인터페이스 내장인지 외장인지 확인하시고 레지스터 맞게 세팅하시고 데이터 버퍼에 넣으면 날아갑니다... 좀더 손 많이 댄다는거빼면 별차이 없지요....
무엇을 하는데 어디까지 되어있고 어떤용도로 프로토콜을 설계하시는지를 밝혀주셔야 어떤걸 보라고 좀더 적절한 조언을 해드릴수 있습니다.... 아니면 rs232 통신을 아예 처음해서 어디서 부터 손대야하는지 모르시는건지..?
윗분들은 하드웨어 세팅부터 데이터 전송하는데까지 필요한 내용이고 제가 쓴부분은 소프트웨어적인부분입니다....
어느쪽을 더 자세히 답해드려야할지 모르겠는데요 ;;;;;
http://www.beyondlogic.org/se
http://www.beyondlogic.org/serial/serial.htm
google해서 나온건데 이거 본 다음에 뚝딱거리면 될 거 같습니다.
Taeho Oh ( ohhara@postech.edu , ohhara@plus.or.kr ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Digital Media Professionals Inc. http://www.dmprof.com
Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com
소프트웨어적인
소프트웨어적인 부분이구요. 처음해보는 겁니다. 맨 땅에 헤딩 중임...
rs232 내장일 겁니다. 대개의 보드는 rs232가 기본으로 있는걸로 알아서;
rs-232 to 485 컨버터를 사용해서
서로 통신할 것이기 때문에 결론적으로 rs232 통신이 가능하면 되구요.
회사에서 보드를 아직 안받아서 레지스터라던가 한개도 모르겠네요; 어떻게 짜야하는 지도 모르겠구요.
통신프로그램과 프로토콜의 차이의 개념이 많이 애매하구요..
관련 소스 내용도 본 적이 없는터라 관련 지식도 전무하구요.
정리하자면 rs232를 통한 상호간의 통신을 위한 프로토콜을 만든다(구현). 라고 할 수 있겠네요;
통신 프로그램과 프로토콜.. 제생각
통신 프로그램이라는건 프로토콜 위에 엊혀진다고 생각하는데....
통신 프로그램을 짜시면 속도랑....뭐뭐 기본적인 셋팅만 해주시고 아래단에 있는 프로토콜을 이용하여 전송이 되는걸로 알고 있습니다.
그리고 프로토콜이라는걸 너무 어렵게 생각하시는거 같습니다.
규약에 없는 그러니까 stepper님께서 개인적으로 만든 프로토콜의 내용이 처음 시작비트는 '00001111' 이렇게 전송을 하고 끝비트를 '111110000'(그럼 중간에 데이타들이 들어가겠지요) 이렇게 정의하셨다면 이것도 프로토콜이라고 생각합니다. 단, 수신측에도 같이 해줘야겠지요. 한마디로 송신측과 수신측의 약속이죠.
프로토콜을 너무 어렵게 생각하지 마세요. 그냥 'RS232규약에 맞게 프로그램 한다' 라고 생각 하시면 쉬우실듯 합니다.
저도 프로토콜이란걸 처음에 접했을때(몇번 접하지도 않았습니다^^;;) 엄청 대단한거라 생각하고 어렵게만 생각 했었습니다. 그러나 어떤건지 이해하니깐 많이 쉬워지더군요.
저도 아직 학생이다보니깐 자세히 안다거나...틀린 부분이 있을 수 있습니다.
틀린부분이 있다면 댓글로 고쳐주시기 바랍니다.
요긴 다들 멋진말만 남기더군요.-_-
프로토콜
음.. 프로토콜을 일종의 rs232 규격에 맞는 데이터프레임을 규정한다.. 라고 생각은 하고있는데요
내용을 어떻게 만들어야하는지를 하나도 모르겠습니다. 그리고 프로토콜이라는게 device driver가 이미 하고 있는 역할이 아닌가 하는 생각도
들구요.. 왜냐하면 생각해보면 별다른 설정없이 minicom을 통해 데이터를 다운로드 받을 수 있지않습니까?..
whitelazy 님이 말한 것 처럼.. 레지스터 맞게 세팅하시고 데이터 버퍼에 넣으면 날아간다.. 이런 이유이기도 하구요..
프로토콜은 프로그램 내부에 포함되는 일종의 baudrate설정같은게 되는건지..
그렇다면 프로토콜이라는걸 따로 만들 필요가 없다는 건데... 아무튼 복잡하네요..
네트워크 디바이스 드라이버
커널 내부에 있는 네트워크 포로토콜 스택과 연동하다록 설계되어있고 네트워크 디바이스 드라이버에는 디바이스 파일이 없다.
인터넷에 이런글이 있네요.
제 생각에는 디바이스 드라이버는 커널에 존재하는 프로토콜과 연결시켜주는 역할만 하는거 같습니다.
근데 어떤 종류의 보드를 쓰시는지 알려주시면 같이 공부하면서 이것저것 찾기가 수월할텐데요^^;; ARM같은 CPU가 달린 보드인지, 아님 그냥 MCU가 컨트럴하는 보드인지요^^;;;;
글들을 보면 OS가 올라가는 보드인거 같은데...
요긴 다들 멋진말만 남기더군요.-_-
stepper 님이
stepper 님이 말슴하시는건 하드웨어 적인 레벨입니다... 이게 헷갈릴 수도 있는부분이 TCP/IP 통신같은경우는 하드웨어에서 상당부분을 처리해주기때문인데 rs232 통신 자체에는 기본적으로 주고받기밖에 없습니다 나머지 부분을 어떻게 처리해 주어야할까를 약속한게 프로토콜입니다.
소프트웨어적으로 처리해줘야할 부분은 만약에 예를들어서 rs232 통신으로 전등을 제어한다고 가정해 보겠습니다.
그냥 릴레이 붙여서 on/off 해도 되지만 전등자체에 컨트롤러가 붙어서 rs232 통신으로 하려면 메인 서버쪽에서는 불켜라 불꺼라 명령을 줘야겠죠?
간단하게 여기서는 불켜는데 0x00, 불끄는데 0x0F 이렇게 한바이트로 명령을 줘 보죠...
이제 테스트를 해 봐야하니까 메인 PC에서 0x00을 날려봅니다 안켜집니다.. 통신속도를 안정했으니 받는쪽에서 못알아 먹습니다...
RS232는 동기신호가 없기때문에 통신속도를 서로 정해놓고 받는쪽에선 알아먹으리라 가정하고 무조건 날려버리는 방식입니다. 따라서 통신속도를 맞춰줘야겠죠..
별로 고속통신 필요없으니 전등 쪽에 붙은 컨트롤러가 9600bps로 통신이 된다고 가정해봅니다. 추가적인 가정으로 아래에서 정의하는 기능은 미리 전등쪽에 정의되있거나 매번 새로 추가한다고 치죠뭐...
다시 통신속도, 데이터비트 스톱비트 플로우컨트롤 기타등등 맞춰주고 0x00을 날립니다.
불 켜집니다.
0x0F를 날립니다. 불 꺼집니다.
이제 문서를 만듭니다.
buadrate: 9600bps
data bits: 8
stop bit: 1
parity: none
전등 제어 명령
전등 ON: 0x00
전등 OFF: 0x0F
제어명령에 따른 응답: 없음
프로토콜 정의 완료되었습니다 -_-a 이제 이걸 프로토콜 정의하라고 오더 내리신분께 이쁘게 문서 만들어서 쏴드리면됩니다.
너무 성의 없어보이나요... 추가로 쓸데없이 양을 불려봅니다(말이 그렇단거죠 -_-a)
이게 연결이 되어있는지 아닌지 알아보고 싶다면? 중간에 끊어질수도있고 천재지변으로 그 전등이 달린 천정만 무너질수도 있으니.... 확인을 해야겠죠
물어보는 코드를 추가합니다. 또다시 성의없이... (=3333) 0x07 로 정합니다. 응답도 있어야 살아있는줄 알겠죠 응답은 귀찮으니까 걍 받은거 모조리 리턴하도록 하겠습니다.
보낸 명령어가 돌아오면 동작은 하는거니까요.
다시정의하면
이 됩니다.
이제 한가지더 메인서버가 헤까닥 죽었습니다. 급하게 살렸는데 전등쪽 상태를 알 수가 없습니다. 응용프로그램에서 표시를 해 주어야하는데 알수가 없군요 찍어야하나요? 잘못찍었다가 걸리면?
물어봅니다. 0x44 (에라 그냥 맘편히 죽어라 하는심정에서... 四나 死나...)로... 응답은 명령어와 상태를 돌려주도록 하겠습니다. 귀찮으니 0x00과 0x0F를 돌려주죠뭐.....
다시정의하면
이 됩니다.
이벤트같은거... 사용자가 메인서버를 거치지 않고 잔인하게도 스위치를 눌러서 껐다면..? 0x18에 생태도 발생시키도록 해보지요... (...사심가득한 숫자 선택에 기분나쁘신분있다면 죄송합니다만.. 참을수 없는 충동이....)
계속 반복하기 귀찮으니 몰아서 처리하면 전등하나만 쓸께 아니니까 ID도 붙여봅니다. rs232는 무선통신처럼 개방형은 아니니까 256개만 써봅니다. 귀찮으니 한군데다 통합시킵니다.
생각해보면 상태변경 이벤트에서는 PC쪽에서 응답을 똑같이 줘야할까말까 고민되네요... 이거만봐서는 정리해줍니다.
다시정의하면
이 됩니다. 앵무새처럼 돌아오는 응답은 무시하고 단방향으로 봤고 무언가 데이터가 붙어서 날아오는 응답은 양방향으로 정해보았습니다.
무언가 긴 데이터가 날아가야한다면 좀더 복잡해지겠죠. 네트워크 구조에 따라서 복잡해질테고...
시작과 끝, 커멘드종류, 데이터 길이, 오류처리용 CRC, 어느놈이 어느놈한테 보내는 명령어다 어느놈이 어느놈한테 보내는 데이터다 응답이다 요청이다 등등... 만드시면됩니다.
아.. 근데 rs232는 1:1이군요... OTL
p.s. 모든 시리얼 통신이 저렇게 대충가지는 않습니다 ㅎㅎ 그냥 on/off만 동작하기에간단히 했습니다.
p.s2. 선배 결혼식 가야되는데 꽃단장 포기하고 쓴글이니까 개판으로 써놨더라도 짱돌만은좀 자제해주시길바라며 도망갑니다!! 순식간에 양복 다려입고 뛰어야겠네요 ;;
댓글 달기