--- In l..., Mike Harrison wrote:
>
> 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.
>
Poor choice of words on my part to include the word "framing". I meant
that with 3x sampling, you have no redundancy as there is effectivley
only one sample per data bit. If there's any (very transient) noise on
the line, you can misread the bit. With three or more samples you have
a bit more info to play with (e.g. if all three are low, you have a
much greater confidence that it really is a low bit; if two of the
three are low it's up to you to decide to declare either a low or an
error). I believe real hardware UARTs typically do 16x sampling and
filtering to remove such transient errors.
I still believe 3x is not sufficient for a robust UART implementation:
as I explained it behaves badly where the sender's clock is off. From
what others have said, 4x works in most (but not all) situations;
hence my recommendation to go with at least 5x.
Just because you can show something working in a lab doesn't mean it's
a viable solution for the real world.....
Brendan
LPC2103 I/O and processing speed to handle 6 serial ports.
Started by ●October 3, 2006
Reply by ●October 6, 20062006-10-06
Reply by ●October 6, 20062006-10-06
Hi,
> Poor choice of words on my part to include the word "framing". I meant
> that with 3x sampling, you have no redundancy as there is effectivley
> only one sample per data bit. If there's any (very transient) noise on
> the line, you can misread the bit. With three or more samples you have
> a bit more info to play with (e.g. if all three are low, you have a
> much greater confidence that it really is a low bit; if two of the
> three are low it's up to you to decide to declare either a low or an
> error). I believe real hardware UARTs typically do 16x sampling and
> filtering to remove such transient errors.
>
> I still believe 3x is not sufficient for a robust UART implementation:
> as I explained it behaves badly where the sender's clock is off. From
> what others have said, 4x works in most (but not all) situations;
> hence my recommendation to go with at least 5x.
I disagree with you... It all depends on the specs. General purpose UART
chips are made to behave as well as possible in the widest possible range of
situations. A software based UART with 3x sampling will work perfectly if
all the devices attached to it have crystal controlled clocks or even
ceramic resonators with no problems at all.. I agree that more samples and
filtering will make it less sensitive to noise but that is not necessarily
"better" if you do not have that noise present in the system ! We have to
design based on the constraints of the product..
> Just because you can show something working in a lab doesn't mean it's
> a viable solution for the real world.....
I have about 3 thousand equipaments in the field using this technique
and I am sure that there are many, many more products using it in the field
and it works... It is not a "lab" curiosity at all...
Best regards,
Alexandre Guimaraes
> Poor choice of words on my part to include the word "framing". I meant
> that with 3x sampling, you have no redundancy as there is effectivley
> only one sample per data bit. If there's any (very transient) noise on
> the line, you can misread the bit. With three or more samples you have
> a bit more info to play with (e.g. if all three are low, you have a
> much greater confidence that it really is a low bit; if two of the
> three are low it's up to you to decide to declare either a low or an
> error). I believe real hardware UARTs typically do 16x sampling and
> filtering to remove such transient errors.
>
> I still believe 3x is not sufficient for a robust UART implementation:
> as I explained it behaves badly where the sender's clock is off. From
> what others have said, 4x works in most (but not all) situations;
> hence my recommendation to go with at least 5x.
I disagree with you... It all depends on the specs. General purpose UART
chips are made to behave as well as possible in the widest possible range of
situations. A software based UART with 3x sampling will work perfectly if
all the devices attached to it have crystal controlled clocks or even
ceramic resonators with no problems at all.. I agree that more samples and
filtering will make it less sensitive to noise but that is not necessarily
"better" if you do not have that noise present in the system ! We have to
design based on the constraints of the product..
> Just because you can show something working in a lab doesn't mean it's
> a viable solution for the real world.....
I have about 3 thousand equipaments in the field using this technique
and I am sure that there are many, many more products using it in the field
and it works... It is not a "lab" curiosity at all...
Best regards,
Alexandre Guimaraes
Reply by ●October 6, 20062006-10-06
Alexandre Guimars wrote:
> I have about 3 thousand equipaments in the field using this technique
> and I am sure that there are many, many more products using it in the field
> and it works... It is not a "lab" curiosity at all...
There are many things that work in certain situations with the right
equipment etc. If that is the case for you then good, who is to tell you
otherwise (except maybe that irate customer). But there is absolutely no
way that 3x sampling can be used as a "general-purpose" soft-uart for
connection to anything that may be compatible.
Your application and protocol may mask errors but they do exist, even in
the most perfectly precise setup. Mind you though, it is possible that
the 3x sampling works better if it is not exactly matched to the baud
rate. It's like driving a car at a speed that exactly matches the change
of traffic lights, when you go through a green light then you will get
all green lights but conversely when you run a red light it will keep
happening.
The red light here is the metastable condition when a sample is taken
right on the transition, is it high? is it low?, certainly it will come
back as a high or a low but there is no guarantee that it will do the
same next time. Designing synchronous logic requires that setup and hold
times be honored to guarantee that the sample is correct.
The reality is that coms signals are a lot sloppier than most clocked
logic signals and that red light is effectively on for a longer period.
Talking about lab curiosities this is a challenge for you (and me). Take
your 3x interface and place it in a loop-back mode so that is echoes
everything that it receives. Using a coms protocol tester or suitable
program on your PC try and pump that 3x interface and see if it is error
free. I seriously doubt it will hold up to sustained testing. Now throw
in some real line lengths and conditions and it certainly won't get any
better. (Don't gloat if you do not get any errors, it just means you are
not testing properly)
If by chance you are absolutely correct then you can tell all the
uart/micro designers that they have been doing it all wrong with 16x
sample rates all these years and that the same uart can run 5 times
faster than it does. So then my LPC21xx could run at 20M baud, WOW!
But I am not one to go making claims without backing it up too. I have
been through this exercise before but I will do it again with different
sample rates and line conditions and publish my findings on this group.
There is always a chance that I may have to eat humble pie but heck, it
sure is fun finding out!
Remember! We are engineers, we don't just talk about it, we roll around
in it!
*Peter*
> I have about 3 thousand equipaments in the field using this technique
> and I am sure that there are many, many more products using it in the field
> and it works... It is not a "lab" curiosity at all...
There are many things that work in certain situations with the right
equipment etc. If that is the case for you then good, who is to tell you
otherwise (except maybe that irate customer). But there is absolutely no
way that 3x sampling can be used as a "general-purpose" soft-uart for
connection to anything that may be compatible.
Your application and protocol may mask errors but they do exist, even in
the most perfectly precise setup. Mind you though, it is possible that
the 3x sampling works better if it is not exactly matched to the baud
rate. It's like driving a car at a speed that exactly matches the change
of traffic lights, when you go through a green light then you will get
all green lights but conversely when you run a red light it will keep
happening.
The red light here is the metastable condition when a sample is taken
right on the transition, is it high? is it low?, certainly it will come
back as a high or a low but there is no guarantee that it will do the
same next time. Designing synchronous logic requires that setup and hold
times be honored to guarantee that the sample is correct.
The reality is that coms signals are a lot sloppier than most clocked
logic signals and that red light is effectively on for a longer period.
Talking about lab curiosities this is a challenge for you (and me). Take
your 3x interface and place it in a loop-back mode so that is echoes
everything that it receives. Using a coms protocol tester or suitable
program on your PC try and pump that 3x interface and see if it is error
free. I seriously doubt it will hold up to sustained testing. Now throw
in some real line lengths and conditions and it certainly won't get any
better. (Don't gloat if you do not get any errors, it just means you are
not testing properly)
If by chance you are absolutely correct then you can tell all the
uart/micro designers that they have been doing it all wrong with 16x
sample rates all these years and that the same uart can run 5 times
faster than it does. So then my LPC21xx could run at 20M baud, WOW!
But I am not one to go making claims without backing it up too. I have
been through this exercise before but I will do it again with different
sample rates and line conditions and publish my findings on this group.
There is always a chance that I may have to eat humble pie but heck, it
sure is fun finding out!
Remember! We are engineers, we don't just talk about it, we roll around
in it!
*Peter*
Reply by ●October 6, 20062006-10-06
On Sat, 07 Oct 2006 09:12:03 +1000, you wrote:
>Alexandre Guimars wrote:
>> I have about 3 thousand equipaments in the field using this technique
>> and I am sure that there are many, many more products using it in the field
>> and it works... It is not a "lab" curiosity at all...
>
>There are many things that work in certain situations with the right
>equipment etc. If that is the case for you then good, who is to tell you
>otherwise (except maybe that irate customer). But there is absolutely no
>way that 3x sampling can be used as a "general-purpose" soft-uart for
>connection to anything that may be compatible.
Depends entirely on your definition of "General purpose". Nobody is arguing that a soft uart will be
as good as a hardware one in all circumstances, However as long as the overall system parameters
are known, an appropriately designed soft UART with much lower sample rate than a hardware one can
be 100% reliable wihin those parameters,.
There are very few cases where you need to be able to interface with absolutely any conceivable
RS232 device. In practice, the range of devices that any embedded device needs to talk to will be
very limited, and well defined, by the nature of the product.
>Your application and protocol may mask errors but they do exist, even in
>the most perfectly precise setup.
>Mind you though, it is possible that
>the 3x sampling works better if it is not exactly matched to the baud
>rate. It's like driving a car at a speed that exactly matches the change
>of traffic lights, when you go through a green light then you will get
>all green lights but conversely when you run a red light it will keep
>happening.
>
>The red light here is the metastable condition when a sample is taken
>right on the transition, is it high? is it low?, certainly it will come
>back as a high or a low but there is no guarantee that it will do the
>same next time. Designing synchronous logic requires that setup and hold
>times be honored to guarantee that the sample is correct.
But all microcontrollers will have a number of levels of latching between the pin and the data path
that will render the probability of metastability as near to zero as doesn't matter. In a soft-uart
situation, especially with multiple channels, where you sample all at once then process, there will
be many instructions between the sample and using the data, metastability simply won't ever be an
issue unless there us some fundamental flaw in the MCU's port architecture. .
ALL Microcontrollers (as opposed to microprocessors) have to deal with asynchronous input data, so
it is reasonable to assume that the manufacturers will have taken care of it properly.
>The reality is that coms signals are a lot sloppier than most clocked
>logic signals and that red light is effectively on for a longer period.
Yes, but as long as you can quantify all the likely errors in a given system, then you can determine
whether or not a given sample rate is going to be 100% reliable or not. .
>Talking about lab curiosities this is a challenge for you (and me). Take
>your 3x interface and place it in a loop-back mode so that is echoes
>everything that it receives.
>Using a coms protocol tester or suitable
>program on your PC try and pump that 3x interface and see if it is error
>free. I seriously doubt it will hold up to sustained testing.
Why not?
Where exactly will the errors come from ?
If you're talking about resilience to noise etc., then sure, a 3x sampled UART will often fare less
well than a dedicated hardware UART with majority sampling etc. but for clean (false
transition-free) data, within the overall error budget, 3x sampling will work all the time, every
time, with no errors..
> Now throw
>in some real line lengths and conditions and it certainly won't get any
>better. (Don't gloat if you do not get any errors, it just means you are
>not testing properly)
Which is why you need to know the entire error budget before you can determine what sample rate you
need.
>If by chance you are absolutely correct then you can tell all the
>uart/micro designers that they have been doing it all wrong with 16x
>sample rates all these years and that the same uart can run 5 times
>faster than it does. So then my LPC21xx could run at 20M baud, WOW!
MCU UARTS are designed to be general-purpose devices applicable to the widest possible range of
applications. Soft uarts will be tailored to specific application requirements, and their
performance optimised accordingly.
>But I am not one to go making claims without backing it up too. I have
>been through this exercise before but I will do it again with different
>sample rates and line conditions and publish my findings on this group.
>There is always a chance that I may have to eat humble pie but heck, it
>sure is fun finding out!
>
>Remember! We are engineers, we don't just talk about it, we roll around
>in it!
>
>*Peter*
>
>
>
>Alexandre Guimars wrote:
>> I have about 3 thousand equipaments in the field using this technique
>> and I am sure that there are many, many more products using it in the field
>> and it works... It is not a "lab" curiosity at all...
>
>There are many things that work in certain situations with the right
>equipment etc. If that is the case for you then good, who is to tell you
>otherwise (except maybe that irate customer). But there is absolutely no
>way that 3x sampling can be used as a "general-purpose" soft-uart for
>connection to anything that may be compatible.
Depends entirely on your definition of "General purpose". Nobody is arguing that a soft uart will be
as good as a hardware one in all circumstances, However as long as the overall system parameters
are known, an appropriately designed soft UART with much lower sample rate than a hardware one can
be 100% reliable wihin those parameters,.
There are very few cases where you need to be able to interface with absolutely any conceivable
RS232 device. In practice, the range of devices that any embedded device needs to talk to will be
very limited, and well defined, by the nature of the product.
>Your application and protocol may mask errors but they do exist, even in
>the most perfectly precise setup.
>Mind you though, it is possible that
>the 3x sampling works better if it is not exactly matched to the baud
>rate. It's like driving a car at a speed that exactly matches the change
>of traffic lights, when you go through a green light then you will get
>all green lights but conversely when you run a red light it will keep
>happening.
>
>The red light here is the metastable condition when a sample is taken
>right on the transition, is it high? is it low?, certainly it will come
>back as a high or a low but there is no guarantee that it will do the
>same next time. Designing synchronous logic requires that setup and hold
>times be honored to guarantee that the sample is correct.
But all microcontrollers will have a number of levels of latching between the pin and the data path
that will render the probability of metastability as near to zero as doesn't matter. In a soft-uart
situation, especially with multiple channels, where you sample all at once then process, there will
be many instructions between the sample and using the data, metastability simply won't ever be an
issue unless there us some fundamental flaw in the MCU's port architecture. .
ALL Microcontrollers (as opposed to microprocessors) have to deal with asynchronous input data, so
it is reasonable to assume that the manufacturers will have taken care of it properly.
>The reality is that coms signals are a lot sloppier than most clocked
>logic signals and that red light is effectively on for a longer period.
Yes, but as long as you can quantify all the likely errors in a given system, then you can determine
whether or not a given sample rate is going to be 100% reliable or not. .
>Talking about lab curiosities this is a challenge for you (and me). Take
>your 3x interface and place it in a loop-back mode so that is echoes
>everything that it receives.
>Using a coms protocol tester or suitable
>program on your PC try and pump that 3x interface and see if it is error
>free. I seriously doubt it will hold up to sustained testing.
Why not?
Where exactly will the errors come from ?
If you're talking about resilience to noise etc., then sure, a 3x sampled UART will often fare less
well than a dedicated hardware UART with majority sampling etc. but for clean (false
transition-free) data, within the overall error budget, 3x sampling will work all the time, every
time, with no errors..
> Now throw
>in some real line lengths and conditions and it certainly won't get any
>better. (Don't gloat if you do not get any errors, it just means you are
>not testing properly)
Which is why you need to know the entire error budget before you can determine what sample rate you
need.
>If by chance you are absolutely correct then you can tell all the
>uart/micro designers that they have been doing it all wrong with 16x
>sample rates all these years and that the same uart can run 5 times
>faster than it does. So then my LPC21xx could run at 20M baud, WOW!
MCU UARTS are designed to be general-purpose devices applicable to the widest possible range of
applications. Soft uarts will be tailored to specific application requirements, and their
performance optimised accordingly.
>But I am not one to go making claims without backing it up too. I have
>been through this exercise before but I will do it again with different
>sample rates and line conditions and publish my findings on this group.
>There is always a chance that I may have to eat humble pie but heck, it
>sure is fun finding out!
>
>Remember! We are engineers, we don't just talk about it, we roll around
>in it!
>
>*Peter*
>
>
>
Reply by ●October 6, 20062006-10-06
Hi,
> There are many things that work in certain situations with the right
> equipment etc. If that is the case for you then good, who is to tell you
> otherwise (except maybe that irate customer). But there is absolutely no
> way that 3x sampling can be used as a "general-purpose" soft-uart for
> connection to anything that may be compatible.
>
> Your application and protocol may mask errors but they do exist, even in
> the most perfectly precise setup. Mind you though, it is possible that
> the 3x sampling works better if it is not exactly matched to the baud
> rate. It's like driving a car at a speed that exactly matches the change
> of traffic lights, when you go through a green light then you will get
> all green lights but conversely when you run a red light it will keep
> happening.
I maybe completely wrong... I have done that before..... But I checked
it on paper and it looks good to me, except for the filtering in case you
have glitches and noise in the signal..
> The red light here is the metastable condition when a sample is taken
> right on the transition, is it high? is it low?, certainly it will come
> back as a high or a low but there is no guarantee that it will do the
> same next time. Designing synchronous logic requires that setup and hold
> times be honored to guarantee that the sample is correct.
>
> The reality is that coms signals are a lot sloppier than most clocked
> logic signals and that red light is effectively on for a longer period.
I will try to describe the algorithm in detail and maybe I can make
myself clearer. My poor english does not help much...
I have a timer interrupt at 3x the bit rate and a state machine that
controls the reading.. I will describe for a single channel but the state
machines are exactly the same for any number of channels.
State 0 --- Wait for start bit
This is done at 1/3 of the bit period so I will detect the start bit
at the first 1/3 of the start bit.
When the start bit is detected
set the counter for the number of bits to 8
set the counter for the next sample at 4.
Advance to state 1
State 1 ---
Decrement the counter for the next sample
When it is zero
Read the bit, shift and etc...
Set the counter for the next sample at 3
Decrement the counter for the number of bits
When it is zero finish.... Get the byte...
Set the state to 0. ( if you want to check for framing you
can wait for the end of the stop bit)
> Talking about lab curiosities this is a challenge for you (and me). Take
> your 3x interface and place it in a loop-back mode so that is echoes
> everything that it receives. Using a coms protocol tester or suitable
> program on your PC try and pump that 3x interface and see if it is error
> free. I seriously doubt it will hold up to sustained testing. Now throw
> in some real line lengths and conditions and it certainly won't get any
> better. (Don't gloat if you do not get any errors, it just means you are
> not testing properly)
It is either me or you... Someone is really missing something...
My worst case conditions for detecting the start bit are at the very
beggining of the bit or at the very end and that will put my sampling at the
first one third of the bit period..
After detecting the start bit I delay the next sample by 4 counts and
that will make me sample the first real bit anywhere between the end of the
first 1/3 and the beginning of the second 1/3 of the bit period.
After that I sample each bit at 3 counts and I will be at the same place
!
What is wrong with that ??? If you do not have noise you are quite in
the middle of the bit to take the samples !
> If by chance you are absolutely correct then you can tell all the
> uart/micro designers that they have been doing it all wrong with 16x
> sample rates all these years and that the same uart can run 5 times
> faster than it does. So then my LPC21xx could run at 20M baud, WOW!
They do it because it needs to be as generic as possible ! I am not
saying that filtering will not help. I am just saying that it is not
essential ! If you get glichtes in the middle of a bit the higher level
protocol will detect it.
> But I am not one to go making claims without backing it up too. I have
> been through this exercise before but I will do it again with different
> sample rates and line conditions and publish my findings on this group.
> There is always a chance that I may have to eat humble pie but heck, it
> sure is fun finding out!
>
> Remember! We are engineers, we don't just talk about it, we roll around
> in it!
I will draw the timing diagram again just to make sure I am not getting
crazy :-) If you do not delay 4 times to read the first bit you are in real
trouble but besides that and noise in the line it has to work...
Best regards,
Alexandre Guimaraes
> There are many things that work in certain situations with the right
> equipment etc. If that is the case for you then good, who is to tell you
> otherwise (except maybe that irate customer). But there is absolutely no
> way that 3x sampling can be used as a "general-purpose" soft-uart for
> connection to anything that may be compatible.
>
> Your application and protocol may mask errors but they do exist, even in
> the most perfectly precise setup. Mind you though, it is possible that
> the 3x sampling works better if it is not exactly matched to the baud
> rate. It's like driving a car at a speed that exactly matches the change
> of traffic lights, when you go through a green light then you will get
> all green lights but conversely when you run a red light it will keep
> happening.
I maybe completely wrong... I have done that before..... But I checked
it on paper and it looks good to me, except for the filtering in case you
have glitches and noise in the signal..
> The red light here is the metastable condition when a sample is taken
> right on the transition, is it high? is it low?, certainly it will come
> back as a high or a low but there is no guarantee that it will do the
> same next time. Designing synchronous logic requires that setup and hold
> times be honored to guarantee that the sample is correct.
>
> The reality is that coms signals are a lot sloppier than most clocked
> logic signals and that red light is effectively on for a longer period.
I will try to describe the algorithm in detail and maybe I can make
myself clearer. My poor english does not help much...
I have a timer interrupt at 3x the bit rate and a state machine that
controls the reading.. I will describe for a single channel but the state
machines are exactly the same for any number of channels.
State 0 --- Wait for start bit
This is done at 1/3 of the bit period so I will detect the start bit
at the first 1/3 of the start bit.
When the start bit is detected
set the counter for the number of bits to 8
set the counter for the next sample at 4.
Advance to state 1
State 1 ---
Decrement the counter for the next sample
When it is zero
Read the bit, shift and etc...
Set the counter for the next sample at 3
Decrement the counter for the number of bits
When it is zero finish.... Get the byte...
Set the state to 0. ( if you want to check for framing you
can wait for the end of the stop bit)
> Talking about lab curiosities this is a challenge for you (and me). Take
> your 3x interface and place it in a loop-back mode so that is echoes
> everything that it receives. Using a coms protocol tester or suitable
> program on your PC try and pump that 3x interface and see if it is error
> free. I seriously doubt it will hold up to sustained testing. Now throw
> in some real line lengths and conditions and it certainly won't get any
> better. (Don't gloat if you do not get any errors, it just means you are
> not testing properly)
It is either me or you... Someone is really missing something...
My worst case conditions for detecting the start bit are at the very
beggining of the bit or at the very end and that will put my sampling at the
first one third of the bit period..
After detecting the start bit I delay the next sample by 4 counts and
that will make me sample the first real bit anywhere between the end of the
first 1/3 and the beginning of the second 1/3 of the bit period.
After that I sample each bit at 3 counts and I will be at the same place
!
What is wrong with that ??? If you do not have noise you are quite in
the middle of the bit to take the samples !
> If by chance you are absolutely correct then you can tell all the
> uart/micro designers that they have been doing it all wrong with 16x
> sample rates all these years and that the same uart can run 5 times
> faster than it does. So then my LPC21xx could run at 20M baud, WOW!
They do it because it needs to be as generic as possible ! I am not
saying that filtering will not help. I am just saying that it is not
essential ! If you get glichtes in the middle of a bit the higher level
protocol will detect it.
> But I am not one to go making claims without backing it up too. I have
> been through this exercise before but I will do it again with different
> sample rates and line conditions and publish my findings on this group.
> There is always a chance that I may have to eat humble pie but heck, it
> sure is fun finding out!
>
> Remember! We are engineers, we don't just talk about it, we roll around
> in it!
I will draw the timing diagram again just to make sure I am not getting
crazy :-) If you do not delay 4 times to read the first bit you are in real
trouble but besides that and noise in the line it has to work...
Best regards,
Alexandre Guimaraes
Reply by ●October 6, 20062006-10-06
> I will draw the timing diagram again just to make
sure I am not getting
> crazy :-) If you do not delay 4 times to read the first bit you are in real
> trouble but besides that and noise in the line it has to work...
On paper it always works :)
Don't worry I understand the controlled use of 3x sampling and if it is
practical for that application I would use it too. Your English is good
and I do not have any trouble understanding you at all, it may just be
my brain reinterpreting it (we don't speak English here in Oz).
My response is probably to do with the aussie in me, someone makes a
claim and you just have to "knock em" about it in a friendly manner.
Somewhere through all the banter the truth comes out. It could very well
be that we are both "right" but the truth may be neither.
*Peter*
> crazy :-) If you do not delay 4 times to read the first bit you are in real
> trouble but besides that and noise in the line it has to work...
On paper it always works :)
Don't worry I understand the controlled use of 3x sampling and if it is
practical for that application I would use it too. Your English is good
and I do not have any trouble understanding you at all, it may just be
my brain reinterpreting it (we don't speak English here in Oz).
My response is probably to do with the aussie in me, someone makes a
claim and you just have to "knock em" about it in a friendly manner.
Somewhere through all the banter the truth comes out. It could very well
be that we are both "right" but the truth may be neither.
*Peter*
Reply by ●October 7, 20062006-10-07
Have a look at
www.semiconductors.philips.com/acrobat/applicationnotes/AN446.pdf
Peter Jakacki wrote: > I will draw the timing diagram again just to make sure I am not getting
> crazy :-) If you do not delay 4 times to read the first bit you are in real
> trouble but besides that and noise in the line it has to work...
On paper it always works :)
Don't worry I understand the controlled use of 3x sampling and if it is
practical for that application I would use it too. Your English is good
and I do not have any trouble understanding you at all, it may just be
my brain reinterpreting it (we don't speak English here in Oz).
My response is probably to do with the aussie in me, someone makes a
claim and you just have to "knock em" about it in a friendly manner.
Somewhere through all the banter the truth comes out. It could very well
be that we are both "right" but the truth may be neither.
*Peter*
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2/min or less.
www.semiconductors.philips.com/acrobat/applicationnotes/AN446.pdf
Peter Jakacki wrote: > I will draw the timing diagram again just to make sure I am not getting
> crazy :-) If you do not delay 4 times to read the first bit you are in real
> trouble but besides that and noise in the line it has to work...
On paper it always works :)
Don't worry I understand the controlled use of 3x sampling and if it is
practical for that application I would use it too. Your English is good
and I do not have any trouble understanding you at all, it may just be
my brain reinterpreting it (we don't speak English here in Oz).
My response is probably to do with the aussie in me, someone makes a
claim and you just have to "knock em" about it in a friendly manner.
Somewhere through all the banter the truth comes out. It could very well
be that we are both "right" but the truth may be neither.
*Peter*
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2/min or less.
Reply by ●October 7, 20062006-10-07
--- In l..., syed ismail wrote:
>
> Have a look at
>
> www.semiconductors.philips.com/acrobat/applicationnotes/AN446.pdf
>
Please replace link with this one:
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/an447.pdf
This was written for 8051 but the principals still apply
Bob
>
> Have a look at
>
> www.semiconductors.philips.com/acrobat/applicationnotes/AN446.pdf
>
Please replace link with this one:
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/an447.pdf
This was written for 8051 but the principals still apply
Bob
Reply by ●October 7, 20062006-10-07
--- In l..., Alexandre Guimars
wrote:
>
> Hi,
>
> > There are many things that work in certain situations with the
right
> > equipment etc. If that is the case for you then good, who is to
tell you
> > otherwise (except maybe that irate customer). But there is
absolutely no
> > way that 3x sampling can be used as a "general-purpose" soft-
uart for
> > connection to anything that may be compatible.
> >
> > Your application and protocol may mask errors but they do exist,
even in
> > the most perfectly precise setup. Mind you though, it is
possible that
> > the 3x sampling works better if it is not exactly matched to the
baud
> > rate. It's like driving a car at a speed that exactly matches
the change
> > of traffic lights, when you go through a green light then you
will get
> > all green lights but conversely when you run a red light it will
keep
> > happening.
>
> I maybe completely wrong... I have done that before..... But I
checked
> it on paper and it looks good to me, except for the filtering in
case you
> have glitches and noise in the signal..
>
> > The red light here is the metastable condition when a sample is
taken
> > right on the transition, is it high? is it low?, certainly it
will come
> > back as a high or a low but there is no guarantee that it will
do the
> > same next time. Designing synchronous logic requires that setup
and hold
> > times be honored to guarantee that the sample is correct.
> >
> > The reality is that coms signals are a lot sloppier than most
clocked
> > logic signals and that red light is effectively on for a longer
period.
>
> I will try to describe the algorithm in detail and maybe I can
make
> myself clearer. My poor english does not help much...
>
> I have a timer interrupt at 3x the bit rate and a state
machine that
> controls the reading.. I will describe for a single channel but
the state
> machines are exactly the same for any number of channels.
>
> State 0 --- Wait for start bit
> This is done at 1/3 of the bit period so I will detect the
start bit
> at the first 1/3 of the start bit.
> When the start bit is detected
> set the counter for the number of bits to 8
> set the counter for the next sample at 4.
> Advance to state 1
>
> State 1 ---
> Decrement the counter for the next sample
> When it is zero
> Read the bit, shift and etc...
> Set the counter for the next sample at 3
> Decrement the counter for the number of bits
> When it is zero finish.... Get the byte...
> Set the state to 0. ( if you want to check for
framing you
> can wait for the end of the stop bit)
>
> > Talking about lab curiosities this is a challenge for you (and
me). Take
> > your 3x interface and place it in a loop-back mode so that is
echoes
> > everything that it receives. Using a coms protocol tester or
suitable
> > program on your PC try and pump that 3x interface and see if it
is error
> > free. I seriously doubt it will hold up to sustained testing.
Now throw
> > in some real line lengths and conditions and it certainly won't
get any
> > better. (Don't gloat if you do not get any errors, it just means
you are
> > not testing properly)
>
> It is either me or you... Someone is really missing
something...
>
> My worst case conditions for detecting the start bit are at
the very
> beggining of the bit or at the very end and that will put my
sampling at the
> first one third of the bit period..
> After detecting the start bit I delay the next sample by 4
counts and
> that will make me sample the first real bit anywhere between the
end of the
> first 1/3 and the beginning of the second 1/3 of the bit period.
> After that I sample each bit at 3 counts and I will be at the
same place
> !
>
> What is wrong with that ??? If you do not have noise you are
quite in
> the middle of the bit to take the samples !
>
> > If by chance you are absolutely correct then you can tell all the
> > uart/micro designers that they have been doing it all wrong with
16x
> > sample rates all these years and that the same uart can run 5
times
> > faster than it does. So then my LPC21xx could run at 20M baud,
WOW!
>
> They do it because it needs to be as generic as possible ! I
am not
> saying that filtering will not help. I am just saying that it is
not
> essential ! If you get glichtes in the middle of a bit the higher
level
> protocol will detect it.
>
> > But I am not one to go making claims without backing it up too.
I have
> > been through this exercise before but I will do it again with
different
> > sample rates and line conditions and publish my findings on this
group.
> > There is always a chance that I may have to eat humble pie but
heck, it
> > sure is fun finding out!
> >
> > Remember! We are engineers, we don't just talk about it, we roll
around
> > in it!
>
> I will draw the timing diagram again just to make sure I am
not getting
> crazy :-) If you do not delay 4 times to read the first bit you
are in real
> trouble but besides that and noise in the line it has to work...
>
> Best regards,
> Alexandre Guimaraes
>
Alexandre,
First point: your English is excellent, so no worries on that front.
I used the term "lab" as a shorthand for saying something that'll
work in controlled circumstances. If your product will always work
in controlled circumstances (e.g. your UART is always used to
connect to a particular device of known characteristics), then I
agree, 3x sampling will work perfectly well. I agree it's not just a
lab curiosity: it will work. However, it will only work in known,
controlled circumstances.
My point about oversampling to filter noise is a minor point: you
may never see it in practice or may be happy to live with the very
rarely misread bit.
My major concern about 3x sampling is its poor behaviour where the
sender's clock is not exactly at the nominal bit rate: this is
common in practice. I'd suggest you look at your bit timings and
algorithm again where the receiver is working at 9600 bps, the
sender is sending at say 9310 bps (about 3% off), and the start bit
arrives immediately after a sample is taken.
There are three issues that I see with this:
1. If your product is one where someone can plug any device into it
(for example, any serial printer), then someone is bound to actually
do just that. Hence, if you have any volume of product in the field,
you'll get support issues (nobody will be the slightest bit
interested to hear that their printer that works with everything
else is in fact using incorrect timing on its serial port).
2. Even if the circumstances are controlled at the start, someone
may bring out a "rev 2" version of the unit to which the serial port
is connected, with less favorable characteristics.
3. By the nature of things, the soft UART that was developed for a
particular setup will possibly get re-used in some other product in
the future. If the knowledge that it only works in certain cases
is "lost", then the first you might hear of it is when those support
calls start coming in.
I completely take the point that in a lot of cases you have to
design for the fixed constraints in a system (in particular unit
cost), which drives you to use special knowledge about the system to
optimise resources (in this case processor capacity). You are after
all not designing a general purpose UART.
My point is that you need to be very aware of the limitations of a
particular design and secondly you should try if possible to make
designs work in is many circumstances as possible to take account of
future unanticipated changes.
Brendan
wrote:
>
> Hi,
>
> > There are many things that work in certain situations with the
right
> > equipment etc. If that is the case for you then good, who is to
tell you
> > otherwise (except maybe that irate customer). But there is
absolutely no
> > way that 3x sampling can be used as a "general-purpose" soft-
uart for
> > connection to anything that may be compatible.
> >
> > Your application and protocol may mask errors but they do exist,
even in
> > the most perfectly precise setup. Mind you though, it is
possible that
> > the 3x sampling works better if it is not exactly matched to the
baud
> > rate. It's like driving a car at a speed that exactly matches
the change
> > of traffic lights, when you go through a green light then you
will get
> > all green lights but conversely when you run a red light it will
keep
> > happening.
>
> I maybe completely wrong... I have done that before..... But I
checked
> it on paper and it looks good to me, except for the filtering in
case you
> have glitches and noise in the signal..
>
> > The red light here is the metastable condition when a sample is
taken
> > right on the transition, is it high? is it low?, certainly it
will come
> > back as a high or a low but there is no guarantee that it will
do the
> > same next time. Designing synchronous logic requires that setup
and hold
> > times be honored to guarantee that the sample is correct.
> >
> > The reality is that coms signals are a lot sloppier than most
clocked
> > logic signals and that red light is effectively on for a longer
period.
>
> I will try to describe the algorithm in detail and maybe I can
make
> myself clearer. My poor english does not help much...
>
> I have a timer interrupt at 3x the bit rate and a state
machine that
> controls the reading.. I will describe for a single channel but
the state
> machines are exactly the same for any number of channels.
>
> State 0 --- Wait for start bit
> This is done at 1/3 of the bit period so I will detect the
start bit
> at the first 1/3 of the start bit.
> When the start bit is detected
> set the counter for the number of bits to 8
> set the counter for the next sample at 4.
> Advance to state 1
>
> State 1 ---
> Decrement the counter for the next sample
> When it is zero
> Read the bit, shift and etc...
> Set the counter for the next sample at 3
> Decrement the counter for the number of bits
> When it is zero finish.... Get the byte...
> Set the state to 0. ( if you want to check for
framing you
> can wait for the end of the stop bit)
>
> > Talking about lab curiosities this is a challenge for you (and
me). Take
> > your 3x interface and place it in a loop-back mode so that is
echoes
> > everything that it receives. Using a coms protocol tester or
suitable
> > program on your PC try and pump that 3x interface and see if it
is error
> > free. I seriously doubt it will hold up to sustained testing.
Now throw
> > in some real line lengths and conditions and it certainly won't
get any
> > better. (Don't gloat if you do not get any errors, it just means
you are
> > not testing properly)
>
> It is either me or you... Someone is really missing
something...
>
> My worst case conditions for detecting the start bit are at
the very
> beggining of the bit or at the very end and that will put my
sampling at the
> first one third of the bit period..
> After detecting the start bit I delay the next sample by 4
counts and
> that will make me sample the first real bit anywhere between the
end of the
> first 1/3 and the beginning of the second 1/3 of the bit period.
> After that I sample each bit at 3 counts and I will be at the
same place
> !
>
> What is wrong with that ??? If you do not have noise you are
quite in
> the middle of the bit to take the samples !
>
> > If by chance you are absolutely correct then you can tell all the
> > uart/micro designers that they have been doing it all wrong with
16x
> > sample rates all these years and that the same uart can run 5
times
> > faster than it does. So then my LPC21xx could run at 20M baud,
WOW!
>
> They do it because it needs to be as generic as possible ! I
am not
> saying that filtering will not help. I am just saying that it is
not
> essential ! If you get glichtes in the middle of a bit the higher
level
> protocol will detect it.
>
> > But I am not one to go making claims without backing it up too.
I have
> > been through this exercise before but I will do it again with
different
> > sample rates and line conditions and publish my findings on this
group.
> > There is always a chance that I may have to eat humble pie but
heck, it
> > sure is fun finding out!
> >
> > Remember! We are engineers, we don't just talk about it, we roll
around
> > in it!
>
> I will draw the timing diagram again just to make sure I am
not getting
> crazy :-) If you do not delay 4 times to read the first bit you
are in real
> trouble but besides that and noise in the line it has to work...
>
> Best regards,
> Alexandre Guimaraes
>
Alexandre,
First point: your English is excellent, so no worries on that front.
I used the term "lab" as a shorthand for saying something that'll
work in controlled circumstances. If your product will always work
in controlled circumstances (e.g. your UART is always used to
connect to a particular device of known characteristics), then I
agree, 3x sampling will work perfectly well. I agree it's not just a
lab curiosity: it will work. However, it will only work in known,
controlled circumstances.
My point about oversampling to filter noise is a minor point: you
may never see it in practice or may be happy to live with the very
rarely misread bit.
My major concern about 3x sampling is its poor behaviour where the
sender's clock is not exactly at the nominal bit rate: this is
common in practice. I'd suggest you look at your bit timings and
algorithm again where the receiver is working at 9600 bps, the
sender is sending at say 9310 bps (about 3% off), and the start bit
arrives immediately after a sample is taken.
There are three issues that I see with this:
1. If your product is one where someone can plug any device into it
(for example, any serial printer), then someone is bound to actually
do just that. Hence, if you have any volume of product in the field,
you'll get support issues (nobody will be the slightest bit
interested to hear that their printer that works with everything
else is in fact using incorrect timing on its serial port).
2. Even if the circumstances are controlled at the start, someone
may bring out a "rev 2" version of the unit to which the serial port
is connected, with less favorable characteristics.
3. By the nature of things, the soft UART that was developed for a
particular setup will possibly get re-used in some other product in
the future. If the knowledge that it only works in certain cases
is "lost", then the first you might hear of it is when those support
calls start coming in.
I completely take the point that in a lot of cases you have to
design for the fixed constraints in a system (in particular unit
cost), which drives you to use special knowledge about the system to
optimise resources (in this case processor capacity). You are after
all not designing a general purpose UART.
My point is that you need to be very aware of the limitations of a
particular design and secondly you should try if possible to make
designs work in is many circumstances as possible to take account of
future unanticipated changes.
Brendan
Reply by ●October 7, 20062006-10-07
--- In l..., "lpc2100_fan" wrote:
>
> --- In l..., syed ismail
wrote:
> >
> > Have a look at
> >
> >
www.semiconductors.philips.com/acrobat/applicationnotes/AN446.pdf
> >
This URL redirected to the www.nxp.com site and I put AN446.pdf
into its search field and it did not find it. I hope nxp makes
that work better in the future.
Thanks for the proper URL.
boB
>
> Please replace link with this one:
>
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/
an447.pdf
>
> This was written for 8051 but the principals still apply
>
> Bob
>
>
> --- In l..., syed ismail
wrote:
> >
> > Have a look at
> >
> >
www.semiconductors.philips.com/acrobat/applicationnotes/AN446.pdf
> >
This URL redirected to the www.nxp.com site and I put AN446.pdf
into its search field and it did not find it. I hope nxp makes
that work better in the future.
Thanks for the proper URL.
boB
>
> Please replace link with this one:
>
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/
an447.pdf
>
> This was written for 8051 but the principals still apply
>
> Bob
>
