Transformador de Baud Rate

[Fidel Martins]

Buena a todos.
Necesito cambiar el baud rate que sale del GPS a 9600 y vá al navegador plotter, que recibe a 4800.
El pic es el 12f675 y la RS232 hecha en codigo.
El desafio es recibir de cinco a siete sentencias con un ancho de 40 a 60 bytes (no confirmado), una pegada a la otra, ocupando la recepcion 450ms, sobrando 550ms.
De inmediato ya veo que será sacrificado un paquete...y por ai empieza...

[tsu_electronica]

interesante, lo que me pasa por la cabeza es que en niple se puede configurar por código 2 puertos para que cada uno trabaje a diferentes velocidades y eso parece que es sin problema lo que si creo es que el pic no tenga la memoria para recibir esos paquetes me parece que solo puede 30 o algo así hay que checar.

[remi04]

Si pudieses usar un pic con dos uart física tu puedes recibir a 9600 por una uart. Mientras estas recibiendo una sentencia completa, se estaría enviando simultáneamente la mitad de la anterior a 4800 por la otra uart. Luego en los 550 ms de reposo terminas de enviar la otra media sentencia que queda y así no pierdes ni una.

  Incluso en un pic con una sola uart física usando interrupciones haces el envío a 4800 por software.

[dogflu66]

Hola amigos; no quiero ser negativo, pero generar dos puertos serie por software con ese micro va a ser imposible.
Si tienes mucho tiempo entre tramas y suficiente memoria ram puedes crear una uart por software y un buffer donde almacenar la trama.
Posteriormente en la pausa que no recibes datos vaciar el buffer por otra uart por software.

Si dispones de un micro con una uart por hardware, puedes configurar una uart por software como entrada, y de inmediato enviar el byte recibido por la uart por hardware (esta ocupa un tiempo despreciable de proceso), de esta manera te ahorras el buffer de entrada y el programa sería muy simple.
También puedes reprogramar la uart cada vez y no usar el puerto por software, todo de pende de la memoria disponible.

[dogflu66]

Con este MCU moderno de 8pin casi seguro puedes realizar lo que quieres PIC12F1840.
No lo he utilizado en ningún proyecto, pero si he realizado practicas con el, y es una verdadera bestia en miniatura.
En España se puede conseguir fácilmente por menos de 2€ en todos sus formatos.

[Fidel Martins]

Solo ahora estoy leyendo sus respuestas. Muchas gracias a todos.
Me antecipe y hice un codigo con dos RS 232/codigo, donde separo una sola sentencia (por su inicial "$GPGLL), asi que llega, la voy guardando en la eeprom y cuando termina, la envio por la segunda RS 232.
Ojala funcione con solo esta sentencia.
Pero de qualquer forma, lo mas inportante, es el desafio en hacer...

[Fidel Martins]

Estoy probando el codigo en MPLAB y percibo que para grabar un dato (byte) en la eeprom, se demora una eternidad, con el reloj a 4Mhz, gasta mas de 4ms para limpiar el bit "eecon1,wr"...
Con esse tiempo queda inposible hacer la tarea, puez para cargar un byte gasto 920us.

[DominusDRR]

Estoy probando el codigo en MPLAB y percibo que para grabar un dato (byte) en la eeprom, se demora una eternidad, con el reloj a 4Mhz, gasta mas de 4ms para limpiar el bit "eecon1,wr"...
Con esse tiempo queda inposible hacer la tarea, puez para cargar un byte gasto 920us.

No tengo ni idea de como es tu código (tal vez debas compartirlo) y lo que diga, tal vez no tenga sentido, pero ¿Por qué no guardas todos los bytes que llegan en la memoria RAM?

Luego, cuando finalice la transacción de información procedes a guardar el contenido de la RAM a la EEPROM.

[elreypic2]

No conozco Niple, pero tal vez esté usando mucha memoria ram y no quede suficiente para crear el buffer de recepción de 60 bytes. Por lo que sólo quedarían 4 bytes de ram para implementar los dos puertos seriales.
Ya que no son simultáneos, siendo uno de recepción a 9600 bps y el de transmisión a 4800 bps. Lo ideal sería usar assembler y tal vez así sea posible implementar el código en este microcontrolador con tan poco recursos.
El problema de usar el eeprom como buffer de recepción es que la eeprom tiene un número maximo de escrituras y una vez alcanzado, la eeprom fallará y por lo tanto también la recepción/transmisión de datos.

elreypic

[Fidel Martins]

No tengo ni idea de como es tu código (tal vez debas compartirlo) y lo que diga, tal vez no tenga sentido, pero ¿Por qué no guardas todos los bytes que llegan en la memoria RAM?

Luego, cuando finalice la transacción de información procedes a guardar el contenido de la RAM a la EEPROM.

No hay RAM suficiente, por eso eligi usar la EEPROM.
Los datos son apenas guardados para enviarlos enseguida.

[Fidel Martins]

No tengo ni idea de como es tu código (tal vez debas compartirlo) y lo que diga, tal vez no tenga sentido, pero ¿Por qué no guardas todos los bytes que llegan en la memoria RAM?

Luego, cuando finalice la transacción de información procedes a guardar el contenido de la RAM a la EEPROM.

No hay RAM suficiente, por eso eligi usar la EEPROM.
Los datos son apenas guardados para enviarlos enseguida.

Si, justamente eso...poca RAM
De la EEPROM no funcionar por mucho tiempo, es cierto, pero el problema que expongo, es el tiempo que gasta para grabar un dato.

[Eduardo2]

Buena a todos.
Necesito cambiar el baud rate que sale del GPS a 9600 y vá al navegador plotter, que recibe a 4800.
....

¿No es al revés?  Si el GPS cumple la norma NMEA 0183  debe salir a 4800.

[Fidel Martins]

No, no es asy.
La mayoria de los modulos antena/gps, salen a 9600.

[Fidel Martins]

 

Captura de tela 2023-07-08 121645.png
(71.69 kB, 1017x906 - visto 286 veces)

codigo en prueba.

Captura de tela 2023-07-08 121645.png
(71.69 kB, 1017x906 - visto 286 veces)

[DominusDRR]

No hay RAM suficiente, por eso eligi usar la EEPROM.
Los datos son apenas guardados para enviarlos enseguida.

La escritura de la EEPROM es un cuello de botella en la latencia de un sistema con un microcontrolador.

Tal vez deberías escribir tu código en ensamblador, ya que un lenguaje alto nivel crea más código y ocupa más memoria RAM.

La otra opción es ocupar un microcontrolador de mejores características.