¿Cómo puedo decodificar por software este flujo serie de 260KHz?

Question

He sondeado este flujo serie que sale de un controlador de marcador y parece un protocolo propietario. ¿Cómo puedo tratar de decodificar esto por software?

El bit de inicio tiene una longitud de 7,8us. Todos los bits de datos duran unos 3,85us, lo que da una velocidad de bus de unos 260KHz. Un bit lógico HIGH comienza con un periodo HIGH de 3,1us y luego un LOW de ~800ns. Un bit LOW lógico es lo mismo pero los periodos se intercambian. Cada paquete se compone de 255 bits, por lo que se envía aproximadamente un paquete cada milisegundo.

He pensado en disparar en el flanco ascendente y luego leer el nivel del pin después de un breve retraso, pero no creo que un esquema basado en interrupciones funcione tan bien debido a la sobrecarga.

¿Alguna idea?

Answer 1

Dices que la sobrecarga del manejo de las interrupciones sería demasiado alta, pero no creo que eso sea necesariamente cierto. Un microcontrolador barato puede no ser capaz de hacer mucho procesamiento útil del flujo de datos, pero debería ser lo suficientemente potente como para servir de convertidor ad-hoc.

Tomemos un chip AVR como ejemplo: el ATmega328P que sirve como núcleo de la placa de desarrollo Arduino. A la máxima velocidad de reloj de 20MHz, se obtienen 77 ciclos de reloj por bit. Según la hoja de datos (página 15) se necesitan unos 7 ciclos de reloj para entrar en un ISR y 4 ciclos para salir.

Suponiendo que pasas la mitad de cada bit de datos en un bucle de giro esperando el momento adecuado para muestrear la entrada, te quedan unos 27 ciclos por bit fuera del manejador de interrupciones. La mayoría de las instrucciones del AVR son de un solo ciclo, por lo que debería ser tiempo suficiente para encuadrar los bits en bytes y meterlos en un enlace SPI a tu procesador anfitrión.

(He pasado por alto el problema de la detección de los bits de inicio. Una opción es reiniciar uno de los temporizadores incorporados al comienzo de cada bit, y utilizar la salida comparar para determinar si el intervalo entre dos bordes ascendentes supera un umbral).

Answer 2

He decodificado señales como esta con AVRs. Lo hice con una interrupción de cambio de pin y un temporizador de funcionamiento libre. También se podría hacer con una entrada de captura en el temporizador, pero también estaba despertando en los datos por lo que necesitaba la capacidad de detección asíncrona.

Básicamente lo que hice fue que cada vez que recibía una interrupción por cambio de pin, miraba la hora y el estado del pin. Entonces podía decir "el pin estaba 3us alto" o "el pin estaba 3us bajo" y desplazar el 1 o el 0 a una palabra de datos de entrada. Usé un @#define@ para determinar el tiempo de umbral de un alto o bajo y determiné empíricamente un buen valor para usar. Mis palabras de datos recibidas tenían 33 bits de longitud, así que después de contar 33 bits marqué la recepción como completa y marqué la rutina principal para verificar y decodificar la palabra de datos.

Para mayor robustez, también puse a cero un temporizador que tenía un periodo de unos 10ms. Si esa interrupción se disparaba significaba que debía reiniciar mi subsistema de recepción ya que no había datos entrando y mi contador de bits no había contado suficientes datos para considerar el mensaje completo.

Answer 3

Una forma de decodificar esto sería invertirlo y luego alimentarlo a una UART que esté configurada para 2,6 Mbps (un poco extremo, pero algunas UARTs pueden configurarse tan alto).

El flanco ascendente de cada pulso se convertiría en un flanco descendente -un bit de inicio- para la UART, y cada tipo de pulso produciría un patrón de datos único en el receptor de la UART: un "1" se convertiría en 0x80, un "0" se convertiría en 0xFE, y un "bit de inicio" se convertiría en 0x00 (y posiblemente causaría un error de "sobrecarga"). El firmware convertiría estos valores de bytes en bits y luego decodificaría el protocolo según corresponda.

Es posible que puedas configurar la UART a 1,3 Mbps y recibir dos de los pulsos de señal por byte - la decodificación se vuelve un poco más complicada, pero sólo tendrías que lidiar con la mitad de la tasa de interrupción.

• 0x00 → impulso de inicio
• 0x7F → 0 seguido de 0
• 0x0F → 0 seguido de 1
• 0x74 → 1 seguido de 0
• 0x04 → 1 seguido de 1

---

Un enfoque completamente diferente sería utilizar un par de multivibradores monoestables con disparo posterior . Uno se ajustaría a un periodo de aproximadamente 1,9 µs; crearía un borde de reloj en el centro de cada bit. El otro se ajustaría a un periodo de unos 5 µs; detectaría el pulso de "inicio".

Entonces conectarías estas señales a un puerto esclavo SPI de tu micro: la señal de datos original a MOSI, la señal de reloj a SCLK y la señal de inicio a SSEL. La interfaz SPI recogería 8 bits a la vez, y los entregaría al firmware a una velocidad de unos 32 kB/seg.