Cómo leer datos en serie desde el osciloscopio

Primero, algo que Olin notó también: los niveles son lo contrario de lo que generalmente produce un microcontrolador:

Nadadequepreocuparse,veremosquetambiénpodemosleerlodeestamanera.Solotenemosquerecordarqueenelalcanceunbitdeinicioserá1yelbitdeparada0.

Acontinuación,tienelabasedetiempoincorrectaparaleerestocorrectamente.9600bitsporsegundo(unidadesmásapropiadasqueBaud,aunqueesteúltimonoesincorrecto)es104\$\mu\$sporbit,quees1/10deunadivisiónensuconfiguraciónactual.Acercaryestableceruncursorverticalenelprimerborde.Eseeselcomienzodetubitdeinicio.Muevaelsegundocursoracadaunodelosbordessiguientes.Ladiferenciaentreloscursoresdebesermúltiplosde104\$\mu\$s.Cada104\$\mu\$sesunbit,primeroelbitdeinicio(1),luego8bitsdedatos,eltiempototal832\$\mu\$s,yunbitdeparada(0).

Noparecequelosdatosdelapantallacoincidanconel0x00enviado.Deberíaverunbitde1estrecho(elbitdeinicio)seguidodeunnivelbajomáslargo(936\$\mu\$s,8bitsdedatoscero+unbitdeparada).
Lomismoparael0xFFqueestásenviando;deberíaverunnivelaltolargo(nuevamente936\$\mu\$s,estavezelbitdeinicio+8bitsdedatos).Asíqueesodeberíasercasi1divisiónconsuconfiguraciónactual,peroesonoesloqueveo.
Parecemásbienqueenlaprimeracapturadepantallaestásenviandodosbytes,yenlasegundacuatro,conlasegundaylaterceraelmismovalor.

guesstimates:

  

0b11001111=0xCF
  0b11110010=0xF2

    

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

editar
Olintienetodalarazón,estoesalgoasícomoASCII.Dehecho,eselcomplemento1deASCII.

  

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

    

0xF2~0x0D=[CR]

Estoconfirmaquemiinterpretacióndelascapturasdepantallaescorrecta.

edit2(cómointerpretolosdatos,apeticiónpopular:-))
Advertencia:estaesunalargahistoria,porqueesunatranscripcióndeloquesucedeenmicabezaCuandotratodedecodificarunacosacomoesta.Léalosolosiquiereaprenderunaformadeabordarlo.

Ejemplo:elsegundobyteenlaprimeracapturadepantalla,comenzandoconlos2pulsosestrechos.Comienzoconelsegundobyteapropósitoporquehaymásbordesqueenelprimerbyte,porloqueserámásfácilhacerlobien.Cadaunodelospulsosestrechosesaproximadamente1/10deunadivisión,porloquepodríaserde1bitdealtocadauno,conunbitbajoentreellos.Tampocoveonadamásestrechoqueesto,asíquesupongoqueessolounbit.Esaesnuestrareferencia.
Luego,despuésde101hayunperíodomáslargoenelnivelbajo.Seveaproximadamenteeldobledeanchoquelosanteriores,porloquepodríaser00.Elsiguientemáximoesnuevamenteeldobledeancho,porloqueserá1111.Ahoratenemos9bits:unbitdeinicio(1)más8bitsdedatos.Entonces,elsiguientebitseráelbitdeparada,perocomoes0noesvisibledeinmediato.Entonces,aljuntartodotenemos1010011110,incluidoslosbitsdeinicioyparada.Sielbitdeparadanofueracero,¡habríahechounamalasuposiciónenalgunaparte!
RecuerdequeunUARTenvíaelLSB(bitmenossignificativo)primero,asíquetendremosqueinvertirlos8bitsdedatos:11110010=0xF2.

Ahorasabemoselanchodeunbitsimple,unbitdobleyunasecuenciade4bits,yechamosunvistazoalprimerbyte.Elprimerperíodoalto(elpulsoancho)esligeramentemásanchoqueel1111enelsegundobyte,porloquetendráunanchode5bits.Elperíodobajoyelperíodoaltoquelosiguensontananchoscomoelbitdobleenelotrobyte,porloqueobtenemos111110011.Nuevamente9bits,porloqueelsiguientedeberíaserunbitbajo,elbitdeparada.Estábien,asíquesinuestraestimaciónescorrecta,podemosrevertirnuevamentelosbitsdedatos:11001111=0xCF.

EntoncesrecibimosunapistadeOlin.Laprimeracomunicaciónesde2bytesdelargo,2bytesmáscortosqueelsegundo.Y"0" también es 2 bytes más corto que "255". Así que probablemente sea algo como ASCII, aunque no exactamente. También tengo en cuenta que el segundo y tercer byte de "255" son los mismos. Genial, ese será el doble "5". ¡Lo estamos haciendo bien! (Debes animarte de vez en cuando). Después de decodificar "0", "2" y "5", observo que hay una diferencia de 2 entre los códigos de los dos primeros y una diferencia de 3 entre los últimos dos. Y finalmente, me doy cuenta de que 0xC_ es el complemento de 0x3_ , que es el patrón para los dígitos en ASCII.

