--- In l..., Peter Jakacki wrote:
>
> > 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 appreciate this point. There's always some limit on what you can do.
The interesting thing about this technique is that the amount of I/O
and interrupt rate doesn't go up (at least on the LPC21xx) as you
increase the number of channels (the point I was making). Clearly,
other limits come into play, particularly CPU capacity, as the number
of channels and/or line speed increases.
The main disadvantage that I can see (apart from the CPU used up) is
that handling channels with different bit rates is somewhat complex.
In practice, I'd guess that most people would only implement this if
all channels were at a single, known bit rate that is hard coded into
the implementation.
One final point I'd agree on is that the sampling clock clearly has to
be stable. On an LPC2xxx this probably means using an FIQ that is
never disabled with all I/O done at the top of the ISR. That way, the
jitter is limited to about 20 or so cycles (to account for differing
interrupt response times), which is fine for the speeds involved.
Brendan
LPC2103 I/O and processing speed to handle 6 serial ports.
Started by ●October 3, 2006
Reply by ●October 5, 20062006-10-05
Reply by ●October 5, 20062006-10-05
> Sorry Bob, most of us don't have a dedicated
timer per channel that
> we can reset, that is why they are sampled.
You can make multiple counters out of one timer interrupt.
You can even do this without any interrupts but I prefer interrupts.
> Crikey mate! there are so many factors that influence reliable
>coms.
> Have you actually attempted multi-channel soft-coms?
>
> *Peter*
Yep. Last company I was at had 10 channels on one AVR micro working
just fine at 9600 Baud. Since the bits are re-synchronized each
start bit, the clock has 10 bits X number of samples to drift. One
of the recent Freescale processors I was using spec'd the maximum
percentage off could be up to 4.0 % Sounds pretty high to me but I
suppose it could work.
> 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!
A hardware UART would have the same problem. I guess you'd have to
wait for a good moment.
It works.
boB
--- In l..., Peter Jakacki wrote:
>
> 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*
>
> we can reset, that is why they are sampled.
You can make multiple counters out of one timer interrupt.
You can even do this without any interrupts but I prefer interrupts.
> Crikey mate! there are so many factors that influence reliable
>coms.
> Have you actually attempted multi-channel soft-coms?
>
> *Peter*
Yep. Last company I was at had 10 channels on one AVR micro working
just fine at 9600 Baud. Since the bits are re-synchronized each
start bit, the clock has 10 bits X number of samples to drift. One
of the recent Freescale processors I was using spec'd the maximum
percentage off could be up to 4.0 % Sounds pretty high to me but I
suppose it could work.
> 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!
A hardware UART would have the same problem. I guess you'd have to
wait for a good moment.
It works.
boB
--- In l..., Peter Jakacki wrote:
>
> 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*
>
Reply by ●October 5, 20062006-10-05
bobtransformer wrote:
>> Sorry Bob, most of us don't have a dedicated timer per channel that
>> we can reset, that is why they are sampled.
>
> You can make multiple counters out of one timer interrupt.
> You can even do this without any interrupts but I prefer interrupts.
That's not even remotely disputed that you can do this. Maybe we are
getting wires crossed (crosstalk!) as I am referring to limitations of
not being able to detect the start edge, only the change of state.
> Yep. Last company I was at had 10 channels on one AVR micro working
> just fine at 9600 Baud. Since the bits are re-synchronized each
> start bit, the clock has 10 bits X number of samples to drift. One
> of the recent Freescale processors I was using spec'd the maximum
> percentage off could be up to 4.0 % Sounds pretty high to me but I
> suppose it could work.
Sounds good, does the AVR have to do much else though or is it primarily
a coms micro? Exactly what do you mean by re-synchronized then because
the only way to correct for drift is to pick the start edge?
>> 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!
>
> A hardware UART would have the same problem. I guess you'd have to
> wait for a good moment.
True, but the point was the need for stop bits or perhaps more
specifically, the need for a gap to resynch. In general-purpose use this
may not happen.
*Peter*
>> Sorry Bob, most of us don't have a dedicated timer per channel that
>> we can reset, that is why they are sampled.
>
> You can make multiple counters out of one timer interrupt.
> You can even do this without any interrupts but I prefer interrupts.
That's not even remotely disputed that you can do this. Maybe we are
getting wires crossed (crosstalk!) as I am referring to limitations of
not being able to detect the start edge, only the change of state.
> Yep. Last company I was at had 10 channels on one AVR micro working
> just fine at 9600 Baud. Since the bits are re-synchronized each
> start bit, the clock has 10 bits X number of samples to drift. One
> of the recent Freescale processors I was using spec'd the maximum
> percentage off could be up to 4.0 % Sounds pretty high to me but I
> suppose it could work.
Sounds good, does the AVR have to do much else though or is it primarily
a coms micro? Exactly what do you mean by re-synchronized then because
the only way to correct for drift is to pick the start edge?
>> 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!
>
> A hardware UART would have the same problem. I guess you'd have to
> wait for a good moment.
True, but the point was the need for stop bits or perhaps more
specifically, the need for a gap to resynch. In general-purpose use this
may not happen.
*Peter*
Reply by ●October 5, 20062006-10-05
--- In l..., Peter Jakacki wrote:
> True, but the point was the need for stop bits or perhaps more
> specifically, the need for a gap to resynch. In general-purpose
use this
> may not happen.
Peter,
You'll always have a stop bit (if you didn't it wouldn't be
asynchronous serial, which is what we're talking about), which
should be enough time to resynch.
I think we're all basically agreeing:
- you clearly can't detect the start bit edge at any more accuracy
than the sampling rate: it could be anywhere between two samples
- you can however detect the change in state of the samples, and
therefore know where the start bit edge is to sufficient accuracy to
make the thing work
- you should resynch the start bit detection at the end of each
character to avoid errors accumulating
- all things being equal, the higher the sample rate the better (and
3x is questionable at best)
There's no doubt a long stream of data with noise will cause
problems, but the same is true of a hardware UART. That's why level
2 protocols are needed.
My own view is that the technique will work well if implemented
carefully, but it would be difficult to make it as good (i.e. the
same ability to detect error conditions) as a hardware UART.
Brendan.
> True, but the point was the need for stop bits or perhaps more
> specifically, the need for a gap to resynch. In general-purpose
use this
> may not happen.
Peter,
You'll always have a stop bit (if you didn't it wouldn't be
asynchronous serial, which is what we're talking about), which
should be enough time to resynch.
I think we're all basically agreeing:
- you clearly can't detect the start bit edge at any more accuracy
than the sampling rate: it could be anywhere between two samples
- you can however detect the change in state of the samples, and
therefore know where the start bit edge is to sufficient accuracy to
make the thing work
- you should resynch the start bit detection at the end of each
character to avoid errors accumulating
- all things being equal, the higher the sample rate the better (and
3x is questionable at best)
There's no doubt a long stream of data with noise will cause
problems, but the same is true of a hardware UART. That's why level
2 protocols are needed.
My own view is that the technique will work well if implemented
carefully, but it would be difficult to make it as good (i.e. the
same ability to detect error conditions) as a hardware UART.
Brendan.
Reply by ●October 5, 20062006-10-05
On Thu, 05 Oct 2006 03:03:31 -0000, you wrote:
>--- 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:
I can't see any reason to use higher sample rates than 4x, unless other error sources are present
that makes timing at 4x marginal.
3x will work 100% robustly as long as you have sufficient margin after other error sources are
accounted for.
>--- 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:
I can't see any reason to use higher sample rates than 4x, unless other error sources are present
that makes timing at 4x marginal.
3x will work 100% robustly as long as you have sufficient margin after other error sources are
accounted for.
Reply by ●October 5, 20062006-10-05
--- In l..., Mike Harrison wrote:
> I can't see any reason to use higher sample rates than 4x, unless
other error sources are present
> that makes timing at 4x marginal.
>
> 3x will work 100% robustly as long as you have sufficient margin
after other error sources are
> accounted for.
>
Mike,
I can see 3x working OK, but I'd question how robust it would be.
If the sender's clock is out by 5%, at the end of 10 bits (i.e. one
character), it will be out by 50%. Even if you happen to be exactly
synchronised at the start (unlikely), by the end of the character,
you'll be right on the edge of misreading the last bit. Now you could
be out by as much as 33% in synchronising to the start bit: in that
case the sender can be out my much less than 5% for you to misread bits.
In the real world, you have to take account for mismatched clocks:
being 2 or 3% out is not uncommon due to the fact a lot of systems
can't get the exactlly correct speed with the particular crystal they
use. You mightn't see any problem in lab testing, but for a system
deployed in any volume, you can expect to encounter such systems.
Another issue is that at 3x sampling, you effectivley have no framing
error detection, as there's no redundancy built into the sampling.
Hance my recommendation to use a higher sampling rate (Id suggest 5x as
a minimum).
Brendan.
> I can't see any reason to use higher sample rates than 4x, unless
other error sources are present
> that makes timing at 4x marginal.
>
> 3x will work 100% robustly as long as you have sufficient margin
after other error sources are
> accounted for.
>
Mike,
I can see 3x working OK, but I'd question how robust it would be.
If the sender's clock is out by 5%, at the end of 10 bits (i.e. one
character), it will be out by 50%. Even if you happen to be exactly
synchronised at the start (unlikely), by the end of the character,
you'll be right on the edge of misreading the last bit. Now you could
be out by as much as 33% in synchronising to the start bit: in that
case the sender can be out my much less than 5% for you to misread bits.
In the real world, you have to take account for mismatched clocks:
being 2 or 3% out is not uncommon due to the fact a lot of systems
can't get the exactlly correct speed with the particular crystal they
use. You mightn't see any problem in lab testing, but for a system
deployed in any volume, you can expect to encounter such systems.
Another issue is that at 3x sampling, you effectivley have no framing
error detection, as there's no redundancy built into the sampling.
Hance my recommendation to use a higher sampling rate (Id suggest 5x as
a minimum).
Brendan.
Reply by ●October 5, 20062006-10-05
> Posted by: "Brendan Murphy" b...@yahoo.com
> brendanmurphy37
> 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?
> I'm only asking, as I've never tried this, and would like to know.
We use this to handle multiple MDB bus channels in vending
machines and also for HVAC systems. It works fine at 4x if the
other end is crystal controlled. On systems that have less
accurate clocks, we had to go to 8x sampling for the start bit.
We also use FIQ for the interrupt to reduce jitter - these
widgets also have six tasks, a TCP/IP stack and an Ethernet
controller.
Stephen
--
Stephen Pelc, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
> brendanmurphy37
> 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?
> I'm only asking, as I've never tried this, and would like to know.
We use this to handle multiple MDB bus channels in vending
machines and also for HVAC systems. It works fine at 4x if the
other end is crystal controlled. On systems that have less
accurate clocks, we had to go to 8x sampling for the start bit.
We also use FIQ for the interrupt to reduce jitter - these
widgets also have six tasks, a TCP/IP stack and an Ethernet
controller.
Stephen
--
Stephen Pelc, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●October 6, 20062006-10-06
Brendan Murphy wrote:
> --- 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.
We have an app that uses a dumpy old 8015 to sample 24 channels
of serial communication coming in from noisy IR detectors at
about 48 KBPS.
The 24 channels come in on three parallel ports, and the data
streams are completely asynchronous.
After the parallel ports are read, each bit goes through a
little state machine, so the start bits are detected separately
for each channel.
If I recall, we only do a 4x sample...
> Finally, apologies for starting all this: I sould have thought a bit
> more before asking the original question.
This is useful discussion.
Ralph
> --- 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.
We have an app that uses a dumpy old 8015 to sample 24 channels
of serial communication coming in from noisy IR detectors at
about 48 KBPS.
The 24 channels come in on three parallel ports, and the data
streams are completely asynchronous.
After the parallel ports are read, each bit goes through a
little state machine, so the start bits are detected separately
for each channel.
If I recall, we only do a 4x sample...
> Finally, apologies for starting all this: I sould have thought a bit
> more before asking the original question.
This is useful discussion.
Ralph
Reply by ●October 6, 20062006-10-06
--- In l..., "Brendan Murphy"
wrote:
> Another issue is that at 3x sampling, you effectivley have no framing
> error detection, as there's no redundancy built into the sampling.
>
> Hance my recommendation to use a higher sampling rate (Id suggest 5x as
> a minimum).
>
> Brendan.
>
Two more quick comments ...
1. There are some UARTs that perform -small- intermediate corrections
during the character itself by observing the edge positions and
adjusting the sampling positions accordingly. This must obviously be
done with some caution and is probably only relevant with fast
sampling rates. But it can address the problem of accumulated error
over 10 data bits (i.e. before the next start pulse).
2. We are also "short" one receive UART and have decided upon a
different approach. We are going to use a small, inexpensive PIC10F
processor to analyze the incoming asynchronous data stream and
generate synchronizing pulses that allow us to bring the data into one
of the LPC2130's unused synchronous ports. This appeared to be the
most cost effective approach for our application.
Best regards, Scott.
wrote:
> Another issue is that at 3x sampling, you effectivley have no framing
> error detection, as there's no redundancy built into the sampling.
>
> Hance my recommendation to use a higher sampling rate (Id suggest 5x as
> a minimum).
>
> Brendan.
>
Two more quick comments ...
1. There are some UARTs that perform -small- intermediate corrections
during the character itself by observing the edge positions and
adjusting the sampling positions accordingly. This must obviously be
done with some caution and is probably only relevant with fast
sampling rates. But it can address the problem of accumulated error
over 10 data bits (i.e. before the next start pulse).
2. We are also "short" one receive UART and have decided upon a
different approach. We are going to use a small, inexpensive PIC10F
processor to analyze the incoming asynchronous data stream and
generate synchronizing pulses that allow us to bring the data into one
of the LPC2130's unused synchronous ports. This appeared to be the
most cost effective approach for our application.
Best regards, Scott.
Reply by ●October 6, 20062006-10-06
On Fri, 06 Oct 2006 16:12:37 -0000, you wrote:
>--- In l..., "Brendan Murphy"
>wrote:
>
>> Another issue is that at 3x sampling, you effectivley have no framing
>> error detection, as there's no redundancy built into the sampling.
Nonsense - you sample the stopbit just like any other data bit.
>> Hance my recommendation to use a higher sampling rate (Id suggest 5x as
>> a minimum).
5x is overkill unless you have additional error sources,
>> Brendan.
>>Two more quick comments ...
>
>1. There are some UARTs that perform -small- intermediate corrections
>during the character itself by observing the edge positions and
>adjusting the sampling positions accordingly.
I'm not convinced this is true - what use is a uart that can only resync on certain data patterns..?
The only possible use I can think is if you're doing a uart on a particularly poor stability clock,
e.g. an internal RC osc for cost reasons. Other than that I can't see any point.
>This must obviously be
>done with some caution and is probably only relevant with fast
>sampling rates. But it can address the problem of accumulated error
>over 10 data bits (i.e. before the next start pulse).
>
>2. We are also "short" one receive UART and have decided upon a
>different approach. We are going to use a small, inexpensive PIC10F
>processor to analyze the incoming asynchronous data stream and
>generate synchronizing pulses that allow us to bring the data into one
>of the LPC2130's unused synchronous ports. This appeared to be the
>most cost effective approach for our application.
Reminds me of something I spotted in the LPC datasheet - as the SPI port has programmable frame
length, you should be able to use it as a TX UART, ny including the start & stop bits in the data
frame.
>--- In l..., "Brendan Murphy"
>wrote:
>
>> Another issue is that at 3x sampling, you effectivley have no framing
>> error detection, as there's no redundancy built into the sampling.
Nonsense - you sample the stopbit just like any other data bit.
>> Hance my recommendation to use a higher sampling rate (Id suggest 5x as
>> a minimum).
5x is overkill unless you have additional error sources,
>> Brendan.
>>Two more quick comments ...
>
>1. There are some UARTs that perform -small- intermediate corrections
>during the character itself by observing the edge positions and
>adjusting the sampling positions accordingly.
I'm not convinced this is true - what use is a uart that can only resync on certain data patterns..?
The only possible use I can think is if you're doing a uart on a particularly poor stability clock,
e.g. an internal RC osc for cost reasons. Other than that I can't see any point.
>This must obviously be
>done with some caution and is probably only relevant with fast
>sampling rates. But it can address the problem of accumulated error
>over 10 data bits (i.e. before the next start pulse).
>
>2. We are also "short" one receive UART and have decided upon a
>different approach. We are going to use a small, inexpensive PIC10F
>processor to analyze the incoming asynchronous data stream and
>generate synchronizing pulses that allow us to bring the data into one
>of the LPC2130's unused synchronous ports. This appeared to be the
>most cost effective approach for our application.
Reminds me of something I spotted in the LPC datasheet - as the SPI port has programmable frame
length, you should be able to use it as a TX UART, ny including the start & stop bits in the data
frame.
