On 2007-10-11, Bo <bo@cephus.com> wrote:> The tcdrain() function waits until all output written to the terminal > referenced by fd has been transmitted to the terminal... > > I'll give that a try.I'll bet you dollars to doughnuts that won't help. All tcdrain() does is block the calling process until the tx buffer and tx fifo are empty. It has no effect whatsoever on the transmission of the bytes. It just lets you know whent they're gone (however some drivers are broken and return before the last few bytes have been sent). -- Grant Edwards grante Yow! ! The land of the at rising SONY!! visi.com
elimination of intercharacter gap in RS232 stream?
Started by ●October 10, 2007
Reply by ●October 11, 20072007-10-11
Reply by ●October 11, 20072007-10-11
On 2007-10-11, Paul Keinanen <keinanen@sci.fi> wrote:> On Thu, 11 Oct 2007 07:10:48 -0500, "Bo" <bo@cephus.com> wrote: > >>Definitely not what I want to do--but I happened across: >> >>The tcdrain() function waits until all output written to the terminal >> referenced by fd has been transmitted to the terminal... > > My guess is that it will only worsen your situation compared to a > normal ISR based transmit, since this involves more overhead.It will make no difference whatsoever. It's still using interrupt-based transmissions. tcdrain() is just a way to wait until the data has been sent. It doesn't affect the actual sending of the data. -- Grant Edwards grante Yow! Are we on STRIKE yet? at visi.com
Reply by ●October 11, 20072007-10-11
On 2007-10-10, Bo <bo@cephus.com> wrote:> Writing an Embbeded Linux app for a PC104/Versalogic board. Linux 2.6.14.17. > > Using write() to transmit data packets to another PC104 board. > If I write() 30 bytes, sometimes there is a 2-5mS gap in the > middle of the transmission, usually at about byte 15-20, but > sometimes at byte 29--as seen on a scope.You don't say what your serial ports are, but based on the symptoms, I'd guess they have a 16-byte FIFO that's underflowing. I've been using standard 16550 serial ports under Linux for 15 years and have never seen gaps in sent data (yes, I have looked, and in many applications I would have noticed). Something on your system must be disabling interrupts for a long time. What baud rate are you using?. Try removing other drivers and/or hardware. Get rid of network interfaces, video cards, etc. -- Grant Edwards grante Yow! Look into my eyes and at try to forget that you have visi.com a Macy's charge card!
Reply by ●October 11, 20072007-10-11
"Grant Edwards" <grante@visi.com> wrote in message news:13gsdpnmchmn69@corp.supernews.com...> On 2007-10-11, Paul Keinanen <keinanen@sci.fi> wrote: >> On Thu, 11 Oct 2007 07:10:48 -0500, "Bo" <bo@cephus.com> wrote: >> >>>Definitely not what I want to do--but I happened across: >>> >>>The tcdrain() function waits until all output written to the terminal >>> referenced by fd has been transmitted to the terminal... >> >> My guess is that it will only worsen your situation compared to a >> normal ISR based transmit, since this involves more overhead. > > It will make no difference whatsoever.BINGO. It's still using> interrupt-based transmissions. tcdrain() is just a way to > wait until the data has been sent. It doesn't affect the > actual sending of the data. > > -- > Grant Edwards grante Yow! Are we on STRIKE > yet? > at > visi.com
Reply by ●October 11, 20072007-10-11
"Paul Keinanen" <keinanen@sci.fi> wrote in message news:9r9rg3l8v4h6l6dqqk5mecbujgcvk4qcke@4ax.com...> On Wed, 10 Oct 2007 10:00:22 -0700, cbarn24050@aol.com wrote: > >>On Oct 10, 5:50?pm, "Bo" <b...@cephus.com> wrote: >>> Writing an Embbeded Linux app for a PC104/Versalogic board. Linux >>> 2.6.14.17. >>> >>> Using write() to transmit data packets to another PC104 board. If I >>> write() >>> 30 bytes, sometimes there is a 2-5mS gap in the middle of the >>> transmission, usually at about byte 15-20, but sometimes at byte 29--as >>> seen >>> on a scope. Tried using low latency setting when >>> opening the port--but this made no difference. This is causing >>> difficulties >>> for the receiving end-- and we have yet to add two more serial ports to >>> the >>> application. >>> >>> Any ideas on how to force continous transmission of the data? >>> >>> Thanks, >>> >>> Bo >> >>You would do better to solve the problem at the receiving end, thats >>where your real problem is. > > Modbus is a quite common industrial protocol that requires that the > space between characters within the message is less than 1.5 character > times. > > I am not familiar with that particular UART, but it sounds as if the > it has a 16 character transmit FIFO, which is not loaded fast enough > by the interrupt service routine (ISR), when the first 16 characters > have been sent.Perhaps--if the gap was always at byte 16--but its not.> > If the maximum allowed gap is defined in character times, try a lower > baud rate.I can't. System spec is for 115.2K> > If the UART FIFO has some adjustable low water mark interrupt, try to > increase the low water mark level, so that the ISR has more time to > load more characters, before the previous characters have been > transmitted. > > Reducing the Tx-FIFO size might also spread out the latency with more > frequent but faster loadings. > > Since this is a PC104 board (ISA) board, what other devices do you > have on the bus ?a video card and a digital IO board. I thin you may be onto something here-- I'll try it without the video and see what happens. Thanks, Bo In the 1990's there were a lot of latency problems> with PC hardware due to bad Ethernet chips or drivers. Some IDE > drivers as well as some accelerated VGAs disabled interrupts for a > long time. If you can remove the other cards from the PC104 stack, > check if this makes any difference to the latencies. > > Paul >
Reply by ●October 11, 20072007-10-11
"Grant Edwards" <grante@visi.com> wrote in message news:13gsg1ergqdct54@corp.supernews.com...> On 2007-10-10, Bo <bo@cephus.com> wrote: > >> Writing an Embbeded Linux app for a PC104/Versalogic board. Linux >> 2.6.14.17. >> >> Using write() to transmit data packets to another PC104 board. >> If I write() 30 bytes, sometimes there is a 2-5mS gap in the >> middle of the transmission, usually at about byte 15-20, but >> sometimes at byte 29--as seen on a scope. > > You don't say what your serial ports are, but based on the > symptoms, I'd guess they have a 16-byte FIFO that's > underflowing. > > I've been using standard 16550 serial ports under Linux for 15 > years and have never seen gaps in sent data (yes, I have > looked, and in many applications I would have noticed). > > Something on your system must be disabling interrupts for a > long time.I agree. The time to respond to data is huge--- I usually dont see my tx even start until 50-100mS! What baud rate are you using?. Try removing other> drivers and/or hardware. Get rid of network interfaces, video > cards, etc. > > -- > Grant Edwards grante Yow! Look into my eyes > and > at try to forget that you > have > visi.com a Macy's charge card!
Reply by ●October 11, 20072007-10-11
"Grant Edwards" <grante@visi.com> wrote in message news:13gsg1ergqdct54@corp.supernews.com...> On 2007-10-10, Bo <bo@cephus.com> wrote: > >> Writing an Embbeded Linux app for a PC104/Versalogic board. Linux >> 2.6.14.17. >> >> Using write() to transmit data packets to another PC104 board. >> If I write() 30 bytes, sometimes there is a 2-5mS gap in the >> middle of the transmission, usually at about byte 15-20, but >> sometimes at byte 29--as seen on a scope. > > You don't say what your serial ports are, but based on the > symptoms, I'd guess they have a 16-byte FIFO that's > underflowing.16550's. 115.2K rate, 8N1, no flow ctl.> > I've been using standard 16550 serial ports under Linux for 15 > years and have never seen gaps in sent data (yes, I have > looked, and in many applications I would have noticed). > > Something on your system must be disabling interrupts for a > long time. What baud rate are you using?. Try removing other > drivers and/or hardware. Get rid of network interfaces, video > cards, etc. > > -- > Grant Edwards grante Yow! Look into my eyes > and > at try to forget that you > have > visi.com a Macy's charge card!
Reply by ●October 11, 20072007-10-11
On Thu, 11 Oct 2007 14:46:15 -0000, Grant Edwards <grante@visi.com> wrote:>On 2007-10-11, Paul Keinanen <keinanen@sci.fi> wrote: >> On Thu, 11 Oct 2007 07:10:48 -0500, "Bo" <bo@cephus.com> wrote: >> >>>Definitely not what I want to do--but I happened across: >>> >>>The tcdrain() function waits until all output written to the terminal >>> referenced by fd has been transmitted to the terminal... >> >> My guess is that it will only worsen your situation compared to a >> normal ISR based transmit, since this involves more overhead. > >It will make no difference whatsoever. It's still using >interrupt-based transmissions. tcdrain() is just a way to >wait until the data has been sent. It doesn't affect the >actual sending of the data.On '550 style UARTs tcdrain would have to be implemented by a constant register polling (no interrupt available) and exactly for this reason, I refuse to use any '550 chips in any RS-485 2-wire networks. Paul
Reply by ●October 11, 20072007-10-11
On Thu, 11 Oct 2007 12:51:46 -0500, "Bo" <bo@cephus.com> wrote:> >"Paul Keinanen" <keinanen@sci.fi> wrote in message >news:9r9rg3l8v4h6l6dqqk5mecbujgcvk4qcke@4ax.com...>> I am not familiar with that particular UART, but it sounds as if the >> it has a 16 character transmit FIFO, which is not loaded fast enough >> by the interrupt service routine (ISR), when the first 16 characters >> have been sent. > >Perhaps--if the gap was always at byte 16--but its not.Not necessarily. You might be more successfull in loading a few bytes into the FIFO at previous times, so you are not getting exactly 1.6 ms pauses.>> If the maximum allowed gap is defined in character times, try a lower >> baud rate. > >I can't. System spec is for 115.2KSo you have about 100 us time to load the next char (if the TX FIFO is disabled) into the UART TX register.>> Since this is a PC104 board (ISA) board, what other devices do you >> have on the bus ? > > a video card and a digital IO board. I thin you may be onto something >here-- I'll try it without the video and see what happens.If the serial board does not contain any FIFO, you really have to look for any other driver that might disable interrupts for more than 100 us. Paul
Reply by ●October 11, 20072007-10-11
On Oct 11, 6:45?am, Paul Keinanen <keina...@sci.fi> wrote:> Modbus is a quite common industrial protocol that requires that the > space between characters within the message is less than 1.5 character > times.Thats not right accoring to my sources. There are two modbus protocalls ASCII and binary. Only the binary version frames the message blocks with gaps (because it cannot send control characters). The ASCII version can have gaps as long as 1 second between characters.
