On 2007-10-11, Bo <bo@cephus.com> wrote:>> 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!I'm afraid I don't see the connection between interrupt latency and "time to respond to data". The former is strictly a kernel-space problem, and the latter is probably mostly a user-space issue. -- Grant Edwards grante Yow! This MUST be a good at party -- My RIB CAGE is visi.com being painfully pressed up against someone's MARTINI!!
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:>>>>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 even the polling method is difficult to get working consistently. Some '550s appear to set the shift register empty bit at the start of the stop bit.> and exactly for this reason, I refuse to use any '550 chips in > any RS-485 2-wire networks.Yup. Half-duplex with a '550 sucks pretty badly. An '850 works nicely if you don't mind the complete hash they've made of the register interface in order to remain backwards compatible. -- Grant Edwards grante Yow! Could I have a drug at overdose? visi.com
Reply by ●October 11, 20072007-10-11
On 2007-10-11, cbarn24050@aol.com <cbarn24050@aol.com> wrote:> 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.In my experience, only the latter has been used for the past 15 years or so.> 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.That's right, but nobody uses ASCII mode. -- Grant Edwards grante Yow! HELLO KITTY gang at terrorizes town, family visi.com STICKERED to death!
Reply by ●October 11, 20072007-10-11
On Thu, 11 Oct 2007 15:26:12 -0700, cbarn24050@aol.com wrote:>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.Have you actually seen anybody using Modbus ASCII in contrast to Modbus RTU or Modbus/TCP ? Paul
Reply by ●October 12, 20072007-10-12
On Oct 12, 12:00?am, Grant Edwards <gra...@visi.com> wrote:> On 2007-10-11, cbarn24...@aol.com <cbarn24...@aol.com> wrote: > > > 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. > > In my experience, only the latter has been used for the past 15 > years or so. > > > 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. > > That's right, but nobody uses ASCII mode.You may wll be right but this thread is about ASCII transmision so mentioning modbus is irrelevent in this instance.> > -- > Grant Edwards grante Yow! HELLO KITTY gang > at terrorizes town, family > visi.com STICKERED to death!
Reply by ●October 12, 20072007-10-12
On Oct 12, 12:02?am, Paul Keinanen <keina...@sci.fi> wrote:> On Thu, 11 Oct 2007 15:26:12 -0700, cbarn24...@aol.com wrote: > >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. > > Have you actually seen anybody using Modbus ASCII in contrast to > Modbus RTU or Modbus/TCP ? > > PaulSee previous answer.
Reply by ●October 12, 20072007-10-12
On 2007-10-12, cbarn24050@aol.com <cbarn24050@aol.com> wrote:> On Oct 12, 12:00?am, Grant Edwards <gra...@visi.com> wrote: >> On 2007-10-11, cbarn24...@aol.com <cbarn24...@aol.com> wrote: >> >> > 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. >> >> In my experience, only the latter has been used for the past 15 >> years or so. >> >> > 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. >> >> That's right, but nobody uses ASCII mode. > > You may wll be right but this thread is about ASCII > transmision so mentioning modbus is irrelevent in this > instance.My aplogies, I wasn't aware that you had restricted this thread to discussing the transmission of ASCII text. -- Grant Edwards grante Yow! I'm pretending I'm at pulling in a TROUT! Am I visi.com doing it correctly??
Reply by ●October 13, 20072007-10-13
On Oct 12, 4:16?pm, Grant Edwards <gra...@visi.com> wrote:> On 2007-10-12, cbarn24...@aol.com <cbarn24...@aol.com> wrote: > > > > > > > On Oct 12, 12:00?am, Grant Edwards <gra...@visi.com> wrote: > >> On 2007-10-11, cbarn24...@aol.com <cbarn24...@aol.com> wrote: > > >> > 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. > > >> In my experience, only the latter has been used for the past 15 > >> years or so. > > >> > 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. > > >> That's right, but nobody uses ASCII mode. > > > You may wll be right but this thread is about ASCII > > transmision so mentioning modbus is irrelevent in this > > instance. > > My aplogies,Apology accepted I wasn't aware that you had restricted this thread> to discussing the transmission of ASCII text.I didn't the op did, allways read the question carefully before trying to answer it.> > -- > Grant Edwards grante Yow! I'm pretending I'm > at pulling in a TROUT! Am I > visi.com doing it correctly??- Hide quoted text - > > - Show quoted text -
Reply by ●October 13, 20072007-10-13
On Oct 11, 11:14 am, "Bo" <b...@cephus.com> wrote:> "Grant Edwards" <gra...@visi.com> wrote in message > > news:13gsg1ergqdct54@corp.supernews.com... > > > On 2007-10-10, 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. > > > 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!DMA will send the bytes back to back. Peter Nachtwey
Reply by ●October 13, 20072007-10-13
Bo wrote:> "Tim Wescott" <tim@seemywebsite.com> wrote in message > news:A6idndX7n8gRm5DanZ2dnUVZ_gmdnZ2d@web-ster.com... > >>On Wed, 10 Oct 2007 11:50:19 -0500, Bo 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? >>> >> >>You're probably running afoul of Linix's only-almost-real-time character. >>If you have some compelling system reason to send the serial stream >>unbroken then you'll probably need to get RTAI Linux or Xenomai going, and >>write your own serial driver under that to get your unbroken packets. >> >>If you _don't_ have a compelling system reason to do this, and you _do_ >>have access to the receiver code, fix it there per cbarn24050's >>suggestion. >> >>-- >>Tim Wescott >>Control systems and communications consulting >>http://www.wescottdesign.com >> > > Indeed. I'd love to be doing this on an RTOS. > > We've tried several things to fix the rcvr end at app level(cbarns > suggestion) but aren't getting repeatable, reliable results. As often the > case, I don't have explicit specs that indicate whether this gap will be a > problem or not for other/all devices in the system--so even if we manage to > fix our rx end, I'd like to fix my tx end to be sure that other devices are > happy with me. To clarify a little-- we are developing 2 apps on 2 identical > boards-- one is simulator, the other a command module going into a > missile--both running Linux. The command module talks with many devices over > serial ports. > > Wish I knew the answer's to Ted's questions--but I don't--yet. This would be > simple to do with no RTOS even on an 8051 talking to a 16550---but the Linux > factor, and the fact I'm in Linux learning curve, is the problem for me. If > I could directly/easily control the UART I know I could fix the problem. I > don't know whether the kernel calls/system are causing the gap, or a setup > issue in the UART. I was hoping for a magic API function that would _flush_ > the uart buffers, not throw away the data. > > Thanks for all the quick replies and suggestions Tim, Cbarn, Ted, Donald, > et. al.Have you 'zoomed' out, to see if the 2-5ms gaps follows a common period ? Most common source of these issues, from memory, was a SysTimer interrupt, or sometimes unusual video interrupts. If the lack of a gap matters, more than absolute speed. (some protocols use the GAP for sync), you could wait for the timer-tick, and then send a packet, You could also do that as a test, to confirm it IS timer-tick driven. -jg
