Thanks Brendan,
I am having a lot of UARTS in my system 34 (2 of them used are internal)
In order to serve the data as fast as possible I was trying to keep
the things at minimum.
NXP mentions use of TxEN for flow control. So I was planning to use it.
Thanks for the inputs.

Suvidh
--- In l..., "Brendan Murphy"
wrote:
> I'd also receommend never disabling the transmitter: apart from any
> problems it might cause, it's one more thing to control: the simpler
> the better.
>
> If you get an XOFF, set a s/w flag (blocked = TRUE), and just stop
> filling the FIFO.
>
> If the flag is set, don't put anything new in the FIFO.
>
> When you get an XON, clear the flag and fill the FIFO with buffered
> data (if any).
>
> --- In l..., Robert Adsett
> wrote:
> >
> > At 04:33 PM 1/5/07 +0000, suvidhk wrote:
> > >I think I had not put my point clearly.
> > >
> > >I assumed that certain bytes will be sent even after receiving
> xoff.
> > >
> > >I was considering a situation like :
> > >I received the Xoff.
> > >I disable the transmit (Like using Txen in LPC) but their are some
> > >chars in transmit buffer.
> >
> > Not a good way of shutting it down. I'd have to check but there
> may be a
> > possibility of shutting it off mid byte.
> >
> > >After some time my receiver threshold is reached I want to send
> Xoff.
> > >
> > > From the discussions I think Theirs no method I can insert this
> XOFF
> >
> > That should be there's by the way.
> >
> > >char and transmit. So I must first better empty the transmitter
> before
> > >disabling transmit and their after do not put anything in transmit
> > >FIFO of UART
> >
> > Right.
> >
> > >In the previous UART I was using CD1865 their were embedded
> commands
> > >and I could send Xon / Xoff keeping the transmit buffer as it is.
> >
> > Ah, I've not run across such a UART before. A lot of embedded
> UARTs that
> > have FIFOs are based on the now classic 16xx50 design. Another
> large
> > subset of embedded UARTS don't have FIFOs at all but do have
> features to
> > make 9-bit protocols easier.
> >
> > >I was trying to emulate it through driver in LPC. So that the
> > >application can just fill the transmitter buffer if empty without
> > >caring for flow control like the other UARTs.
> >
> > Well like the CD1865 anyway. And no you won't be able to emulate
> it. Just
> > check your xon/xoff flags before you fill the FIFO
> >
> > Robert
> >
> > Another sign of the end of civilization, our technical magazines
> are
> > getting chatty
> > From an EETimes product descriptions 2006/08/09
> > ".... systems that can sample gobs of inputs simultaneously"
> > Now just what is the technical definition for gobs again?
> > http://www.aeolusdevelopment.com/
> Start a New Thread

Thanks

I did checked that the current character is transmitted completely if
I disable TxEN.
However I cannot confirm this for enabling BREAK signal.

Suvidh

--- In l..., "suvidhk" wrote:
>
> Thanks robert .
> In many present UARTS [ALSO one I am using externally] xon / xoff is
> auto. So at application layer I was trying to have same for all UARTs
> internal and external.
>
> New question is
> >Not a good way of shutting it down. I'd have to check but there may
> >be a possibility of shutting it off mid byte.
> LPC datasheet do not mention anything if it will send the current char
> or stop instantly.
> Similarly if I enable "BREAK" . Will it start break instantly or allow
> the present char to be transmitted.
> Currently I am assuming it will send the current char instantly !!
> Any ideas ??
>
> Suvidh
>
> --- In l..., Robert Adsett wrote:
> >
> > At 04:33 PM 1/5/07 +0000, suvidhk wrote:
> > >I think I had not put my point clearly.
> > >
> > >I assumed that certain bytes will be sent even after receiving xoff.
> > >
> > >I was considering a situation like :
> > >I received the Xoff.
> > >I disable the transmit (Like using Txen in LPC) but their are some
> > >chars in transmit buffer.
> >
> > Not a good way of shutting it down. I'd have to check but there may
> be a
> > possibility of shutting it off mid byte.
> >
> > >After some time my receiver threshold is reached I want to send Xoff.
> > >
> > > From the discussions I think Theirs no method I can insert this XOFF
> >
> > That should be there's by the way.
> >
> > >char and transmit. So I must first better empty the transmitter
before
> > >disabling transmit and their after do not put anything in transmit
> > >FIFO of UART
> >
> > Right.
> >
> > >In the previous UART I was using CD1865 their were embedded commands
> > >and I could send Xon / Xoff keeping the transmit buffer as it is.
> >
> > Ah, I've not run across such a UART before. A lot of embedded UARTs
> that
> > have FIFOs are based on the now classic 16xx50 design. Another large
> > subset of embedded UARTS don't have FIFOs at all but do have
> features to
> > make 9-bit protocols easier.
> >
> > >I was trying to emulate it through driver in LPC. So that the
> > >application can just fill the transmitter buffer if empty without
> > >caring for flow control like the other UARTs.
> >
> > Well like the CD1865 anyway. And no you won't be able to emulate
> it. Just
> > check your xon/xoff flags before you fill the FIFO
> >
> > Robert
> >
> > Another sign of the end of civilization, our technical magazines are
> > getting chatty
> > From an EETimes product descriptions 2006/08/09
> > ".... systems that can sample gobs of inputs simultaneously"
> > Now just what is the technical definition for gobs again?
> > http://www.aeolusdevelopment.com/
> Start a New Thread

At 05:23 PM 1/5/07 +0000, suvidhk wrote:
>Thanks robert .
>In many present UARTS [ALSO one I am using externally] xon / xoff is
>auto. So at application layer I was trying to have same for all UARTs
>internal and external.

If you really want them to behave identically I'm afraid you'll have to
treat them all like the least capable.

>New question is
> >Not a good way of shutting it down. I'd have to check but there may
> >be a possibility of shutting it off mid byte.
>LPC datasheet do not mention anything if it will send the current char
>or stop instantly.
>Similarly if I enable "BREAK" . Will it start break instantly or allow
>the present char to be transmitted.
>Currently I am assuming it will send the current char instantly !!
>Any ideas ??

You could check the 16c550 data sheet but given that the LPC data sheet
doesn't say I wouldn't depend on it waiting for end of character before
disabling transmission even if tests showed it did. Likewise I wouldn't
depend on break either waiting or not waiting. For the usual uses of break
as some sort of synchronizer or error indicator it doesn't matter anyway.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock." Start a New Thread

Robert Adsett wrote:
> You could check the 16c550 data sheet but given that the LPC data sheet
> doesn't say I wouldn't depend on it waiting for end of character before
> disabling transmission even if tests showed it did. Likewise I wouldn't
> depend on break either waiting or not waiting. For the usual uses of
> break
> as some sort of synchronizer or error indicator it doesn't matter anyway.
>

He may want to check out a device such as the NXP (Philips) SC16IS762
Dual UART. It has an enhanced feature set which can automagically do
XON/XOFF flow control in the chip itself. So far, I've found the chip
very easy to work with with it's SPI interface.

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread