This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Serial Tx problem
- From: Gary Thomas <gary at mlbassoc dot com>
- To: jporthouse at toptech dot com
- Cc: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Wed, 16 Nov 2005 07:09:56 -0700
- Subject: RE: [ECOS] Serial Tx problem
- References: <MDAEMON-F200511160857.AA5747390md50000309700@toptech.com>
On Wed, 2005-11-16 at 09:00 -0500, Joe Porthouse wrote:
> 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?
What kept you from just extending the existing drivers?
> 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.
Try turning off CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT
>
> 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
>
>
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss