On 2022-11-07 Rick C wrote in comp.arch.embedded:
> On Monday, November 7, 2022 at 1:20:33 PM UTC-4, Stef wrote:
>> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> > On Monday, November 7, 2022 at 6:55:27 AM UTC-4, Stef wrote:
>> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>> >> > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote:
>> >> >> On 11/6/22 8:56 AM, Rick C wrote:
>> >> >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing.
>> >> >> If the only way to handle a missed message is to abort the whole
>> >> >> software system, that seems to be a pretty bad system.
>> >> >
>> >> > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error.
>> >> I would not dare to implement a serial protocol without any form of
>> >> error checking, on any length of cable.
>> >>
>> >> You mention ESD somewhere. This can be a serious disturbance that can
>> >> easily corrupt a few bits.
>> >
>> > Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment.
>> >
>> You wrote:
>> "I could probably get away with TTL level signals, but I'd like to have
>> the ESD protection these RS-422 chips give. That additional noise
>> immunity means there is an extremely small chance of bit errors. If we
>> have problems, the error handling can be added."
>> This led me to believe you were expecting actual ESD discharges that
>> could disturb your messages.
>>
>> ESD protection is just that: protection against device damage
>>
>> I do not believe ESD protection does anything to improve noise immunity.
>> It just increases the ESD level at which the device will be damaged.
>
> Yes, you are right. My language there is poor. I should have said I prefer the noise immunity the RS-422 devices have compared to TTL devices *in addition to* the ESD immunity.
>
>
>> And if you have an ESD controlled environment, that is not actually
>> needed.
>
> In theory, but I can't control how these will be used in the future. ESD immunity is something I want designed into any application that is connected by a cable.
>

Yes, alway protect accessible parts.

>
>> >> Reminds me of a product where we got windows blue screens during ESD
>> >> testing on a device connected via an FTDI USB to serial adapter. Cable
>> >> length less than 6 feet.
>> >
>> > I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise.
>> No a device with an FTDI chip on it was tested. USB cable was <= 6 feet
>> and serial ports were only a few centimeters of TTL level PCB traces.
>> This was reproducable with an evaluation kit with only USB connected.
>
> So you were shooting high voltages into a device and were surprised the PC it was connected to crashed? I'm not following this at all. I'm pretty sure the FTDI cable is not rated to provide isolation. That has nothing to do with ESD protection. As you say, ESD protection is about damage, not operation.

Ofcourse not into a device. But all over the enclosure, as is required
to pass EMC testing. These discharges cause current spikes that can
induce currents in parts of your circuits. Part of ESD testing also uses
coupling planes, where you fire on a metal plate 'near' the device. That
can also give a lot of noise. All these things may not cause device
damage like direct ESD discharges, but they can disturb the device
operation. Depending on the expected performance level, this may cause a
fail. For medical devices you usually cannot get away with worse than
"temporary loss of function and recovery without operator intervention".

ESD protection is indeed about damage prevention. But passing an ESD
test usually requires more than just preventing damage.

How would you rate a phone that resets every time you pick it up when
you have not properly discharged yourself from static electricity? It
may just reboot and work fine after that, but it would still be a crappy
phone.

>> >> >> Note, if the master sends out a message, and waits for a response, with
>> >> >> a retry if the message is not replied to, that naturally puts a pause in
>> >> >> the communication bus for inter-message synchronization.
>> >> >
>> >> > The pause is already there by virtue of the protocol. Commands and replies are on different busses.
>> >> >
>> >> >
>> >> >> Based on your description, I can't imagine the master starting a message
>> >> >> for another slave until after the first one answers, or you will
>> >> >> interfere with the arbitration control of the reply bus.
>> >> >
>> >> > Exactly! Now you are starting to catch on.
>> >> So you do wait for a reply, and a reply is only expected on a valid
>> >> message? What if there is no reply, do you retry? If so, you already have
>> >> implemented some basic error checking. For more robustness you could (I
>> >> would) add some kind of CRC.
>> >
>> > There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance).
>> Okay, the slaves are already implemented? Missed that.
>
> A test fixture is in use, with software on the PC. There's no reason to change the protocol in the new test fixture and software unless there is a need, a new requirement.

Ah, existing stuff.

>> So there is some very basic error detection: the command must be valid.
>> And if it is not and the slave does not reply, what does the master do?
>
> The command being valid is based on as single character. The command is something like, "01 23 X<cr><lf>". I suppose the CR LF might also be required, but I don't recall. It might require one and ignore the other. The whole CR LF thing is such a PITA. The only character that is required for sure, is the "X", which at the moment can be one of three from the possible characters (don't recall if they are 8 bit or 7). I also don't recall if parity checking is used.

Okay, more restrictions on valid messages, yet more error detection
present already. ;-)

> I do know that I had a flaw in the initial setup that gave intermittent errors. I had the hardest time finding the problem because of using bias in where to look. I tried adding re-transmission, which helped, but it borked up the code pretty well. I guess my software skills are not so good. In the end, it was an Ariane problem where the UART in the FPGA was existing code that was reused. Thinking it was a previously validated module, it was not suspected... at all. Eventually I realized it did not include the input FF synchronization to absolve race conditions. That was left for the system designer to add, since there may be more than one device on the same input.
>
> Since that was solved, we've tested thousands of UUTs with no interface bit errors. So I have no worries about this.
>
>
>> > Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing.
>> A test rig that ignores errors. I don't know the requirements of this
>> test and how bad it would be to have an invalid pass/fail result.
>
> Since the test will be run, over night, every few seconds, with all UUT errors logged, the chances of the same bit error happening the same way, causing the same miss of a UUT failure some thousands of time (about 7,000), is on the order as a proton decaying. Well, maybe a bit more likely.
>

Another layer of error detection. ;-)

