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/
LPC2103 I/O and processing speed to handle 6 serial ports.
Started by ●October 3, 2006
Reply by ●October 8, 20062006-10-08
Reply by ●October 9, 20062006-10-09
--- 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
>
> 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
Reply by ●October 9, 20062006-10-09
----- 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
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
Reply by ●October 24, 20062006-10-24
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..!)
>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..!)
