Problemas relacionados con los módulos transceptores Bit-banging

Tengo dos módulos de transceptor de infrarrojos de TFDU4101-TR3 en dos placas separadas, cada una conectada al microcontrolador ATMega164PA . Para controlar estos transceptores se necesita un endec que no he usado en mi diseño debido a restricciones presupuestarias.

Entonces, lo que estoy tratando de hacer es golpear un poco. RX y TX siguen el estándar normal, RX está activo bajo y TX está activo alto. Estoy alternando el pin TxD uno 'Tablero A' 50 veces a 5 Khz para enviar 50 pulsos al receptor. En la 'Placa B' he implementado una interrupción de cambio de PIN que técnicamente debería recibir 100 pulsos (2 pulsos por cada pulso de transmisión que recibe). Este no es el diseño final, solo estoy aprendiendo y experimentando cómo transmitir datos de una placa a otra.

Ahora, el problema es que cuando envío 50 pulsos de la placa A a la placa B, no obtengo 100 pulsos, sino que a veces obtengo 90 u 81 o 98. En resumen, no obtengo la cantidad de pulsos deseada. ¿Hay algo mal con mi enfoque?

Por favor, hágamelo saber si se necesita más información.

Respuestas (2)

El enfoque general suena bien, pero debe tener cuidado de no exceder la longitud máxima del pulso de transmisión. Según la hoja de datos, 20 uS es una longitud de pulso típica y, si se excede demasiado, puede ver que hará que el controlador LED se deshabilite:

Esta entrada Schmitt-Trigger se utiliza para transmitir datos en serie cuando SD es bajo. Un circuito de protección en el chip desactiva el controlador LED si el pin TXD se activa durante más de 50 μs (máx. 300 μs).

Entonces, suponiendo que sus 5 KHz sean una onda cuadrada, habrá excedido la duración del pulso. Una vez que se solucione, las cosas deberían ser más confiables, aunque la última vez que usé un transceptor IrDA recibía o dos por ciento de los paquetes que estaban dañados, por lo que vale la pena considerar la detección de errores dependiendo de lo que esté haciendo.

También vale la pena señalar que algunos microcontroladores Atmel (y otros) tienen un modo USART que cumple con el tiempo IrDA, aunque después de un vistazo rápido a la hoja de datos, esa parte en particular no parece tener esa función.

Gracias por tu respuesta PedroJ. Tiene razón acerca de no poder usar USART. Lo conecté al micro a través de USART pero estaba recibiendo basura del otro lado. La hoja de datos no es clara al respecto y tiene una nota muy pequeña que dice "se requiere un endec para la interfaz con USART", lo cual es muy molesto. En lo que respecta a la duración típica del pulso, 20uS es aproximadamente 50 KHz, lo que significa que la velocidad máxima a la que se puede alternar el transmisor es de 50 KHz, pero la frecuencia a la que estoy corriendo es de 5 KHz.
Además, acabo de descubrir que tengo pérdida de paquetes. Con una versión revisada de mi código, recibo la misma cantidad de pulsos en el otro tamaño del transmisor, pero a veces hay pérdidas aquí y allá.
@David, IrDA puede ir a velocidades más altas, pero supongo que esa cantidad típica es buena para seguir cuando no necesita nada más rápido. Podría ser algo para jugar para ver qué diferencia hace en la práctica, para el proyecto que estaba haciendo (que tenía que conectarse a una PC) encontré que 57600 parecía ser la mejor velocidad de transmisión estándar.
¿Cómo definirías 'mejor'? ¿Es eso en términos de menor pérdida de paquetes o mayor alcance o algo más?
@David sí parecía tener el rango más bajo de pérdida de paquetes/mejor, pero era un fabricante diferente, por lo que puede obtener resultados diferentes. Era algo en lo que la transferencia de datos era de solo 50 KB o así que la velocidad no era un gran problema.
Lo tengo funcionando, lo que estoy haciendo en este momento es algo de novato que solo envía un tren de pulsos cada uno a intervalos regulares, por lo que no se implementa PWM en este estado y obtengo la misma cantidad de paquetes en el otro extremo pero de vez en cuando los paquetes no llegan al otro extremo. ¿Cómo implemento la comprobación de errores en este caso? ¿Alguna sugerencia?

El TFDU4101 está diseñado para transmitir datos a 115,2 kbit/s. Esa es una de las velocidades estándar de IrDA. Así que el dispositivo está optimizado en torno a eso.

Entonces, la duración de un bit es de aproximadamente 1,000,000us/1152.kbit/s = 8.7us

La hoja de datos dice que el ancho de pulso RXD (recibido) típico se especifica como 2.2us, lo que significaría 4 pulsos por bit de una señal portadora de aproximadamente 460,800kHz. Así que parece que suma.

No tienes que enviar datos a esa velocidad. Sin embargo, trate de usar una modulación de portadora base similar, y luego el chip no luchará contra usted. Utilice un número entero de ciclos de esa frecuencia portadora para enviar sus datos, con un número distintivo de ciclos para representar 0 y 1, y debe ser razonablemente sólido y confiable. Aunque es posible que también deba usar la detección de errores.

460,800kHz es una velocidad bastante alta para bit bang, aunque es factible. Puede comenzar intentando enviar datos de esa manera.

Intento que la señal de modulación de la portadora base se realice en el hardware para reducir la carga en la CPU.

La forma en que hago la transmisión es configurar un temporizador MCU para estar lo más cerca posible del tiempo del ciclo de modulación base y usarlo para controlar el LED del transmisor. Algunos de los temporizadores de ATmel le permiten establecer el conteo máximo, y con un valor de captura/comparación de 1/2 conteo máximo, generará una onda cuadrada. (Una alternativa es dividir el reloj, usando un valor de preescala)

Luego uso el valor del registro de captura/comparación (0 o máximo, según el esquema de modulación) para conectar esa señal con los datos. La señal de la portadora base se generará correctamente usando un valor de comparación de 1/2 conteo máximo, incluso si mi software está un poco ocupado.

Lo he picado un poco y ahora recibo la señal por el otro lado pero hay pequeños (aunque muy raros) que los paquetes no llegan al otro extremo. Un problema con el bit bang es que es difícil implementar un pulso alto largo o un pulso bajo largo porque tiene que coordinarse con el temporizador. En segundo lugar, me gusta la idea de mantener la modulación de la portadora separada de la CPU, pero debido a limitaciones de espacio no puedo implementar eso.
@David Norman: no entiendo "Me gusta la idea de mantener la modulación de la portadora separada de la CPU, pero debido a limitaciones de espacio no puedo implementar eso". Uso uno de los temporizadores dentro de la MCU (he editado mi respuesta porque no estaba claro), por lo que no ocupa más espacio en el tablero; toda la electrónica está dentro de la MCU existente si hay un temporizador libre. Esto debería reducir el número de conflictos entre la modulación de la señal y otros eventos.
Oh k, creo que entendí mal. Pensé que sugeriste usar componentes externos como un temporizador IC
@DavidNorman: me disculpo por eso, mi respuesta fue ambigua. Espero haberlo arreglado ahora. Un temporizador interno que genera la modulación de la portadora ahorra bastante trabajo y facilita un poco la modulación del 0 o el 1. Aún mejor si tiene dos temporizadores internos disponibles.
Problemas relacionados con los módulos transceptores Bit-banging
RespuestasAquíPolítica de privacidad1y, 0v