Hi,
> My Nite job uses the LPC series, but just 2 UARTS.
>
> At my last job, we used an AVR with 10 UARTS in software
> at 9600 baud plus the one hardware UART at 19,200 baud.
Any special algorithm used ? Or just a timer at 3x or 4x the bit rate ?
Best regards,
Alexandre Guimaraes
LPC2103 I/O and processing speed to handle 6 serial ports.
Started by ●October 3, 2006
Reply by ●October 4, 20062006-10-04
Reply by ●October 4, 20062006-10-04
--- In l..., Alexandre Guimars wrote:
>
> Hi,
>
> > My Nite job uses the LPC series, but just 2 UARTS.
> >
> > At my last job, we used an AVR with 10 UARTS in software
> > at 9600 baud plus the one hardware UART at 19,200 baud.
>
> Any special algorithm used ? Or just a timer at 3x or 4x the bit
rate ?
>
> Best regards,
> Alexandre Guimaraes
>
Having followed this thread I curious: does sampling at 3x or 4x the
bit rate work reliably, given the receive characters can arrive at any
time?
If it does, it sounds like a good technique, as you can parallel many
receive channels with the one timer and one read, though they
obviously all have to be the same speed or multiples of eachother.
(Indeed: why stop at 6 UARTS? why not 10, 12....?)
I wonder how reliable it is, though, particularly for long streams of
characters where the sender's clock is slightly out. I would have
thought there might be problems, as you never actually "see" the edge
of the start bit, which is what receivers normally synchronise with.
I'm only asking, as I've never tried this, and would like to know.
Or maybe I'm misunderstanding how this works?
Brendan.
>
> Hi,
>
> > My Nite job uses the LPC series, but just 2 UARTS.
> >
> > At my last job, we used an AVR with 10 UARTS in software
> > at 9600 baud plus the one hardware UART at 19,200 baud.
>
> Any special algorithm used ? Or just a timer at 3x or 4x the bit
rate ?
>
> Best regards,
> Alexandre Guimaraes
>
Having followed this thread I curious: does sampling at 3x or 4x the
bit rate work reliably, given the receive characters can arrive at any
time?
If it does, it sounds like a good technique, as you can parallel many
receive channels with the one timer and one read, though they
obviously all have to be the same speed or multiples of eachother.
(Indeed: why stop at 6 UARTS? why not 10, 12....?)
I wonder how reliable it is, though, particularly for long streams of
characters where the sender's clock is slightly out. I would have
thought there might be problems, as you never actually "see" the edge
of the start bit, which is what receivers normally synchronise with.
I'm only asking, as I've never tried this, and would like to know.
Or maybe I'm misunderstanding how this works?
Brendan.
Reply by ●October 4, 20062006-10-04
On Wed, 4 Oct 2006 18:37:39 -0300, you wrote:
>Hi,
>
>> My Nite job uses the LPC series, but just 2 UARTS.
>>
>> At my last job, we used an AVR with 10 UARTS in software
>> at 9600 baud plus the one hardware UART at 19,200 baud.
>
> Any special algorithm used ? Or just a timer at 3x or 4x the bit rate ?
>
>Best regards,
>Alexandre Guimaraes
The main trick is to read all the inputs, and send all the outputs (from the previous cycle) right
at the start of the timer interrupt. This means that any variation in processing time during the
code do not introduce jitter.
This is important as the method of doing UART receive with a timer int only (as opposed to using an
edge int on the startbit, which is better, but only really practical for a single uart ) introduces
inherent jitter to the rx sampling, so other possible jitter sources must be minimised to keep
sufficient timing margin for reliable reception.
After that you can keep adding more uarts until you run out of clock cycles before the next timer
int (or RAM to put all the data).
>Hi,
>
>> My Nite job uses the LPC series, but just 2 UARTS.
>>
>> At my last job, we used an AVR with 10 UARTS in software
>> at 9600 baud plus the one hardware UART at 19,200 baud.
>
> Any special algorithm used ? Or just a timer at 3x or 4x the bit rate ?
>
>Best regards,
>Alexandre Guimaraes
The main trick is to read all the inputs, and send all the outputs (from the previous cycle) right
at the start of the timer interrupt. This means that any variation in processing time during the
code do not introduce jitter.
This is important as the method of doing UART receive with a timer int only (as opposed to using an
edge int on the startbit, which is better, but only really practical for a single uart ) introduces
inherent jitter to the rx sampling, so other possible jitter sources must be minimised to keep
sufficient timing margin for reliable reception.
After that you can keep adding more uarts until you run out of clock cycles before the next timer
int (or RAM to put all the data).
Reply by ●October 4, 20062006-10-04
> Having followed this thread I curious: does sampling
at 3x or 4x the
> bit rate work reliably, given the receive characters can arrive at any
> time?
>
> If it does, it sounds like a good technique, as you can parallel many
> receive channels with the one timer and one read, though they
> obviously all have to be the same speed or multiples of eachother.
> (Indeed: why stop at 6 UARTS? why not 10, 12....?)
>
> I wonder how reliable it is, though, particularly for long streams of
> characters where the sender's clock is slightly out. I would have
> thought there might be problems, as you never actually "see" the edge
> of the start bit, which is what receivers normally synchronise with.
>
> I'm only asking, as I've never tried this, and would like to know.
>
> Or maybe I'm misunderstanding how this works?
>
I'm curious as well, as I ruled this out as a design choice early on. I
bit bang six channels of data, but I don't start quantum sampling until
the first edge. So timer interrupts only happen when there's data.
Joel
> bit rate work reliably, given the receive characters can arrive at any
> time?
>
> If it does, it sounds like a good technique, as you can parallel many
> receive channels with the one timer and one read, though they
> obviously all have to be the same speed or multiples of eachother.
> (Indeed: why stop at 6 UARTS? why not 10, 12....?)
>
> I wonder how reliable it is, though, particularly for long streams of
> characters where the sender's clock is slightly out. I would have
> thought there might be problems, as you never actually "see" the edge
> of the start bit, which is what receivers normally synchronise with.
>
> I'm only asking, as I've never tried this, and would like to know.
>
> Or maybe I'm misunderstanding how this works?
>
I'm curious as well, as I ruled this out as a design choice early on. I
bit bang six channels of data, but I don't start quantum sampling until
the first edge. So timer interrupts only happen when there's data.
Joel
Reply by ●October 4, 20062006-10-04
On Wed, 04 Oct 2006 22:38:42 -0000, you wrote:
>--- In l..., Alexandre Guimars wrote:
>>
>> Hi,
>>
>> > My Nite job uses the LPC series, but just 2 UARTS.
>> >
>> > At my last job, we used an AVR with 10 UARTS in software
>> > at 9600 baud plus the one hardware UART at 19,200 baud.
>>
>> Any special algorithm used ? Or just a timer at 3x or 4x the bit
>rate ?
>>
>> Best regards,
>> Alexandre Guimaraes
>>Having followed this thread I curious: does sampling at 3x or 4x the
>bit rate work reliably, given the receive characters can arrive at any
>time?
Yes, if done properly. 4x is generally better as you can centre the nominal sample point in the
middle of the bit time, and as long as any additional jitter sources keep sample jitter below half a
bit-time by th etime you get to the last bit, it will work (assuming clean data).
It will not be as good with noisy data as a UART that does multiple sampling per bit, but if your
data needs that you are probably already in trouble.
>If it does, it sounds like a good technique, as you can parallel many
>receive channels with the one timer and one read, though they
>obviously all have to be the same speed or multiples of eachother.
>(Indeed: why stop at 6 UARTS? why not 10, 12....?)
Exactly. At some point you will have issues dealing with all the data, probably before you run out
of possible UARTS..
Remember of course that it can start putting a fairly heavy load on the processor - 9600 baud at 4x
sampling means an interrupt every 26 microseconds.
>I wonder how reliable it is, though, particularly for long streams of
>characters where the sender's clock is slightly out. I would have
>thought there might be problems, as you never actually "see" the edge
>of the start bit, which is what receivers normally synchronise with.
No, but you see the transition from 1 to 0 within a quarter-bit-time window, so you are starting off
with a 25%-per-bit (for 4x sampling) jitter error, which corresponds to starting off with a minimum
2.5% error over 10 bit-times. Even with a ceramic resonator at both ends (say, 1% each), you still
have a fairly comfortable margin. As I said, you need to carefully evaluate ALL possible error
sources, both source and receive, and make sure you have enough margin for your particular
applications..
One thing you really need to be careful of is if there are any other interrupt sources, as these
could introduce a catastrophic jitter error at higher baudrates. The UART int will generally need to
have the highest priority.
For a lot of uarts on an ARM, using FIQs would be a good idea...
>--- In l..., Alexandre Guimars wrote:
>>
>> Hi,
>>
>> > My Nite job uses the LPC series, but just 2 UARTS.
>> >
>> > At my last job, we used an AVR with 10 UARTS in software
>> > at 9600 baud plus the one hardware UART at 19,200 baud.
>>
>> Any special algorithm used ? Or just a timer at 3x or 4x the bit
>rate ?
>>
>> Best regards,
>> Alexandre Guimaraes
>>Having followed this thread I curious: does sampling at 3x or 4x the
>bit rate work reliably, given the receive characters can arrive at any
>time?
Yes, if done properly. 4x is generally better as you can centre the nominal sample point in the
middle of the bit time, and as long as any additional jitter sources keep sample jitter below half a
bit-time by th etime you get to the last bit, it will work (assuming clean data).
It will not be as good with noisy data as a UART that does multiple sampling per bit, but if your
data needs that you are probably already in trouble.
>If it does, it sounds like a good technique, as you can parallel many
>receive channels with the one timer and one read, though they
>obviously all have to be the same speed or multiples of eachother.
>(Indeed: why stop at 6 UARTS? why not 10, 12....?)
Exactly. At some point you will have issues dealing with all the data, probably before you run out
of possible UARTS..
Remember of course that it can start putting a fairly heavy load on the processor - 9600 baud at 4x
sampling means an interrupt every 26 microseconds.
>I wonder how reliable it is, though, particularly for long streams of
>characters where the sender's clock is slightly out. I would have
>thought there might be problems, as you never actually "see" the edge
>of the start bit, which is what receivers normally synchronise with.
No, but you see the transition from 1 to 0 within a quarter-bit-time window, so you are starting off
with a 25%-per-bit (for 4x sampling) jitter error, which corresponds to starting off with a minimum
2.5% error over 10 bit-times. Even with a ceramic resonator at both ends (say, 1% each), you still
have a fairly comfortable margin. As I said, you need to carefully evaluate ALL possible error
sources, both source and receive, and make sure you have enough margin for your particular
applications..
One thing you really need to be careful of is if there are any other interrupt sources, as these
could introduce a catastrophic jitter error at higher baudrates. The UART int will generally need to
have the highest priority.
For a lot of uarts on an ARM, using FIQs would be a good idea...
Reply by ●October 4, 20062006-10-04
Hi,
>Having followed this thread I curious: does sampling at 3x or 4x the
>bit rate work reliably, given the receive characters can arrive at any
>time?
The reason for 3x or 4x is exacly that.. With 3x the bitrate you detect
the start bit at most within 1/3 bitrate delay after the edge. After that
you just sample at the bitrate and you are at the "middle" of the bit.
>If it does, it sounds like a good technique, as you can parallel many
>receive channels with the one timer and one read, though they
>obviously all have to be the same speed or multiples of eachother.
>(Indeed: why stop at 6 UARTS? why not 10, 12....?)
The time available inside the timer interrupt starts to "fade away"....
And the buffers space go away even faster :-(
>I wonder how reliable it is, though, particularly for long streams of
>characters where the sender's clock is slightly out. I would have
>thought there might be problems, as you never actually "see" the edge
>of the start bit, which is what receivers normally synchronise with.
Remember that we are talking about asyncronous data streams, you always
have the stop bit and the new start bit to resync. The problem is just
inside a byte, there is no "real" continuous stream of data in this
application..
>I'm only asking, as I've never tried this, and would like to know.
>Or maybe I'm misunderstanding how this works?
I think hardware usart usually sample at rates 16x the bitrate and some
take more than one sample at each bit to decide the state of the bit. I have
used bit banged uarts in many projects for many years and never found them
to be less reliable than hardware uarts but in noisy environments they
probably are, but, in noisy environments you have a handshake protocol and
crc's anyway....
Best regards,
Alexandre Guimaraes
>Having followed this thread I curious: does sampling at 3x or 4x the
>bit rate work reliably, given the receive characters can arrive at any
>time?
The reason for 3x or 4x is exacly that.. With 3x the bitrate you detect
the start bit at most within 1/3 bitrate delay after the edge. After that
you just sample at the bitrate and you are at the "middle" of the bit.
>If it does, it sounds like a good technique, as you can parallel many
>receive channels with the one timer and one read, though they
>obviously all have to be the same speed or multiples of eachother.
>(Indeed: why stop at 6 UARTS? why not 10, 12....?)
The time available inside the timer interrupt starts to "fade away"....
And the buffers space go away even faster :-(
>I wonder how reliable it is, though, particularly for long streams of
>characters where the sender's clock is slightly out. I would have
>thought there might be problems, as you never actually "see" the edge
>of the start bit, which is what receivers normally synchronise with.
Remember that we are talking about asyncronous data streams, you always
have the stop bit and the new start bit to resync. The problem is just
inside a byte, there is no "real" continuous stream of data in this
application..
>I'm only asking, as I've never tried this, and would like to know.
>Or maybe I'm misunderstanding how this works?
I think hardware usart usually sample at rates 16x the bitrate and some
take more than one sample at each bit to decide the state of the bit. I have
used bit banged uarts in many projects for many years and never found them
to be less reliable than hardware uarts but in noisy environments they
probably are, but, in noisy environments you have a handshake protocol and
crc's anyway....
Best regards,
Alexandre Guimaraes
Reply by ●October 4, 20062006-10-04
Brendan Murphy wrote:
> --- In l..., Alexandre Guimars wrote:
>> Hi,
>>
>>> My Nite job uses the LPC series, but just 2 UARTS.
>>>
>>> At my last job, we used an AVR with 10 UARTS in software
>>> at 9600 baud plus the one hardware UART at 19,200 baud.
>> Any special algorithm used ? Or just a timer at 3x or 4x the bit
> rate ?
>> Best regards,
>> Alexandre Guimaraes
>> Having followed this thread I curious: does sampling at 3x or 4x the
> bit rate work reliably, given the receive characters can arrive at any
> time?
Yes, as long as the receive stream is reliable :)
> If it does, it sounds like a good technique, as you can parallel many
> receive channels with the one timer and one read, though they
> obviously all have to be the same speed or multiples of eachother.
> (Indeed: why stop at 6 UARTS? why not 10, 12....?)
There are only 86,400,000,000 microseconds in a day, after up'ing the
baud rate and increasing the channels it doesn't leave a lot of time
left to twiddle other bits though.
> I wonder how reliable it is, though, particularly for long streams of
> characters where the sender's clock is slightly out. I would have
> thought there might be problems, as you never actually "see" the edge
> of the start bit, which is what receivers normally synchronize with.
The multi-channel constant timer method doesn't ever worry about edges
as it discovers the start bit from taking samples. If we are only doing
3x sampling then things can get a bit hairy. Transmit is never a problem
as it is controlled by the CPU but receive data can come in at any time.
There is no problem really if the baud-rates are extremely accurate and
stable but is this ever the case? Have a look at the timing diagrams to
see what I mean for 3x sampling.
3x receive timing where start bit is detected early
--------- ----------------
---------------- ----------
S S S S S S S S
STR? STR D0 D1
3x receive timing where start bit is detected late
--------- ---------------- -----------
---------------- ----------------
S S S S S S S S
STR? STR D0 D1
^cutting it fine every time ^
Obviously then you could fake it with 3x sampling but not over long
streams of data as timing errors accumulate. So naturally you would have
to go to 4x sampling at least. Personally I'd sample much more than this
to account for all the drifts, mismatches, and signal distortion that
belongs to the real world. The highs aren't exactly the same as the
lows, especially at higher baud rates or long line lengths. Apply that
to the timing diagrams and you will probably go "ouch".
> I'm only asking, as I've never tried this, and would like to know.
>
> Or maybe I'm misunderstanding how this works?
I think the real world conditions are often overlooked and for a
commercial product that means that cutting corners will come to burn you
badly later on. On the Parallax Propeller that I have been playing with
it has 8x 32-bit x20mip cpus each of which can be programmed as a single
full-duplex uart at baud rates of over 1Mb if you want. That's 8x 1Mbit
reliable soft-uarts.
Now that I don't mind.
*Peter*
> --- In l..., Alexandre Guimars wrote:
>> Hi,
>>
>>> My Nite job uses the LPC series, but just 2 UARTS.
>>>
>>> At my last job, we used an AVR with 10 UARTS in software
>>> at 9600 baud plus the one hardware UART at 19,200 baud.
>> Any special algorithm used ? Or just a timer at 3x or 4x the bit
> rate ?
>> Best regards,
>> Alexandre Guimaraes
>> Having followed this thread I curious: does sampling at 3x or 4x the
> bit rate work reliably, given the receive characters can arrive at any
> time?
Yes, as long as the receive stream is reliable :)
> If it does, it sounds like a good technique, as you can parallel many
> receive channels with the one timer and one read, though they
> obviously all have to be the same speed or multiples of eachother.
> (Indeed: why stop at 6 UARTS? why not 10, 12....?)
There are only 86,400,000,000 microseconds in a day, after up'ing the
baud rate and increasing the channels it doesn't leave a lot of time
left to twiddle other bits though.
> I wonder how reliable it is, though, particularly for long streams of
> characters where the sender's clock is slightly out. I would have
> thought there might be problems, as you never actually "see" the edge
> of the start bit, which is what receivers normally synchronize with.
The multi-channel constant timer method doesn't ever worry about edges
as it discovers the start bit from taking samples. If we are only doing
3x sampling then things can get a bit hairy. Transmit is never a problem
as it is controlled by the CPU but receive data can come in at any time.
There is no problem really if the baud-rates are extremely accurate and
stable but is this ever the case? Have a look at the timing diagrams to
see what I mean for 3x sampling.
3x receive timing where start bit is detected early
--------- ----------------
---------------- ----------
S S S S S S S S
STR? STR D0 D1
3x receive timing where start bit is detected late
--------- ---------------- -----------
---------------- ----------------
S S S S S S S S
STR? STR D0 D1
^cutting it fine every time ^
Obviously then you could fake it with 3x sampling but not over long
streams of data as timing errors accumulate. So naturally you would have
to go to 4x sampling at least. Personally I'd sample much more than this
to account for all the drifts, mismatches, and signal distortion that
belongs to the real world. The highs aren't exactly the same as the
lows, especially at higher baud rates or long line lengths. Apply that
to the timing diagrams and you will probably go "ouch".
> I'm only asking, as I've never tried this, and would like to know.
>
> Or maybe I'm misunderstanding how this works?
I think the real world conditions are often overlooked and for a
commercial product that means that cutting corners will come to burn you
badly later on. On the Parallax Propeller that I have been playing with
it has 8x 32-bit x20mip cpus each of which can be programmed as a single
full-duplex uart at baud rates of over 1Mb if you want. That's 8x 1Mbit
reliable soft-uarts.
Now that I don't mind.
*Peter*
Reply by ●October 4, 20062006-10-04
Long packets of bytes doesn't make the clock accuracy any worse
than receiving just one byte. All timing should be reset
on a MARK to SPACE transition (start bit). i.e. High to Low (usually
after a certain amount of time of inactivity (if the transmitter
gives you any time). Either way, the start bit of the next byte
should reset your clock. Sample more than 3 or 4 times if possible.
8 or so minimum, and then average (debounce) a few of those samples
Stop bits are not necessary, but it's sure nice to have
a moment of sanity before the next incoming byte (start bit)
The clock should be able to be a couple percent off of the actual
baud rate
boB
--- In l..., Peter Jakacki wrote:
>
> Brendan Murphy wrote:
> > --- In l..., Alexandre Guimars
wrote:
> >> Hi,
> >>
> >>> My Nite job uses the LPC series, but just 2 UARTS.
> >>>
> >>> At my last job, we used an AVR with 10 UARTS in software
> >>> at 9600 baud plus the one hardware UART at 19,200 baud.
> >> Any special algorithm used ? Or just a timer at 3x or 4x the
bit
> > rate ?
> >> Best regards,
> >> Alexandre Guimaraes
> >>
> >
> > Having followed this thread I curious: does sampling at 3x or 4x
the
> > bit rate work reliably, given the receive characters can arrive
at any
> > time?
> Yes, as long as the receive stream is reliable :)
>
> > If it does, it sounds like a good technique, as you can parallel
many
> > receive channels with the one timer and one read, though they
> > obviously all have to be the same speed or multiples of
eachother.
> > (Indeed: why stop at 6 UARTS? why not 10, 12....?)
>
> There are only 86,400,000,000 microseconds in a day, after up'ing
the
> baud rate and increasing the channels it doesn't leave a lot of
time
> left to twiddle other bits though.
>
> > I wonder how reliable it is, though, particularly for long
streams of
> > characters where the sender's clock is slightly out. I would have
> > thought there might be problems, as you never actually "see" the
edge
> > of the start bit, which is what receivers normally synchronize
with.
>
> The multi-channel constant timer method doesn't ever worry about
edges
> as it discovers the start bit from taking samples. If we are only
doing
> 3x sampling then things can get a bit hairy. Transmit is never a
problem
> as it is controlled by the CPU but receive data can come in at any
time.
> There is no problem really if the baud-rates are extremely accurate
and
> stable but is this ever the case? Have a look at the timing
diagrams to
> see what I mean for 3x sampling.
>
> 3x receive timing where start bit is detected early
> --------- ----------------
> ---------------- ----------
> S S S S S S S S
> STR? STR D0 D1
>
>
> 3x receive timing where start bit is detected late
> --------- ---------------- -----------
> ---------------- ----------------
> S S S S S S S S
> STR? STR D0 D1
> ^cutting it fine every time ^
>
> Obviously then you could fake it with 3x sampling but not over long
> streams of data as timing errors accumulate. So naturally you would
have
> to go to 4x sampling at least. Personally I'd sample much more than
this
> to account for all the drifts, mismatches, and signal distortion
that
> belongs to the real world. The highs aren't exactly the same as the
> lows, especially at higher baud rates or long line lengths. Apply
that
> to the timing diagrams and you will probably go "ouch".
>
> > I'm only asking, as I've never tried this, and would like to know.
> >
> > Or maybe I'm misunderstanding how this works?
>
> I think the real world conditions are often overlooked and for a
> commercial product that means that cutting corners will come to
burn you
> badly later on. On the Parallax Propeller that I have been playing
with
> it has 8x 32-bit x20mip cpus each of which can be programmed as a
single
> full-duplex uart at baud rates of over 1Mb if you want. That's 8x
1Mbit
> reliable soft-uarts.
>
> Now that I don't mind.
>
> *Peter*
>
than receiving just one byte. All timing should be reset
on a MARK to SPACE transition (start bit). i.e. High to Low (usually
after a certain amount of time of inactivity (if the transmitter
gives you any time). Either way, the start bit of the next byte
should reset your clock. Sample more than 3 or 4 times if possible.
8 or so minimum, and then average (debounce) a few of those samples
Stop bits are not necessary, but it's sure nice to have
a moment of sanity before the next incoming byte (start bit)
The clock should be able to be a couple percent off of the actual
baud rate
boB
--- In l..., Peter Jakacki wrote:
>
> Brendan Murphy wrote:
> > --- In l..., Alexandre Guimars
wrote:
> >> Hi,
> >>
> >>> My Nite job uses the LPC series, but just 2 UARTS.
> >>>
> >>> At my last job, we used an AVR with 10 UARTS in software
> >>> at 9600 baud plus the one hardware UART at 19,200 baud.
> >> Any special algorithm used ? Or just a timer at 3x or 4x the
bit
> > rate ?
> >> Best regards,
> >> Alexandre Guimaraes
> >>
> >
> > Having followed this thread I curious: does sampling at 3x or 4x
the
> > bit rate work reliably, given the receive characters can arrive
at any
> > time?
> Yes, as long as the receive stream is reliable :)
>
> > If it does, it sounds like a good technique, as you can parallel
many
> > receive channels with the one timer and one read, though they
> > obviously all have to be the same speed or multiples of
eachother.
> > (Indeed: why stop at 6 UARTS? why not 10, 12....?)
>
> There are only 86,400,000,000 microseconds in a day, after up'ing
the
> baud rate and increasing the channels it doesn't leave a lot of
time
> left to twiddle other bits though.
>
> > I wonder how reliable it is, though, particularly for long
streams of
> > characters where the sender's clock is slightly out. I would have
> > thought there might be problems, as you never actually "see" the
edge
> > of the start bit, which is what receivers normally synchronize
with.
>
> The multi-channel constant timer method doesn't ever worry about
edges
> as it discovers the start bit from taking samples. If we are only
doing
> 3x sampling then things can get a bit hairy. Transmit is never a
problem
> as it is controlled by the CPU but receive data can come in at any
time.
> There is no problem really if the baud-rates are extremely accurate
and
> stable but is this ever the case? Have a look at the timing
diagrams to
> see what I mean for 3x sampling.
>
> 3x receive timing where start bit is detected early
> --------- ----------------
> ---------------- ----------
> S S S S S S S S
> STR? STR D0 D1
>
>
> 3x receive timing where start bit is detected late
> --------- ---------------- -----------
> ---------------- ----------------
> S S S S S S S S
> STR? STR D0 D1
> ^cutting it fine every time ^
>
> Obviously then you could fake it with 3x sampling but not over long
> streams of data as timing errors accumulate. So naturally you would
have
> to go to 4x sampling at least. Personally I'd sample much more than
this
> to account for all the drifts, mismatches, and signal distortion
that
> belongs to the real world. The highs aren't exactly the same as the
> lows, especially at higher baud rates or long line lengths. Apply
that
> to the timing diagrams and you will probably go "ouch".
>
> > I'm only asking, as I've never tried this, and would like to know.
> >
> > Or maybe I'm misunderstanding how this works?
>
> I think the real world conditions are often overlooked and for a
> commercial product that means that cutting corners will come to
burn you
> badly later on. On the Parallax Propeller that I have been playing
with
> it has 8x 32-bit x20mip cpus each of which can be programmed as a
single
> full-duplex uart at baud rates of over 1Mb if you want. That's 8x
1Mbit
> reliable soft-uarts.
>
> Now that I don't mind.
>
> *Peter*
>
Reply by ●October 4, 20062006-10-04
bobtransformer wrote:
> Long packets of bytes doesn't make the clock accuracy any worse
> than receiving just one byte. All timing should be reset
> on a MARK to SPACE transition (start bit). i.e. High to Low (usually
> after a certain amount of time of inactivity (if the transmitter
> gives you any time). Either way, the start bit of the next byte
> should reset your clock. Sample more than 3 or 4 times if possible.
> 8 or so minimum, and then average (debounce) a few of those samples
Sorry Bob, most of us don't have a dedicated timer per channel that we
can reset, that is why they are sampled. As mentioned in this thread
there is no problem to resync when there is only a single channel. Of
course if we were implementing 300 baud coms then I am sure it can be
done :)
> Stop bits are not necessary, but it's sure nice to have
> a moment of sanity before the next incoming byte (start bit)
Away from the safety and sanity of the workbench serial data streams
happen at any time and what if the receive micro was glitched or reset
and started up in the middle of a stream?, which one is the start
bit?...which?...which?...oh well, GIGO!
> The clock should be able to be a couple percent off of the actual
> baud rate
Crikey mate! there are so many factors that influence reliable coms.
Have you actually attempted multi-channel soft-coms?
*Peter*
> Long packets of bytes doesn't make the clock accuracy any worse
> than receiving just one byte. All timing should be reset
> on a MARK to SPACE transition (start bit). i.e. High to Low (usually
> after a certain amount of time of inactivity (if the transmitter
> gives you any time). Either way, the start bit of the next byte
> should reset your clock. Sample more than 3 or 4 times if possible.
> 8 or so minimum, and then average (debounce) a few of those samples
Sorry Bob, most of us don't have a dedicated timer per channel that we
can reset, that is why they are sampled. As mentioned in this thread
there is no problem to resync when there is only a single channel. Of
course if we were implementing 300 baud coms then I am sure it can be
done :)
> Stop bits are not necessary, but it's sure nice to have
> a moment of sanity before the next incoming byte (start bit)
Away from the safety and sanity of the workbench serial data streams
happen at any time and what if the receive micro was glitched or reset
and started up in the middle of a stream?, which one is the start
bit?...which?...which?...oh well, GIGO!
> The clock should be able to be a couple percent off of the actual
> baud rate
Crikey mate! there are so many factors that influence reliable coms.
Have you actually attempted multi-channel soft-coms?
*Peter*
Reply by ●October 5, 20062006-10-05
--- In l..., Peter Jakacki wrote:
> Sorry Bob, most of us don't have a dedicated timer per channel that
we
> can reset, that is why they are sampled. As mentioned in this thread
> there is no problem to resync when there is only a single channel.
Of
> course if we were implementing 300 baud coms then I am sure it can
be
> done :)
>
Peter,
I think Bob's just saying that you need to reset your per-channel
state machine that detects a character every character, not that you
have individual timers for each channel.
On thinking about it a bit more, I can see that the technique would
work reasonably well, provided you did just that (i.e. reset the bit
to character state machine at the end of each character): errors will
then only accumulate over the length of a single character, as others
have pointed out.
However, I think 3x sampling is likely to proove problematic: I think
you'd need at least 5x sampling to be reasonably robust. I'm assuming
the algorithm would then be something like:
- detect start bit transition (e.g. 3 ones after zero)
- number 1st bit after transition as a 1
- read bits 3, 8, 13, 18 etc. to accumulate 10 bits (assuming 8-N-1)
- go back to detecting start bit transition state
Dpending on the oversampling rate, you might want to add some error
detection (i.e. to ensure there's a consistant state around the middle
of each data bit).
The key is that you reset the algorithm at the end of the character.
By the way, to the person that suggested only starting the timer at
the start of a character: this is fine if you're doing only one
channel, or can afford one timer per channel, but it does nothing for
you when there's multiple channels, as they won't be synchronised.
Finally, apologies for starting all this: I sould have thought a bit
more before asking the original question.
Brendan
> Sorry Bob, most of us don't have a dedicated timer per channel that
we
> can reset, that is why they are sampled. As mentioned in this thread
> there is no problem to resync when there is only a single channel.
Of
> course if we were implementing 300 baud coms then I am sure it can
be
> done :)
>
Peter,
I think Bob's just saying that you need to reset your per-channel
state machine that detects a character every character, not that you
have individual timers for each channel.
On thinking about it a bit more, I can see that the technique would
work reasonably well, provided you did just that (i.e. reset the bit
to character state machine at the end of each character): errors will
then only accumulate over the length of a single character, as others
have pointed out.
However, I think 3x sampling is likely to proove problematic: I think
you'd need at least 5x sampling to be reasonably robust. I'm assuming
the algorithm would then be something like:
- detect start bit transition (e.g. 3 ones after zero)
- number 1st bit after transition as a 1
- read bits 3, 8, 13, 18 etc. to accumulate 10 bits (assuming 8-N-1)
- go back to detecting start bit transition state
Dpending on the oversampling rate, you might want to add some error
detection (i.e. to ensure there's a consistant state around the middle
of each data bit).
The key is that you reset the algorithm at the end of the character.
By the way, to the person that suggested only starting the timer at
the start of a character: this is fine if you're doing only one
channel, or can afford one timer per channel, but it does nothing for
you when there's multiple channels, as they won't be synchronised.
Finally, apologies for starting all this: I sould have thought a bit
more before asking the original question.
Brendan
