오실로스코프에서 직렬 데이터를 읽는 방법

마이크로 컨트롤러 (PICAXE 20X2)와 포트 미터가 있습니다. 포트 미터의 변경 사항을 PC의 직렬 포트로 보내도록 마이크로를 프로그래밍했습니다. 분명히 8 비트 ADC입니다. 이제 흥미로운 점은 오실로스코프에서이 직렬 데이터를 디코딩 할 수 있다는 것입니다.

다음은 두 개의 그림입니다. 첫 번째는 마이크로가 PC에 "0"을 보낼 때이고 다음은 "255"를 보낼 때입니다. 9600 buad를 사용하여 데이터를 전송하고 있으며 PC 터미널에서 수신 할 수 있습니다.

첫 사진

두 번째 사진

내 질문은 내 범위에서 올바른 데이터를 캡처 했습니까? 두 번째는이 펄스를 16 진수 또는 ASCII 형식으로 읽고 디코딩하는 방법입니다. 이 상승 및 하강 펄스 (0/1)를 읽는 방법을 의미합니다.

감사.

먼저 Olin도 주목했습니다. 레벨은 마이크로 컨트롤러가 일반적으로 출력하는 것과 반대입니다.

걱정할 것이 없습니다. 우리도이 방법으로 읽을 수 있다는 것을 알게 될 것입니다. 우리는 단지 스코프에서 시작 비트가 a 1및 정지 비트 임을 기억해야합니다 0.

다음으로, 당신은 이것을 올바르게 읽을 시간 기반이 잘못되었습니다. 초당 9600 비트 (saud 당 잘못된 것은 아니지만 Baud보다 적절한 단위)는 비트 당 104 s이며 이는 현재 설정의 1/10 분할입니다. 확대하고 첫 번째 가장자리에 수직 커서를 설정하십시오. 시작 비트의 시작입니다. 두 번째 커서를 다음 각 모서리로 이동하십시오. 커서의 차이는 104 의 배수 여야합니다 . 각 104 s는 1 비트이며, 먼저 시작 비트 ( ), 8 데이터 비트, 총 시간 832 s 및 정지 비트 ( )입니다. $\mu$$\mu$$\mu$1$\mu$0

화면 데이터가 전송 된 것과 일치하지 않습니다 0x00. 좁은 1비트 (시작 비트) 다음에 긴 하위 레벨 (936 s, 8 제로 데이터 비트 + 정지 비트)이 뒤 따릅니다 . 에 대한 같은 당신이 보내는; 당신은 긴 높은 레벨을 보게 될 것입니다 (이번에는 936 s, 이번에는 시작 비트 + 8 데이터 비트). 따라서 현재 설정과 거의 1 구간이어야하지만 그것이 내가 보는 것은 아닙니다. 첫 번째 스크린 샷에서 2 바이트를 보내고 두 번째 4에서 두 번째와 세 번째가 동일한 값을 갖는 것처럼 보입니다. $\mu$
0xFF$\mu$

추측 :

0b11001111 = 0xCF
0b11110010 = 0xF2

0b11001101 = 0xCD
0b11001010 = 0xCA
0b11001010 = 0xCA
0b11110010 = 0xF2

편집
Olin은 절대적으로 맞습니다. 이것은 ASCII와 같습니다. 사실 ASCII 의 1의 보수 입니다.

0xCF ~ 0x30 = '
0'0xCE ~ 0x31 = ' 1'0xCD ~
0x32 =
'
2'0xCC ~ 0x33 = ' 3'0xCB ~ 0x34 = '
4'0xCA ~ 0x35 = '5'

0xF2 ~ 0x0D = [CR]

이것은 스크린 샷에 대한 나의 해석이 올바른 것을 확인합니다.

편집 2 (인기있는 요청에 따라 데이터를 해석하는 방법 :-))
경고 : 이것은 긴 이야기입니다. 왜냐하면 이것은 이와 같은 것을 해독하려고 할 때 내 머리에서 일어나는 일의 기록이기 때문입니다. 해결하는 한 가지 방법을 배우고 싶을 때만 읽으십시오.

