On Wed, 04 Oct 2006 08:10:45 +0100, you wrote:

>On Wed, 4 Oct 2006 01:17:03 -0300, you wrote:
>
>>Hi, Mike
>>
>>> You could do this on an 8-bit AVR, so an ARM should be able to so this
>>> easily without breaking a
>>> sweat.
>>> A useful trick for multiple UARTS is at the start of the timer interrupt,
>>> to read all the rx bits in
>>> one go, and write the tx bits from the previous interrupt, then do the
>>> processing - that way
>>> differing processing times don't introduce jitter. If you have other
>>> ints, you want your soft UART
>>> timer int to be 3x or 4x the baudrate to get optimal bit-centering
>>
>> I already have this done with a ATMEGA8 but I need more RAM and the AVR
>>family just goes up to 8K :-( I use a 3x timer interrupt and also handle
>>SLIP protocol inside the timer int's.. It is all coded in assembler so I
>>will probably loose most of the code when migrating to the ARM family :-(
>>
>> My main concern is that I have read sometimes that the LPC family is
>>rather slow when doing I/O operations. As I have never worked with any ARM's
>>and do not have the setup ready for testing I guessed that it is better to
>>be safe than sorry and preferred to ask before spending money on buying a
>>new compiler and building new hardware..
>
>IO speed is not really an issue - up to 8 uarts takes one 8-bit port read and one write at 3 or 4x
>the baudrate, hardly taxing at 4800baud, even with slow IO..!
Just a little follow-up on this topic - I've just started a project needing a LOT of rx uarts on an
AVR, so you ought to be able to do at least as much on an LPC.

I only (!) need 16 receive channels, at 9600 baud.
Measuring the worst-case execution time, it could in principle do about 30 channels on a 20MHZ
clock (I suppose it might be fun to try pushing to 32...). This is for 3x sampling.
I'm using 74HC597's as input expansion, driven from the SPI port - this doesn't add much overhead,
as all the registers are latched in one go, and after I have the first byte, I can be shift the
later bytes out whilst handing the first 8 channels.

For speed, the code for each UART channel is in-lined and encapsulated in a macro. (this is not done
in C, obviously..!) Start a New Thread

----- Original Message -----
From:
To:
Sent: Monday, October 09, 2006 2:59 AM
Subject: Re: [lpc2000] Re: LPC2103 I/O and processing speed to handle 6
serial ports.
> Citando jayasooriah :
>
>> --- In l..., "Brendan Murphy"
>> wrote:
>> > I believe real hardware UARTs typically do 16x sampling and
>> > filtering to remove such transient errors.
>>
>> Oh really? Which one?
>>
>> Jaya
>
> AVRs do sample at 16x the baud rate. Extracted from DOC0839.PDF (AT90S2313
> Datasheet):
>
> "The Receiver front-end logic samples the signal on the RXD pin at a
> frequency
> of 16 times the baud rate. While the line is idle, one single sample of
> logical "0" will be interpreted as the falling edge of a start bit, and
> the
> start bit detection sequence is initiated."

I think that Jaya was questioning the filtering, not the sample rate.

Leon Start a New Thread

--- In l..., wagner@... wrote:
>
> Citando jayasooriah :
>
> > --- In l..., "Brendan Murphy"
> > wrote:
> > > I believe real hardware UARTs typically do 16x sampling and
> > > filtering to remove such transient errors.
> >
> > Oh really? Which one?
> >
> > Jaya
>
> AVRs do sample at 16x the baud rate. Extracted from DOC0839.PDF
(AT90S2313
> Datasheet):
>
> "The Receiver front-end logic samples the signal on the RXD pin at a
frequency
> of 16 times the baud rate. While the line is idle, one single sample of
> logical "0" will be interpreted as the falling edge of a start bit,
and the
> start bit detection sequence is initiated."
>
> Wagner.
>
> -------------
> This mail sent through IMP: http://horde.org/imp/
>

The 16550 UART requires a 16x clock and it has an internal baud rate
generator to create it. The Intel 8251 is somewhat different in that
it wants a minimum 30x clock.

Richard Start a New Thread

Citando jayasooriah :

> --- In l..., "Brendan Murphy"
> wrote:
> > I believe real hardware UARTs typically do 16x sampling and
> > filtering to remove such transient errors.
>
> Oh really? Which one?
>
> Jaya

AVRs do sample at 16x the baud rate. Extracted from DOC0839.PDF (AT90S2313
Datasheet):

"The Receiver front-end logic samples the signal on the RXD pin at a frequency
of 16 times the baud rate. While the line is idle, one single sample of
logical 0 will be interpreted as the falling edge of a start bit, and the
start bit detection sequence is initiated."

Wagner.

-------------
This mail sent through IMP: http://horde.org/imp/ Start a New Thread

--- In l..., Alexandre Guimars
wrote:
>
> Hi,
>
> I am not sure who asked for me to test the software uart in
loopback
> mode to check for errors.. I did it sending a series from 0 to 255
to make
> it easy to check and also made the generation of the sequence
using the same
> timer interrupt and also coming from another board to make it
asynchronous
> and both ran for some hours with zero erros...
>
> I can't tell you how relieved that makes me fell :-)
Oversampling and
> redundancy is nice to have but not essential if your higher level
protocol
> can handle some errors once in a while. In a clean, noiseless
environment it
> is not necessary.
>
> There was one piece of information on the discussion that is
really nice
> and can be quite easy to implement even with 3x bit rate
sampling... You can
> double check for the start bit, that would make just one more
state in the
> state machine. Cheap and easy to implement. I will make that when
I recode
> the routines for the ARM...
>
> Best regards,
> Alexandre Guimaraes
>

Alexandre,

I owe you something of an apology.

My concern was that if the sender's and receiver's clocks differed,
the sampling error would accumulate over the length of the character
to give misread bits at the end if 3x sampling was used.

The problem was I didn't take into account in my back of the
envelope calculation that the start bit detection moves all the
samples around in time (i.e. the start point shifts). It turns out
the clocks have to differ by about 7% for a misread bit to happen
with 3x sampling.

As this is quite a lot, I'd agree with you: for most cases 3x should
be enough. Sorry if I caused you any unnecessary concern!

Regards
Brendan



Start a New Thread

Hi,

I am not sure who asked for me to test the software uart in loopback
mode to check for errors.. I did it sending a series from 0 to 255 to make
it easy to check and also made the generation of the sequence using the same
timer interrupt and also coming from another board to make it asynchronous
and both ran for some hours with zero erros...

I can't tell you how relieved that makes me fell :-) Oversampling and
redundancy is nice to have but not essential if your higher level protocol
can handle some errors once in a while. In a clean, noiseless environment it
is not necessary.

There was one piece of information on the discussion that is really nice
and can be quite easy to implement even with 3x bit rate sampling... You can
double check for the start bit, that would make just one more state in the
state machine. Cheap and easy to implement. I will make that when I recode
the routines for the ARM...

Best regards,
Alexandre Guimaraes Start a New Thread

Thanks, Bob, that's exactly what I meant!

Brendan

--- In l..., "bobtransformer" wrote:
>
> --- In l..., "jayasooriah" wrote:
> >>
> > Over sampling in UARTs determines sampling timer resolution and
has
> > nothing to do with filtering noise or spikes as the original post
> > suggested, or any 'generic' sense as it like to believe.
> >
> > Designers of UARTs know the difference between timing the frame
and
> > filtering.
> >
> > Jaya
> > In addition to timing resolution, the oversampling is handy
> to use for "debouncing" of the data, as I like to think of it.
> Not "filtering", as in low pass of course, but mainly False Start-
Bit
> Detection. That's the most important point I think but this can
> also be applied to the other bits where an average is taken over
> the samples during the middle of the bit times and a vote is taken.
> Here's some False Start-Bit Detection notes:
>
> For instance, from Maxim:
>
> http://www.maxim-ic.com/appnotes.cfm/appnote_number/2141/
>
> "The Start bit is typically sampled at the mid bit time to check
that
> the level is still low, to ensure that the detected falling edge
was
> a Start bit not a noise spike. Another common improvement is to
> sample each bit not simply once at the mid bit position (clock
count
> 8 out of 16), but three times (clock counts 7, 8, and 9 out of
16)."
> From Philips SCC2691_2.pdf UART note:
>
> "The receiver has a digital filter designed to reject "noisy" data
> transitions and the receiver state machine was designed to reject
> noisy start bits or noise that might be considered a start bit."
>
> From TI TL16PIR552:
>
> "The UART tries to resynchronize after a framing error. To
accomplish
> this, it is assumed that the framing error is due to the next
start
> bit. The UART samples this start bit twice and then accepts the
input
> data..... The next character transfer is enabled after SIN goes to
> the marking state for at least two RCLK samples and then receives
the
> next valid start bit."
>
> Intersil 82C50A:
>
> "Verifying the start bit prevents the receiver from assembling an
> incorrect data character due to a low going noise spike on the SIN
> input."
> These 2 are from other forums but is relative to noise in the non
> start bits bits too. We did this at my last job with those 10
> software UARTS:
>
> 1)
> "Many UART chips use the 16x clock to sample the RxD pin multiple
> times for every bit, then they use a majority algorithm to
determine
> the final state of the bit (in case all samples don't agree)."
>
> 2)
> "Before a start bit is recognized, you look for a couple of
> consecutive mark samples (typically 3 or 4) before deciding
> that it really is a start bit. THis kills noise effects. Then
> sample at the bit mid points (the start bit mid point would be 4
or 5
> clocks from the detection of the start in a 16x system). Sample
> again every 16th clock to read the midpoints of the bits. If you
> want to get fancier, you can sense several of the samples around
the
> mid points and vote on the level for a little more noise immunity."
> etc....
> boB
> Start a New Thread

--- In l..., "jayasooriah" wrote:
>>
> Over sampling in UARTs determines sampling timer resolution and has
> nothing to do with filtering noise or spikes as the original post
> suggested, or any 'generic' sense as it like to believe.
>
> Designers of UARTs know the difference between timing the frame and
> filtering.
>
> Jaya
>

In addition to timing resolution, the oversampling is handy
to use for "debouncing" of the data, as I like to think of it.
Not "filtering", as in low pass of course, but mainly False Start-Bit
Detection. That's the most important point I think but this can
also be applied to the other bits where an average is taken over
the samples during the middle of the bit times and a vote is taken.
Here's some False Start-Bit Detection notes:

For instance, from Maxim:

http://www.maxim-ic.com/appnotes.cfm/appnote_number/2141/

"The Start bit is typically sampled at the mid bit time to check that
the level is still low, to ensure that the detected falling edge was
a Start bit not a noise spike. Another common improvement is to
sample each bit not simply once at the mid bit position (clock count
8 out of 16), but three times (clock counts 7, 8, and 9 out of 16)."
>From Philips SCC2691_2.pdf UART note:

"The receiver has a digital filter designed to reject "noisy" data
transitions and the receiver state machine was designed to reject
noisy start bits or noise that might be considered a start bit."

>From TI TL16PIR552:

"The UART tries to resynchronize after a framing error. To accomplish
this, it is assumed that the framing error is due to the next start
bit. The UART samples this start bit twice and then accepts the input
data..... The next character transfer is enabled after SIN goes to
the marking state for at least two RCLK samples and then receives the
next valid start bit."

Intersil 82C50A:

"Verifying the start bit prevents the receiver from assembling an
incorrect data character due to a low going noise spike on the SIN
input."
These 2 are from other forums but is relative to noise in the non
start bits bits too. We did this at my last job with those 10
software UARTS:

1)
"Many UART chips use the 16x clock to sample the RxD pin multiple
times for every bit, then they use a majority algorithm to determine
the final state of the bit (in case all samples don't agree)."

2)
"Before a start bit is recognized, you look for a couple of
consecutive mark samples (typically 3 or 4) before deciding
that it really is a start bit. THis kills noise effects. Then
sample at the bit mid points (the start bit mid point would be 4 or 5
clocks from the detection of the start in a 16x system). Sample
again every 16th clock to read the midpoints of the bits. If you
want to get fancier, you can sense several of the samples around the
mid points and vote on the level for a little more noise immunity."
etc....
boB Start a New Thread

