From: "valentin tihomirov" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 06:36:03 +0200 Lines: 55 Message-ID: NNTP-Posting-Host: 80-235-104-171-dsl.kjj.estpak.ee (80.235.104.171) X-Trace: news.uni-berlin.de 1069734991 63818850 80.235.104.171 (16 [212430]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!feed.news.nacamar.de!fu-berlin.de!uni-berlin.de!80-235-104-171-dsl.kjj.estpak.EE!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:35998 UART is used to transfer a byte in serial form bit-by-bit. I know that 10% deriviations in frequencies of transmitter and receiver are permissible. I was learnt that UARTs synchronyze at the falling edge (1to0) of start bit; hence, there should allow for transfer of a stream of bytes of arbitrary length. I have developed a simple UART. It's receiver and transimtter run at 9600 bps with 16x oversampling. Both receiver and transmitter have 1-byte buffer. To test the design I've created an echo device; it merely mirrors all the bytes sent to it back to the sender. It works fine with one of COM ports on my PC. Another COM port has its crystal running at a bit faster fundamental frequency. This causes a problem when it sends a long stream of bytes to my UART. In fact, sender and recepient cannot synchronize at falling edge of start bit because one of them is slower and is processing a previous byte wrile sender proceeds to next byte transmitting start bit. Despite of the fact, my receiver still works fine beacuse it is ready to receive next byte right after a first half of stop bit is received. Just to clarify, receiver acquares values from serial input at the middle of each data bit slice; it reports BYTE_READY in the middle of stop bit and from this moment is ready to accept next byte, i.e. ready fror synchronization. Therefore, if data is coming slightly faster and falling edge of start bit is located within stop bit (according to my UART's clock) receiver is still capable not to overlook the data. On the other hand, transmitter should transmit all 10 bits (start + 8 data + stop) @ 9600 bps. Consider for instance an UART forwarder or an echo device. If data is coming faster than I forward it I get a buffer overrun ultimately. That is, receiver is ready with a byte in its buffer to be copied into transmitter to forward but slow transmitter is still shifting data out and its buffer is blocked. I have a "fast" solution for my UART echo device; if transmitter has transmitted > half of stop bit and sences that there is a next byte received it stops sending current stop bit and starts transmitting a start bit for next byte. Untimely ceasing transmission is not good solution because transmitter may be connected to a good matched or slightly slower running UART. Design may be not a forwarder thus data provider may differ from 9600 bps receiver. In this case, starting early transmission of next byte while remote peer is still receiving stop bit causes stop bit error. What is interesting in this situation is the fact I can build a good echo device from any industrial manufactured UART (I've used standalone 16c750 and ones built into i8051). They never have a buffer overrun issue despite sending port is slightly faster than receiving (like sending data from my fast COM port to slow one). Note, no flow control is used, buffers are always 1-byte long. Which trick do they use? Again, 10% frequency dereviations between sender and receiver are considered permittable and no flow control is not required since sender and receiver both run at formal 9600bps. I feel this should be a well-known problem (solution) and just wonder why I did not encounter this consideration before. Thanks. ###### From: rickman Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 00:47:59 -0500 Organization: Arius, Inc Lines: 44 Message-ID: <3FC2ED0F.5FA3D2C5@yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYZ2SkRDA7znpxr1c8l+T8Gt0dwSnB+jPV568GOscN59Jh3yL72zF7f X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 25 Nov 2003 05:49:22 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.cwix.com!feed1.news.rcn.net!rcn!feed3.news.rcn.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36002 valentin tihomirov wrote: > > UART is used to transfer a byte in serial form bit-by-bit. I know that 10% > deriviations in frequencies of transmitter and receiver are permissible. I > was learnt that UARTs synchronyze at the falling edge (1to0) of start bit; > hence, there should allow for transfer of a stream of bytes of arbitrary > length. > > I have developed a simple UART. It's receiver and transimtter run at 9600 > bps with 16x oversampling. Both receiver and transmitter have 1-byte buffer. > To test the design I've created an echo device; it merely mirrors all the > bytes sent to it back to the sender. It works fine with one of COM ports on > my PC. Another COM port has its crystal running at a bit faster fundamental > frequency. This causes a problem when it sends a long stream of bytes to my > UART. When you say "your" UART, is this a design you did yourself in an FPGA? If so you may not have designed the logic correctly. In order for the receiver to synchronize to a continuous data stream, it has to sample the stop bit in what it thinks is the center and then *immediately* start looking for the next start bit. This will allow a mismatch in speed of almost a half bit minus whatever slack there is for the sample clock rate. BTW, you are sampling at at least 8x the bit rate, right? The max mismatch is not 10%, but a bit less that 5%. In the field I find that 2 to 3% mismatch is reliable, but any more and you can start getting errors. I guess the difference in theory and practice is perhaps skew caused by the drivers. Does this make sense? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: "valentin tihomirov" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 08:49:45 +0200 Lines: 33 Message-ID: References: <3FC2ED0F.5FA3D2C5@yahoo.com> NNTP-Posting-Host: 80-235-104-171-dsl.kjj.estpak.ee (80.235.104.171) X-Trace: news.uni-berlin.de 1069743013 62684116 80.235.104.171 (16 [212430]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!fu-berlin.de!uni-berlin.de!80-235-104-171-dsl.kjj.estpak.EE!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36003 > When you say "your" UART, is this a design you did yourself in an FPGA? Yes, you're right I have my design runs on CPLD. However, the qestion is more in logic rather than implementation. The value 10% I have got from www.8052.com's forum where "Software Uart" is a hot topic. > If so you may not have designed the logic correctly. In order for the > receiver to synchronize to a continuous data stream, it has to sample > the stop bit in what it thinks is the center and then *immediately* > start looking for the next start bit. This will allow a mismatch in > speed of almost a half bit minus whatever slack there is for the sample > clock rate. BTW, you are sampling at at least 8x the bit rate, right? I use 16x oversampling and check input values at middle of a bit (SampleCnt = 7). You suggest exactly what I have done. I think receiver part will work under any condition. But I need to know what should I do with transmitter module. As I attempted to explain, this half-bit solution cannot be used to synchronize transmitters. It is a bad idea to start transmitting next byte at the middle of the stop bit. It may fail listening device with slow clock as it reaches center of stop bit when start bit of next byte is being transmitted. On the other hand, if data is coming slightly faster transmitter should do something, otherwise I face buffer overrun condition. I understand that I can ignore the problem with transmitter module, it is receiver that should synchronize with transmitter. However, I had got buffer overrun problem until I used a trick described in my message (early transmit). It is defenetely not the problem with receiver because I have solved it right before got problem with transmitter's buffer overrun. And I want to know how should function correct logic; there should be a solution as commertial UARTs work without any problems. My UART is the first one where I've realized that it is at all possible to get a problem with slowly transmitting uart. Is now the problem become clearer? ###### From: "Joel Kolstad" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 00:13:06 -0800 Organization: Oregon State University Lines: 53 Message-ID: References: NNTP-Posting-Host: bob15.ece.orst.edu X-Trace: news.oregonstate.edu 1069747948 26170 128.193.48.172 (25 Nov 2003 08:12:28 GMT) X-Complaints-To: abuse@orst.edu NNTP-Posting-Date: Tue, 25 Nov 2003 08:12:28 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeeds.sol.net!news-out.visi.com!petbe.visi.com!news.state.mn.us!lenny.tc.umn.edu!news.oregonstate.edu!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36007 Valentin, You bright up a good subject, and you're absolutely correct that if you continuously send data from one serial port at 9600.01bps to a receiver at 9600, sooner or later there must be a buffer overflow. There's no way around this -- but keep in mind that RS-232 (or most any protocol, for that matter) isn't designed to send a truly continuous stream for days, months, or years at a time without a break! With a typical RS-232 device, there are MANY breaks, and keep in mind that something like a PC often has a pretty generous software buffer (many kilobytes) backing up the hardware so that it would take a 'long' time to create an overflow. I can't explain your observation that an, e.g., 8031-based data forwarder -- supposedly -- works other than to say I suspect that perhaps you didn't really do the type of torture test that could produce an overrun. (I.e., did you look with a scope or logic analyzer to make sure there was NEVER a idle bit time that might have allowed the receiver to 'catch up'?) One solution that you can use for protocols such as 8B/10B -- where you get a bazillion data bytes interspersed with an occasional 'comma' character -- is to use a form of compression where you assign 9 bits to ever received byte and 'swallow' any comma you get by setting the high bit. You can then sit down and work out how often you need to insert a comma into your bitstream to avoid buffer overflow. We had a gigabit fiber interface that used this approach, and with a 16 byte FIFO for buffering and a +/-100PPM clock at 1.0625Gbps, the numbers worked out to many thousands of bytes before overflow would be a concern. To build a data repeater that never suffers from potential buffer overflow under any circumstances whatsoever, I don't think you have many options other than locking the re-transmit bit rate to that of the received data using, e.g., a PLL. You could try this in software as well, I suppose, if you have a bit rate generator that's 'finely tunable' -- most in microcontrollers aren't! A few other comments: > UART is used to transfer a byte in serial form bit-by-bit. I know that 10% > deriviations in frequencies of transmitter and receiver are permissible. 'Permissible,' yeah, I suppose, although 10% wouldn't be anything to write home about! > I have developed a simple UART. It's receiver and transimtter run at 9600 > bps with 16x oversampling. Nothing wrong with 16x oversampling (it will definitely help -- a little), but keep in mind that you _can_ get away with no oversampling at all and get quite reasonable results if you position the sample point at the middle of each bit interval. ---Joel Kolstad ###### From: "juergen sauermann" Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 00:49:47 -0800 Organization: (none) Lines: 15 Message-ID: References: NNTP-Posting-Host: www.xtra.xilinx.com Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.media.kyoto-u.ac.jp!Spring.edu.tw!news.nctu.edu.tw!netnews.eranet.net!news.ttn.net!feeder.seed.net.tw!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!WebX Xref: redlance.franklin.ch comp.arch.fpga:36010 Valentin,

apparently you are trying to resolve the clock difference by cutting the stop bit in order to achieve a higher transmission rate.
That is a very nice idea and it is completely wrong.
In commercial (and all other) Uarts, it is the receiver that compensates for the clock difference. The rule is that the transmitter sends 10 bits (Start + 8 Data + Stop), but the receiver only requires 9.5 bits (1 Start + 8 Data + 0.5 Stop). It is this 0.5 bit difference which compensates the clock difference (and which also gives you the 5% that rick mentioned).
So far, your design seems correct. But then you try to speed up the transmitter as well by sending less than 10 bits (actually 9.5 bits).
The net effect is that you have changed the usual "transmit 10 & receive 9.5" scheme to a "transmit 9.5 & receive 9.5" scheme, which is as bad as a "transmit 10 & receive 10" scheme when the clocks are different. By doing this you will neccessarily lose single bits long before your buffer overruns. You stole the 0.5 bits from the receiver that the receiver desperately needs to compensate for the clock differences.
In other words, your attempt to avoid buffer overflows (which cannot occur since the receiver takes care of the clock frequencies) has actually created the problem you are describing. The solution is simple: don't touch the transmitter.
BTW., you should check if your 10% refers to clock jitter (moving of the clock edges around a fixed reference point) rather than to a difference in clock frequency.
/// Juergen ###### From: hmurray@suespammers.org (Hal Murray) Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 08:51:46 -0000 Message-ID: X-Newsreader: xrn 9.02 Sender: murray@glypnod (Hal Murray) References: X-Complaints-To: abuse@supernews.com Lines: 18 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-04!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!glypnod!hmurray Xref: redlance.franklin.ch comp.arch.fpga:36009 >You bright up a good subject, and you're absolutely correct that if you >continuously send data from one serial port at 9600.01bps to a receiver at >9600, sooner or later there must be a buffer overflow. ... I think you are missing a key idea. The receiver has to make sure that it will tolerate early start bits. That is the receiver has to start looking for a new start-of-start-bit right after it has checked the middle of the stop bit rather than wait unitl the end of the stop bit to start looking. [Interesting thread. Thanks. I didn't know about that trick.] -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam. ###### Reply-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics References: Subject: Re: Slightly unmatched UART frequencies Lines: 64 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Tue, 25 Nov 2003 23:07:42 +1300 NNTP-Posting-Host: 218.101.47.150 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069754783 218.101.47.150 (Tue, 25 Nov 2003 23:06:23 NZDT) NNTP-Posting-Date: Tue, 25 Nov 2003 23:06:23 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!newsfeed.icl.net!newsfeed.fjserv.net!c03.atl99!news.webusenet.com!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36012 "Hal Murray" wrote in message news:vs6612g8rso066@corp.supernews.com... > >You bright up a good subject, and you're absolutely correct that if you > >continuously send data from one serial port at 9600.01bps to a receiver at > >9600, sooner or later there must be a buffer overflow. ... > > I think you are missing a key idea. The receiver has to make > sure that it will tolerate early start bits. That is the receiver > has to start looking for a new start-of-start-bit right after > it has checked the middle of the stop bit rather than wait unitl > the end of the stop bit to start looking. Correct. If you really must tolerate continuous streams, with no data loss, and only a single stop bit, then you must actually be able to 'pass on' data at whatever average rate it comes in at. Some UARTS have the idea of fractional TX stop bits to allow this, most just choose 2 stop bits to give margin. Receive should ALWAYS start looking for START at the middle of STOP. ( but chips do not always get this right :) The OP's idea of a full half bit is a coarse example, that can force an error, as it jumps right to the limit Since this was using 16x BAUD clocking, you can quantize to 1/16 of bit time, or in appx 0.625% steps. 4 of these is 2.5%, or 1/4 bit, that tolerates to 9840 Baud If you don't want to use up all the error budget at one end, that's about the limit. ( 1/4 bit at each end, or a tad less, if you use 3 slot vote sampling ) This is why most uC with trimmed on-chip OSCs specify 2.5% or 2% precision. Since this a PLD device, you could watch for TX buffer phase, and nominally send a full STOP bit, but if the phase indicates margin problems (incomming faster than outgoing) you can decrement the STOP bit in 1/16 fractions - or you could force 15/16 wide STOP bit and use a crystal, and keep the logic simpler. (tolerates to 9660 Baud, 100% traffic ) A purists design would also extend STOP bits fractionally, (17/16 at ip <9600Bd true) so a sudden whole bit jump did not occur. That could cause problems if a number of these are in a chain, and a system with phase jitter, that averages 9600, but is sometimes faster, sometime slower might also exist. Makes the idea of a Continuous BAUD test pattern generator interesting - one that can generate controlled errors on both sides of true, and with dithering. Good student project :) -jg ###### From: peg@slingshot.co.nz (GPG) Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: 25 Nov 2003 03:09:26 -0800 Organization: http://groups.google.com Lines: 2 Message-ID: <62069f15.0311250309.f28037c@posting.google.com> References: <3FC2ED0F.5FA3D2C5@yahoo.com> NNTP-Posting-Host: 202.180.83.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1069758567 8153 127.0.0.1 (25 Nov 2003 11:09:27 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 25 Nov 2003 11:09:27 +0000 (UTC) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews1.google.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36015 MAXIMUM error is .5 bit over one frame. In your case frame = 10 bits. .5/10 = 5% ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> References: X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 190 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr29.news.prodigy.com 1069764769 ST000 216.103.85.188 (Tue, 25 Nov 2003 07:52:49 EST) NNTP-Posting-Date: Tue, 25 Nov 2003 07:52:49 EST X-UserInfo1: [[PGG]WD\BR[C_TX@BCD^VX@WB]^PCPDLXUNNHXIJYWZUYICD^RAQBKZQTZTX\_I[^G_KGFNON[ZOE_AZNVO^\XGGNTCIRPIJH[@RQKBXLRZ@CD^HKANYVW@RLGEZEJN@\_WZJBNZYYKVIOR]T]MNMG_Z[YVWSCH_Q[GPC_A@CARQVXDSDA^M]@DRVUM@RBM Date: Tue, 25 Nov 2003 12:52:49 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!newsfeed.vmunix.org!peer02.cox.net!cox.net!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr29.news.prodigy.com.POSTED!7ae961dc!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36017 Valentin wrote: > ... > >I have a "fast" solution for my UART echo device; if transmitter has >transmitted > half of stop bit and sences that there is a next byte received >it stops sending current stop bit and starts transmitting a start bit for >next byte. Untimely ceasing transmission is not good solution because >transmitter may be connected to a good matched or slightly slower running >UART. Design may be not a forwarder thus data provider may differ from 9600 >bps receiver. In this case, starting early transmission of next byte while >remote peer is still receiving stop bit causes stop bit error. > > ... juergen sauermann wrote: >Valentin, >apparently you are trying to resolve the clock difference by cutting >the stop bit in order to achieve a higher transmission rate. >That is a very nice idea and it is completely wrong. And Philip writes: Modifying the local transmited character to be a non-standard length by changing the length of the stop bit on the fly as buffer over-run is about to occur is not a good idea, as you don't know the details of how the receiver that is listening to it was designed, and it may not be very happy to see the next start bit before it is finished with what it expects is a full length stop bit, but it is not. The underlying problem is that you are potentially sending very long streams of data through a protocol that was designed for asynchronous transmission. That is why there are start bits and stop bits. In real systems, there is flow control, typically implemented one of 3 ways: 1) Hardware flow control: CTS/RTS 2) Character based flow control: XON/XOFF (ctrl-q/ctrl-s) 3) Upper layer flow control: packet based transfers with acknowledge packets used to pace transmissions. The "real-time-ness" (new word I just invented) of the flow control depends on the size of the receive buffer. With only 1 byte, you need (1), and even this may not be good enough, you may need at least 2 bytes of buffer. As the buffer gets bigger (say 8 to 100 bytes) then (2) is workable, and can even tolerate some operating system delay. When the buffers get to be multiple packets in size, then (3) may be appropriate. juergen sauermann also wrote: >In commercial (and all other) Uarts, it is the receiver that >compensates for the clock difference. The rule is that the >transmitter sends 10 bits (Start + 8 Data + Stop), but the >receiver only requires 9.5 bits (1 Start + 8 Data + 0.5 Stop). Well up to a point this is correct. The receiver can cetainly declare that the character has arrived after the sample is taken in the middle of the stop bit (at 9.5 bit times into the received character). BUT this is not a solution to the original poster's problem! The problem still exists because the remaining .5 bit is still going to arrive, the data is being sent with a slightly faster clock than the transmitter is able to retransmit the character. If there is no line idle time between the end of the inbound stop bit and the next inbound start bit, the system will eventually have an over-run problem, no matter how big the input buffer. The closer the two clock rates, and the bigger the buffer, the longer it takes to happen, but it will happen. Do the math: Let the far end transmitter be running at 1% faster clock rate than the local transmitter that is going to retransmit the character. Here are some easy to work with numbers: Perfect 9600 baud is 104.1666666 microseconds per bit 1 character time (1 Start,8 Data,1 Stop) is 1.041666666 ms After 1 character has arrived, we start to retransmit it. It doesnt matter if we start at the 9.5 or 10 bit time, it will take us 1.010101 times longer to send it than it took to receive. If we have a multibyte buffer, after 100 characters arrive at a far-end transmit rate that is 1% too fast, we have the following: .99 * 100 * 1.041666666 = 103.1249999 ms If our local transmitter is right on spec for baud rate, it will take 104.1666666 to send these characters, this is regardless of whether it starts at the 9.5 or the 10.0 point, because the character is going through a buffer, and changing clock domains. the difference in time will mean that in the time that the local transmitter takes to send 100 characters, the far end transmitter will send 101 charcaters. If our buffer is 10 characters long, then after 1000 characters arrive we will only have managed to offload 990 characters, and our 10 character buffer is full. Some time during the next 100 characters, we will have buffer over-run. juergen sauermann also wrote: >It is this 0.5 bit difference which compensates the clock >difference (and which also gives you the 5% that rick mentioned). As you can see above, I disagree. This is not a solution. >So far, your design seems correct. But then you try to speed >up the transmitter as well by sending less than 10 bits >(actually 9.5 bits). The net effect is that you have changed >the usual "transmit 10 & receive 9.5" scheme to a >"transmit 9.5 & receive 9.5" scheme, which is as bad as a >"transmit 10 & receive 10" scheme when the clocks are different. Actually, he hasn't changed the receiver to receive 9.5, because the far end transmitter is still sending 10 bits. ignoring the last .5 bit does not solve the problem, as it is accumulative. >By doing this you will neccessarily lose single bits long before >your buffer overruns. You stole the 0.5 bits from the receiver >that the receiver desperately needs to compensate for the clock >differences. Nope. This does not work. >In other words, your attempt to avoid buffer overflows (which >cannot occur since the receiver takes care of the clock >frequencies) has actually created the problem you are describing. >The solution is simple: don't touch the transmitter. Nope. This does not work. The following solutions can be made to work: A) Use one of the 3 described flow control systems above, with a suitable length buffer, or some other flow control system with similar effect. B) Deliberately force some idle time between characters at the far end transmitter. If your system is designed for a worst case of 5% difference in clock frequencies, forcing an idle between the stop bit and the next start bit of .6 bit time will achieve this (with some minor safety margin). You will still need some buffer though between your receiver and transmitter. Another version of this is to just add some idle time every N characters, such as "every 100 characters, let the go to sleep for 2 character time". C) Use a PLL to derive a local clock that is phase locked to the received data, and use this for transmit. D) At the far end transmitter, add some pad characters at regular times to the data stream, that can be thrown away at the receiver. E) run a clock line from the far end transmitter to your system and use that for your transmit clock (hardly an async system any more) F) Be sneaky. Most UARTs can be set for 1 , 1.5 , or 2 stop bits. Set the far end transmitter for 8N2 (1 start, 8 data, 2 stop). Set your receiver and transmitter for 8N1 (1 start, 8 data, 1 stop). This works, because stop bits look just like line-idle. This effectively implements (B), but is localized to the initialization code for the far end transmitter. Philip Freidin Philip Freidin Fliptronics ###### From: "Ulf Samuelsson" Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 13:45:20 +0100 Organization: atmel-nantes.fr Lines: 17 Message-ID: References: <3FC2ED0F.5FA3D2C5@yahoo.com> <62069f15.0311250309.f28037c@posting.google.com> NNTP-Posting-Host: 10.175.196.209 X-Trace: public2.atmel-nantes.fr 1069766470 16530 10.175.196.209 (25 Nov 2003 13:21:10 GMT) X-Complaints-To: usenet@public2.atmel-nantes.fr NNTP-Posting-Date: Tue, 25 Nov 2003 13:21:10 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!skynet.be!freenix!oleane.net!oleane!news.atmel-nantes.fr!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36019 "GPG" wrote in message news:62069f15.0311250309.f28037c@posting.google.com... > MAXIMUM error is .5 bit over one frame. In your case frame = 10 bits. > .5/10 = 5% And if the sender is 2% too slow and the receiver is 2% too fast, you have 4% error which is just below the 5% error tolerated. -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden. ###### From: "juergen Sauermann" Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 07:20:58 -0800 Organization: (none) Lines: 20 Message-ID: References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> NNTP-Posting-Host: www.xtra.xilinx.com Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!ihnp4.ucsd.edu!usc.edu!news.usc.edu!attla2!attla1!ip.att.net!newsgate.xilinx.com!WebX Xref: redlance.franklin.ch comp.arch.fpga:36023 Philip,

after thinking about the problem once more, I hate to admit that, yes, you are right.

I still do not believe, though, that inserting idle time one way or the other (including cutting the transmitter's stop bit) is a solution. Consider the following:

Left side: Slow (9600 Baud)
Right side: Fast (9700 Baud)

Both sides use e.g. 8N2 for Tx and 8N1 for Rx.

At some point in time, Left see's its buffer filling up and hence skips a few stop bits here and there (using 8N1) in order to compensate this. Left is now faster that Right, despite of the clock rates.

As a consequence, Right sees its buffer filling up and skips stop bits (using 8N1) as well.

This continues until both sides transmit with 8N1 all the time; at this time Left will loose data.

Thus, there must be some kind of understanding between Left and Right, which of the two is the "clock master", that ultimately controls the transmission speed. Unfortunately this is sometimes not possible, for instance in symmetric configurations.

/// Juergen ###### From: "Tim" Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 15:41:15 -0000 Lines: 14 Message-ID: References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> NNTP-Posting-Host: tile.demon.co.uk X-Trace: news.demon.co.uk 1069778525 4544 158.152.50.250 (25 Nov 2003 16:42:05 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 25 Nov 2003 16:42:05 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MSMail-Priority: Normal Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!skynet.be!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36030 Philip Freidin wrote: > The following solutions can be made to work: G) copy the scheme used in the TI MSP430, effectively a DDS. Using this arrangement gets you a lot more speed, and you can take the TI documentation as a spec and save a ton of time... If you do it, please forward the results to Xilinx for a writeup as an App Note ;-) ###### From: "Joel Kolstad" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 08:48:06 -0800 Organization: Oregon State University Lines: 20 Message-ID: References: NNTP-Posting-Host: bob15.ece.orst.edu X-Trace: news.oregonstate.edu 1069778866 2082 128.193.48.172 (25 Nov 2003 16:47:46 GMT) X-Complaints-To: abuse@orst.edu NNTP-Posting-Date: Tue, 25 Nov 2003 16:47:46 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!skynet.be!hermes.visi.com!news-out.visi.com!petbe.visi.com!news.state.mn.us!lenny.tc.umn.edu!news.oregonstate.edu!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36031 Hal Murray wrote: >> You bright up a good subject, and you're absolutely correct that if you >> continuously send data from one serial port at 9600.01bps to a receiver >> at 9600, sooner or later there must be a buffer overflow. ... > > I think you are missing a key idea. The receiver has to make > sure that it will tolerate early start bits. That is the receiver > has to start looking for a new start-of-start-bit right after > it has checked the middle of the stop bit rather than wait unitl > the end of the stop bit to start looking. Unless your (slightly slower) transmitter also has the capability of producing shortened start (or stop) bits, how those this approach 'fix' the problem? If the date rates are, say, 9601 received BPS and 9600 transmitted BPS, detecting early start bits just buys you one extra bit interval before your overrun your buffers, doesn't it? ---Joel ###### From: glen herrmannsfeldt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 50 Message-ID: NNTP-Posting-Host: 12.228.234.203 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s52 1069788182 12.228.234.203 (Tue, 25 Nov 2003 19:23:02 GMT) NNTP-Posting-Date: Tue, 25 Nov 2003 19:23:02 GMT Organization: Comcast Online Date: Tue, 25 Nov 2003 19:23:02 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!attbi_s52.POSTED!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36040 juergen Sauermann wrote: (snip) > I still do not believe, though, that inserting idle time one way or the > other (including cutting the transmitter's stop bit) is a solution. > Consider the following: > > Left side: Slow (9600 Baud) > Right side: Fast (9700 Baud) > > Both sides use e.g. 8N2 for Tx and 8N1 for Rx. > > At some point in time, Left see's its buffer filling up and hence skips > a few stop bits here and there (using 8N1) in order to compensate this. > Left is now faster that Right, despite of the clock rates. > > As a consequence, Right sees its buffer filling up and skips stop bits > (using 8N1) as well. > > This continues until both sides transmit with 8N1 all the time; at this > time Left will loose data. As far as I know, asynchronous transmission was intended to be between two devices, such as a terminal and a computer, though more likely two terminals in the early days. The two stop bits were required by machines that mechanically decided the bits. (The Teletype (R) ASR33, for example.) Using stop bits as flow control seems unusual to me. Electronic UARTs (no comment on mechanical ones) sample the bit at the center of each bit time. For a character with no transitions (X'00' or X'FF') timing error can accumulate for the duration of the character. The STOP bit is the receivers chance to adjust the timing, and start over with the new START bit. With a 5% timing error, which is very large for a crystal controlled clock, the stop bit could start 0.45 bit times early, but the receiver will still detect it at the right time, and be ready to start the next character. The timing for each character is from the leading edge of the START bit. This allows for difference in the bit clock rate between the transmitter and receiver. It is unrelated to any buffering or buffer overflow problems that may occur. -- glen ###### Reply-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> Subject: Re: Slightly unmatched UART frequencies Lines: 77 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Wed, 26 Nov 2003 09:55:52 +1300 NNTP-Posting-Host: 218.101.47.150 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1069793673 218.101.47.150 (Wed, 26 Nov 2003 09:54:33 NZDT) NNTP-Posting-Date: Wed, 26 Nov 2003 09:54:33 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.xtra.co.nz!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36042 "Philip Freidin" wrote > > And Philip writes: > Modifying the local transmited character to be a non-standard length > by changing the length of the stop bit on the fly as buffer > over-run is about to occur is not a good idea, as you don't > know the details of how the receiver that is listening to it was > designed, and it may not be very happy to see the next start bit > before it is finished with what it expects is a full length stop > bit, but it is not. UARTs look for the START edge, from the _middle_ of the STOP bit. With x16 clocking, typically that gives 8 possible time slots for earlier start. I would agree that a half-bit jump in STOP, as the OP first suggested, is NOT a good idea, but fractional (1/16 quantized ) STOP changes are valid and safe. > > BUT this is not a solution to the original poster's problem! > The problem still exists because the remaining .5 bit is still > going to arrive, the data is being sent with a slightly faster > clock than the transmitter is able to retransmit the character. > If there is no line idle time between the end of the inbound > stop bit and the next inbound start bit, the system will > eventually have an over-run problem, no matter how big the > input buffer. The closer the two clock rates, and the bigger > the buffer, the longer it takes to happen, but it will happen. Yes, true if the stop bit is 'whole bit' quantized. CAN be avoided if the TX can move the START edge as needed, both left and right, in 1/16 steps. Something like +/-4 sixteenths would leave design margin. > F) > Be sneaky. Most UARTs can be set for 1 , 1.5 , or 2 stop bits. > Set the far end transmitter for 8N2 (1 start, 8 data, 2 stop). > Set your receiver and transmitter for 8N1 (1 start, 8 data, 1 stop). > This works, because stop bits look just like line-idle. This > effectively implements (B), but is localized to the initialization > code for the far end transmitter. Yes, by far the simplest, and most practical solution. However, this is comp.arch.fpga, and here we can design any UART we like, including one that can handle 100% traffic loading, single stop bits, and 1-2% region clock skews. ! :) To illustrate this, look at the SC28C94 UART data, this from info on their 16 possible STOP BIT options: MR2[3..0] = Stop Bit Length 0 = 0.563 1 = 0.625 2 = 0.688 3 = 0.750 4 = 0.813 5 = 0.875 6 = 0.938 7 = 1.000 8 = 1.563 9 = 1.625 A = 1.688 B = 1.750 C = 1.813 C = 1.875 E = 1.938 F = 2.000 -jg ###### From: Peter Alfke Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 14:01:58 -0800 Organization: Xilinx,Inc Lines: 63 Message-ID: <3FC3D157.2FCFD5E8@xilinx.com> References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> NNTP-Posting-Host: peter.xilinx.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en To: glen herrmannsfeldt Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!logbridge.uoregon.edu!nntp-server.caltech.edu!attla2!attla1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36045 Here is my simple analysis: There are two very different situations: If the transmitter clocks slower than the receiver, there is no problem on the receive end, as long as the error inside the word does not exceed half a bit time. If the transmitter clocks faster than the receiver, the receiver has to be able to resynchronize after only half a stop bit (which may be touchy). Peter Alfke ============================== glen herrmannsfeldt wrote: > > juergen Sauermann wrote: > > (snip) > > > I still do not believe, though, that inserting idle time one way or the > > other (including cutting the transmitter's stop bit) is a solution. > > Consider the following: > > > > Left side: Slow (9600 Baud) > > Right side: Fast (9700 Baud) > > > > Both sides use e.g. 8N2 for Tx and 8N1 for Rx. > > > > At some point in time, Left see's its buffer filling up and hence skips > > a few stop bits here and there (using 8N1) in order to compensate this. > > Left is now faster that Right, despite of the clock rates. > > > > As a consequence, Right sees its buffer filling up and skips stop bits > > (using 8N1) as well. > > > > This continues until both sides transmit with 8N1 all the time; at this > > time Left will loose data. > > As far as I know, asynchronous transmission was intended to be between > two devices, such as a terminal and a computer, though more likely two > terminals in the early days. > > The two stop bits were required by machines that mechanically decided > the bits. (The Teletype (R) ASR33, for example.) Using stop bits as > flow control seems unusual to me. > > Electronic UARTs (no comment on mechanical ones) sample the bit at the > center of each bit time. For a character with no transitions (X'00' or > X'FF') timing error can accumulate for the duration of the character. > The STOP bit is the receivers chance to adjust the timing, and start > over with the new START bit. > > With a 5% timing error, which is very large for a crystal controlled > clock, the stop bit could start 0.45 bit times early, but the receiver > will still detect it at the right time, and be ready to start the next > character. > > The timing for each character is from the leading edge of the START bit. > > This allows for difference in the bit clock rate between the transmitter > and receiver. It is unrelated to any buffering or buffer overflow > problems that may occur. > > -- glen ###### From: Allan Herriman Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Wed, 26 Nov 2003 11:20:47 +1100 Organization: Global Crossing Internet Lines: 17 Message-ID: <6bs7sv4om47k6lcmfms72lo5ig2vr5q5ra@4ax.com> References: NNTP-Posting-Host: nnrp2.phx1.gblx.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: node21.cwnet.roc.gblx.net 1069806049 15096 64.214.31.41 (26 Nov 2003 00:20:49 GMT) X-Complaints-To: abuse@gblx.net NNTP-Posting-Date: Wed, 26 Nov 2003 00:20:49 +0000 (UTC) X-Newsreader: Forte Free Agent 1.93/32.576 English (American) X-Original-NNTP-Posting-Host: 203.219.10.94 X-Original-Trace: 26 Nov 2003 11:20:47 +1100, 203.219.10.94 Cache-Post-Path: nnrp2.phx1.gblx.net!203.12.160.33 X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!news-FFM2.ecrc.net!nntp1.roc.gblx.net!nntp.gblx.net!nntp.gblx.net!news.globalcrossing.net!dnews.tpgi.com.au!tpg.com.au!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36054 On Tue, 25 Nov 2003 06:36:03 +0200, "valentin tihomirov" wrote: >UART is used to transfer a byte in serial form bit-by-bit. I know that 10% >deriviations in frequencies of transmitter and receiver are permissible. I >was learnt that UARTs synchronyze at the falling edge (1to0) of start bit; >hence, there should allow for transfer of a stream of bytes of arbitrary >length. ITU-T Recommendation V.110 (a.k.a. I.463) explains how to do synchronous to asynchronous conversion (to get async serial signals across ISDN). This includes things like stop bit shaving. http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-V.110-200002-I Regards, Allan. ###### From: peg@slingshot.co.nz (GPG) Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Date: 25 Nov 2003 19:00:26 -0800 Organization: http://groups.google.com Lines: 9 Message-ID: <62069f15.0311251900.5975057e@posting.google.com> References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> <3FC3D157.2FCFD5E8@xilinx.com> NNTP-Posting-Host: 202.180.83.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1069815626 9637 127.0.0.1 (26 Nov 2003 03:00:26 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 26 Nov 2003 03:00:26 +0000 (UTC) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews1.google.com!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36057 > > As far as I know, asynchronous transmission was intended to be between > > two devices, such as a terminal and a computer, though more likely two > > terminals in the early days. > > Originally developed by Emille Baudot (google) for telex. Hence Baud. Buffer overflows are irrelevant in the modern world since the terminals will be handling the data far faster than the transmission rate. All that is required is the receiving uart detect the start bit reliably. Longer stop bits help. ###### From: rickman Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Wed, 26 Nov 2003 00:11:54 -0500 Organization: Arius, Inc Lines: 83 Message-ID: <3FC4361A.CFF4740F@yahoo.com> References: <3FC2ED0F.5FA3D2C5@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZsrGShV/q3QxHrf734xi0javvN1zop/ZkC1jHVnAu6/QGI8vKadN6U X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 26 Nov 2003 05:12:55 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!feed.news.nacamar.de!rcn!feed3.news.rcn.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36061 valentin tihomirov wrote: > > > When you say "your" UART, is this a design you did yourself in an FPGA? > Yes, you're right I have my design runs on CPLD. However, the qestion is > more in logic rather than implementation. The value 10% I have got from > www.8052.com's forum where "Software Uart" is a hot topic. Well, this is not correct. Analyze the situation yourself and see at what point the receiver will not sample the data at the correct time. You will find the allowed slip is half a bit over the whole word which is about 5% give or take. > > If so you may not have designed the logic correctly. In order for the > > receiver to synchronize to a continuous data stream, it has to sample > > the stop bit in what it thinks is the center and then *immediately* > > start looking for the next start bit. This will allow a mismatch in > > speed of almost a half bit minus whatever slack there is for the sample > > clock rate. BTW, you are sampling at at least 8x the bit rate, right? > I use 16x oversampling and check input values at middle of a bit (SampleCnt > = 7). You suggest exactly what I have done. I think receiver part will work > under any condition. That assumption is where you are wrong. There is nothing the transmitter can do to change the way it works unless you *always* transmit at a rate slower than your receiver. The transmitter can be either faster or slower than the receiver. If the transmitter is slower than the receiver, then the start bit detection will simply happen a few clocks after the end of the stop bit rather than right at the end. If the transmitter is faster than the receiver, then the start bit detection has to occur before the end of the timing of the stop bit. If the transmitter starts the start bit early you make the problem worse. If the transmitter delays the start bit, then this will prevent any issues. So you can eliminate the problem by sending two stop bits and only looking for one at the receiver, but clearly this is not how commercial units work. Commercial receivers start looking for a start bit leading edge as soon as the middle of the stop bit has been timed and checked. You need to do the same thing. You don't care when the end of the stop bit happens. You only care about the leading edge of the start bit which may be a bit earlier than the end of the stop bit as timed by the receiver. Others have posted in this thread by this point all the info you should need. If you still don't understand what is wrong with your understanding of the problem, let us know and we will try to make it more clear. > But I need to know what should I do with transmitter > module. As I attempted to explain, this half-bit solution cannot be used to > synchronize transmitters. It is a bad idea to start transmitting next byte > at the middle of the stop bit. It may fail listening device with slow clock > as it reaches center of stop bit when start bit of next byte is being > transmitted. On the other hand, if data is coming slightly faster > transmitter should do something, otherwise I face buffer overrun condition. > I understand that I can ignore the problem with transmitter module, it is > receiver that should synchronize with transmitter. However, I had got buffer > overrun problem until I used a trick described in my message (early > transmit). It is defenetely not the problem with receiver because I have > solved it right before got problem with transmitter's buffer overrun. And I > want to know how should function correct logic; there should be a solution > as commertial UARTs work without any problems. My UART is the first one > where I've realized that it is at all possible to get a problem with slowly > transmitting uart. > Is now the problem become clearer? To us, yes. Is it more clear to you as well? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Wed, 26 Nov 2003 00:18:33 -0500 Organization: Arius, Inc Lines: 38 Message-ID: <3FC437A9.CBD7025A@yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVaha+0Ta4XZPFsrvsKit6W4Pj7F9cnV0QU9xmdRyHd1a9kDbFrMH768 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 26 Nov 2003 05:19:32 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.cwix.com!nntp.abs.net!rcn!feed3.news.rcn.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36062 Joel Kolstad wrote: > > Hal Murray wrote: > >> You bright up a good subject, and you're absolutely correct that if you > >> continuously send data from one serial port at 9600.01bps to a receiver > >> at 9600, sooner or later there must be a buffer overflow. ... > > > > I think you are missing a key idea. The receiver has to make > > sure that it will tolerate early start bits. That is the receiver > > has to start looking for a new start-of-start-bit right after > > it has checked the middle of the stop bit rather than wait unitl > > the end of the stop bit to start looking. > > Unless your (slightly slower) transmitter also has the capability of > producing shortened start (or stop) bits, how those this approach 'fix' the > problem? If the date rates are, say, 9601 received BPS and 9600 transmitted > BPS, detecting early start bits just buys you one extra bit interval before > your overrun your buffers, doesn't it? No, by looking for the start of next word before the last word is complete, the receiver can receive data faster than you would calculate given the clock speed and the bit count. The receiver can receive data in 9.5 bit times per byte rather than the 10 bit times per byte the transmitter takes to send them. That is where the 0.5 bit or about 5% rate mismatch numbers come from. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: rickman Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Wed, 26 Nov 2003 00:27:17 -0500 Organization: Arius, Inc Lines: 57 Message-ID: <3FC439B5.662227A@yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYzhc+qJXPdElbFHP6UoNqWP297w2F1x7lVQtY7+r9i5xFz7UTXSzb4 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 26 Nov 2003 05:28:17 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.cwix.com!nntp.abs.net!rcn!feed3.news.rcn.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36063 Joel Kolstad wrote: > > Hal Murray wrote: > >> You bright up a good subject, and you're absolutely correct that if you > >> continuously send data from one serial port at 9600.01bps to a receiver > >> at 9600, sooner or later there must be a buffer overflow. ... > > > > I think you are missing a key idea. The receiver has to make > > sure that it will tolerate early start bits. That is the receiver > > has to start looking for a new start-of-start-bit right after > > it has checked the middle of the stop bit rather than wait unitl > > the end of the stop bit to start looking. > > Unless your (slightly slower) transmitter also has the capability of > producing shortened start (or stop) bits, how those this approach 'fix' the > problem? If the date rates are, say, 9601 received BPS and 9600 transmitted > BPS, detecting early start bits just buys you one extra bit interval before > your overrun your buffers, doesn't it? I think I just understood what is wrong with my thinking. I was only looking at one direction. The problem the OP has is that he is looping back the received data and retransmitting it at the same slow(er) rate the receiver is using. Since the transmitter must use a full 10 bits, then the buffer between the receiver and transmitter will overflow at some point. This is a problem that is found in communications systems. All units must run at the same rate, but may use a different reference. So if they receive data at 8.0000 kHz and try to DAC it at 7.9999 kHz, about once per ten seconds there will be a byte too many and a sample will have to be dropped. This will cause a noticable click or other distortion of the voice. Some systems try to buffer this out, but that only postpones the problem. Most systems use a common reference that is very accurate and stable. Then the ADC and DAC clocks must be sync'd to the reference. I worked on a system that used a bendable VCXO to establish the 8 kHz rate. As the buffer data count varied from half full, the VCXO rate was increased or decreased by small amounts to keep the average rates matched. In the case of the OP, the first channel can use two stop bits and the echo channel can use one stop bit. This may not be pretty, but it will work. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX ###### From: "Joel Kolstad" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 22:29:11 -0800 Organization: Oregon State University Lines: 32 Message-ID: References: <3FC439B5.662227A@yahoo.com> NNTP-Posting-Host: bob15.ece.orst.edu X-Trace: news.oregonstate.edu 1069828150 19651 128.193.48.172 (26 Nov 2003 06:29:10 GMT) X-Complaints-To: abuse@orst.edu NNTP-Posting-Date: Wed, 26 Nov 2003 06:29:10 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!msc1.onvoy!onvoy.com!lenny.tc.umn.edu!news.oregonstate.edu!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36065 Hi Rick et al., rickman wrote: > Since the transmitter must use a full 10 bits, > then the buffer between the receiver and transmitter will overflow at > some point. I'm glad someone else agrees with me! I think we'd all agree now, then, that either you need an adjustable output clock or the part to transmit with a shortened stop (or start) bit, which is effectively the same thing as adjusting your output clock rate anyway. > This is a problem that is found in communications systems. All units > must run at the same rate, but may use a different reference. > Some systems try to buffer this out, but that only postpones the > problem. Most systems use a common reference that is very accurate and > stable. ...or they force the data to be encoded with its clock so that a PLL can extract the exact frequency reference and work with that. > In the case of the OP, the first channel can use two stop bits and the > echo channel can use one stop bit. This may not be pretty, but it will > work. It certainly will but the price is a reduction of ~10% of the average throughput! Of course, that may be negligible depending on the system. ---Joel ###### From: Philip Freidin Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies Organization: Fliptronics Reply-To: philip@fliptronics.com Message-ID: <4bo9svsen73hiba5sjnevf07lste7vcm7q@4ax.com> References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 81 NNTP-Posting-Host: 216.103.85.188 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr25.news.prodigy.com 1069867426 ST000 216.103.85.188 (Wed, 26 Nov 2003 12:23:46 EST) NNTP-Posting-Date: Wed, 26 Nov 2003 12:23:46 EST X-UserInfo1: SCSGG]WD\BR[C_TX@BCD^VX@WB]^PCPDLXUNNH\KMAVNDQUBLNTC@AWZWDXZXQ[K\FFSKCVM@F_N_DOBWVWG__LG@VVOIPLIGX\\BU_B@\P\PFX\B[APHTWAHDCKJF^NHD[YJAZMCY_CWG[SX\Y]^KC\HSZRWSWKGAY_PC[BQ[BXAS\F\\@DMTLFZFUE@\VL Date: Wed, 26 Nov 2003 17:23:46 GMT Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!newsfeed.mathworks.com!news-out.cwix.com!newsfeed.cwix.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr25.news.prodigy.com.POSTED!7ae961dc!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36084 On Tue, 25 Nov 2003 07:20:58 -0800, "juergen Sauermann" wrote: >Philip, >after thinking about the problem once more, I hate to admit that, yes, you are right. Sorry. >I still do not believe, though, that inserting idle time one way or the other >(including cutting the transmitter's stop bit) is a solution. Consider the following: > >Left side: Slow (9600 Baud) >Right side: Fast (9700 Baud) > >Both sides use e.g. 8N2 for Tx and 8N1 for Rx. The extra stop bit gives you about 9% margin, the difference between 9600 and 9700 is about 1% >At some point in time, Left see's its buffer filling up and hence skips >a few stop bits here and there (using 8N1) in order to compensate this. >Left is now faster that Right, despite of the clock rates. I agree. More exactly, Left's RX is faster than Right's TX. The examples I gave in my prior post help with unidirectional messages between a faster transmitter and a slower receiver, and assume the system at the slower receiver can process the received character in the local clock domain in 10 bit times. But if you retransmit the character with 2 stop bits in the slower clock domain, that takes 11 bit times, and the system will fail. So retransmitting with 11 bits throws away the advantage of the RX using 1 stop bit and the far end TX using 2 stop bits. If you knew which system had the slower clock, you could set its transmitter for 1 stop bit and then the system would work. Unfortunately this is not normally possible. >As a consequence, Right sees its buffer filling up and skips >stop bits (using 8N1) as well. >This continues until both sides transmit with 8N1 all the time; >at this time Left will loose data. This is not what I intended. I am assuming that the number of stop bits is fixed, and is dependent on which end has the faster clock. Try this: Left side: Slow (9600 Baud) RX: 1 + 8 + 1 TX: 1 + 8 + 1 Right side: Fast (9700 Baud) RX: 1 + 8 + 1 TX: 1 + 8 + 2 I believe you can send stuff continuously all day this way without over-run, in both directions. Only problem is that you need to know which end has the faster clock. You could figur this out by running both TX at 1+8+1 and see which RX has over-run errors first, then adjust the other end's TX. Not pretty, but could be made to work. Maybe OK for a 1 off project, but not for production. >Thus, there must be some kind of understanding between Left and Right, >which of the two is the "clock master", that ultimately controls the >transmission speed. Unfortunately this is sometimes not possible, for >instance in symmetric configurations. I agree. hence the need for flow control. >/// Juergen Philip Philip Freidin Fliptronics ###### From: "Joel Kolstad" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Tue, 25 Nov 2003 08:52:36 -0800 Organization: Oregon State University Lines: 16 Message-ID: References: <3FC2ED0F.5FA3D2C5@yahoo.com> <62069f15.0311250309.f28037c@posting.google.com> NNTP-Posting-Host: bob15.ece.orst.edu X-Trace: news.oregonstate.edu 1069779136 2252 128.193.48.172 (25 Nov 2003 16:52:16 GMT) X-Complaints-To: abuse@orst.edu NNTP-Posting-Date: Tue, 25 Nov 2003 16:52:16 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.arcor-online.net!news.tele.dk!news.tele.dk!small.news.tele.dk!msc1.onvoy!onvoy.com!lenny.tc.umn.edu!news.oregonstate.edu!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36159 GPG wrote: > MAXIMUM error is .5 bit over one frame. In your case frame = 10 bits. > .5/10 = 5% I remember the story at a former employee who was using an HP serial test set at 38400 bps to debug a data stream that went to a slot machine controller. He kept having inexplicable data corruption errors until he looked at the timing very closely on a 'scope and discovered that -- due to an 'off by one' error in some register of the UART in the microcontroller generating the data stream -- the actual bit rate was something like 10% off. It had gone undiscovered for years since the microcontroller at the receiving end was using the same code! ---Joel Kolstad ###### From: "valentin tihomirov" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Sun, 30 Nov 2003 18:00:57 +0200 Lines: 9 Message-ID: References: NNTP-Posting-Host: 80-235-104-171-dsl.kjj.estpak.ee (80.235.104.171) X-Trace: news.uni-berlin.de 1070208101 64449656 80.235.104.171 ([212430]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!fu-berlin.de!uni-berlin.de!80-235-104-171-dsl.kjj.estpak.EE!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36163 Error accumulates. 1% means that receiver accepts 9.9bit long farmes while transmitter transmits 10.0 bit-long frames. After re-transmitting 100 bytes (frames) we get 10-bit error. 10 bit is one byte, so 1-byte buffer is not enaught. The longer the stream the lager the buffer required. Infinite buffer is required for continous stream. As masters stated, UART was not designed for this purpose. ###### Reply-To: "Jim Granville" From: "Jim Granville" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics References: Subject: Re: Slightly unmatched UART frequencies Lines: 16 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <6Esyb.10584$ws.984103@news02.tsnz.net> Date: Mon, 1 Dec 2003 09:45:06 +1300 NNTP-Posting-Host: 218.101.44.30 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1070225026 218.101.44.30 (Mon, 01 Dec 2003 09:43:46 NZDT) NNTP-Posting-Date: Mon, 01 Dec 2003 09:43:46 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.belwue.de!feed.news.tiscali.de!newsfeed.icl.net!newsfeed.fjserv.net!c03.atl99!news.webusenet.com!news02.tsnz.net!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36167 "valentin tihomirov" > Error accumulates. 1% means that receiver accepts 9.9bit long farmes while > transmitter transmits 10.0 bit-long frames. After re-transmitting 100 bytes > (frames) we get 10-bit error. 10 bit is one byte, so 1-byte buffer is not > enaught. The longer the stream the lager the buffer required. Infinite > buffer is required for continous stream. As masters stated, UART was not > designed for this purpose. Some UARTs are designed for this purpose - look at the data for Philips 26C94 families, and esp. the area of Sending fractional stop bits. -jg ###### From: "Simon Peacock" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics References: Subject: Re: Slightly unmatched UART frequencies Lines: 26 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Original-NNTP-Posting-Host: 202.154.130.208 Message-ID: <3fcae1a9@news.actrix.gen.nz> Date: Mon, 1 Dec 2003 19:37:29 +1300 NNTP-Posting-Host: 203.96.16.33 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1070260652 203.96.16.33 (Mon, 01 Dec 2003 19:37:32 NZDT) NNTP-Posting-Date: Mon, 01 Dec 2003 19:37:32 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!in.100proofnews.com!in.100proofnews.com!news02.tsnz.net!news.actrix.gen.nz!202.154.130.208 Xref: redlance.franklin.ch comp.arch.fpga:36170 you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks ... ALL async UARTs MUST be capable of handling this.. that's why there's flow control. You will find that 99.9% of them start looking for the start bit 1/2 way thru the stop bit. If you want to build a repeater then you will need a fractional stop bit generator OR you can over spec the crystal by 1.5% (or the baud rate generator) OR you add RTS / CTS flow control like everybody else. Simon "valentin tihomirov" wrote in message news:bqd493$1ter3o$1@ID-212430.news.uni-berlin.de... > Error accumulates. 1% means that receiver accepts 9.9bit long farmes while > transmitter transmits 10.0 bit-long frames. After re-transmitting 100 bytes > (frames) we get 10-bit error. 10 bit is one byte, so 1-byte buffer is not > enaught. The longer the stream the lager the buffer required. Infinite > buffer is required for continous stream. As masters stated, UART was not > designed for this purpose. > > > ###### From: "Joel Kolstad" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Sun, 30 Nov 2003 23:28:53 -0800 Organization: Oregon State University Lines: 36 Message-ID: References: <3fcae1a9@news.actrix.gen.nz> NNTP-Posting-Host: bob15.ece.orst.edu X-Trace: news.oregonstate.edu 1070263707 6308 128.193.48.172 (1 Dec 2003 07:28:27 GMT) X-Complaints-To: abuse@orst.edu NNTP-Posting-Date: Mon, 1 Dec 2003 07:28:27 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news-fra1.dfn.de!news.tele.dk!news.tele.dk!small.news.tele.dk!msc1.onvoy!onvoy.com!lenny.tc.umn.edu!news.oregonstate.edu!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36171 Simon Peacock wrote: > you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks > ... ALL async UARTs MUST be capable of handling this.. that's why there's > flow control. There are a lot of systems in the world that don't use flow control and simply rely on a 'mutual agreement' between the interconnected devices that large streams of unbroken serial data isn't produced. This is especially the case of, e.g., sensors that produce real-time RS-232 output data with no buffering of their own -- in such a case flow control would just throw data away, so it's often not implemented to begin with. (I have a motto something to the effect of... if detecting an error does no more good than just ignoring it, you might as well ignore it... Although unfortunately this idea is often perverted into, 'if detecting an error takes effort, even if ignoring it causes the machine to rip off someone's arm, you might as well ignore it because otherwise the customer will immediately be able to pin the blame on you rather than having to guess whose fault it is.' :-( ) > You will find that 99.9% of them start looking for the start bit 1/2 way > thru the stop bit. If you want to build a repeater then you will need a > fractional stop bit generator OR you can over spec the crystal by 1.5% > (or the baud rate generator) OR you add RTS / CTS flow control like > everybody else. 1 -- The fractional stop bit generator is a good idea, and is apparently implemented in -- some -- commercial devices. This was news to me, but it does seem to be a very good solution. 2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution' is inherently non-scalable -- I can't connect together a dozen of these repeaters unless each one is progressively 1.5% faster, which isn't viable. 3 -- I'd agree that flow control is the 'proper' or 'textbook' solution, just that the real world doesn't always play by those rules. :-) ---Joel Kolstad ###### From: "Simon Peacock" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics References: <3fcae1a9@news.actrix.gen.nz> Subject: Re: Slightly unmatched UART frequencies Lines: 57 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Original-NNTP-Posting-Host: 202.154.130.115 Message-ID: <3fcc3fa4@news.actrix.gen.nz> Date: Tue, 2 Dec 2003 20:30:41 +1300 NNTP-Posting-Host: 203.96.16.33 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1070350245 203.96.16.33 (Tue, 02 Dec 2003 20:30:45 NZDT) NNTP-Posting-Date: Tue, 02 Dec 2003 20:30:45 NZDT Organization: TelstraClear Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!feed.news.tiscali.de!newsfeed.vmunix.org!peer02.cox.net!cox.net!pd7cy1no!pd7cy2so!shaw.ca!sjc70.webusenet.com!c03.atl99!news.webusenet.com!news02.tsnz.net!news.actrix.gen.nz!202.154.130.115 Xref: redlance.franklin.ch comp.arch.fpga:36193 "Joel Kolstad" wrote in message news:bqeqiq$654$1@news.oregonstate.edu... > Simon Peacock wrote: > > you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks > > ... ALL async UARTs MUST be capable of handling this.. that's why there's > > flow control. > > There are a lot of systems in the world that don't use flow control and > simply rely on a 'mutual agreement' between the interconnected devices that > large streams of unbroken serial data isn't produced. This is especially > the case of, e.g., sensors that produce real-time RS-232 output data with no > buffering of their own -- in such a case flow control would just throw data > away, so it's often not implemented to begin with. (I have a motto > something to the effect of... if detecting an error does no more good than > just ignoring it, you might as well ignore it... Although unfortunately this > idea is often perverted into, 'if detecting an error takes effort, even if > ignoring it causes the machine to rip off someone's arm, you might as well > ignore it because otherwise the customer will immediately be able to pin the > blame on you rather than having to guess whose fault it is.' :-( ) > > > You will find that 99.9% of them start looking for the start bit 1/2 way > > thru the stop bit. If you want to build a repeater then you will need a > > fractional stop bit generator OR you can over spec the crystal by 1.5% > > (or the baud rate generator) OR you add RTS / CTS flow control like > > everybody else. > > 1 -- The fractional stop bit generator is a good idea, and is apparently > implemented in -- some -- commercial devices. This was news to me, but it > does seem to be a very good solution. > 2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution' > is inherently non-scalable -- I can't connect together a dozen of these > repeaters unless each one is progressively 1.5% faster, which isn't viable. > 3 -- I'd agree that flow control is the 'proper' or 'textbook' solution, > just that the real world doesn't always play by those rules. :-) > Actually you can :-) Data is only sent at the speed it arrives at.. so although you are 1.5% fast.. you actually end up adding extra stop bits into the stream to compensate .. is simple and oh so clever. This is exactly what modems did for years to cope with the V.14 shaved bits when they couldn't do them. Simon ###### From: "Joel Kolstad" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Mon, 1 Dec 2003 23:41:23 -0800 Organization: Oregon State University Lines: 23 Message-ID: References: <3fcae1a9@news.actrix.gen.nz> <3fcc3fa4@news.actrix.gen.nz> NNTP-Posting-Host: bob15.ece.orst.edu X-Trace: news.oregonstate.edu 1070350836 3835 128.193.48.172 (2 Dec 2003 07:40:36 GMT) X-Complaints-To: abuse@orst.edu NNTP-Posting-Date: Tue, 2 Dec 2003 07:40:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!snoopy.risq.qc.ca!msc1.onvoy!onvoy.com!lenny.tc.umn.edu!news.oregonstate.edu!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36194 HI Simon, Simon Peacock wrote: > Data is only sent at the speed it arrives at.. so although you are 1.5% > fast.. you actually end up adding extra stop bits into the stream to > compensate .. is simple and oh so clever. Well, fair enough, if you KNOW that your data source is truly supposed to be 'nominally,' say, 9600bps, then you can be clever and get away with an internal nominal bit rate of 9600*1.015=9744bps. However, if you tell me you have such a device that you'd like to connect to one of my devices, you'd better be able to convince me there really is no way your device could start spewing data continuously at 9744 bps when my 9600 bps receiver isn't going to be able to hack it! >This is exactly what modems did > for years to cope with the V.14 shaved bits when they couldn't do them. Interesting; I didn't know that either! ---Joel ###### From: "Simon Peacock" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics References: <3fcae1a9@news.actrix.gen.nz> <3fcc3fa4@news.actrix.gen.nz> Subject: Re: Slightly unmatched UART frequencies Date: Thu, 4 Dec 2003 22:20:21 +1300 Lines: 39 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 NNTP-Posting-Host: 202.154.130.38 X-Original-NNTP-Posting-Host: 202.154.130.38 Message-ID: <3fcefc56@news.actrix.gen.nz> X-Trace: 4 Dec 2003 22:20:22 NZST, 202.154.130.38 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.xtra.co.nz!newsfeeds.ihug.co.nz!ihug.co.nz!news!news.iprolink.co.nz!news.actrix.gen.nz!202.154.130.38 Xref: redlance.franklin.ch comp.arch.fpga:36258 "Joel Kolstad" wrote in message news:bqhflk$3nr$1@news.oregonstate.edu... > HI Simon, > > Simon Peacock wrote: > > Data is only sent at the speed it arrives at.. so although you are 1.5% > > fast.. you actually end up adding extra stop bits into the stream to > > compensate .. is simple and oh so clever. > > Well, fair enough, if you KNOW that your data source is truly supposed to be > 'nominally,' say, 9600bps, then you can be clever and get away with an > internal nominal bit rate of 9600*1.015=9744bps. However, if you tell me > you have such a device that you'd like to connect to one of my devices, > you'd better be able to convince me there really is no way your device could > start spewing data continuously at 9744 bps when my 9600 bps receiver isn't > going to be able to hack it! > > >This is exactly what modems did > > for years to cope with the V.14 shaved bits when they couldn't do them. > > Interesting; I didn't know that either! > if you start looking for a start bit 1/2 way thru the stop .. no problems :-) Since modems often use embedded processors.. which don't do fractional stop.. you have to do something.. so they mostly fudge it. Rockwell, Intel, silicon systems.. all have done it.. maybe even still do.. wouldn't surprise me if they did.. the first Rockwell 33k6 modems just used a fast version of their 2400 processors.. 6802 or something like that Simon ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies References: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 04 Dec 2003 19:14:32 -0800 Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 4 Dec 2003 19:20:51 -0800, ruckus.brouhaha.com Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.spies.com!ruckus.brouhaha.com Xref: redlance.franklin.ch comp.arch.fpga:36295 "Joel Kolstad" writes: > You bright up a good subject, and you're absolutely correct that if you > continuously send data from one serial port at 9600.01bps to a receiver at > 9600, sooner or later there must be a buffer overflow. No, that will work just fine. When a real UART is set for one stop bit, it actually only needs just over 1/2 a stop bit (usually 9/16). > There's no way around this Certainly there are ways around it. Read ITU Rec. V.14. > Nothing wrong with 16x oversampling (it will definitely help -- a little), It helps a lot, if you do it right. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies References: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 04 Dec 2003 19:16:35 -0800 Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 4 Dec 2003 19:22:54 -0800, ruckus.brouhaha.com Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.spies.com!ruckus.brouhaha.com Xref: redlance.franklin.ch comp.arch.fpga:36296 "Joel Kolstad" writes: > Unless your (slightly slower) transmitter also has the capability of > producing shortened start (or stop) bits, An async transmitter should NEVER produce shortened start or stop bits! It is the RECEIVER that should handle short stop bits, in order to deal with the exact sort of speed mismatch you're talking about. > how those this approach 'fix' the > problem? If the date rates are, say, 9601 received BPS and 9600 transmitted > BPS, detecting early start bits just buys you one extra bit interval before > your overrun your buffers, doesn't it? No, if the receiver works correctly this should be maintainable indefinitely (provided there's nothing else in the receiving device that overflows). ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies References: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 04 Dec 2003 19:21:12 -0800 Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 4 Dec 2003 19:27:30 -0800, ruckus.brouhaha.com Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.spies.com!ruckus.brouhaha.com Xref: redlance.franklin.ch comp.arch.fpga:36297 "juergen sauermann" writes: > Valentin,

apparently you are trying to resolve the clock difference by cutting the stop bit in order to achieve a higher transmission rate. > > That is a very nice idea and it is completely wrong. If it's completely wrong, why did the ITU standardize it in the V.14 standard? Admittedly shaving stop bits should only be used in certain limited circumstances. It is not intended to deal with sending data to a receiver that is running slightly slower than the transmitter. Rather, it is used when converting slightly overspeed data from a synchronous modem modulation to async (when no error control protocol like V.42 is in use). Only a small number of commercially produced UARTs, such as the NEC uPD7201, fail to work correctly with slightly short stop bits. This problem was commonly seen on the AT&T 7300 Unix PC in the late 1980s. ###### Sender: eric@ruckus.brouhaha.com From: Eric Smith Newsgroups: comp.arch.fpga Subject: Re: Slightly unmatched UART frequencies References: <4rg6sv019htbrpuhqpmfplq7qilmb2dmgu@4ax.com> Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy. Date: 04 Dec 2003 19:23:54 -0800 Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: ruckus.brouhaha.com X-Trace: 4 Dec 2003 19:30:12 -0800, ruckus.brouhaha.com Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!enews.sgi.com!news.spies.com!ruckus.brouhaha.com Xref: redlance.franklin.ch comp.arch.fpga:36298 "Jim Granville" writes: > UARTs look for the START edge, from the _middle_ of the STOP bit. > With x16 clocking, typically that gives 8 possible time slots for earlier > start. Actually they usually start looking for a start transition 9/16 of the way into the previous stop bit. Some UARTs with noise detection sample the RX input at 7/16, 8/16, and 9/16 of the bit time, so those might not start looking for a start bit until 10/16 of the way into the previous stop bit. > I would agree that a half-bit jump in STOP, as the OP first suggested, > is NOT a good idea, but fractional (1/16 quantized ) STOP changes are > valid and safe. Yes, with rare exceptions such as the NEC uPD7201, which actually requires a full stop bit on receive. ###### From: Allan Herriman Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Fri, 05 Dec 2003 14:59:51 +1100 Message-ID: References: X-Newsreader: Forte Free Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Original-NNTP-Posting-Host: 203.219.10.94 X-Original-Trace: 5 Dec 2003 14:59:51 +1100, 203.219.10.94 Lines: 17 NNTP-Posting-Host: dnews.tpgi.com.au X-Trace: news-syd 1070604086 dnews.tpgi.com.au (5 Dec 2003 01:01:26 -0500) Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!news-peer1.sprintlink.net!news.sprintlink.net!news-syd!dnews.tpgi.com.au!tpg.com.au!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36301 On 04 Dec 2003 19:16:35 -0800, Eric Smith wrote: >"Joel Kolstad" writes: >> Unless your (slightly slower) transmitter also has the capability of >> producing shortened start (or stop) bits, > >An async transmitter should NEVER produce shortened start or stop bits! Some [well engineered] systems will not work in all cases unless they are able to use shortened stop bits. I refer you to ITU-T recommendations V.110 and V.14. (You could argue that they aren't 'async', but still...) Regards, Allan. ###### From: "Joel Kolstad" Newsgroups: comp.arch.fpga,sci.electronics.design,sci.electronics.basics Subject: Re: Slightly unmatched UART frequencies Date: Thu, 4 Dec 2003 21:53:09 -0800 Organization: Oregon State University Lines: 38 Message-ID: References: NNTP-Posting-Host: bob15.ece.orst.edu X-Trace: news.oregonstate.edu 1070603579 23409 128.193.48.172 (5 Dec 2003 05:52:59 GMT) X-Complaints-To: abuse@orst.edu NNTP-Posting-Date: Fri, 5 Dec 2003 05:52:59 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Path: redlance.franklin.ch!pfaff2.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!proxad.net!news-out.visi.com!petbe.visi.com!news.state.mn.us!lenny.tc.umn.edu!news.oregonstate.edu!not-for-mail Xref: redlance.franklin.ch comp.arch.fpga:36300 Eric Smith wrote: > "Joel Kolstad" writes: >> You bright up a good subject, and you're absolutely correct that if you >> continuously send data from one serial port at 9600.01bps to a receiver >> at 9600, sooner or later there must be a buffer overflow. > > No, that will work just fine. When a real UART is set for one stop bit, > it actually only needs just over 1/2 a stop bit (usually 9/16). If you read further into the thread, you'll see that the 'problem' is that while, sure, you can receive all the characters coming in at 9600.01 bps correctly, if you're then only going to re-transmit them (a data buffer-type device) at 9600 bps, sooner or later you run out of storage for all the accumulating bits. That's what my 'there's no way around this' comment meant. In the interim, people have suggested lots of clever techiques to deal with mismatched frequencies. >> Nothing wrong with 16x oversampling (it will definitely help -- a >> little), > > It helps a lot, if you do it right. I'll buy that I suppose -- I've done just fine with 1x or 3x sampling with software-based UARTs, but the mere fact that they were software-based meant that they were only at, e.g., 9600bps or less and they happened to be over short distances. I.e., the data signals were always 'nice and clean.' > An async transmitter should NEVER produce shortened start or stop bits! Perhaps you should tell that to all the guys out there who've designed UARTs that do just that? Keep reading the thread -- if data comes into a data forwarder at 9600.01 bps, you have to 'effectively' re-transmit at 9600.01bps as well. You can do that by using a slightly faster clocking frequency and/or slightly shortening your data bits -- your choice. ---Joel Kolstad