[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] UART problems
Mattias Ågren wrote:
> Since HCI isn't capable of handling erroneous data on the
> UART the whole stack is malfunctioned as a result when only
> a single byte is trashed or lost on the serial port.
I've been thinking about this problem for a while. The stack is really
vulnerable to problems in UART data. The worst situation I've seen is when
the UART drops a byte (due to receive overruns -- a problem we frequently had
on MIPS) and the length field of the HCI packets gets munged. The usual
result is that HCI expects a __REALLY__ big packet of data and waits forever
for it to come in, effectively hanging the connection.
One way to avoid this type of problem is to change the way the layers above
HCI parse. Currently, HCI waits until the complete packet comes in before
passing it up to the next layer. If we modify this so that HCI always
immediately hands up all available data to the next upper layer, that layer
would detect data corruption errors much sooner and could prevent this "hang"
Another possible advantage is that we could reduce the buffer sizes in HCI
because we don't have to accrue a complete contigous packet, we just need
buffers big enough to handle whatever the lower layer needs to give us in one
The down side is that the upper layers like L2CAP would have to implement
parsing state machines similar to the one in HCI. And these can get fairly
What are your thoughts?
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com