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

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

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

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 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

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

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

Robert and Brendan have just given a fair appraisal of the situation, the
only thing to add really in terms of LPC is to answer your question on
whether you can promote sending XOFF to the front of the queue? Simple
answer is no you can't. The Transmit Holding Register for the UART (U0THR
etc) is write only, once data's in there you have two options, either let it
be sent or manually clear the entire contents of the FIFO and re-send. The
problem with the latter being you have no real knowledge on what state the
transmit is in in terms of transmission of stored data ie, you don't know
what you cleared and what you potentially still sent.
You could limit the fifo size to force the echo of every character but
personally I can't see it really needing this form of control as software
XON/XOFF is only realistically going to work in the manner that Robert just
described.

Andy

-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Robert Adsett
Sent: 05 January 2007 16:10
To: l...; l...
Subject: Re: [lpc2000] Re: Software FLow Control With LPC UART
At 03:54 PM 1/5/07 +0000, suvidhk wrote:
>Thanks
>
>My system is configurable by the user for flow control and hence need
>to implement it.
>
>The problem with consideration of characters already transmitted is
>that theirs a chance that the remote system has already requested to
>stop the transmission and the transmitter is on hold.
>Now sometimes ahead the receiver is full and want to send an xoff
>request without sending the characters pending in transmit buffer.
>(Though one way would be to keep transmit buffer empty once an stop
>request is received).

As Brendan pointed out this is in general not possible. Even with an older
non-FIFO UART there will be the possibility of
- The byte on the line
- The byte in the transmit buffer
- The byte(s) in the receive sides receive buffer/FIFO

The only way I know of to avoid that is to wait for the echo of every
byte.

Any system implementing xon/xoff MUST be able to tolerate data arriving
after sending an xoff. Typical implementations I have worked with send the
xoff at buffer 3/4 full and that point was frequently adjustable to deal
with systems that were slow to respond to an xoff. Xon would be sent at
something like buffer 1/4 full or for worst case buffer empty. When you
receive an xoff you don't try to stop the FIFO from emptying (I'm not even
sure that's possible) you just stop putting more into it. The receiving
system must be able to receive them.

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

Thanks Robert,

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.
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
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

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.
Latest UART take care automatically.

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.

Regards

Suvidh

--- In l..., Robert Adsett wrote:
>
> At 03:54 PM 1/5/07 +0000, suvidhk wrote:
> >Thanks
> >
> >My system is configurable by the user for flow control and hence need
> >to implement it.
> >
> >The problem with consideration of characters already transmitted is
> >that theirs a chance that the remote system has already requested to
> >stop the transmission and the transmitter is on hold.
> >Now sometimes ahead the receiver is full and want to send an xoff
> >request without sending the characters pending in transmit buffer.
> >(Though one way would be to keep transmit buffer empty once an stop
> >request is received).
>
> As Brendan pointed out this is in general not possible. Even with
an older
> non-FIFO UART there will be the possibility of
> - The byte on the line
> - The byte in the transmit buffer
> - The byte(s) in the receive sides receive buffer/FIFO
>
> The only way I know of to avoid that is to wait for the echo of
every byte.
>
> Any system implementing xon/xoff MUST be able to tolerate data arriving
> after sending an xoff. Typical implementations I have worked with
send the
> xoff at buffer 3/4 full and that point was frequently adjustable to
deal
> with systems that were slow to respond to an xoff. Xon would be
sent at
> something like buffer 1/4 full or for worst case buffer empty. When you
> receive an xoff you don't try to stop the FIFO from emptying (I'm
not even
> sure that's possible) you just stop putting more into it. The
receiving
> system must be able to receive them.
>
> 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

Agreed.

To clariy my original response: don't try and "jump the queue" by
trying to put the XOFF at the head of the FIFO.

Even if it were possible (and it probably isn't) it would be complex
and error prone to implement, and as Robert points out shouldn't be
necessary in any case.

It's called a FIFO for a reason....

Brendan

--- In l..., Robert Adsett
wrote:
>
> At 03:54 PM 1/5/07 +0000, suvidhk wrote:
> >Thanks
> >
> >My system is configurable by the user for flow control and hence
need
> >to implement it.
> >
> >The problem with consideration of characters already transmitted is
> >that theirs a chance that the remote system has already requested
to
> >stop the transmission and the transmitter is on hold.
> >Now sometimes ahead the receiver is full and want to send an xoff
> >request without sending the characters pending in transmit buffer.
> >(Though one way would be to keep transmit buffer empty once an stop
> >request is received).
>
> As Brendan pointed out this is in general not possible. Even with
an older
> non-FIFO UART there will be the possibility of
> - The byte on the line
> - The byte in the transmit buffer
> - The byte(s) in the receive sides receive buffer/FIFO
>
> The only way I know of to avoid that is to wait for the echo of
every byte.
>
> Any system implementing xon/xoff MUST be able to tolerate data
arriving
> after sending an xoff. Typical implementations I have worked with
send the
> xoff at buffer 3/4 full and that point was frequently adjustable to
deal
> with systems that were slow to respond to an xoff. Xon would be
sent at
> something like buffer 1/4 full or for worst case buffer empty. When
you
> receive an xoff you don't try to stop the FIFO from emptying (I'm
not even
> sure that's possible) you just stop putting more into it. The
receiving
> system must be able to receive them.
>
> 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