>
>> > On the Apollo moon missions, they took no precautions against damage from micrometeoroids, because the effort required was not commensurate with the likelihood of the event.
>> I am not sure what they could have done, but adding effective shields
>> would probably have prohibitive weight consequences, if at all possible.
>> But if you can believe the movie Apollo 13, thre is a real danger from
>> micrometeorites.
>
> Real, even if very small danger. That's the point. In this case, the impact is small, the likelihood is small, and the work to mitigate the problem is far more effort than justifiable, no matter how emotional people may get about "Errors! OMG, there may be ERRORS!"
>
> Maybe I need a heavy duty cabinet to protect against the very real possibility of meteors?
>
> https://abc7chicago.com/meteor-california-destroys-home-shower/12425011/
>

On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote:
> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> > On Monday, November 7, 2022 at 12:57:27 PM UTC-4, Stef wrote:
> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >> > On Monday, November 7, 2022 at 7:07:43 AM UTC-4, Stef wrote:
> >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >> >> > On Monday, November 7, 2022 at 5:26:06 AM UTC-5, Stef wrote:
> >> >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >> >> >
> >> >> > I care. Don't you?
> >> >> No, I don't. We do use FTDI chips in our designs to interface a serial
> >> >> port to USB. And we also use ready made FTDI cables. We use these chips
> >> >> and cables based on their specifications in datasheets and user guides
> >> >> etc. I have never felt the need to invesitigate how the UART/USB
> >> >> functionality was actually implemented inside the chip. What would I do
> >> >> with this knowledge? In a design I must rely on the behaviour as
> >> >> specified in the datasheet.
> >> >
> >> > It's hard to imagine an engineer with no curiosity.
> >> Yes, that's hard. But imagining an engineer who does not care about the
> >> internal structure of every single chip he uses is a lot easier (for
> >> me). I tend to focus my curiiosity on things that matter to me, don't
> >> you?
> >
> > By definition curiosity is, "an eager desire to know or learn about something". That's not limited to things I *need* to know about. In fact, I don't limit my curiosity at all. It's a desire, not an act.
> >
> Learn about something != learn about everything
> Matter to me != *need* to know about
>
> My not caring abbout the innards of a particular chip seems to let you
> think I don't care about anything. But we are not discussing my
> interests here, but your bus.

Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts.

--

Rick C.

----- Get 1,000 miles of free Supercharging
----- Tesla referral code - https://ts.la/richard1120

On Monday, November 7, 2022 at 5:04:29 PM UTC-4, Stef wrote:
> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> > On Monday, November 7, 2022 at 1:20:33 PM UTC-4, Stef wrote:
> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >> > On Monday, November 7, 2022 at 6:55:27 AM UTC-4, Stef wrote:
> >> >> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> >> >> > On Sunday, November 6, 2022 at 6:34:59 PM UTC-5, Richard Damon wrote:
> >> >> >> On 11/6/22 8:56 AM, Rick C wrote:
> >> >> >> > There's no point to inter-message delays. If there is an error that causes a loss of framing, the devices will see that and ignore the message. As I've said, the real issue is that the message will not be responded to, and the software will fail. At that point the user will exit the software on the PC and start over. That gives a nice long delay for resyncing.
> >> >> >> If the only way to handle a missed message is to abort the whole
> >> >> >> software system, that seems to be a pretty bad system.
> >> >> >
> >> >> > You would certainly think that if your error rate was more than once a hundred years. I expect to be long dead before an RS-422 bus only 10 feet long burps a bit error.
> >> >> I would not dare to implement a serial protocol without any form of
> >> >> error checking, on any length of cable.
> >> >>
> >> >> You mention ESD somewhere. This can be a serious disturbance that can
> >> >> easily corrupt a few bits.
> >> >
> >> > Yes, I mentioned ESD somewhere. This is testing newly constructed circuit boards, so is used in an ESD controlled environment.
> >> >
> >> You wrote:
> >> "I could probably get away with TTL level signals, but I'd like to have
> >> the ESD protection these RS-422 chips give. That additional noise
> >> immunity means there is an extremely small chance of bit errors. If we
> >> have problems, the error handling can be added."
> >> This led me to believe you were expecting actual ESD discharges that
> >> could disturb your messages.
> >>
> >> ESD protection is just that: protection against device damage
> >>
> >> I do not believe ESD protection does anything to improve noise immunity.
> >> It just increases the ESD level at which the device will be damaged.
> >
> > Yes, you are right. My language there is poor. I should have said I prefer the noise immunity the RS-422 devices have compared to TTL devices *in addition to* the ESD immunity.
> >
> >
> >> And if you have an ESD controlled environment, that is not actually
> >> needed.
> >
> > In theory, but I can't control how these will be used in the future. ESD immunity is something I want designed into any application that is connected by a cable.
> >
> Yes, alway protect accessible parts.
> >
> >> >> Reminds me of a product where we got windows blue screens during ESD
> >> >> testing on a device connected via an FTDI USB to serial adapter. Cable
> >> >> length less than 6 feet.
> >> >
> >> > I assume you mean some other device was being ESD tested? This is not being used in an ESD testing lab. Was the FTDI serial cable RS-232 by any chance? Being single ended, that is much less tolerant of noise.
> >> No a device with an FTDI chip on it was tested. USB cable was <= 6 feet
> >> and serial ports were only a few centimeters of TTL level PCB traces.
> >> This was reproducable with an evaluation kit with only USB connected.
> >
> > So you were shooting high voltages into a device and were surprised the PC it was connected to crashed? I'm not following this at all. I'm pretty sure the FTDI cable is not rated to provide isolation. That has nothing to do with ESD protection. As you say, ESD protection is about damage, not operation.
> Ofcourse not into a device. But all over the enclosure, as is required
> to pass EMC testing. These discharges cause current spikes that can
> induce currents in parts of your circuits. Part of ESD testing also uses
> coupling planes, where you fire on a metal plate 'near' the device. That
> can also give a lot of noise. All these things may not cause device
> damage like direct ESD discharges, but they can disturb the device
> operation. Depending on the expected performance level, this may cause a
> fail. For medical devices you usually cannot get away with worse than
> "temporary loss of function and recovery without operator intervention".
>
> ESD protection is indeed about damage prevention. But passing an ESD
> test usually requires more than just preventing damage.
>
> How would you rate a phone that resets every time you pick it up when
> you have not properly discharged yourself from static electricity? It
> may just reboot and work fine after that, but it would still be a crappy
> phone.