--- In l..., "Brendan Murphy"
wrote:

> Jaya,
>
> I think your filter to remove my posts to the forum for you is
> broken!
>
> To answer your question: there are plenty of UARTs that use 16x
> sampling (see other posts for some specific ones). I was using the
> term "filtering" in its generic sense (i.e. applying some operation
> to an input signal - in this case a series of samples - to an output
> signal - in this case a one or zero bit). I guess you'd have to
> consult the designers of the UARTs to find out the exact techniques
> they use.
>
> Regards
> Brendan

Actually I was surprised how well the filter worked and picked up
misinformation about filters!

Over sampling in UARTs determines sampling timer resolution and has
nothing to do with filtering noise or spikes as the original post
suggested, or any 'generic' sense as it like to believe.

Designers of UARTs know the difference between timing the frame and
filtering.

Jaya Start a New Thread

--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "Brendan Murphy"
> wrote:
> > I believe real hardware UARTs typically do 16x sampling and
> > filtering to remove such transient errors.
>
> Oh really? Which one?
>
> Jaya
>

Jaya,

I think your filter to remove my posts to the forum for you is
broken!

To answer your question: there are plenty of UARTs that use 16x
sampling (see other posts for some specific ones). I was using the
term "filtering" in its generic sense (i.e. applying some operation
to an input signal - in this case a series of samples - to an output
signal - in this case a one or zero bit). I guess you'd have to
consult the designers of the UARTs to find out the exact techniques
they use.

Regards
Brendan Start a New Thread