¿Cómo descodificaré por software este flujo serial de 260KHz?

Usted dice que la sobrecarga del manejo de interrupciones sería demasiado alta, pero no creo que eso sea necesariamente cierto. Es posible que un microcontrolador barato no pueda realizar un procesamiento muy útil del flujo de datos, pero debería ser lo suficientemente potente como para ser un convertidor ad hoc.

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

Suponiendo que gasta la mitad de cada bit de datos en un bucle giratorio esperando el momento adecuado para muestrear la entrada, queda aproximadamente 27 ciclos por bit fuera del manejador de interrupciones. La mayoría de las instrucciones de AVR son de un solo ciclo, por lo que debería ser suficiente tiempo para enmarcar los bits en bytes y colocarlos en un enlace SPI a su procesador host.

(He pasado por alto el problema de la detección de bits de inicio. Una opción es restablecer uno de los temporizadores incorporados al comienzo de cada bit, y usar la comparación de salida para determinar si el intervalo entre dos flancos ascendentes excede un umbral.)

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 podría hacerlo con una entrada de captura en el temporizador, pero también me estaba despertando con 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 de cambio de pin, observaba la hora y el estado del pin. Entonces podría decir "el pin estaba demasiado alto" o "el pin estaba 3us bajo" y cambiar el 1 o el 0 en una palabra de datos de entrada. Utilicé un @ # define @ para determinar el tiempo de umbral de un valor alto o bajo y determiné empíricamente un buen valor para usar. Mis palabras de datos recibidas tenían una longitud de 33 bits, por lo que, después de contar 33 bits, señalé la recepción como completa y la rutina principal para verificar y decodificar la palabra de datos.

Por robustez, también reinicié un temporizador que tuvo un período de aproximadamente 10 ms. Si esa interrupción se activó, eso significaba que debía restablecer mi subsistema de recepción, ya que no ingresaban datos y mi contador de bits no contaba con suficientes datos para considerar el mensaje completo.

Una forma de descodificar esto sería invertirlo y luego alimentarlo a un UART que está configurado para 2.6 Mbps (un poco extremo, pero algunos UART se pueden establecer a este nivel).

El flanco ascendente de cada pulso se convertirá en un flanco descendente, un bit de inicio, para el UART, y cada tipo de pulso producirá un patrón de datos único en el receptor UART: un "1" se convertirá 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" saturación "). El firmware convertiría estos valores de bytes en bits y luego decodificaría el protocolo según corresponda.

Es posible que pueda configurar el UART a 1.3 Mbps y recibir dos de los pulsos de señal por byte: la descodificación se vuelve un poco más complicada, pero solo tendría que lidiar con la mitad de la tasa de interrupción.

• 0x00 → pulso 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 retractables . Uno se establecería en un período de aproximadamente 1,9 µs; crearía un borde de reloj en el centro de cada bit. El otro se establecería en un período de aproximadamente 5 µs; detectaría el pulso de "inicio".

Luego conectaría estas señales a un puerto esclavo SPI en su 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 recopilaría 8 bits a la vez y los entregaría al firmware a una velocidad de aproximadamente 32 kB / seg.