Lol! I probably would barely notice! Cell phones are among the most unreliable devices we use with any regularity. I recall a Dave Barry article that was talking about cell phones which he mocked by describing typical conversations as, "What? WHAT?" Now, it's more like, "Hello...? Hello...? <click>"

> >> >> >> Note, if the master sends out a message, and waits for a response, with
> >> >> >> a retry if the message is not replied to, that naturally puts a pause in
> >> >> >> the communication bus for inter-message synchronization.
> >> >> >
> >> >> > The pause is already there by virtue of the protocol. Commands and replies are on different busses.
> >> >> >
> >> >> >
> >> >> >> Based on your description, I can't imagine the master starting a message
> >> >> >> for another slave until after the first one answers, or you will
> >> >> >> interfere with the arbitration control of the reply bus.
> >> >> >
> >> >> > Exactly! Now you are starting to catch on.
> >> >> So you do wait for a reply, and a reply is only expected on a valid
> >> >> message? What if there is no reply, do you retry? If so, you already have
> >> >> implemented some basic error checking. For more robustness you could (I
> >> >> would) add some kind of CRC.
> >> >
> >> > There should not be any messages other than "valid" messages. I don't recall specifically what the slave does on messages with bit errors, but I'm pretty sure it simply doesn't know they have bit errors. The message has no checksum or other bit error control. The format has one character to indicate the "command" type. If that character is corrupted, the command is not used, unless it is changed to another valid character (3 of 256 chance)..
> >> Okay, the slaves are already implemented? Missed that.
> >
> > A test fixture is in use, with software on the PC. There's no reason to change the protocol in the new test fixture and software unless there is a need, a new requirement.
> Ah, existing stuff.

Yes, the very first sentence of the very first post was, "I have a test fixture that uses RS-232 to communicate with a PC."

> >> So there is some very basic error detection: the command must be valid..
> >> And if it is not and the slave does not reply, what does the master do?
> >
> > The command being valid is based on as single character. The command is something like, "01 23 X<cr><lf>". I suppose the CR LF might also be required, but I don't recall. It might require one and ignore the other. The whole CR LF thing is such a PITA. The only character that is required for sure, is the "X", which at the moment can be one of three from the possible characters (don't recall if they are 8 bit or 7). I also don't recall if parity checking is used.
> Okay, more restrictions on valid messages, yet more error detection
> present already. ;-) No real detection since there's no awareness of the error. It's like saying your transmission has "error detection" because it can stop working because a gear tooth broke off and jammed the whole transmission breaking more gears.

> > I do know that I had a flaw in the initial setup that gave intermittent errors. I had the hardest time finding the problem because of using bias in where to look. I tried adding re-transmission, which helped, but it borked up the code pretty well. I guess my software skills are not so good. In the end, it was an Ariane problem where the UART in the FPGA was existing code that was reused. Thinking it was a previously validated module, it was not suspected... at all. Eventually I realized it did not include the input FF synchronization to absolve race conditions. That was left for the system designer to add, since there may be more than one device on the same input..
> >
> > Since that was solved, we've tested thousands of UUTs with no interface bit errors. So I have no worries about this.
> >
> >
> >> > Again, there's no reason to "detect" errors since I've implemented no error protocol. That is many times more complex than simply ignoring the errors, which works because errors don't happen often enough to have an impact on testing.
> >> A test rig that ignores errors. I don't know the requirements of this
> >> test and how bad it would be to have an invalid pass/fail result.
> >
> > Since the test will be run, over night, every few seconds, with all UUT errors logged, the chances of the same bit error happening the same way, causing the same miss of a UUT failure some thousands of time (about 7,000), is on the order as a proton decaying. Well, maybe a bit more likely.
> >
> Another layer of error detection. ;-)

On 2022-11-07 Rick C wrote in comp.arch.embedded:
> On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote:
....
>> My not caring abbout the innards of a particular chip seems to let you
>> think I don't care about anything. But we are not discussing my
>> interests here, but your bus.
>
> Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts.

That was not my intention. It seemed to me that you cared about the
internal implementation of the FTDI chip in relation to your bus
problem. I just wanted to point out that is of no concern for your bus
operation. And then I just got dragged in. ;-)

--
Stef

He's the kind of guy, that, well, if you were ever in a jam he'd
be there... with two slices of bread and some chunky peanut butter.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> I could shove the details of tests into the FPGAs, so the commands are
> more like, run test 1 on channel number 2. That would cut the number
> of tests significantly, but require much more work in updating the
> FPGA software.

Are we circling back to the idea putting a microprocessor on the test
board? Ivan Sutherland famously called this a wheel of reincarnation:

http://www.cap-lore.com/Hardware/Wheel.html

On 11/7/22 11:05 AM, Rick C wrote:
> On Monday, November 7, 2022 at 6:00:09 AM UTC-4, Stef wrote:
>> On 2022-11-05 Rick C wrote in comp.arch.embedded:
>>> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote:
>>>
>>>> In UART communication, this is handled at the protocol level rather than
>>>> the hardware (though some UART hardware may have "idle detect" signals
>>>> when more than 11 bits of high level are seen in a row). Some
>>>> UART-based protocols also use a "break" signal between frames - that is
>>>> a string of at least 11 bits of low level.
>>>>
>>>> If you do not have such pauses, and a receiver is out of step,
>>>
>>> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"?
>> I have seen this happen in long messages (few kB) with no pauses between
>> characters and transmitter and receiver set to 8,N,1. It seemed that the
>> receiver needed the complete stop bit and then immediately saw the low
>> of the next start bit. Detecting the edge when it was ready to see it,
>> not when it actually happened. When the receiver is slightly slower than
>> the transmitter, this caused the detection of the start bit (and
>> therefor the whole character) to shift a tiny bit. This added up over
>> the character stream until it eventually failed.
>>
>> Lowering the baud rate did not solve the issue, but inserting pauses
>> after a number of chars did. What also solved it was setting the
>> transmitter to 2 stop bits and the receiver to one stop bit. This was a
>> one way stream and this may not be possible on a bi-directional stream.
>>
>> I would expect a sensible UART implementation to allow for a slightly
>> shorter stop bit to compensate for issues like this. But apparently this
>> UART did not do so in the 1 stop bit setting. I have not tested if
>> setting both ends to 2 stop bits also solved the problem.
>
> If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip. That gives up to ±5% combined timing error tolerance.
>
> If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%.
>
> That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control.
>
> You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver.
>

YOU may consider it a design flaw, but I have seen too many serial ports
having this flaw in them to just totally ignore it.

Yes, the "robust" design will allow for a short stop bit, but you can't
count on all serial adaptors allowing for it.

Part of the problem is that (at least as far as I know) the Asynchronous
Serial Format isn't actually a "Published Standard", but just an
de-facto protocol that is simple enough that it mostly just works, but
still hides a few gotchas for corner cases.

On Monday, November 7, 2022 at 7:07:50 PM UTC-4, Stef wrote:
> On 2022-11-07 Rick C wrote in comp.arch.embedded:
> > On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote:
> ...
> >> My not caring abbout the innards of a particular chip seems to let you
> >> think I don't care about anything. But we are not discussing my
> >> interests here, but your bus.
> >
> > Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts.
> That was not my intention. It seemed to me that you cared about the
> internal implementation of the FTDI chip in relation to your bus
> problem. I just wanted to point out that is of no concern for your bus
> operation. And then I just got dragged in. ;-)

I'm always curious about how things are implemented. I thought I had heard somewhere that the FTDI chip was a fast, but small processor. I design those for use in FPGA designs and they can be very effective. Often the code is very minimal.

--

Rick C.

---+- Get 1,000 miles of free Supercharging
---+- Tesla referral code - https://ts.la/richard11209

On Monday, November 7, 2022 at 7:14:56 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes:
> > I could shove the details of tests into the FPGAs, so the commands are
> > more like, run test 1 on channel number 2. That would cut the number
> > of tests significantly, but require much more work in updating the
> > FPGA software.

That should have been, "cut back the number of commands".

> Are we circling back to the idea putting a microprocessor on the test
> board? Ivan Sutherland famously called this a wheel of reincarnation:
>
> http://www.cap-lore.com/Hardware/Wheel.html

Zero need for a processor in the FPGA at this point. At least the need for a conventional processor. The commands are things like, assert pin X, read pin Y. A test of some basic functionality that could be debugged separately from other tests would be a few of these instructions. Very easy to do in an FPGA by using memory blocks and stepping through the commands. But I'm open to a processor. It would be one of my own design, however.

--

Rick C.

---++ Get 1,000 miles of free Supercharging
---++ Tesla referral code - https://ts.la/richard11209

On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote:
> On 11/7/22 11:05 AM, Rick C wrote:
> > On Monday, November 7, 2022 at 6:00:09 AM UTC-4, Stef wrote:
> >> On 2022-11-05 Rick C wrote in comp.arch.embedded:
> >>> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote:
> >>>
> >>>> In UART communication, this is handled at the protocol level rather than
> >>>> the hardware (though some UART hardware may have "idle detect" signals
> >>>> when more than 11 bits of high level are seen in a row). Some
> >>>> UART-based protocols also use a "break" signal between frames - that is
> >>>> a string of at least 11 bits of low level.
> >>>>
> >>>> If you do not have such pauses, and a receiver is out of step,
> >>>
> >>> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"?
> >> I have seen this happen in long messages (few kB) with no pauses between
> >> characters and transmitter and receiver set to 8,N,1. It seemed that the
> >> receiver needed the complete stop bit and then immediately saw the low
> >> of the next start bit. Detecting the edge when it was ready to see it,
> >> not when it actually happened. When the receiver is slightly slower than
> >> the transmitter, this caused the detection of the start bit (and
> >> therefor the whole character) to shift a tiny bit. This added up over
> >> the character stream until it eventually failed.
> >>
> >> Lowering the baud rate did not solve the issue, but inserting pauses
> >> after a number of chars did. What also solved it was setting the
> >> transmitter to 2 stop bits and the receiver to one stop bit. This was a
> >> one way stream and this may not be possible on a bi-directional stream..
> >>
> >> I would expect a sensible UART implementation to allow for a slightly
> >> shorter stop bit to compensate for issues like this. But apparently this
> >> UART did not do so in the 1 stop bit setting. I have not tested if
> >> setting both ends to 2 stop bits also solved the problem.
> >
> > If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip.. That gives up to ±5% combined timing error tolerance.
> >
> > If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%.
> >
> > That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control..
> >
> > You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver.
> >
> YOU may consider it a design flaw, but I have seen too many serial ports
> having this flaw in them to just totally ignore it.

That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock.

I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format.. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error.

> Yes, the "robust" design will allow for a short stop bit, but you can't
> count on all serial adaptors allowing for it.

There's always garbage designs. I'm surprised I never ran into one. I guess being crystal controlled, there was never enough error to add up to a bit.

> Part of the problem is that (at least as far as I know) the Asynchronous
> Serial Format isn't actually a "Published Standard", but just an
> de-facto protocol that is simple enough that it mostly just works, but
> still hides a few gotchas for corner cases.

True, but anyone designing chips should understand what they are designing. If they don't, you get garbage. I learned that lesson in a class in school where I screwed up a detail on a program I wrote, because I didn't understand the spec. I've always tried to ask questions since and even if they seem like stupid questions, I don't read the specs wrong.

--

Rick C.

--+-- Get 1,000 miles of free Supercharging
--+-- Tesla referral code - https://ts.la/richard11209

On 08/11/2022 01:50, Rick C wrote:
> On Monday, November 7, 2022 at 7:07:50 PM UTC-4, Stef wrote:
>> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>>> On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote:
>> ...
>>>> My not caring abbout the innards of a particular chip seems to
>>>> let you think I don't care about anything. But we are not
>>>> discussing my interests here, but your bus.
>>>
>>> Seems to me you wanted to talk about my interests when you said,
>>> "Why are you discussing this?" and then continued discussing that
>>> issue for some half dozen more posts.
>> That was not my intention. It seemed to me that you cared about
>> the internal implementation of the FTDI chip in relation to your
>> bus problem. I just wanted to point out that is of no concern for
>> your bus operation. And then I just got dragged in. ;-)
>
> I'm always curious about how things are implemented. I thought I had
> heard somewhere that the FTDI chip was a fast, but small processor.
> I design those for use in FPGA designs and they can be very
> effective. Often the code is very minimal.
>

There's nothing wrong with curiosity. However, I have no doubt that you
heard wrong, or heard about different FTDI devices, or that your source
heard wrong. FTDI have been making these things for a couple of
decades, since the earliest days of USB. You can be sure they are
hardware peripherals, not software.

For /you/, and /your/ designs in FPGAs, adding a small processor can be
a good solution. The balance is different for ASICs and for dedicated
silicon, and it is different now than it was when FTDI made their MPSE
block for use in their devices.

Really, we are not talking about a peripheral that is much more advanced
than common serial communication blocks. It multiplexes a UART, an SPI
and an I²C on the same pins. That's it. You don't bother with a
processor and software for that.

FTDI /do/ make devices using embedded processors, with a few different
types (I forget which - perhaps Tensila cores). But those are other chips.

On 11/7/22 8:15 PM, Rick C wrote:
> On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote:
>> On 11/7/22 11:05 AM, Rick C wrote:
>>> On Monday, November 7, 2022 at 6:00:09 AM UTC-4, Stef wrote:
>>>> On 2022-11-05 Rick C wrote in comp.arch.embedded:
>>>>> On Saturday, November 5, 2022 at 6:58:24 AM UTC-4, David Brown wrote:
>>>>>
>>>>>> In UART communication, this is handled at the protocol level rather than
>>>>>> the hardware (though some UART hardware may have "idle detect" signals
>>>>>> when more than 11 bits of high level are seen in a row). Some
>>>>>> UART-based protocols also use a "break" signal between frames - that is
>>>>>> a string of at least 11 bits of low level.
>>>>>>
>>>>>> If you do not have such pauses, and a receiver is out of step,
>>>>>
>>>>> You have failed to explain how a receiver would get "out of step". The receiver syncs to every character transmitted. If all characters are received, what else do you need? How does it get "out of step"?
>>>> I have seen this happen in long messages (few kB) with no pauses between
>>>> characters and transmitter and receiver set to 8,N,1. It seemed that the
>>>> receiver needed the complete stop bit and then immediately saw the low
>>>> of the next start bit. Detecting the edge when it was ready to see it,
>>>> not when it actually happened. When the receiver is slightly slower than
>>>> the transmitter, this caused the detection of the start bit (and
>>>> therefor the whole character) to shift a tiny bit. This added up over
>>>> the character stream until it eventually failed.
>>>>
>>>> Lowering the baud rate did not solve the issue, but inserting pauses
>>>> after a number of chars did. What also solved it was setting the
>>>> transmitter to 2 stop bits and the receiver to one stop bit. This was a
>>>> one way stream and this may not be possible on a bi-directional stream.
>>>>
>>>> I would expect a sensible UART implementation to allow for a slightly
>>>> shorter stop bit to compensate for issues like this. But apparently this
>>>> UART did not do so in the 1 stop bit setting. I have not tested if
>>>> setting both ends to 2 stop bits also solved the problem.
>>>
>>> If a UART receiver can not properly receive a message like this, it is defective. The point of the start and stop bits are to provide the synchronization. The receiver simply needs to detect the stop be state (by sampling where the receiver thinks is the middle of the bit) and then immediately start looking for the leading edge of the next start bit. The receiver will then be synchronized to the new character bit timing and it will never slip. That gives up to ±5% combined timing error tolerance.
>>>
>>> If the receiver waits until a later time, such as the expected end of the received stop bit, to start looking for a start bit leading edge, it will not be able to tolerate a timing error where the transmitter is faster than the receiver making the timing tolerance unipolar, i.e. 5% rather than ±5%.
>>>
>>> That's a receiver design flaw, or the transmitter is sending short stop bits, which you can easily see on the scope with a delayed trigger control.
>>>
>>> You should be able to diagnose which end has the problem by connecting a different type of receiver to the stream. If a different receiver UART is able to receive the messages without fault, the problem is obviously the failing receiver.
>>>
>> YOU may consider it a design flaw, but I have seen too many serial ports
>> having this flaw in them to just totally ignore it.
>
> That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock.

Depends on how you design it. IF you start a counter at the leading edge
of the start bit and then detect the counter at its middle value, then
the stop bit ends when the counter finally expires at the END of the
stop bit.

>
> I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error.

IF you don't start the looking for the start bit until the time has
passed for the END of the stop bit, and the receiver is 0.1% slow, then
every bit you lose 0.1% of a bit, or 1% per character, so after 50
consecutive characters you are 1/2 a bit late, and getting errors.

>
>
>> Yes, the "robust" design will allow for a short stop bit, but you can't
>> count on all serial adaptors allowing for it.
>
> There's always garbage designs. I'm surprised I never ran into one. I guess being crystal controlled, there was never enough error to add up to a bit.

As I pointed out, 0.1% means 50 characters. 0.001% means 5000
characters, long enough string of characters and eventually you hit the
problem.

If you only use short messages, you never have a problem.

>
>
>> Part of the problem is that (at least as far as I know) the Asynchronous
>> Serial Format isn't actually a "Published Standard", but just an
>> de-facto protocol that is simple enough that it mostly just works, but
>> still hides a few gotchas for corner cases.
>
> True, but anyone designing chips should understand what they are designing. If they don't, you get garbage. I learned that lesson in a class in school where I screwed up a detail on a program I wrote, because I didn't understand the spec. I've always tried to ask questions since and even if they seem like stupid questions, I don't read the specs wrong.
>

The problem is that if you describe the sampling as "Middle of bit",
then going to the end of the stop bit makes sense.

If you are adding functionality like RS-485 control that needs to know
when that end of bit is, and it is easy to forget that the receiver has
different needs than the transmitter.

On 11/7/22 7:50 PM, Rick C wrote:
> On Monday, November 7, 2022 at 7:07:50 PM UTC-4, Stef wrote:
>> On 2022-11-07 Rick C wrote in comp.arch.embedded:
>>> On Monday, November 7, 2022 at 4:30:37 PM UTC-4, Stef wrote:
>> ...
>>>> My not caring abbout the innards of a particular chip seems to let you
>>>> think I don't care about anything. But we are not discussing my
>>>> interests here, but your bus.
>>>
>>> Seems to me you wanted to talk about my interests when you said, "Why are you discussing this?" and then continued discussing that issue for some half dozen more posts.
>> That was not my intention. It seemed to me that you cared about the
>> internal implementation of the FTDI chip in relation to your bus
>> problem. I just wanted to point out that is of no concern for your bus
>> operation. And then I just got dragged in. ;-)
>
> I'm always curious about how things are implemented. I thought I had heard somewhere that the FTDI chip was a fast, but small processor. I design those for use in FPGA designs and they can be very effective. Often the code is very minimal.
>

The key is that if it is specified to have a quick Disable at end of
transimition capability, then you can count on that, and not say it is
up to the speed of the program to turn of the transmitter.

Sometimes we hit a blurry line between what is really a general purpose
computer and what is a FSM doing an operation.

Ultimately, we need to look at the specifications of performance to
decide what we need to do.

On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote:
> On 11/7/22 8:15 PM, Rick C wrote:
> > On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote:
> >> YOU may consider it a design flaw, but I have seen too many serial ports
> >> having this flaw in them to just totally ignore it.
> >
> > That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock.
> Depends on how you design it. IF you start a counter at the leading edge
> of the start bit and then detect the counter at its middle value, then
> the stop bit ends when the counter finally expires at the END of the
> stop bit.

There is still some extra logic to distinguish the condition. There is a bit timing counter, and a counter to track which bit you are in. Everything happening in the operation of the UART is happening at the middle of a bit.. Then you need extra logic to distinguish the end of a bit.

> > I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error.
> IF you don't start the looking for the start bit until the time has
> passed for the END of the stop bit, and the receiver is 0.1% slow, then
> every bit you lose 0.1% of a bit, or 1% per character, so after 50
> consecutive characters you are 1/2 a bit late, and getting errors.

There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah.

I recall the Intel USART was such a part for other technical flaws. So they finally came out with a new version that fixed the problems.

> >> Yes, the "robust" design will allow for a short stop bit, but you can't
> >> count on all serial adaptors allowing for it.
> >
> > There's always garbage designs. I'm surprised I never ran into one. I guess being crystal controlled, there was never enough error to add up to a bit.
> As I pointed out, 0.1% means 50 characters. 0.001% means 5000
> characters, long enough string of characters and eventually you hit the
> problem.
>
> If you only use short messages, you never have a problem.

You mean if you have gaps with idle time.

> >> Part of the problem is that (at least as far as I know) the Asynchronous
> >> Serial Format isn't actually a "Published Standard", but just an
> >> de-facto protocol that is simple enough that it mostly just works, but
> >> still hides a few gotchas for corner cases.
> >
> > True, but anyone designing chips should understand what they are designing. If they don't, you get garbage. I learned that lesson in a class in school where I screwed up a detail on a program I wrote, because I didn't understand the spec. I've always tried to ask questions since and even if they seem like stupid questions, I don't read the specs wrong.
> >
> The problem is that if you describe the sampling as "Middle of bit",
> then going to the end of the stop bit makes sense.

Sorry, you are not clear. This doesn't make sense to me. What is "going to the end of the stop bit"?

> If you are adding functionality like RS-485 control that needs to know
> when that end of bit is, and it is easy to forget that the receiver has
> different needs than the transmitter.

???

--

Rick C.

--+-+ Get 1,000 miles of free Supercharging
--+-+ Tesla referral code - https://ts.la/richard11209

On 9/11/22 00:50, Rick C wrote:
> On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote:
>> IF you don't start the looking for the start bit until the time has
>> passed for the END of the stop bit, and the receiver is 0.1% slow, then
>> every bit you lose 0.1% of a bit, or 1% per character, so after 50
>> consecutive characters you are 1/2 a bit late, and getting errors.
>
> There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah.

Yeah, but you can still insist that the stop bit fills 99%, or 90% of
the required time, and not get that pathology.

This is a branch of the principle "be rigorous in what you produce,
permissive in what you accept". I've personally moved away from that
principle - I think being permissive too often just masks problems until
they re-occur downstream but cannot be diagnosed there. So I'm much more
willing to reject bad input (or to complain but still accept it) early on.

CH

On Tuesday, November 8, 2022 at 7:45:14 PM UTC-4, Clifford Heath wrote:
> On 9/11/22 00:50, Rick C wrote:
> > On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote:
> >> IF you don't start the looking for the start bit until the time has
> >> passed for the END of the stop bit, and the receiver is 0.1% slow, then
> >> every bit you lose 0.1% of a bit, or 1% per character, so after 50
> >> consecutive characters you are 1/2 a bit late, and getting errors.
> >
> > There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah.
> Yeah, but you can still insist that the stop bit fills 99%, or 90% of
> the required time, and not get that pathology.

I'm not clear on what you are saying. The larger the clock difference, the earlier the receiver has to look for the start bit. It will work just fine with the start bit check being delayed until the end of the stop bit, as long as the timing clocks aren't offset in one direction. Looking for the start bit in the middle of the stop bit gives a total of 5% tolerance, pretty much taking mistiming out of the list of problems for async data transmission. Drop that to 0.05% (your 99% example) and you are in the realm of crystal timing error on the two systems, ±250 ppm.

--

Rick C.

--++- Get 1,000 miles of free Supercharging
--++- Tesla referral code - https://ts.la/richard11209

On 9/11/22 11:46, Rick C wrote:
> On Tuesday, November 8, 2022 at 7:45:14 PM UTC-4, Clifford Heath wrote:
>> On 9/11/22 00:50, Rick C wrote:
>>> On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote:
>>>> IF you don't start the looking for the start bit until the time has
>>>> passed for the END of the stop bit, and the receiver is 0.1% slow, then
>>>> every bit you lose 0.1% of a bit, or 1% per character, so after 50
>>>> consecutive characters you are 1/2 a bit late, and getting errors.
>>>
>>> There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah.
>> Yeah, but you can still insist that the stop bit fills 99%, or 90% of
>> the required time, and not get that pathology.
>
> I'm not clear on what you are saying. The larger the clock difference, the earlier the receiver has to look for the start bit. It will work just fine with the start bit check being delayed until the end of the stop bit, as long as the timing clocks aren't offset in one direction. Looking for the start bit in the middle of the stop bit gives a total of 5% tolerance, pretty much taking mistiming out of the list of problems for async data transmission. Drop that to 0.05% (your 99% example) and you are in the realm of crystal timing error on the two systems, ±250 ppm.
>

Go back to the first words I quoted from Richard:

"
IF you don't start the looking for the start bit until the time has
passed for the END of the stop bit, and the receiver is 0.1% slow, then
every bit you lose 0.1% of a bit
"

But if you wait until 95% of the stop bit time, and allow a new start
bit to come early by 5%, then it doesn't matter if "the receiver is 0.1%
slow" and you don't lose sync; the 5% early doesn't mount up over "50
consecutive characters".

Same if you wait 99% and the new start bit is only 1% early.

So your "There you go! You have just proven..." was a bogus situation
proposed by Richard, that's trivially avoided, and basically all actual
UARTs will do that,

On Wednesday, November 9, 2022 at 7:32:25 AM UTC-4, Clifford Heath wrote:
> On 9/11/22 11:46, Rick C wrote:
> > On Tuesday, November 8, 2022 at 7:45:14 PM UTC-4, Clifford Heath wrote:
> >> On 9/11/22 00:50, Rick C wrote:
> >>> On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote:
> >>>> IF you don't start the looking for the start bit until the time has
> >>>> passed for the END of the stop bit, and the receiver is 0.1% slow, then
> >>>> every bit you lose 0.1% of a bit, or 1% per character, so after 50
> >>>> consecutive characters you are 1/2 a bit late, and getting errors.
> >>>
> >>> There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah.
> >> Yeah, but you can still insist that the stop bit fills 99%, or 90% of
> >> the required time, and not get that pathology.
> >
> > I'm not clear on what you are saying. The larger the clock difference, the earlier the receiver has to look for the start bit. It will work just fine with the start bit check being delayed until the end of the stop bit, as long as the timing clocks aren't offset in one direction. Looking for the start bit in the middle of the stop bit gives a total of 5% tolerance, pretty much taking mistiming out of the list of problems for async data transmission. Drop that to 0.05% (your 99% example) and you are in the realm of crystal timing error on the two systems, ±250 ppm.
> >
> Go back to the first words I quoted from Richard:
> "
> IF you don't start the looking for the start bit until the time has
> passed for the END of the stop bit, and the receiver is 0.1% slow, then
> every bit you lose 0.1% of a bit
> "
> But if you wait until 95% of the stop bit time, and allow a new start
> bit to come early by 5%, then it doesn't matter if "the receiver is 0.1%
> slow" and you don't lose sync; the 5% early doesn't mount up over "50
> consecutive characters".
>
> Same if you wait 99% and the new start bit is only 1% early.
>
> So your "There you go! You have just proven..." was a bogus situation
> proposed by Richard, that's trivially avoided, and basically all actual
> UARTs will do that,

If you cherry pick your numbers, you can make anything work. Looking for a start bit at the middle of the stop bit gives you the ±5% tolerance of timing. If you delay when you start looking for a start bit, you reduce this tolerance. So, in that case, if you are happy to provide a ±0.1% tolerance clock under all conditions, then sure, you can look for the start bit later. In the real world, there are users who expect a UART to work the way it is supposed to work, and use less accurate timing references than a crystal. This UART won't work for them and that would become known to users in general. While a claim has been made that such UARTs exist, no one has provided information about one.

I would also point out that the above timing analysis is not actually worse case since it does not take into account the 1/16th or 1/8th bit jitter from the first character start bit detection. So the requirements on the timing reference are even tighter when using the sloppy timing for start bit checking.

On 11/8/22 8:50 AM, Rick C wrote:
> On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote:
>> On 11/7/22 8:15 PM, Rick C wrote:
>>> On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote:
>>>> YOU may consider it a design flaw, but I have seen too many serial ports
>>>> having this flaw in them to just totally ignore it.
>>>
>>> That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock.
>> Depends on how you design it. IF you start a counter at the leading edge
>> of the start bit and then detect the counter at its middle value, then
>> the stop bit ends when the counter finally expires at the END of the
>> stop bit.
>
> There is still some extra logic to distinguish the condition. There is a bit timing counter, and a counter to track which bit you are in. Everything happening in the operation of the UART is happening at the middle of a bit. Then you need extra logic to distinguish the end of a bit.

Nope, simplest logic is to have your 8x sub-bit counter start at 0 and
count up starting on the leading edge, on the count values of 3, 4, and
5 you sample the bit for noise detection, and roll over from 7 to 0 for
the next bit, and count to the next bit. You stop the counter when it
rolls from 7 to 0 in the stop bit, and counts past the stop bit.