예 : 두 번째 좁은 펄스로 시작하여 첫 번째 스크린 샷의 두 번째 바이트입니다. 첫 번째 바이트보다 더 많은 가장자리가 있기 때문에 의도적으로 두 번째 바이트로 시작하므로 올바르게 얻는 것이 더 쉽습니다. 각각의 좁은 펄스는 약 1/10의 분할이므로, 그 사이에 낮은 비트와 함께 각각 1 비트 높을 수 있습니다. 나는 또한 이것보다 좁은 것을 보지 못하므로 단일 비트라고 생각합니다. 이것이 우리의 참조입니다.
그런 다음 101낮은 수준에서 더 긴 기간이 지난 후 . 이전 것보다 두 배 정도 넓습니다 00. 높은 팔로어는 다시 두 배 넓습니다 1111. 이제 시작 비트 ( 1)에 8 데이터 비트를 더한 9 비트가 있습니다. 다음 비트는 스톱 비트가되지만0즉시 보이지 않습니다. 1010011110시작 및 정지 비트를 포함하여 모든 것을 하나로 모았습니다 . 정지 비트가 0이 아니라면 어딘가에 잘못된 가정을했을 것입니다!
UART는 LSB (최하위 비트)를 먼저 전송하므로 8 개의 데이터 비트를 반전시켜야합니다 : 11110010= 0xF2.

이제 단일 비트, 이중 비트 및 4 비트 시퀀스의 너비를 알고 첫 번째 바이트를 살펴 봅니다. 첫 번째 높은주기 (와이드 펄스)는 1111두 번째 바이트의 것보다 약간 넓으 므로 5 비트 너비가됩니다. 그 다음에 오는 낮은 기간과 높은 기간은 다른 바이트의 더블 비트만큼 넓기 때문에 우리는 얻을 수 111110011있습니다. 다시 9 비트이므로 다음 비트는 하위 비트, 정지 비트 여야합니다. 괜찮습니다. 추정이 정확하다면 데이터 비트를 다시 되돌릴 수 있습니다 : 11001111= 0xCF.

그런 다음 Olin에서 힌트를 얻었습니다. 첫 번째 통신 길이는 2 바이트이며 두 번째 통신보다 2 바이트 더 짧습니다. "0"도 "255"보다 2 바이트 짧습니다. 아마도 ASCII와 같을 수도 있지만 정확하게는 아닙니다. 또한 "255"의 두 번째와 세 번째 바이트는 동일합니다. 큰 "5"가 될 것입니다. 우린 잘 지내고있어! (때때로 자신을 격려해야합니다.) "0", "2"및 "5"를 디코딩 한 후 처음 두 코드의 차이가 2이고 마지막 코드의 차이가 3입니다. 두. 그리고 마지막으로 ASCII의 숫자 패턴 0xC_인의 보수 임을 알았습니다 0x3_.

뭔가가 합치 지 않습니다. 신호가 3.3V 피크-피크 인 것으로 보이며 이는 마이크로에서 곧바로 나옵니다. 그러나 마이크로 컨트롤러 UART 레벨은 (거의) 항상 유휴 상태가 높고 활성 상태가 낮습니다. 귀하의 신호가 그 반대가되어 의미가 없습니다.

궁극적으로이 데이터를 PC로 가져 오려면 RS-232 레벨로 변환해야합니다. 이것은 PC COM 포트가 기대하는 것입니다. RS-232는 유휴 낮고 활성 높지만 낮음은 -5V 미만이고 높음은 + 5V 이상입니다. 다행히 일반적인 마이크로 컨트롤러 로직 레벨 UART 신호와 RS-232 사이를 쉽게 변환 할 수있는 칩이 있습니다. 이 칩에는 3.3V 전원 공급 장치에서 RS-232 전압을 만들기위한 차지 펌프가 포함되어 있습니다. 때때로 이러한 칩은 일반적으로 "MAX232"라고 불립니다. 이는 해당 유형의 초기 대중적인 칩의 부품 번호이기 때문입니다. 5V가 아닌 3.3V 전원을 사용하고 있기 때문에 다른 변형이 필요합니다. 우리는 기본적으로 커넥터가있는 보드에서 이러한 칩 중 하나 인 제품을 만듭니다. http://www.embedinc.com/products/rslink2로 이동 하십시오이러한 칩을 연결하는 방법의 한 예를 보려면 회로도를 살펴보십시오.

