This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Serial Tx problem


Andy
  I am currently writing serial drivers for the PXA255 as well.  Since we
are dealing with RS485/422 with transmitter enable outputs we could not use
the default serial drivers and wrote our own.  Are you using the eCos driver
or are you building your own?
  I have run into a different but similar problem.  I have no problem with
small packets, but when my packet size is 700 bytes or so I start loosing
some RX data.  With FIFO enabled I loose 32 bytes at a time, sometimes less.
With FIFOs disabled I loose 10 bytes or less at a time.  It takes a while to
see (300,000 bytes round trip to occur a few times).  I can see the bytes
are never pulled from UART but I also don't get an overflow error.
  I believe my problem may be that the default drivers are still loaded and
on a poll basis they may be draining my RX chars.  Since my new driver is
not using the Virtual Vectors, I am still trying to figure out how to remove
the default drivers.
 
Joe Porthouse
Toptech Systems, Inc.
280 Hunt Park Cove
Longwood, FL 32750
407-332-1774 x-265
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andy Atkinson
Sent: Wednesday, November 16, 2005 12:54 AM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Serial Tx problem

Hi All

I am using an Intel PXA261. I have the BT-UART setup for 115200 baud
with FIFOs enabled (half-full thresholds). Up to now we have only
transmitted low-volume, bursty trafiic through the UART and out to our
Bluetooth device. We have recently attempted to stream a lot (>1MB) of
data through the UART and have come across an 'interesting' problem.

Every once in a while the transmission just stops. When we detected that
the buffer (in the io layer) was no longer being drained, we inspected
the IIR register and the status indicated that the THR and the
shift-register were both empty. So why did everything just grind to a
halt? It looks like the UART did not generate an interrupt. Anyway, we
manually loaded the THR and off we went again until, some time into the
future it all stopped again. Once more the IIR gave the same info.

Upon consulting the newsgroup archives, I came across the following
thread:

http://sourceware.org/ml/ecos-discuss/2005-05/msg00243.html

This looked like what we needed (although if this really is the required
fix it doesn't really explain how our Tx ever gets going in the first
place as data is only loaded into the THR upon a Tx interrupt, so how
does the first byte ever get in there? Does the BT-UART generate an
interrupt when it is empty?). We implemented this fix and all was well
as long as we used non-blocking IO calls. If we switched to blocking IO,
we were back in the original situation.

Can anyone shed any more light on this problem?

Any help appreciated.

Andy Atkinson


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss




-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]