Since it is not advisable to handle a slow device within an interrupt handler it would be advisable to set a global flag (declared as volatile!) which is checked for in the main-loop. When flag is set, transfer the required data, reset the flag and return to the echo-mode.
Since it is not advisable to handle a slow device within an interrupt handler......
A "slow" device is not a problem for an ISR, generally speaking it is a fast device
that challenges ISRs, like fast com, display refresh, etc..
You could use simple gating, mux, to tie Rx and Tx together to bypass internal
processing, and it would save you MIPs. You should coinsider using a synch
approach to the bypass, eg. when UART finishes a char transmit and there is
a pending request to bypass, then switch the logic/pins. To prevent corruption
of a char being transmitted or received. Or do it async if you do not care if there
is any corrupted link activity.
I understand a "slow" device as using a lot of time to perform its task like sending out data uver UART and waiting for the process to finish. I was not talking about response times.
I think muxing the Tx-line can be difficult, because the switching has to occur byte-synced or you will transmit invalid data, but probably you find a solution for that.
UART and waiting for the process to finish...
I am not following something here. The UART is blocking if it
prints a string, otherwise the HW takes over from simple API
call to write a byte. Latter tells me the process can be carried out
as needed and intermixed with other tasks ?
What am I missing here ?
As I understand, Tom was talking about using interrupts to handle his requirements. Since he said "...event will trigger the need to generate UART data..." I suggested not to handle that within an interrupt handler to keep the system responsive, since the program would have to wait for the complete transmission of the actual character which may take notable time to perform (depending on baud-rate etc)