Bingo. "msg" <msg@_cybertheque.org_> wrote in message news:13gqf23lb7s638@corp.supernews.com...> Bo wrote: > > <snip> > 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. > > I had a strange chill and shuddered at reading this. > I hope this is just a sounding rocket. > > Regards, > > Michael
elimination of intercharacter gap in RS232 stream?
Started by ●October 10, 2007
Reply by ●October 10, 20072007-10-10
Reply by ●October 10, 20072007-10-10
"Grant Edwards" <grante@visi.com> wrote in message news:13gq98pse15f4c9@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. > > It sounds like either your serial driver is broken or you've > got interrupts disabled for a _long_ time. The serial driver > should get an interrupt when the tx fifo is low and have tons > of time to fill it before it underflows.No-- no ISR being disabled--at least in the app. However, when we disable our real-time signals during the wrote, the response time of the protocol jumps from 10mS to 80-120mS!> >> 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? > > Fix the serial driver or fix the other driver that's locking > out interrupts for so long. You could try raising the tx fifo > threshold so that the serial driver has more time to respond. > That will increase the tolerance for high interrupt latency, > but it will generate more frequent interrupts and result in > higher overhead. > > You could also try fixing the receive end so that a gap between > bytes doesn't make it fall over.We're working that issue with _some_ success. THanks, Bo> > -- > Grant Edwards grante Yow! FEELINGS are > cascading > at over me!!! > visi.com
Reply by ●October 10, 20072007-10-10
"Anton Erasmus" <nobody@spam.prevent.net> wrote in message news:a2aqg3lrdiuba5ji63m2l6q01glqb78u0g@4ax.com...> On Wed, 10 Oct 2007 11:50:19 -0500, "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. 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? >> > > Are you flushing the buffers after write ?No--because I've not been able to find an API call that does this. Do you know how? But as other posters have> suggested, it would be better to fix the Rx side. If you ever need to > run your code on a system using USB-serial or ethernet-serial, you > will have these sort of issues in any case.No--no USB or ether-serial ever. Thanks, Bo
Reply by ●October 10, 20072007-10-10
On Wed, 10 Oct 2007 13:25:54 -0500, "Bo" <bo@cephus.com> wrote:> This would be >simple to do with no RTOS even on an 8051 talking to a 16550That's not the *right* fix but it is a fix, although I'm not familiar off-hand with any chips in the 8051 family that have dual uarts (sure to be some, though). Other processors may be better suited. Regardless, without knowing anything else about the IDS but guessing from the original post that an increased latency of 5+ msec would not be a problem as long as the data stream was well-formed, just throw some hardware at it by adding a buffer between the two systems that holds an incoming packet for 5 msec + grace and then streams it out the other end. That would almost certainly "fix" the symptoms but it sounds like the problem is back up the design chain a step or two. Better to fix the design than rely on duct tape. Who's the contract with? May be an opportunity here when it comes up for a recompete... ;-)
Reply by ●October 10, 20072007-10-10
On 2007-10-10, Bo <bo@cephus.com> wrote:>>>Any ideas on how to force continous transmission of the data? >> >> Are you flushing the buffers after write ? > > No--because I've not been able to find an API call that does > this. Do you know how?man tcflush Though I doubt that flushing the buffers is what you want to do. Make sure that the tx FIFO is being used and that the tx FIFO threshold is set to a reasonable value (25-50%). Other than that, figure out what's disabling interrupts for so long. -- Grant Edwards grante Yow! Now KEN and BARBIE at are PERMANENTLY ADDICTED to visi.com MIND-ALTERING DRUGS ...
Reply by ●October 11, 20072007-10-11
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. If the maximum allowed gap is defined in character times, try a lower baud rate. 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 ? 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
Paul Keinanen <keinanen@sci.fi> wrote:>>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.Being common does not mean it isn't broken. From my limited modbus experience tweaks to adjust or relax this requirement are common. --
Reply by ●October 11, 20072007-10-11
"Grant Edwards" <grante@visi.com> wrote in message news:13gqnadg4jl4e8c@corp.supernews.com...> On 2007-10-10, Bo <bo@cephus.com> wrote: > >>>>Any ideas on how to force continous transmission of the data? >>> >>> Are you flushing the buffers after write ? >> >> No--because I've not been able to find an API call that does >> this. Do you know how? > > man tcflush > > Though I doubt that flushing the buffers is what you want to > do. > > Make sure that the tx FIFO is being used and that the tx FIFO > threshold is set to a reasonable value (25-50%). > > Other than that, figure out what's disabling interrupts for so > long. > > -- > Grant Edwards grante Yow! Now KEN and BARBIEMan tcflush(): "The tcflush() function discards any data written to the terminal refer- enced by fd which has not been transmitted to the terminal" 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... I'll give that a try. Thanks again, Bo
Reply by ●October 11, 20072007-10-11
"Rich Webb" <bbew.ar@mapson.nozirev.ten> wrote in message news:0ukqg3p30vc4f14qen4a1t900iosqc06q8@4ax.com...> On Wed, 10 Oct 2007 13:25:54 -0500, "Bo" <bo@cephus.com> wrote: > >> This would be >>simple to do with no RTOS even on an 8051 talking to a 16550 > > That's not the *right* fix but it is a fix, although I'm not familiar > off-hand with any chips in the 8051 family that have dual uarts (sure > to be some, though). Other processors may be better suited.Of course--but in this particular case, there was no HW development-- a VERY tight schedule forced use of COTS PC104. Perhaps a better PC104 could have been found... and certainly an RTOS would make things much more deterministic. No time for that either though now.> > Regardless, without knowing anything else about the IDS but guessing > from the original post that an increased latency of 5+ msec would not > be a problem as long as the data stream was well-formed, just throw > some hardware at it by adding a buffer between the two systems that > holds an incoming packet for 5 msec + grace and then streams it out > the other end.I don't have the luxury to change/add any hardware due to contract/schedule.> > That would almost certainly "fix" the symptoms but it sounds like the > problem is back up the design chain a step or two. Better to fix the > design than rely on duct tape. > > Who's the contract with? May be an opportunity here when it comes up > for a recompete... ;-)One shot deal... I think you're outta luck ;)
Reply by ●October 11, 20072007-10-11
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. Paul
