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?


On Wed, Sep 22, 2010 at 12:08 AM, Dave Hylands <dhylands@gmail.com> wrote:
Hi David,

On Tue, Sep 21, 2010 at 11:52 PM, David Pedersen <signitary@gmail.com> 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.


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

Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
gumstix-users mailing list