>
>
>>> I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error.
>> IF you don't start the looking for the start bit until the time has
>> passed for the END of the stop bit, and the receiver is 0.1% slow, then
>> every bit you lose 0.1% of a bit, or 1% per character, so after 50
>> consecutive characters you are 1/2 a bit late, and getting errors.
>
> There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah.

Except that we have bought many USB serial ports with just this flaw in
them.

So I guess the nobody actually exists.

Seem to be based on an FTDI chip, but maybe just a "look alike", where
they did bare minimum design work.

The key point is that very few applications actually do have very long
uninterrupted sequences of characters, and typical PCs will tend to
naturally add small spaces just becuase the OS isn't that great. Doesn't
require much to fix the issue.

>
> I recall the Intel USART was such a part for other technical flaws. So they finally came out with a new version that fixed the problems.
>
>

On Thursday, November 10, 2022 at 12:46:03 AM UTC-4, Richard Damon wrote:
> On 11/8/22 8:50 AM, Rick C wrote:
> > On Tuesday, November 8, 2022 at 7:54:59 AM UTC-4, Richard Damon wrote:
> >> On 11/7/22 8:15 PM, Rick C wrote:
> >>> On Monday, November 7, 2022 at 8:02:19 PM UTC-4, Richard Damon wrote:
> >>>> YOU may consider it a design flaw, but I have seen too many serial ports
> >>>> having this flaw in them to just totally ignore it.
> >>>
> >>> That is exceedingly hard to imagine, since it would take extra logic to implement. The logic of a UART is to first, detect the start bit which lands the state machine in the middle of said start bit which then times to the middle of all subsequent bits (ignoring timing accuracy). So it thinks it is in the middle of the stop bit when the bit timing is complete. It would need to have more hardware to time to the end of the stop bit. This might be present, for other purposes, but it should not be used to control looking for the start bit. This is by definition of the async protocol, to use the stop bit time to resync to the next start bit. Any device that does not start looking for a new start bit at the point it thinks is the middle of the stop bit, is defective by definition and will never work properly with timing mismatches of one polarity, the receiver's clock being slower than the transmitter clock.
> >> Depends on how you design it. IF you start a counter at the leading edge
> >> of the start bit and then detect the counter at its middle value, then
> >> the stop bit ends when the counter finally expires at the END of the
> >> stop bit.
> >
> > There is still some extra logic to distinguish the condition. There is a bit timing counter, and a counter to track which bit you are in. Everything happening in the operation of the UART is happening at the middle of a bit. Then you need extra logic to distinguish the end of a bit.
> Nope, simplest logic is to have your 8x sub-bit counter start at 0 and
> count up starting on the leading edge, on the count values of 3, 4, and
> 5 you sample the bit for noise detection, and roll over from 7 to 0 for
> the next bit, and count to the next bit. You stop the counter when it
> rolls from 7 to 0 in the stop bit, and counts past the stop bit.

You've conveniently left out a significant amount of logic.

Detecting specific states of the sub-bit counter uses more logic than other function. Most UARTs use 16 sub-samples and so have a 4 bit counter. Counters have a carry chain built in, so the carry out is a free zero count detector.

Counters are most efficient in terms of implementation when done as down counters, with various preloads. The counter is loaded with the half bit count while waiting for the leading edge of the start bit. The same zero detection (carry out) that triggers the next load is also the bit center mark. All loads during an active character will load a full bit count (different in the msb only). Every zero detect will mark a bit center. To get to the end of the final stop bit would require loading the counter with another half bit count, so extra logic. More than anything, why would anyone want to think about adding the extra half bit count when it's not part of any requirement?

> >>> I guess I'm not certain that would cause an error, actually. It would initiate the start bit detection logic, and as long as it does not require seeing the idle condition before detecting the start bit condition, it would still work. Again, this is expected by the definition of asynchronous format. This would result in a grosser offset in timing the middle of the bits, so the allowable timing error is less. But it will still work otherwise. 5% is a very large combined error. Most devices are timed by crystals with maybe ±200 ppm error.
> >> IF you don't start the looking for the start bit until the time has
> >> passed for the END of the stop bit, and the receiver is 0.1% slow, then
> >> every bit you lose 0.1% of a bit, or 1% per character, so after 50
> >> consecutive characters you are 1/2 a bit late, and getting errors.
> >
> > There you go! You have just proven that no one would design a UART to work this way and for it to be used in the market place. There would be too many applications where the data burst would cause it to not work. Programming around such a design flaw would be such a PITA and expose the flaw, that the part would become a pariah.
> Except that we have bought many USB serial ports with just this flaw in
> them.

Oh, you mean the Chinese UARTs that most people won't touch because they are full of flaws! Got it.

I was talking about real UARTs that people use in real designs. I used to buy CH340 based USB cables for work. But we eventually figured out that they were unreliable and I only use FTDI cables now. The CH340 cables seemed to work, but would quit after an hour or two or three.

> So I guess the nobody actually exists.
>
> Seem to be based on an FTDI chip, but maybe just a "look alike", where
> they did bare minimum design work.

There are lots of clones. If you have an FTDI chip with this stop bit problem, I'd love to see it. I think FTDI would love to see it too.

> The key point is that very few applications actually do have very long
> uninterrupted sequences of characters, and typical PCs will tend to
> naturally add small spaces just becuase the OS isn't that great. Doesn't
> require much to fix the issue.

The key point is that a company like FTDI is not going to sell such crap. "Fixing" such issues is only possible if you have control over the system. Not everyone is designing a system from scratch. My brother's company makes a device that interfaces to a measurement device outputting data periodically. For who knows what reason, that company changed the product so it stopped outputting the headers. So a small box was made to add the headers every few lines. The UARTs in it just have to work correctly, since there's no option to modify any other piece of equipment. If they don't work correctly, they get pulled and they use other equipment, and the original maker gets a black eye. Enough black eyes and people don't buy that equipment anymore.

--

Rick C.

--+++ Get 1,000 miles of free Supercharging
--+++ Tesla referral code - https://ts.la/richard11209