시리얼 통신으로 질문을 드리고 싶습니다

글쓴이: 익명 사용자 / 작성시간: 화, 2020/10/06 - 11:23오전
UART로 센서에서 값을 받아와서
ms 단위의 시간과 해당 센서 값을 띄우는 MFC 프로그램을 만들고 있습니다.
이래저래 순조롭게 진행은 됐는데,
시간이 찍히는 걸 보니까 평균적으로 6ms 정도 딜레이가 되어서
(가령, 100ms 주기를 설정했으면 평균적으로 106ms 정도의 주기를 갖게 됩니다.)
tera term이나 그런 프로그램을 이용해서 타임 스탬프를 찍어 봐도 비슷한 결과가 나오더라고요.
제 생각에는 프로그램 자체의 시간 복잡도 때문에 발생하는 문제는 아닌 것 같고,
윈도우 운영체제에서의 타임 슬라이스 문제 때문에 이런 오차가 발생하는 게 아닌가 싶은데
제가 생각한 게 맞는지, 이 오차를 좀 더 줄일 만한 방법이 있을지 여쭈어 보고 싶습니다.
Forums:
윈도우의 기본 time resolution은 15
윈도우의 기본 time resolution은 15.6ms 입니다.
구글에서 "Windows time resolution"으로 검색하면 관련 정보와 변경할 수 있는 방법이 많이 나옵니다.
----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라
감사합니다
timeBeginPeriod 같은 걸 이용하면 된다고는 되어 있던데,
제가 잘못 이해한 건지 생각대로 잘 안 되네요(...)
간단하게 Sleep 같은 거로 테스트를 해 봤을 때 잘 되는 걸 보면
제가 엉뚱하게 써서 안 되는 것 같은데, 이걸로 또 당분간 고민할 것 같네요.
답변 감사합니다.
어떤 통신 속도가 무엇인가요? 38400 bps라면
어떤 통신 속도가 무엇인가요? 38400 bps라면 1 byte 전송되는데 (1 / 38400) * 10 (8 bit + 2 sync bit) = 0.25 msec 가 걸립니다. 만약 10 byte 정도를 보낸다고 했을 때 패킷간 딜레이를 고려하면 3~5 msec 정도가 소요될 겁니다. 그래서 한 클럭 타이머 이벤트에서 UART를 이용한 송출까지 blocking 방식으로 전송하면 5ms 정도가 계속 지연될 수도 있게 되죠.
gettimeofday()와 같은 함수로 원래 타이머의 정확도가 뭔지도 살펴보시고, UART 송출은 타이머 이벤트 핸들러가 아닌 별도의 callback 함수(별도 thread)에서 실행되도록 해 보세요.
정답이십니다.
정답이십니다.
정확히 100ms 단위로 콜백이 실행되도록 하는게 좋겠죠
단 중복해서 실행되지 않도록만 주의하면요
------------------------------------------------------------
ProgrammingHolic
통신 속도는 115,200bps를 쓰고 있습니다
답변해 주셔서 감사합니다.
저는 지금 PC로 수신하는 부분만 우선적으로 과제(?)를 받아서 연습 중인지라
센서 쪽 기기에서 송출하는 부분은 어떻게 되어 있는지 잘 몰랐는데 나중에 꼭 확인해 보겠습니다.
수신도 마찬가지입니다. 수신측에서 계속 6ms가
수신도 마찬가지입니다. 수신측에서 계속 6ms가 추가로 늦게 처리하는데 반해 송신측에서는 매번 정확하게 보낸다면 몇십초 후에는 패킷을 놓칠수도 있고 실시간 처리에도 지장을 줄 수 있습니다.
수신 쪽은 일단 스레드를 생성해서 데이터를 받으면
수신 쪽은 일단 스레드를 생성해서 데이터를 받으면 이벤트가 발생하고 이때 데이터를 버퍼에 저장 후, 메인으로 도착 메시지를 보내고 있습니다.
그리고 메인에서 메시지를 받으면 버퍼의 메시지를 수신하여 파싱하고 출력하는 식으로 만들었습니다.
수신 쪽에서 잘못되었나 싶어서 tera term으로 타임 스탬프 찍어 봤을 때도
동일한 결과가 나오는 걸 봐서는 아마도 송신 쪽을 들여다봐야 할 것 같다는 생각이 들었습니다.
재차 감사드립니다.
지금까지의 상황을 보면 아마도 센서쪽에서...
지금까지의 상황을 보면 아마도 센서쪽에서...
100ms 의 '주기'가 아니라 '딜레이'를 사용한 모양이네요.
센서쪽의 데이터 송신 106ms 주기가 여러 다른 방법으로 확인된다는것을 보여줘야 겠네요.
댓글 달기