Amigo
JavisusII , las respuestas eran para Palermo pero si te quedan dudas aquí te expongo mi explicación.
JavisusII: 1) ¿intrerrupciones software? no lo había oído.Asi es, desde tiempos lejanos en las PCs no todo se puede hacer por hardware, solo 15 IRQs para el sistema y muchos eventos que atender, desembocaron en la necesidad de proveer algun otro método de acceder a 'interrupciones'.
Es ahi que surgieron las interrupciones de software, en principio como funciones de BIOS luego en los sistemas operativos multitarea como Windows como 'eventos'.
Un evento interrumpe el flujo del programa y DEBE ser atendido. un evento puede estar ocasionado por una interrupción de hardware o bien por algun evento de software (por ejemplo Fin de Archivo) o algún TimeOut.
Estas son las llamadas interrupciones de software.
Si buscas en google encontrarás mucha mas información al respecto.
2)Escrito por Maunix
2) Ahora bien, si tu mandarás un dato al pic y luego esperas la respuesta, es ahi donde entran en juego los delays. Ya que si bien el hardware de la PC recibirá los bytes en forma inmediata (tipicamente tienen 16 bytes de buffer por hardware) el sistema operativo no tomará cuenta de esto hasta no 'consultar' dicho dispositivo
JavisusII: No te entiendo Maunix, yo así no programo, no le encuentro el sentido a la frase.¿me perdí algo en la escuela técnica superior?
Oh... que humor. En fin, la dejo pasar. No se que no entiendes de la frase pero he aquí mi explicación a ver si ahora si se entiende. Tampoco se como programas ni que te han dado en la escuela técnica superior, solo digo como son algunos 'timings' inevitables en una comunicacion PC vs Hardware. Además muchos de los conocimientos no se adquieren en la Universidad sino en libros, gralmente las universidades no son tan rápidas para adaptarse a las nuevos cambios ni tampoco pueden seguir todo lo que a uno le interesa. De hecho yo aprendí lo que queria saber fuera de la Universidad porque eran cosas tan específicas que no habia materias que las contengan.
El software de la PC manda un byte a la USART... en realidad 'cree' que manda el byte, ya que el byte queda en cola de espera por el sistema operativo el cual lo enviará al integrado cuando 'se le plazca'. Esto es así en CUALQUIER sistema operativo multitarea. El sistema operativo hace muchas cosas por vez y no porque le digamos manda un dato por la usart va a dejar de reproducir los MP3 o bajar datos de internet o bien, atender una interrupción de disco duro o de la placa de video. Esto provocaría las hermosas pantallas azules a las que nos tenia tan acostumbrado windows.
En el PIC eso no existe (al menos en los casos comunes), el pic recibe el dato y puede responder de inmediato. La PC recibirá en su hardware esos bytes. Si los bytes son mayores a 16, tiene que si o si atenderlo el sistema operativo o sino se llenará el buffer y habrá un overflow. Digo 16 porque los integrados de usart compatibles con el 16550 tienen un buffer de salida y de entrada de 16 bytes. Es aquí donde el SISTEMA OPERATIVO debe vaciar ese buffer de usart antes de que se llene. Luego el sistema operativo + el componente que usemos para comunicarnos con el puerto serie se tienen que entender de manera que se genere un evento de recepción de datos por usart. Y dije evento, no necesariamente tiene que ser una interrupción.
Es ahí donde entra en juego el tema del 'delay' del lado del PIC para no enviar de inmediato.
Hay combinaciones de componentes con Windows que permiten leer miles de bytes por segundo, hay otros componentes que de suerte leen 100 bytes por segundo...no son eficientes.
3)
Si este es tu caso de 'nada' sirve que uses el DTR y el CTS. ¿Para que? Imaginemos la secuencia
La PC quiere enviar el dato entonces activa el DTR, el pic toma cuenta y deja de hacer lo que hacia y da prioridad a la usart. La pc manda los datos, el pic los procesa y responde.
Al responder lo hace de inmediato o con un delay. La PC no tomará cuenta hasta que el sistema operativo no haya leído el hardware de su USART. Además si se reciben varios bytes habrá que ir esperando a que esten disponibles todos los bytes.
JavisusII: Sólo DTR ,nooo, el pic debe dar cuenta con otra señal por ejemplo RTS,CTS, utilizadas por SOFTWARE!!!!Jeje, el pic tiene un software directamente asociado a sus pines, es decir Hardware. Un cambio en un pin que denominemos CTS se refleja en microsegundos a la salida. Esto la PC no lo puede ver tan velozmente. Es ahi donde de nuevo entran en juego los delays.....
4)
3) Pongamos otra situacion. El pic recibe los datos y activa la señal de CTS. La PC cuando detecta esta señal (tampoco es algo rápido) activa el DTR y ahi el pic envia los datos. Nuevamente estarán disponibles cuando el sistema operativo lo disponga
JavisusII: No, estarán disponibles cuando el software bajo (como tu bien decías) evento de entrada los reciba. Delay???? que delay , microsegundos?(eso no es nada)Aqui no serian microsegundos serian milisegundos. Son necesarios para que el sistema operativo realmente tome cuenta de la situacion. A partir de ahi el software recien puede 'conocer' el estado del hardware.
5)En este punto es que los delays son 'variables'. Las pcs no sirven para temporizaciones pequeñas y de precisión. De hecho hace años se matan la cabeza para ver si se puede solucionar esto. Incluso los sistemas operativos en tiempo real con un micro a 3Ghz tiene problemas para atender un evento que transcurre en el orden de las decenas de microsegundos! Siendo que el tiempo de instrucción es del orden de los picosegundos! 
JavisusII: ¿Por qué esta frase ha que viene ?? no entiendo nada.Viene a que por mas que creamos que la PC es rápida, no siempre lo será y más cuando querramos comunicarnos con un PIC. He oido muchas veces: "Tengo un Pentium IV de 2Ghz... como no voy a poder leer datos a 57600 bps" y luego no les anda nada. Precisamente porque el hermoso y veloz pentium está atendiendo 200, 300 o 400 hilos de ejecución al mismo tiempo y esto le impide ser tan rápido como un PIC que solo está abocado a una tarea.
De hecho en las pcs se siguen usando y se seguirán usando por muuucho tiempo los DMA, los Caché, los Buffers, etc.
Cualquier otra cuestión aquí estaré.
Saludos
