Primeiro, algo que Olin notou também: os níveis são o inverso do que um microcontolador geralmente produz:
Nada para se preocupar, veremos que também podemos ler dessa maneira. Só precisamos lembrar que, no escopo, um bit de início será um 1
e o bit de parada 0
.
Em seguida, você tem a base de tempo errada para ler isso corretamente. 9600 bits por segundo (unidades mais apropriadas que Baud, embora este último não esteja errado por sessão) é 104 s por bit, que é 1/10 de uma divisão na sua configuração atual. Aumente o zoom e defina um cursor vertical na primeira borda. Esse é o começo do seu bit de início. Mova o segundo cursor para cada uma das próximas arestas. A diferença entre os cursores deve ser múltiplos de 104 µs. Cada 104 s é um bit, primeiro o bit inicial ( ), depois 8 bits de dados, tempo total 832 s e um bit de parada ( ). μμμ1
μ0
Não parece que os dados da tela correspondem aos enviados 0x00
. Você deve ver um 1
bit estreito (o bit inicial) seguido de um nível baixo mais longo (936 s, 8 bancos de dados zero + um bit de parada).
O mesmo para o que você está enviando; você deve ver um nível alto e longo (novamente 936 s, desta vez o bit inicial + 8 bits de dados). Portanto, isso deve ser quase 1 divisão com a sua configuração atual, mas não é o que vejo.
Parece mais na primeira captura de tela que você está enviando dois bytes e na segunda, com o segundo e o terceiro com o mesmo valor. μ
0xFF
μ
palpites:
0b11001111 = 0xCF
0b11110010 = 0xF2
0b11001101 = 0xCD
0b11001010 = 0xCA
0b11001010 = 0xCA
0b11110010 = 0xF2
editar
Olin está absolutamente certo, isso é algo como ASCII. De fato, é o complemento 1 do ASCII.
0xCF ~ 0x30 = '0'
0xCE ~ 0x31 = '1'
0xCD ~ 0x32 = '2'
0xCC ~ 0x33 = '3'
0xCB ~ 0x34 = '4'
0xCA ~ 0x35 = '5'
0xF2 ~ 0x0D = [CR]
Isso confirma que minha interpretação das capturas de tela está correta.
editar 2 (como interpreto os dados, mediante solicitação popular :-))
Aviso: esta é uma longa história, porque é uma transcrição do que acontece na minha cabeça quando tento decodificar algo assim. Leia-o somente se você quiser aprender uma maneira de enfrentá-lo.
Exemplo: o segundo byte na 1ª captura de tela, começando com os 2 pulsos estreitos. Começo com o segundo byte de propósito, porque há mais arestas do que no primeiro byte, portanto será mais fácil acertar. Cada um dos pulsos estreitos tem cerca de 1/10 de uma divisão, de modo que pode ser 1 bit alto cada um, com um bit baixo no meio. Também não vejo nada mais estreito do que isso, então acho que é um pouco. Essa é a nossa referência.
Depois, após 101
um período mais longo no nível baixo. Parece duas vezes mais largo que os anteriores, então poderia ser 00
. O número seguinte é duas vezes mais largo, e assim será 1111
. Agora temos 9 bits: um bit inicial ( 1
) mais 8 bits de dados. Então, o próximo passo será o de parada, mas porque é0
não é imediatamente visível. Então, juntando tudo o que temos 1010011110
, incluindo começar e parar um pouco. Se o bit de parada não fosse zero, eu teria feito uma suposição ruim em algum lugar!
Lembre-se de que um UART envia o LSB (bit menos significativo) primeiro, portanto, teremos que reverter os 8 bits de dados: 11110010
= 0xF2
.
Agora sabemos a largura de um único bit, um bit duplo e uma sequência de 4 bits, e analisamos o primeiro byte. O primeiro período alto (o pulso amplo) é um pouco mais amplo que o 1111
do segundo byte, de modo que terá 5 bits de largura. O período baixo e o alto após cada um deles são tão amplos quanto o bit duplo no outro byte, então obtemos 111110011
. Novamente 9 bits, então o próximo deve ser um pouco baixo, o bit de parada. Tudo bem, então, se nossa estimativa de estimativa estiver correta, podemos reverter novamente os bits de dados: 11001111
= 0xCF
.
Então nós recebemos uma dica de Olin. A primeira comunicação tem 2 bytes de comprimento, 2 bytes mais curta que a segunda. E "0" também é 2 bytes menor que "255". Portanto, é provavelmente algo como ASCII, embora não exatamente. Também observo que o segundo e o terceiro byte do "255" são os mesmos. Ótimo, esse será o dobro "5". Estamos indo bem! (Você deve se incentivar de vez em quando.) Após decodificar o "0", "2" e "5", percebo que há uma diferença de 2 entre os códigos dos dois primeiros e uma diferença de 3 entre os últimos. dois. E finalmente percebo que esse 0xC_
é o complemento de 0x3_
, que é o padrão para dígitos em ASCII.