elimination of intercharacter gap in RS232 stream?

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.

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.

BINGO.

It's still using

Perhaps--if the gap was always at byte 16--but its not.

I can't. System spec is for 115.2K

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

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

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.

So you have about 100 us time to load the next char (if the TX FIFO is disabled) into the UART TX register.

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

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

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.

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.

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.

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.

In my experience, only the latter has been used for the past 15 years or so.

That's right, but nobody uses ASCII mode.

Have you actually seen anybody using Modbus ASCII in contrast to Modbus RTU or Modbus/TCP ?

Paul

You may wll be right but this thread is about ASCII transmision so mentioning modbus is irrelevent in this instance.

See previous answer.

My aplogies, I wasn't aware that you had restricted this thread to discussing the transmission of ASCII text.

Apology accepted

I wasn't aware that you had restricted this thread

I didn't the op did, allways read the question carefully before trying to answer it.

quoted text -

DMA will send the bytes back to back.

Peter Nachtwey

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