ATMEGA UART transmisión con control de flujo

Navega tus respuestas
2

Fondo

Estoy usando un ATmega328P para enviar datos a otro dispositivo a una alta velocidad de transmisión (230400). El dispositivo al que estoy enviando datos admite el control de flujo y genera la señal RTS cuando necesita mantener la transmisión. El problema es que el dispositivo espera que detenga la transmisión inmediatamente una vez que se haya confirmado el RTS.

El ATmega328P tiene un búfer de transmisión (UDR) y un registro de desplazamiento desde el cual los datos se envían a la línea TX. Como el ATmega328P no admite el control de flujo en hardware, lo estoy implementando en software. Antes de enviar (antes de escribir a UDR) estoy comprobando RTS y esperando a que se detenga, pero aparentemente esto no es suficiente porque todavía se están enviando los datos en el búfer de transmisión y el registro de desplazamiento y todavía se podría enviar un byte completo after RTS se afirma cuando el ATmega328P vacía sus buffers.

Aparentemente, deshabilitar el transmisor cuando se valida RTS (establecer TXEN en cero) no ayuda, ya que no entrará en vigencia hasta que se completen las transmisiones en curso y pendientes, de acuerdo con documentation sección 19.6.5.

Una solución alternativa podría ser esperar hasta Transmit Complete (TXC) antes de enviar cada byte, pero esto afectaría la velocidad de datos, ya que no estoy enviando el flujo de bytes de forma consecutiva incluso cuando RTS no está confirmado (I ' m comienza a enviar un nuevo byte solo después de que el anterior fue enviado por completo).

Mi pregunta es:

Con el ATmega328P, ¿hay una manera de admitir el control de flujo de RTS en el transmisor mientras disfruta de la canalización provista por el búfer de transmisión y el registro de desplazamiento?

    
pregunta Amir Gonnen

1 respuesta

3

Parece que tiene dos problemas básicos, un dispositivo externo mal diseñado y que está tratando de hacer que el hardware inapropiado haga un trabajo para el que no está destinado.

Primero, ¿este otro dispositivo realmente no requiere absolutamente más bytes después de que se valora RTS? Eso sería muy inusual. Es muy común que los transmisores vacíen un pequeño búfer antes de obedecer RTS, por lo tanto, a menos que el otro ingeniero no supiera lo que estaba haciendo, el dispositivo debería poder tolerar algunos bytes más. Tal vez no pueda manejar el caso "con todas las funciones" de 16 bytes más, pero no permitir 2-4 bytes más es un mal diseño.

Segundo, dado que debe dejar de transmitir más rápido que el tamaño del búfer de salida, eligió el hardware incorrecto. No estoy familiarizado con esa línea de micros, pero seguramente esto está en la hoja de datos. Veo tres opciones:

  1. Obtenga un micro que tenga una entrada RTS y que se detenga en el siguiente límite de byte cuando se active. La mayoría de los UART en micros no tienen esta característica adicional, pero ciertamente hay algunos que sí lo tienen. Sé que algunos PIC 33F pueden hacer esto porque los he elegido en parte para esta función. Mira alrededor de la línea de productos Atmel. Pueden tener algunos micros con esta característica también.

  2. Use un UART externo que realice el control de flujo de hardware en el nivel de bytes.

  3. Utilice el UART existente con más intervención de software. No podrá usar el búfer interno, y tendrá que esperar hasta que se envíe un carácter, verifique RTS y luego escriba el siguiente carácter en el UART. Esto se facilitará si el UART puede interrumpir cuando está vacío, no solo cuando hay espacio en el búfer de salida.

Ninguna de estas compensaciones puede ser lo que quieres, pero ese es el costo de la mala arquitectura. Repárelo a continuación, o responda ahora si es realmente importante. El mundo no siempre tiene una respuesta mágica solo porque tu jefe lo quiere ahora o porque te has metido en un rincón.

    
respondido por el Olin Lathrop

Lea otras preguntas en las etiquetas

¿Por qué no funciona un transistor de conmutación en este circuito? Resistencia del emisor en un amplificador de emisor común