합치 지 않는 또 다른 것은 0과 255 만 전송한다고 말하더라도 두 시퀀스가 ​​모두 1 바이트 이상인 것처럼 보입니다. 이러한 유형의 직렬 데이터는 시작 비트와 함께 전송 된 다음 8 데이터 비트와 함께 전송됩니다. 그런 다음 정지 비트. 시작 비트는 항상 라인 유휴 레벨과 반대 극성에 있습니다. 대부분의 설명에서 회선 유휴 수준은 "공간"이라고하며 그 반대의 경우 "표시"라고합니다. 따라서 시작 비트가 항상 표시됩니다. 시작 비트의 목적은 나머지 비트에 대한 시간 동기화를 제공하는 것입니다. 양쪽이 비트 길이를 알고 있기 때문에 유일한 질문은 바이트의 시작 시점입니다. 시작 비트는이 정보를 제공합니다. 수신기는 기본적으로 시작 비트의 선행 에지에서 클럭을 시작하고이를 사용하여 데이터 비트가 언제 올 것인지 알 수 있습니다.

데이터 비트는 마크가 1이고 스페이스가 0 인 최소 순서로 전송됩니다. 스페이스 레벨의 정지 비트가 추가되어 다음 시작 비트의 시작이 새로운 에지가되고 약간의 시간이 남습니다. 바이트 사이. 이렇게하면 발신자와 수신자간에 약간의 오류가 발생합니다. 수신자가 발신자보다 조금 느리면 다음 시작 비트의 시작을 놓치게됩니다. 리시버는 타이밍 오류가 누적되지 않도록 새로운 시작 비트마다 새로 시계를 재설정하고 시작합니다.

따라서이 모든 것에서 첫 번째 트레이스가 최소 2 바이트를 보내는 것으로 보이며 마지막 트레이스는 5 일 것입니다.

추적 시간 범위를 확장하면 도움이됩니다. 그렇게하면 약간의 시간이 실제로 무엇인지 측정 할 수 있습니다. 그러면 실제로 9600 보드 (104 µs / bit)가 있는지 확인할 수 있고 캡처의 개별 비트를 디코딩 할 수 있습니다. 현재와 ​​같이 비트의 위치를 ​​확인할 수있는 해상도가 충분하지 않으므로 실제로 전송중인 내용을 디코딩합니다.

추가 :

방금 시스템이 바이너리 대신 ASCII로 데이터를 전송하는 것으로 나타났습니다. 작은 시스템에서 ASCII로 변환하면 제한된 자원을 더 많이 사용하고 대역폭을 제대로 사용하지 않으며 사용자에게 데이터를 표시하려는 경우 PC에서 쉽게 변환 할 수 있기 때문에 일반적으로 수행되는 방식이 아닙니다. 그러나 전송이 시퀀스가 ​​1 바이트 이상인 이유를 설명하는 ASCII 문자 인 경우, 두 번째 바이트가 더 긴 이유 ( "255"가 "0"보다 많은 문자) 및 둘 다 동일한 바이트로 끝나는 이유는 무엇입니까? 마지막 바이트는 일종의 줄 끝 문자 일 수 있으며 대개 캐리지 리턴 또는 줄 바꿈입니다.

어쨌든 타임 스케일을 확장하면 전송되는 내용을 정확하게 해독 할 수 있습니다.

속도, 시작 비트가있는 경우 데이터 비트 수, 정지 비트가있는 경우 및 패리티 비트가있는 경우 전체 세부 사항을 알아야합니다. 이것은 마이크로 컨트롤러의 UART 구성 방법에 대한 함수 여야합니다.

Rigol 스코프에 직렬 디코딩 옵션이없는 경우 (많은 DSO에 해당) X- 커서를 사용하여 디코딩을 지원할 수 있습니다. 첫 번째 커서를 데이터의 선행 가장자리에 놓고 두 번째 커서를 비트 스트림을 통해 이동합니다. 커서 사이의 델타를 사용하여 간단한 산술로 현재 어떤 '비트'를 가리키고 있는지 확인할 수 있습니다. 시작 / 정지 / 패리티 비트는 무시하십시오.