elimination of intercharacter gap in RS232 stream?

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 

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.

On 10 Oct, 17:50, "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


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

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

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

"Bo" <bo@cephus.com> wrote in message 
news:50921$470d02cb$41a26d4d$30902@API-DIGITAL.COM...
> 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
>
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

"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.

Best regards,
Bo 

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.

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

-- 
Grant Edwards                   grante             Yow! FEELINGS are cascading
                                  at               over me!!!
                               visi.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 ?  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

Bo wrote:

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

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.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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