Re: [Gumstix-users] Serial inter-character delay problems with overo/chestnut43 ttyS0

[David P. <sig...@gm...>]

Isn't UART_USE_FIFO the standard for serial comms?  Why would it not be
set?  I'm using the pre-built image set
omap3-palmtop-image-overo-201008132038.

On Wed, Sep 22, 2010 at 11:18 PM, R. P. McMurphy <log...@gm...> wrote:

> Have you checked that the FIFO is enabled? I cant imagine any other
> reason to have delays between characters. In our system we use a
> 3.6864Mhz clock with no delays between characters, the 64byte FIFO
> works great on both UART1 (ttyS0?) and UART2 (ttyS1?).
>
> On 9/23/10, David Pedersen <sig...@gm...> wrote:
> > Hi Dave,
> >
> > Thanks for responding!  To answer your question, we're using 1 start bit,
> 8
> > data bits, a ninth 'wakeup' bit, and 1 stop bit, and are using the CMSPAR
> > flag and PARODD to set & clear the wake-up bit.  The first byte we send
> is
> > an address byte, which MUST have the ninth bit set, and any remaining
> bytes
> > in the packet must NOT have the ninth bit set.  All of this works
> > perfectly.  Our only trouble is the inter-character delay, which is
> causing
> > the connected device to timeout and cease responding.
> >
> > My understanding is that the ttyS0 port on the overo is not a true
> hardware
> > port, and I'm wondering if that could be the source of the trouble.  I
> also
> > understand that ttyS1 IS a hardware port, but is redirected to the
> bluetooth
> > subsystem rather than the 40-pin chestnut connector.  I've found Nabble
> > posts that indicate the port can be redirected to the 40-pin connector,
> but
> > the information is unclear and seems incomplete.
> >
> > Bottom line is that I need a way to solve the inter-character delay
> > problems, whether by adjusting a setting somewhere, or changing to a
> > different port. Do you have any experience with anything like this or
> know
> > of someone who does?
> >
> > Thanks,
> > Dave
> >
> >
> > On Wed, Sep 22, 2010 at 12:08 AM, Dave Hylands <dhy...@gm...>
> wrote:
> >
> >> Hi David,
> >>
> >> On Tue, Sep 21, 2010 at 11:52 PM, David Pedersen <sig...@gm...>
> >> wrote:
> >> > We have to write the first byte with a wakeup bit set, basically mark
> >> > parity, and then the rest of the message must be sent with space
> parity.
> >> > From 2 or 3 bytes, up to 20 or 30 bytes total in each message.  The
> >> > first
> >> > byte is being sent independently, then the rest of the stream is sent
> >> with a
> >> > single write() call, however, surprisingly, the inter-character delay
> is
> >> > greater with the multiple-byte write!  Strange.  We're seeing about
> >> 14.5ms
> >> > on the single byte, mark parity write, and 15ms delay between the
> bytes
> >> sent
> >> > together.
> >>
> >> Hmmm.
> >>
> >> Are you sending 7-bit characters with parity? If so, then you may want
> >> to configure the uart to send 8-bit characters with no parity and
> >> calculate the parity yourself using a lookup table.
> >>
> >> I'm not familiar with the OMAP UARTs, but all of the UARTs I've worked
> >> with will send a FIFO worth of data completely in HW. I guess you
> >> might have to look into the driver to figure out what's going on.
> >>
> >> If you're changing the parity settings, I would expect that it needs
> >> to allow the FIFO to drain before changing settings. It's also
> >> possible that if the HW doesn't support mark/space parity it might be
> >> doing something funky in the driver.
> >>
> >> It's also possible that the FIFO might not be enabled.
> >>
> >> --
> >> Dave Hylands
> >> Shuswap, BC, Canada
> >> http://www.DaveHylands.com/
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Start uncovering the many advantages of virtual appliances
> >> and start using them to simplify application deployment and
> >> accelerate your shift to cloud computing.
> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> _______________________________________________
> >> gumstix-users mailing list
> >> gum...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users
> >>
> >
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> gumstix-users mailing list
> gum...@li...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>