Check TXIF if you are sending more bytes. This way a new byte will be queued
before the last one has been completely sent out.

Check TRMT if you are waiting for the transmitter to be done (for example
before turning off a line driver).

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Rick Regan" <rdrdr2k@YAHOO.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Wednesday, April 30, 2003 8:31 AM
Subject: Re: [PIC]: Data transfer from P16F877 to serial PC


> >>    This reminds me of a question I've been meaning
> >> to ask.  Some UART code I've seen checks TRMT=1,
> >> other code checks TXIF=1, and some code checks both
> >> flags.  Is there a reason why just checking TXIF=1
> >> to verify that TXREG is empty is not sufficient?
> >
> >The basic difference is that TXIF is part of the
> >interrrupt system. TRMT is not and has to be polled
> >by code. In some applications it may be advantageous
> >to have comms interrupt-driven. The example I gave
> >came from a dedicated routine that had a push-button
> >entry, so there was no other s/w competing for
> >attention during comms so testing TRMT was sufficient
> >TXIF and TRMT are indicators for two registers,
> >TXREG and TSR TXIF shows the condition of TXREG.
> >When TXIF=1 TXREG is available for new data, ie the
> >data previously in TXREG has been moved to TSR (and
> >so on to the comms line)
> >
> >TRMT shows the condition of TSR. When set it
> >indicates that TSR is empty (MT) and that the data
> >has been sent out
> >
> >> Under what circumstances would you need to know
> >> that that the TSR itself is empty before sending
> >> another character?
> >
> >TXREG can be loaded with new data (according to
> >TXIF) even if there is data still in TSR. The PIC
> >won't transfer the new data from TXREG to TSR until
> >the previous data send is complete. Referring
> >back to example I posted, testing TRMT - and knowing
> >that no new data has been loaded into TXREG - tells
> >you that the transmit module is empty. In a
> >handshake situation you could then wait for a data
> >request from the other device, possibly by enabling
> >RCIF interrrupts if the requests are unpredictable
> >
> >That's my quick precis of some aspects of the TX
> >part of the UART in Asynch mode. It's covered in
> >more detail in Section 10.2 of DS30292
> >(F877 manual) and Section 18.4.1 of DS31018
> >(Midrange Reference Manual)
>
> I understand the meanings of the flags but my question
> still remains.  Can you give an example where
> testing TRMT allows you to do something that just
> testing TXIF exclusively couldn't do?
>
> You can poll TXIF without using interrupts.
> In the handshake situation you describe,
> you could enable RCIF interrupts regardless of the
> state of TSR, no?  Also, I can't see how knowing that
> the data is sent out (TRMT=1) helps.  It certainly
> doesn't tell you that the data was received at the
> other end.
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body