Para Jorge Cano, Sobre 232 por USART

[Mike79]

Jorge Cano, tengo una pregunta.

Por que si le pido a Niple que envie un dato por USART, hace una espera interna?.

Es que veo que Niple incluye algo como esto despues de enviar un dato por USART.

rs232_tc6_9600_eperar
   btfss pir1,txif
   goto rs232_tc6_9600_eperar

Según entiendo, esto lo que hace, es que espera a que el dato, efectivamente se ha enviado.

Pero se supone que estoy usando el USART, para que envie el dato de forma asincronica.
NO deberia hacer esta espera. Ya que la idea es pedirle al USART que lo envie y continuar nosotros con el codigo.
De lo contrario estoy pidiendole al micro que lo envie y esperando a que termine para continuar (como si fuera sincronico).

Estoy trabajando en Niple v 5.2.3 con un micro 16F876.

Me interesa saber si esta espera la realizas por que en el pasado tuviste problemas enviando datos uno tras otro?

Esto en parte causa el problema que tengo con la interupción por fin de tranmisión de USART (Ver post anterior).
Ya que estando en este ciclo, la interrupción es activada, y dentro de la interupción mando a invocar esta rutina otra vez.
Ocacionando que la segunda vez, la interrupción no sea invocada, y regresando enviando solo 2 datos.

La solución que he encontrado hasta ahorita, es hacer mis propias rutinas de 232 en modo experto y olvidándome de las
rutinas de niple de envio de datos por 232, y parece que eso me ha dado cierto resultado, aunque no a 100% como lo esperaba,
pero sigo trbajando en eso.

Gracias por tu respuesta.
-
Mike79

[blackcat]

Creo que la espera se hace para no provocar sobre escritura en el registro TX ... y asi evitar algun error ... me refiero en el caso que debes enviar una cadena de caracteres y no solo un carácter ...

No entendí mucho lo que quieres hacer ... creo que lo que intentas es que mientras el micro está enviando un dato tener la habilidad de procesar otra rutina ... cuando se de la interrupcion de fin .. enviar el siguiente dato y asi sucesivamente .... esto es algo parecido a la filosofía de un RTOS.

En el modo experto la transmisión es efectiva con el simple hecho de escribir un dato en el registro TX ... Yo solo usaria las rutinas del NIPLE para configurar el USART .. de ahi en adelante todo lo manejaría como se haría en ensamblador ... lastima!!    porque no se aprovecha todo el potencial de NIPLE; sin embargo, la flexibilidad es mas importante y no queda mas remedio que hacerlo paso a paso con instrucciones en ensamblador (esas de color amarillo!!).

Saludos!

[Mike79]

creo que lo que intentas es que mientras el micro está enviando un dato tener la habilidad de procesar otra rutina ... cuando se de la interrupcion de fin .. enviar el siguiente dato y asi sucesivamente .... esto es algo parecido a la filosofía de un RTOS.

Si, eso es exactamente lo que deseo hacer.
Y precisamente eso hice, enviar a escribir el registro directamente en modo experto, y tambien configure el USART desde codigos en ensamblador (usando bloquecitos amarillos).

La desventaja es que si cambio la velocidad del cristal, tengo que modificar la rutina de configuración (Niple calcula los valores por uno).

Yo creo que Niple hace mal es NO ADVERTIRTE que el modo por USART no es asincronico como deberia o como uno supondria
Me hubiera evitado varias pruebas infructuosas.

Saludos!
-
Mike79

[jorgecano]

Hola Mike,

Estuvimos viendo la maera de automatizar esto de enviar varios datos por medio de la interrupcion por TX.

El problema que tenemos es que el proceso de envio de los bytes nos queda separado en 2 bloques diferentes:
1 bloque en el programa principal (o cualquier rutina) para iniciar la transmision enviando el primer byte y activar la inte por TX.
El segundo bloque deberia estar dentro de la inte por TX y enviaria el resto de los bytes (contaría los bytes, y seleciconaría automaticamente que byte envia segun un contador automatico, dependiendo de los registros seleccionados).

Todo esto se puede automatizar completaemnte.

El problema estaría al querer editar el bloque, no tendrías todos los datos en un solo bloque (como la transmisión sin interupción).
Tendrias que editar los 2 bloques por separado.

¿Uds. Piensan que esto seria mas comodo?

Saludos
Jorge.

[RICHI777]

Hola, de metido nomas que opino, normalmente las transmiciones por UART deben ser por interrpciones, normalmente se emplean colas o buffers circulares. La idea es que la función de quiere enviar, llamemosle PutString2Uart, mete en el buffer, obvio verificando capacidad y otras yerbas, y por ultimo habilita la interrupcion de transmicion. En el handler de interrupcion lo que se hace se sacan los datos de ese buffer y se los mete en el registro de transmicion de la UART, cuando ya no queden mas bytes para transmitir se apaga la interrupcion de transmicion. Ademas a este esquema se suele dar un par de funciones mas como por ejemplo cuantos bytes quedan en el buffer de transmicion, mas que nada para que el usuario pueda sincronizar el fin del envio de un paquete.

Saludos ! y sorry si no les cayo bien mi mensaje.

[Mike79]

El problema que tenemos es que el proceso de envio de los bytes nos queda separado en 2 bloques diferentes:
1 bloque en el programa principal (o cualquier rutina) para iniciar la transmision enviando el primer byte y activar la inte por TX.
El segundo bloque deberia estar dentro de la inte por TX y enviaria el resto de los bytes (contaría los bytes, y seleciconaría automaticamente que byte envia segun un contador automatico, dependiendo de los registros seleccionados).

Bueno, desde mi punto de vista no deberían ser 2 bloques.

Debería ser: 1 bloque donde se configura
Y él bloque que ya hemos estado usando de Activación de Interrupción, pero usando solo:  RCIE=Activado.

Entonces la mecánica sería fácil.
1.- Lo configuras.
2.- Para activarlo usas el bloque de Activación de Interrupción por fin de Transmisión USART = Activado.
3.- Para desactivarlo usas el mismo bloque pero con el valor Desactivado.
4.- Que te genere el código dentro de la interrupción (o bloque si es el caso).

Y pensando un poco más, igual y podria ser una nueva opción, dentro de Herramientas, Rutinas Basicas, Comunicaciones, RS232, RS232 - Enviar Avanzado
Donde solo este Enviar por USART (solo puede ser por USART), y ya no tengas las opciones de escojer patitas y eso, pero si opciones del tipo.
¿Que hacer cuando termine de transmitir?
- Volver a Empezar
- Hacer cola ciclica
- Desactivar la Interrupción de Fin de Transmisión.
- Que variable usar para el contador (Una definida por el usuario), de esta forma podemos consultarla y tomar decisiones.

¿Por que otra opción?
Bueno, en realidad creo que esto no es tan común de usar.
Yo habia estado trabajando hasta ahorita muy bien Niple sin tener esta necesidad. Aunque bueno, talvez yo sea la exepción a la regla.


Aunque bueno, en realidad lo que realmente necesito ahorita, es el bloque de Configuración de puerto RS232, así podria poner el puro bloque de configuración a la velocidad que lo necesito y Niple ya me calcularía los valores dependiendo el cristal que le ponga. Me parece que antes lo tenia .

Saludos y Gracias por responder tan pronto Jorge!
-
Mike79

[jorgecano]

Hola Mike,

Seguramente algo vamos a poder hacer.

Dame un par de dias y te confirmo.
(Estamos termionando unos modulos nuevos y no podemos dejar eso a medio terminar porque despues es mas dificil retomarlo).

Saludos a todos
Jorge.