I am implementing software flow control and want to send an Xoff
character.How can I Transmit a character without flushing the Transmit
FIFO and without waiting for Transmit FIFO to be empty (especiaaly
suppose the remote UART has already sent a request to stop the
transmission and the FIFO is holding data). Now I need to send a xonor
xoff character without transmitting the data already in the FIFO.
Thanks in advance
Software FLow Control With LPC UART
Started by ●January 5, 2007
Reply by ●January 5, 20072007-01-05
--- In l..., "suvidhk" wrote:
>
> I am implementing software flow control and want to send an Xoff
> character.How can I Transmit a character without flushing the Transmit
> FIFO and without waiting for Transmit FIFO to be empty (especiaaly
> suppose the remote UART has already sent a request to stop the
> transmission and the FIFO is holding data). Now I need to send a xonor
> xoff character without transmitting the data already in the FIFO.
>
> Thanks in advance
>
The simplest way to handle this is to consider any characters in the
FIFO as already transmitted (i.e. as soon as the character is in the
FIFO it is effectively "gone").
If you do this, everything is a lot simpler.
The FIFO is relatively small, and systems should not expect that
sending an XOFF should have an instantaneous response, as there will
always be latencies in transmission, reception, buffering etc. before
the receiver even sees the XOFF much less acts on it.
BTW: in general software flow control is not that good for this and
other reasons.
Brendan
>
> I am implementing software flow control and want to send an Xoff
> character.How can I Transmit a character without flushing the Transmit
> FIFO and without waiting for Transmit FIFO to be empty (especiaaly
> suppose the remote UART has already sent a request to stop the
> transmission and the FIFO is holding data). Now I need to send a xonor
> xoff character without transmitting the data already in the FIFO.
>
> Thanks in advance
>
The simplest way to handle this is to consider any characters in the
FIFO as already transmitted (i.e. as soon as the character is in the
FIFO it is effectively "gone").
If you do this, everything is a lot simpler.
The FIFO is relatively small, and systems should not expect that
sending an XOFF should have an instantaneous response, as there will
always be latencies in transmission, reception, buffering etc. before
the receiver even sees the XOFF much less acts on it.
BTW: in general software flow control is not that good for this and
other reasons.
Brendan
Reply by ●January 5, 20072007-01-05
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).
So I would like to know if anyone has any idea about possibility of
inserting a char at the head of the FIFO of LPC UART like some
external UART(CD1865)
Suvidh
--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "suvidhk" wrote:
> >
> > I am implementing software flow control and want to send an Xoff
> > character.How can I Transmit a character without flushing the Transmit
> > FIFO and without waiting for Transmit FIFO to be empty (especiaaly
> > suppose the remote UART has already sent a request to stop the
> > transmission and the FIFO is holding data). Now I need to send a xonor
> > xoff character without transmitting the data already in the FIFO.
> >
> > Thanks in advance
> > The simplest way to handle this is to consider any characters in the
> FIFO as already transmitted (i.e. as soon as the character is in the
> FIFO it is effectively "gone").
>
> If you do this, everything is a lot simpler.
>
> The FIFO is relatively small, and systems should not expect that
> sending an XOFF should have an instantaneous response, as there will
> always be latencies in transmission, reception, buffering etc. before
> the receiver even sees the XOFF much less acts on it.
>
> BTW: in general software flow control is not that good for this and
> other reasons.
>
> Brendan
>
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).
So I would like to know if anyone has any idea about possibility of
inserting a char at the head of the FIFO of LPC UART like some
external UART(CD1865)
Suvidh
--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "suvidhk" wrote:
> >
> > I am implementing software flow control and want to send an Xoff
> > character.How can I Transmit a character without flushing the Transmit
> > FIFO and without waiting for Transmit FIFO to be empty (especiaaly
> > suppose the remote UART has already sent a request to stop the
> > transmission and the FIFO is holding data). Now I need to send a xonor
> > xoff character without transmitting the data already in the FIFO.
> >
> > Thanks in advance
> > The simplest way to handle this is to consider any characters in the
> FIFO as already transmitted (i.e. as soon as the character is in the
> FIFO it is effectively "gone").
>
> If you do this, everything is a lot simpler.
>
> The FIFO is relatively small, and systems should not expect that
> sending an XOFF should have an instantaneous response, as there will
> always be latencies in transmission, reception, buffering etc. before
> the receiver even sees the XOFF much less acts on it.
>
> BTW: in general software flow control is not that good for this and
> other reasons.
>
> Brendan
>
Reply by ●January 5, 20072007-01-05
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."
>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."
Reply by ●January 5, 20072007-01-05
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."
>
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."
>
Reply by ●January 5, 20072007-01-05
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."
>
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."
>
Reply by ●January 5, 20072007-01-05
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."
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."
Reply by ●January 5, 20072007-01-05
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/
>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/
Reply by ●January 5, 20072007-01-05
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/
>
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/
>
Reply by ●January 5, 20072007-01-05
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/
>
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/
>
