Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:
> "Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes:
>> You bright up a good subject, and you're absolutely correct that if you
>> continuously send data from one serial port at 9600.01bps to a receiver
>> at 9600, sooner or later there must be a buffer overflow.
>
> No, that will work just fine. When a real UART is set for one stop bit,
> it actually only needs just over 1/2 a stop bit (usually 9/16).
If you read further into the thread, you'll see that the 'problem' is that
while, sure, you can receive all the characters coming in at 9600.01 bps
correctly, if you're then only going to re-transmit them (a data buffer-type
device) at 9600 bps, sooner or later you run out of storage for all the
accumulating bits. That's what my 'there's no way around this' comment
meant. In the interim, people have suggested lots of clever techiques to
deal with mismatched frequencies.
>> Nothing wrong with 16x oversampling (it will definitely help -- a
>> little),
>
> It helps a lot, if you do it right.
I'll buy that I suppose -- I've done just fine with 1x or 3x sampling with
software-based UARTs, but the mere fact that they were software-based meant
that they were only at, e.g., 9600bps or less and they happened to be over
short distances. I.e., the data signals were always 'nice and clean.'
> An async transmitter should NEVER produce shortened start or stop bits!
Perhaps you should tell that to all the guys out there who've designed UARTs
that do just that? Keep reading the thread -- if data comes into a data
forwarder at 9600.01 bps, you have to 'effectively' re-transmit at
9600.01bps as well. You can do that by using a slightly faster clocking
frequency and/or slightly shortening your data bits -- your choice.
---Joel Kolstad
Reply by Allan Herriman●December 4, 20032003-12-04
On 04 Dec 2003 19:16:35 -0800, Eric Smith
<eric-no-spam-for-me@brouhaha.com> wrote:
>"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> writes:
>> Unless your (slightly slower) transmitter also has the capability of
>> producing shortened start (or stop) bits,
>
>An async transmitter should NEVER produce shortened start or stop bits!
Some [well engineered] systems will not work in all cases unless they
are able to use shortened stop bits.
I refer you to ITU-T recommendations V.110 and V.14. (You could argue
that they aren't 'async', but still...)
Regards,
Allan.
> UARTs look for the START edge, from the _middle_ of the STOP bit.
> With x16 clocking, typically that gives 8 possible time slots for earlier
> start.
Actually they usually start looking for a start transition 9/16 of the
way into the previous stop bit. Some UARTs with noise detection sample
the RX input at 7/16, 8/16, and 9/16 of the bit time, so those might not
start looking for a start bit until 10/16 of the way into the previous
stop bit.
> I would agree that a half-bit jump in STOP, as the OP first suggested,
> is NOT a good idea, but fractional (1/16 quantized ) STOP changes are
> valid and safe.
Yes, with rare exceptions such as the NEC uPD7201, which actually requires
a full stop bit on receive.
> Valentin, <p>apparently you are trying to resolve the clock difference by cutting the stop bit in order to achieve a higher transmission rate.
>
> That is a very nice idea and it is completely wrong.
If it's completely wrong, why did the ITU standardize it in the V.14
standard?
Admittedly shaving stop bits should only be used in certain limited
circumstances. It is not intended to deal with sending data to a
receiver that is running slightly slower than the transmitter. Rather,
it is used when converting slightly overspeed data from a synchronous
modem modulation to async (when no error control protocol like V.42 is
in use).
Only a small number of commercially produced UARTs, such as the NEC
uPD7201, fail to work correctly with slightly short stop bits. This
problem was commonly seen on the AT&T 7300 Unix PC in the late 1980s.
> Unless your (slightly slower) transmitter also has the capability of
> producing shortened start (or stop) bits,
An async transmitter should NEVER produce shortened start or stop bits!
It is the RECEIVER that should handle short stop bits, in order to deal
with the exact sort of speed mismatch you're talking about.
> how those this approach 'fix' the
> problem? If the date rates are, say, 9601 received BPS and 9600 transmitted
> BPS, detecting early start bits just buys you one extra bit interval before
> your overrun your buffers, doesn't it?
No, if the receiver works correctly this should be maintainable indefinitely
(provided there's nothing else in the receiving device that overflows).
> You bright up a good subject, and you're absolutely correct that if you
> continuously send data from one serial port at 9600.01bps to a receiver at
> 9600, sooner or later there must be a buffer overflow.
No, that will work just fine. When a real UART is set for one stop bit, it
actually only needs just over 1/2 a stop bit (usually 9/16).
> There's no way around this
Certainly there are ways around it. Read ITU Rec. V.14.
> Nothing wrong with 16x oversampling (it will definitely help -- a little),
It helps a lot, if you do it right.
Reply by Simon Peacock●December 4, 20032003-12-04
"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:bqhflk$3nr$1@news.oregonstate.edu...
> HI Simon,
>
> Simon Peacock <nowhere@to.be.found> wrote:
> > Data is only sent at the speed it arrives at.. so although you are 1.5%
> > fast.. you actually end up adding extra stop bits into the stream to
> > compensate .. is simple and oh so clever.
>
> Well, fair enough, if you KNOW that your data source is truly supposed to
be
> 'nominally,' say, 9600bps, then you can be clever and get away with an
> internal nominal bit rate of 9600*1.015=9744bps. However, if you tell me
> you have such a device that you'd like to connect to one of my devices,
> you'd better be able to convince me there really is no way your device
could
> start spewing data continuously at 9744 bps when my 9600 bps receiver
isn't
> going to be able to hack it!
>
> >This is exactly what modems did
> > for years to cope with the V.14 shaved bits when they couldn't do them.
>
> Interesting; I didn't know that either!
>
if you start looking for a start bit 1/2 way thru the stop .. no problems
:-)
Since modems often use embedded processors.. which don't do fractional
stop.. you have to do something.. so they mostly fudge it. Rockwell, Intel,
silicon systems.. all have done it.. maybe even still do.. wouldn't surprise
me if they did.. the first Rockwell 33k6 modems just used a fast version of
their 2400 processors.. 6802 or something like that
Simon
Reply by Joel Kolstad●December 2, 20032003-12-02
HI Simon,
Simon Peacock <nowhere@to.be.found> wrote:
> Data is only sent at the speed it arrives at.. so although you are 1.5%
> fast.. you actually end up adding extra stop bits into the stream to
> compensate .. is simple and oh so clever.
Well, fair enough, if you KNOW that your data source is truly supposed to be
'nominally,' say, 9600bps, then you can be clever and get away with an
internal nominal bit rate of 9600*1.015=9744bps. However, if you tell me
you have such a device that you'd like to connect to one of my devices,
you'd better be able to convince me there really is no way your device could
start spewing data continuously at 9744 bps when my 9600 bps receiver isn't
going to be able to hack it!
>This is exactly what modems did
> for years to cope with the V.14 shaved bits when they couldn't do them.
Interesting; I didn't know that either!
---Joel
Reply by Simon Peacock●December 2, 20032003-12-02
"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:bqeqiq$654$1@news.oregonstate.edu...
> Simon Peacock <nowhere@to.be.found> wrote:
> > you guys seem to miss the point.. Async RS232 ALWAYS has mismatched
clocks
> > ... ALL async UARTs MUST be capable of handling this.. that's why
there's
> > flow control.
>
> There are a lot of systems in the world that don't use flow control and
> simply rely on a 'mutual agreement' between the interconnected devices
that
> large streams of unbroken serial data isn't produced. This is especially
> the case of, e.g., sensors that produce real-time RS-232 output data with
no
> buffering of their own -- in such a case flow control would just throw
data
> away, so it's often not implemented to begin with. (I have a motto
> something to the effect of... if detecting an error does no more good than
> just ignoring it, you might as well ignore it... Although unfortunately
this
> idea is often perverted into, 'if detecting an error takes effort, even if
> ignoring it causes the machine to rip off someone's arm, you might as well
> ignore it because otherwise the customer will immediately be able to pin
the
> blame on you rather than having to guess whose fault it is.' :-( )
>
> > You will find that 99.9% of them start looking for the start bit 1/2 way
> > thru the stop bit. If you want to build a repeater then you will need a
> > fractional stop bit generator OR you can over spec the crystal by 1.5%
> > (or the baud rate generator) OR you add RTS / CTS flow control like
> > everybody else.
>
> 1 -- The fractional stop bit generator is a good idea, and is apparently
> implemented in -- some -- commercial devices. This was news to me, but it
> does seem to be a very good solution.
> 2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution'
> is inherently non-scalable -- I can't connect together a dozen of these
> repeaters unless each one is progressively 1.5% faster, which isn't
viable.
> 3 -- I'd agree that flow control is the 'proper' or 'textbook' solution,
> just that the real world doesn't always play by those rules. :-)
>
Actually you can :-)
Data is only sent at the speed it arrives at.. so although you are 1.5%
fast.. you actually end up adding extra stop bits into the stream to
compensate .. is simple and oh so clever. This is exactly what modems did
for years to cope with the V.14 shaved bits when they couldn't do them.
Simon
Reply by Joel Kolstad●December 1, 20032003-12-01
Simon Peacock <nowhere@to.be.found> wrote:
> you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks
> ... ALL async UARTs MUST be capable of handling this.. that's why there's
> flow control.
There are a lot of systems in the world that don't use flow control and
simply rely on a 'mutual agreement' between the interconnected devices that
large streams of unbroken serial data isn't produced. This is especially
the case of, e.g., sensors that produce real-time RS-232 output data with no
buffering of their own -- in such a case flow control would just throw data
away, so it's often not implemented to begin with. (I have a motto
something to the effect of... if detecting an error does no more good than
just ignoring it, you might as well ignore it... Although unfortunately this
idea is often perverted into, 'if detecting an error takes effort, even if
ignoring it causes the machine to rip off someone's arm, you might as well
ignore it because otherwise the customer will immediately be able to pin the
blame on you rather than having to guess whose fault it is.' :-( )
> You will find that 99.9% of them start looking for the start bit 1/2 way
> thru the stop bit. If you want to build a repeater then you will need a
> fractional stop bit generator OR you can over spec the crystal by 1.5%
> (or the baud rate generator) OR you add RTS / CTS flow control like
> everybody else.
1 -- The fractional stop bit generator is a good idea, and is apparently
implemented in -- some -- commercial devices. This was news to me, but it
does seem to be a very good solution.
2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution'
is inherently non-scalable -- I can't connect together a dozen of these
repeaters unless each one is progressively 1.5% faster, which isn't viable.
3 -- I'd agree that flow control is the 'proper' or 'textbook' solution,
just that the real world doesn't always play by those rules. :-)
---Joel Kolstad