Algo no está sumando. Sus señales parecen ser 3.3V pico a pico, lo que implica que están directamente fuera del micro. Sin embargo, los niveles de UART del microcontrolador son (casi) siempre altos y bajos activos. Tus señales se invierten a partir de eso, lo cual no tiene sentido.

Para obtener estos datos en una PC, se deben convertir a niveles RS-232. Esto es lo que un puerto COM de la PC espera ver. RS-232 está inactivo bajo y activo alto, pero bajo es inferior a -5V y alto es superior a + 5V. Afortunadamente, hay chips para eso que facilitan la conversión entre las señales UART de nivel lógico de microcontrolador típicas y RS-232. Estos chips contienen bombas de carga para generar los voltajes RS-232 de su fuente de alimentación de 3.3V. A veces, estos chips se denominan genéricamente como "MAX232" porque era un número de pieza para un chip temprano y popular de ese tipo. Necesita una variante diferente, ya que aparentemente está utilizando una potencia de 3.3V, no 5V. Hacemos un producto que es básicamente uno de estos chips en una placa con conectores. Vaya a enlace y mire el esquema para ver un ejemplo de cómo conectar un chip de este tipo.

Otra cosa que no se suma es que ambas secuencias parecen tener más de un byte, aunque usted dice que solo está enviando 0 y 255. Este tipo de datos en serie se envía con un bit de inicio, luego el 8 bits de datos, luego un bit de parada. El bit de inicio siempre está en la polaridad opuesta al nivel de inactividad de la línea. En la mayoría de las descripciones, el nivel de inactividad de línea se conoce como "espacio" y el opuesto como "marca". Así que el bit de inicio está siempre en la marca. El propósito del bit de inicio es proporcionar sincronización de tiempo para los bits restantes. Dado que ambas partes saben cuánto tiempo dura un bit, la única pregunta es cuándo es el inicio de un byte. El bit de inicio proporciona esta información. Básicamente, el receptor inicia un reloj en el borde inicial del bit de inicio, y lo usa para saber cuándo estarán llegando los bits de datos.

Los bits de datos se envían en el orden menos significativo, con la marca siendo 1 y el espacio es 0. Se agrega un bit de parada en el nivel de espacio para que el inicio del siguiente bit de inicio sea un nuevo borde, y para salir Un poco de tiempo entre bytes. Esto permite un pequeño error entre el remitente y el receptor. Si el receptor fuera más lento que el remitente, incluso un poco, de lo contrario se perdería el inicio del siguiente bit de inicio. El receptor se reinicia e inicia su reloj de nuevo cada nuevo bit de inicio, para que los errores de tiempo no se acumulen.

Por todo esto, debería poder ver que la primera traza parece estar enviando al menos dos bytes, y la última parece que tal vez 5.

Ayudaría si expandiera la escala de tiempo de las trazas. De esa manera podrías medir lo que realmente es un poco de tiempo. Eso le permitiría verificar que realmente tiene 9600 baudios (104 µs / bit) y permitirle decodificar bits individuales de una captura. Tal como está ahora, no hay suficiente resolución para ver dónde están los bits y, por lo tanto, descodificar lo que se está enviando.

Añadido:

Se me acaba de ocurrir que su sistema puede estar enviando los datos en ASCII en lugar de binario. No es así como generalmente se hace, ya que la conversión a ASCII en el pequeño sistema toma más recursos limitados, utiliza poco el ancho de banda y es fácil hacer la conversión en la PC si desea mostrar los datos a un usuario. Sin embargo, si sus transmisiones son caracteres ASCII que expliquen por qué las secuencias son más de un byte, por qué la segunda es más larga ("255" es más caracteres que "0"), y por qué ambas parecen terminar en el mismo byte. El último byte es probablemente una especie de final de línea, que generalmente sería un retorno de carro o un salto de línea.

De todos modos, amplíe la escala de tiempo y podemos decodificar exactamente lo que se está enviando.

Debe conocer todos los detalles: la velocidad, si hay un bit de inicio, el número de bits de datos, si hay un bit de parada y si hay un bit de paridad. Esto debería ser una función de cómo se configura el UART en el microcontrolador.

Si el alcance de Rigol no tiene una opción de decodificación en serie (muchos DSO sí), puede usar los cursores X para ayudar en la decodificación. Coloque el primer cursor en el borde inicial de los datos y mueva el segundo cursor a través del flujo de bits. El delta entre los cursores se puede usar para determinar a qué 'bit' se está desplazando por aritmética simple. Ignorar los bits de inicio / parada / paridad, obviamente.