Consulta con print en CCS5...

[delirio]

Buenas noches gente, que tal?
Me confirman una duda, cuando tengo esto:

Código: [Seleccionar]

#use delay(clock=20000000)
#use rs232(baud=38400, xmit=PIN_C6, rcv=PIN_C7,)

y hago un printf en CCS, por ejemplo:

Código: [Seleccionar]

printf("%c%cL%u%c%c", DeviceTipe, DeviceID ,index, end_of_transmit, new_line);      // imprime


en definitiva no usa el hardware de la usart, lo implementa por soft verdad? es decir, lo sacará por RC7 porque lo declaré, pero el streaming de los datos los envía por rutina no??
O si declaro el pin fisico (RC6/TX) lo colocará en el buff de transmisión y activa dicha labor?
Creería que para eso debería activar INT_TBE no?
Osea... da igual que pin le declare?? podría usar para transmisión el RC1 XXX que el código resultante será el mismo que con RC6?
Vi en otros post que también se puede sin interrupción hacer esto x cada byte:

Código: [Seleccionar]

void SendChar(int8 value)  {
   TXREG = value;
   TXEN = 1
}
Con la recepción no tengo duda xque estoy utilizando el pin fisico (RC7/RX) e interrupción.

xD que matete que tengo... 

El pic es un 16F1936

Gracias de antemano

[cvargcal]

....

Si usas print, se imprime directamente en el primer puerto físico.

Yo siempre uso esto para declarar el puerto, ya sea por HARDWARE o SOFTWARE:

Código: C

1. // Configuración del puerto por Hardware TX=C6 RX=C7 y se nombra  "MODEM", en este caso uso los pines físicos
2. #use rs232(baud=9600,bits=8,parity=N,xmit=PIN_C6,rcv=PIN_C7,ERRORS,stream=MODEM)
3.  
4. // Configuración de puerto por software   RX=C2, TX=C3, y se nombra "debug"
5. #use rs232(baud=9600,bits=8,parity=N,xmit=PIN_C3,rcv=PIN_C2,ERRORS,stream=debug)

y para imprimir uso la función "fprintf":

Código: C

1. fprintf(MODEM,"Hola");    //Imprime en el stream MODEM
2. fprintf(debug,"Hola");      //Imprime en el stream debug

[KILLERJC]

en definitiva no usa el hardware de la usart, lo implementa por soft verdad? es decir, lo sacará por RC7 porque lo declaré, pero el streaming de los datos los envía por rutina no??

Segun el manual de CCS, si usas un pin que pertenece al hardware que compete en este caso la UART, utiliza el UART por hardware. El restante o que no sea de la UART por hardware se implementaria por software. Mirando ahora el datasheet del micro, podras observar que poseen habilitaciones de RX y TX de forma independientes, como si fueran 2 cosas apartes. Por lo cual imagino que CCS ocuparia el RX por hardware y el TX por software (o al menos eso quiero creer)

Como dijo cvargal si tenes varias salidas, lo mejor es usar fprintf y especificar el stream.
Lo que si, si tenes varios #use definidos el printf actuaria sobre el ultimo de estos. ( Segun el manual de CCS)

[delirio]

Gracias cvargcal, lo voy a poner en práctica tú método!
KILLERJC, como siempre muchas gracias.
Ahora bien, cómo administra CCS el envío de mi ejemplo citado, donde tiene que envíar 5 bytes?
Implementa interrupción? Deja el micro en un loop esperando el Buff vacío? No logro darme cuenta con el asm generado! 

[KILLERJC]

Cualquier printf haria que el micro se quede esperando que se vacie el buffer para enviar el siguiente caracter. Asi hasta terminar la sentencia que le diste. Podrias llamarlo bloqueante.

Al ser por software el TX no podes implementar interrupciones, es un loop hasta que se termine de enviar todo. y recien ahi avanza.
Y si fuera por hardware TAMPOCO, a no ser que vos implementes una especie de buffer y algunas variables mas para que el envio se realize por interrupcion y asi tener el menor delay posible en otras cosas.

[delirio]

Siempre tan claro KILLERJC. Un placer leerte
Gracias