Cómo sondear UART mientras se procesan muchas otras cosas

2

Tengo un dispositivo GPS del que necesito extraer datos (las cadenas NMEA). Sin embargo, muchas veces por segundo mi MCU estará ocupada procesando otra cosa. ¿Hay alguna forma de "pausar" una señal UART / RS232 TTL o almacenarla mientras mi MCU hace cosas? Estoy viendo un dsPIC33FJ128GP802 o un AT32UC38x.

El procesamiento de mi OSD no se puede interrumpir, por lo que las interrupciones están fuera.

    
pregunta Thomas O

8 respuestas

5

Dos cosas.

  1. Hazlo para que tengas un búfer y el interrumpe solo pone en cola los datos en ella hasta que tenga tiempo. Hazlo así que el análisis de la cadena GPS es impulsado por interrupciones.
  2. he ayudado 5 Diferentes personas hacen esto. Esto es especialmente sencillo cuando solo necesitas una pequeña parte de la cuerda, como posición.

Puedo entrar en más detalles sobre cualquiera de los métodos si se requiere más claridad.

Nota al margen para microchip. Creo que su asistente para el compilador c18 (no he usado mucho el c30 todavía) le dará una biblioteca para manejar los datos de UART para usted.

¿Tiene otras interrupciones que nunca pueden retrasarse?

Si todo el controlador de pantalla está hecho en interrupciones, ¿no puedes simplemente ponerlo en una interrupción de nivel superior?

Esto significa que siempre que deje su interrupción, la interrupción de datos de RX tiene tiempo para poner los datos en una cola. Esto también significa que cada vez que se activen sus otras interrupciones obtendrán la prioridad que espera.

Luego coloque en su bucle de control principal que no esté controlado por interrupciones, el procesamiento de sus datos GPS. Esto mantiene las cosas bien compartimentadas. Recuerde que en la mayoría de las velocidades en baudios de GPS tiene mucho tiempo para extraer caracteres de la cadena de caracteres, ya que 4800 o 9600 baudios son lentos ...

    
respondido por el Kortuk
6

Creo que parte de la familia dsPIC tiene soporte DMA en el periférico MSSP, que permitirá el almacenamiento en búfer del flujo de entrada sin la intervención de la CPU hasta un punto, limitado por la memoria disponible.

Use una interrupción para procesar los datos GPS en partes, solo asegúrese de que la interrupción de su trabajo de procesamiento de video esté configurada en una prioridad más alta para que pueda interrumpir la interrupción del manejo del GPS.

    
respondido por el Mark
4

Parece que realmente necesita tener su PIC dedicado a la pantalla, 80-90% de uso de CPU es mucho. Veo algunas similitudes entre una computadora y su tarjeta de video. Creo que deberías considerar dividir tu proyecto en 2 PIC, 1 manejará todo el video (como una tarjeta de video) y el otro manejará cualquier otro procesamiento. Este segundo PIC puede tener alguna configuración de control de flujo entre el PIC de video, de modo que el PIC de video le permite saber cuándo tiene tiempo libre de CPU. Tan pronto como su segundo PIC vea que hay tiempo adicional, se le enviarán los datos.

Adición: El paquete GPS probablemente incluya mucha más información que lo que necesita su pantalla, su PIC separado puede "limpiar" los datos para obtener exactamente lo que quiere / necesita.

Además, si su segundo PIC no está haciendo mucho, probablemente pueda salirse con un PIC muy barato (sub $ 3). Probablemente este costo valga la pena el tiempo que ahorrará en codificación y depuración en un solo PIC.

    
respondido por el Kellenjb
3

Otra posible razón para ir con el chip Propeller que se discutió en other thread: tiempo incorporado para el video, y puedes usar un engranaje separado para RS232 sin afectar el video.

Parece que el AT32UC3B1256 también tiene una capacidad DMA periférica, por lo que puede recibir datos del GPS sin utilizar interrupciones.

    
respondido por el tcrosley
3

