Como ler dados seriais do osciloscópio


21

Eu tenho um microcontrolador (PICAXE 20X2) e um medidor de panela. Programei o micro para que ele envie qualquer alteração do medidor de potenciômetro para a porta serial do PC. Obviamente, é um ADC de 8 bits. Agora, o interessante para mim é ser capaz de decodificar esses dados seriais no osciloscópio.

Aqui estão duas fotos, a primeira é quando o micro está enviando "0" para o PC e a próxima é quando ele envia "255". Os dados estão sendo transmitidos usando 9600 buad e posso recebê-los no terminal do PC.

First Pic insira a descrição da imagem aqui

Segunda foto insira a descrição da imagem aqui

Portanto, minha pergunta é: eu capturei os dados corretos no meu escopo e, em segundo lugar, como alguém pode ler e decodificar esses pulsos em um formato hexadecimal ou ascii. Quero dizer como ler esses pulsos crescentes e decrescentes (0/1).

Obrigado.


3
linhas seriais ociosas no estado lógico '1', lembre-se de que você tem 1 na parte inferior e 0 na parte superior aqui. Eu sei que as pessoas já se prenderam a isso. Meu comentário é para orientar futuras capturas de escopo de dados seriais; você pode investigar as coisas para que o estado ocioso seja alto.
31811 JustJeff

Respostas:


14

Primeiro, algo que Olin notou também: os níveis são o inverso do que um microcontolador geralmente produz:

insira a descrição da imagem aqui

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 1e 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 1bit 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 101um 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 é0nã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 1111do 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.


Obrigado pelas dicas, tentarei capturar a forma de onda correta e atualizar minha pergunta.
Sean87

Obrigado, você se importaria de marcar a imagem como você encontra esses dados?
Sean87

1
@ Sean87 - Tornou-se uma longa história, adicionei à minha resposta. Ilustra minha maneira de fazer isso, outros podem seguir caminhos diferentes. Não se preocupe se você acha que não teria visto metade disso; a maior parte é apenas experiência e imaginação. Não há inteligência especial envolvida.
31511 stevenvh

Respostas e perguntas muito boas, mas estou me perguntando por que você disse que o osciloscópio mostra o reverso do que realmente é. Eu sei que a linha ociosa é quase sempre alta, mas o osciloscópio não deve capturar uma imagem exata da coisa real? Exceto se o usuário alterou um parâmetro das configurações do osciloscópio.
Nikos

7

Algo não está somando. Seus sinais parecem ser de 3,3V pico a pico, o que implica que eles estão diretamente fora do micro. No entanto, os níveis de UART do microcontrolador são (quase) sempre ociosos, altos e ativos, baixos. Seus sinais são invertidos, o que não faz sentido.

Para finalmente obter esses dados em um PC, eles precisam ser convertidos para os níveis RS-232. É isso que uma porta COM do PC espera ver. O RS-232 está ocioso baixo e ativo alto, mas baixo está abaixo de -5V e alto está acima de + 5V. Felizmente, existem chips para isso que facilitam a conversão entre os sinais UART típicos do nível lógico do microcontrolador e o RS-232. Esses chips contêm bombas de carga para fazer as tensões RS-232 da sua fonte de alimentação de 3,3V. Às vezes, esses chips são chamados genericamente de "MAX232" porque esse era o número de peça de um chip antigo e popular desse tipo. Você precisa de uma variante diferente, pois aparentemente usa 3,3V de potência, e não 5V. Fabricamos um produto que é basicamente um desses chips em uma placa com conectores. Vá para http://www.embedinc.com/products/rslink2e veja o esquema para ver um exemplo de como conectar um chip desse tipo.

Outra coisa que não vale a pena é que ambas as seqüências parecem ter mais de um byte, mesmo que você diga que está enviando apenas 0 e 255. Esse tipo de dado serial é enviado com um bit inicial, depois os 8 bits, então um pouco de parada. O bit inicial está sempre na polaridade oposta ao nível de inatividade da linha. Na maioria das descrições, o nível de inatividade da linha é referido como "espaço" e o oposto como "marca". Portanto, o bit inicial está sempre na marca. O objetivo do bit inicial é fornecer sincronização de tempo para os bits restantes. Como os dois lados sabem quanto tempo dura, a única questão é quando é o início de um byte. O bit inicial fornece essas informações. O receptor basicamente inicia um relógio na extremidade anterior do bit de início e usa isso para saber quando os bits de dados estarão chegando.

Os bits de dados são enviados na ordem menos significativa, com a marca sendo 1 e o espaço sendo 0. Um bit de parada no nível do espaço é adicionado para que o início do próximo bit de início seja uma nova aresta e deixe um pouco de tempo entre bytes. Isso permite um pequeno erro entre o remetente e o destinatário. Se o receptor fosse um pouco mais lento que o remetente, mesmo que um pouco, ele perderia o início do próximo bit de início. O receptor redefine e inicia o relógio novamente a cada novo bit de inicialização, para que os erros de temporização não se acumulem.

Portanto, com tudo isso, você poderá ver que o primeiro rastreamento parece estar enviando pelo menos dois bytes, e o último se parece com talvez 5.

Ajudaria se você expandisse a escala de tempo dos rastreamentos. Dessa forma, você pode medir o que realmente é um pouco de tempo. Isso permitiria verificar se você realmente possui 9600 baud (104 µs / bit) e decodificar bits individuais de uma captura. No momento, não há resolução suficiente para ver onde estão os bits e, portanto, decodificar o que está sendo enviado.

Adicionado:

Apenas me ocorreu que seu sistema pode estar enviando os dados em ASCII em vez de binários. Não é assim que geralmente é feito, pois a conversão para ASCII no pequeno sistema consome mais recursos limitados, usa pouco a largura de banda e é fácil fazer a conversão no PC se você deseja exibir os dados para um usuário. No entanto, se suas transmissões forem caracteres ASCII, explicariam por que as seqüências têm mais de um byte, por que a segunda é mais longa ("255" tem mais caracteres que "0") e por que ambas parecem terminar no mesmo byte. O último byte é provavelmente algum tipo de caractere de fim de linha, que normalmente seria um retorno de carro ou um avanço de linha.

De qualquer forma, expanda a escala de tempo e podemos decodificar exatamente o que está sendo enviado.


1
O bit de parada (e sendo o oposto do bit de partida) também força uma vantagem no início de uma nova transmissão.
31511 stevenvh

@steven: Sim, percebi que deixei isso de lado ao reler minha resposta e a adicionei em uma edição, provavelmente ao mesmo tempo em que você estava escrevendo seu comentário.
21711 Olin Lathrop

4
Embora o envio de ASCII seja "ineficiente", ainda pode ser uma escolha muito boa. A maioria dos meus sistemas embarcados não apenas envia ASCII, mas também recebe comandos ASCII, tornando possível experimentar manualmente "conversando" com eles a partir de um programa terminal. O padrão SCPI (uma espécie de melhoria no GPIB, estendido a outras interfaces elétricas) é um método muito formal que funciona nesse sentido.
22811 Chris Stratton

4
Indo discordar totalmente . O Ascii usa uma quantidade tão pequena de código, até mesmo executando o bare metal em um pouco de 8 bits. Claro, você pode escrever um programa personalizado, mas o que acontecerá daqui a 10 anos, quando estiver perdido, e levaria uma máquina virtual para executá-lo, mesmo que pudesse ser encontrado? E, com certeza, qualquer programador que se preze pode invadir um terminal binário para fazer engenharia reversa de algo. Mas as interfaces legíveis por humanos valem bem a pequena sobrecarga na maioria dos sistemas críticos, mas limitados à memória e com desempenho severo. Além disso, se você tiver memória, poderá incorporar a saída de depuração com um ativado / desativado.
21911 Chris Stratton

2
Devo mencionar que eu comecei nas interfaces ASCII, pois era um requisito do cliente ... mas eu as mantive devido à sua utilidade. Eu poderia adicionar uma ideia como comando no firmware e testá-la em qualquer lugar da instalação. Sem ter que implantar uma atualização no cliente de configuração toda vez que eu publicava uma versão experimental de firmware com extras para investigar um problema que alguém estava tendo em um sistema complicado, do qual era apenas um módulo. No telefone com um cliente, eu poderia fazê-los ligar um terminal e orientá-los usando funções de teste de fábrica não publicadas.
22811 Chris Stratton

1

Você precisa conhecer todos os detalhes: a velocidade, se houver um bit inicial, o número de bits de dados, se houver um bit de parada e se houver um bit de paridade. Isso deve ser uma função de como o UART no microcontrolador está configurado.

Se o escopo Rigol não tiver uma opção de decodificação serial (muitos DSOs possuem), você poderá usar cursores X para auxiliar na decodificação. Coloque o primeiro cursor na borda anterior dos dados e mova o segundo cursor pelo fluxo de bits. O delta entre os cursores pode ser usado para determinar qual 'bit' você está passando o mouse sobre por aritmética simples. Ignore os bits de início / parada / paridade, obviamente.


Há sempre um bit de início e sempre pelo menos um bit de parada. Pode haver bits de parada extras, mas eles são indistinguíveis do tempo morto entre bytes. Os decodificadores mecânicos antigos às vezes precisavam de dois bits de parada para permitir tempo para o mecanismo reiniciar. Atualmente, quase sempre existem 8 bits de dados e nenhum bit de paridade, mas, como você diz, isso pode variar.
21711 Olin Lathrop
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.