elimination of intercharacter gap in RS232 stream?

You would do better to solve the problem at the receiving end, thats where your real problem is.

Increase task priority - if write executes in the calling task and does not use interrupts to send data.

If it uses interrupts: Disable interrupts and busy wait on the TxRdy bit? Raise the Interrupt Priority of the UART?

How deep is the UARTs transmit buffer? (if it has one)- If you are just using the bit which indicates Tx register empty rather than "buffer low" that might cause what you are seeing.

Cheers TW

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.

Try looking at the handshaking line from the receiver along with the data stream. The receiver may be requesting the pause. The receiver may need a larger buffer.

Don

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.

Best regards, Bo

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.

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.

Are you flushing the buffers after write ? 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.

Regards Anton Erasmus

If this is for a military system, don't you guys have an Interface Control Document that specifies each and every interface to the system fully and completely? In systems where it matters you should have this document at the very least. If you don't have it ask for it from the person that was supposed to be writing the specification and cease working on the final system until you have it.

In the meantime, you can play. Others have given some good and useful hints and tips about looking at the control lines and management of interrupts.

To clarify a little-- we are developing 2 apps on 2 identical

I had a strange chill and shuddered at reading this. I hope this is just a sounding rocket.

Regards,

Michael

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!

We're working that issue with _some_ success.

THanks,

Bo

No--because I've not been able to find an API call that does this. Do you know how?

But as other posters have

No--no USB or ether-serial ever.

Thanks,

Bo

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.

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... ;-)

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.

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

Being common does not mean it isn't broken. From my limited modbus experience tweaks to adjust or relax this requirement are common.

Man 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

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.

I don't have the luxury to change/add any hardware due to contract/schedule.

One shot deal... I think you're outta luck ;)

My guess is that it will only worsen your situation compared to a normal ISR based transmit, since this involves more overhead.

Paul