Realicé la superposición de video en una aplicación que requirió sondeo durante la visualización de datos. Si tiene un FSR de repuesto disponible, inserte:

  btfsc  INTCONx,RCIF   ; I forget which INTCON it's in
   movff RCREG,POSTINC2 ; Or whichever FSR is free  

al menos una vez cada 16 líneas (puede ser más conveniente hacerlo en cada línea). Sólo tres ciclos por línea. Si no tiene un FSR de repuesto disponible, pero su código de pantalla se expande en lugar de en bucle, entonces al menos una vez cada dieciséis líneas debe usar:

  movff  INTCONx,SerStatus+N  ; N=0 for the first one, 1 for the next, etc.
... and then (not necessarily immediately)
  btfsc  SerStatus+N
   movff RCREG,SerData+N

a un costo de tres ciclos en una línea y dos en otra; al final de la pantalla:

  lfsr   0,SerData
  btfsc  SerStatus+0
   movff SerData+0,POSTINC0
  btfsc  SerStatus+1
   movff SerData+1,POSTINC0
  btfsc  SerStatus+2
   movff SerData+2,POSTINC0
  ...
  movlw  (SerData & 255)
  subwf  FSR0L,w
  ; W will now hold number of bytes received
  ; Data will be in SerData+0 to SerData+(W-1)

El truco es no preocuparse por averiguar qué hacer con los datos mientras se muestra la pantalla. Simplemente tíralo a algún lugar y resuélvelo más tarde.

    
respondido por el supercat
2

Suponiendo que su unidad GPS emite cadenas NMEA a 4800bps, debería poder encontrar algunos ciclos de repuesto en su generador de video para decodificar un flujo de bits en serie.

En su defecto:

  • Si su unidad de GPS admite el control de flujo de hardware, es posible que pueda repararlo entre marcos o cuando su dispositivo esté inactivo

  • Otra opción sería un puente externo SPI / I2C a UART. Algunos de estos dispositivos tienen FIFO de tamaño razonable, lo que le permite almacenarse fuera de su PIC. Nuevamente, pruébelo durante su tiempo de inactividad

respondido por el Toby Jaffey
2

4800 baudios es un carácter cada 2 ms. Esta es la edad de un perro para la mayoría de los microcontroladores (PIC incluidos) y no debería tener NINGÚN problema para recopilar los datos del registro de tenencia de UART. Recuerde que incluso el UART más simple tiene un FIFO de 2 caracteres incorporado (el registro de espera y el registro de desplazamiento). Si no puede encontrar algunos ciclos cada 2 ms para elegir un personaje, entonces necesita encontrar un procesador más robusto, uno con FIFO o dividir el trabajo como lo han mencionado otras personas.

El dsPIC que mencionó tiene FIFO de 4 bytes en el UART y también tiene capacidad DMA. Si bien el 90% es una gran carga del sistema para OSD (¿está seguro de que está haciendo su OSD de la manera más eficiente posible?) No sé por qué tendría problemas para extraer un flujo NMEA de 4800 bytes con esta carga del sistema . Faltar en la actualización de GPS impar probablemente tampoco afectará mucho a tu aplicación.

    
respondido por el akohlsmith
0

La mayoría de los dispositivos serie implementan algún tipo de 'control de flujo' == esto es a través de cables adicionales (RTS 'Solicitud de envío', CTS 'Borrar para enviar') un 'apretón de manos' que permite que el dispositivo receptor establezca CTS hola lo para suspender la transmisión ..

... O (para aquellos dispositivos que usan solo líneas RxD / TxD) 'control de flujo de software' (== les envía un código ASCII específico para que diga 'dejar de enviar' y otro para que diga 'ok, comience de nuevo ahora ')

Busque 'Control de flujo' en la hoja de datos de su GPS ...

    
respondido por el SteveB

Lea otras preguntas en las etiquetas