Re: [patch] HWUART instead of BTUART on the h5550 (workaround for Bluetooth UART overruns)

On Mon, Mar 14, 2005 at 11:02:50AM +0100, Catalin Drula wrote:
> Any ideas or suggestions are welcome. Especially maybe people with more
> hardware experience can explain how the value of a byte while it gets
> moved around in a computer can get corrupted. I can understand how it can
> get overwritten as a whole (for example, in the case of UART overruns).
> But how can only some of the bits within be corrupted is beyond me. I mean
> I assume that even if the UARTs perform serial transmission (bit by bit),
> they do have a buffer were bytes are reconstructed before being moved
> further, don't they?

Yes, both the uart on the lmx9814 and the hwuart have a fifo for storing
values and a scratch buffer for reconstructing bytes.

Does changing the speed of the hwuart cause any change in behavior? I
noticed in your previous post that you were using 921kbps. This is
optimal from both a bandwidth and power situation. But maybe there is
something up with the uart at certain speeds.

Also, do you know what the value is in the uart fifo before it makes it
to bluez? drivers/char/serial.c still has a chance at fudging the
values.

I like your diagnosis though. I am willing to blame the lmx9814 for
this. Maybe there is a way to recover more gracefully with bluez such
that it doesn't make the hw out of sync assumption on the bad packet.

Could you give us an idea of how many transmission errors per second
show up on small packets and big packets?

E

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request