[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] hi, hw-dependencies, and local uart-speed

Oliver Kasten wrote:

> i'm new to the list, so: hi everbody!
> i came across an irritation while changing btd (learning by pulling
> things apart und putting them back together upside down):
> whenever i restart btd(user) i have to reset the ericsson module
> (manually) to reset its uart speed to the default value. otherwise
> communications with the bt-hw fails. that's because the stack always
> sets the local serial port speed to the hw default (in init_phys(...) in
> btd.c:1119 ). however, the bt-hw might already be set to another speed
> by the previous instance of btd(user).
> imho there sould be an additional option (say "-ls <speed>") for the
> serial port speed used when first talking to the bt-hw (i.e. the speed
> the bt-hw is set to when starting the stack).
> this leeds to another question: why isn't there a command in the _menu_
> to change the uart speed? i'd like to implement that. however, there
> seems to be a catch for ericsson hw when changing uart speed
> (btd.c:1205):
> /* wait for HW... must be sure we have sent whole message before
>    changing baudrate on serial port but we must change serial baudrate
>    before the result returns if using P9A modules, why are the P9A
>    ericsson modules not sending the result back on same uart speed ?!?!?
> */
> after setting the new baudrate "set_ericsson_baudrate(spd);" there is a
> fixed wait "usleep(10000)". as of now this code is only called when the
> baudrate is set to the hw default (56.7kbps). would the factor have to
> be a different one when starting from a different baudrate? does it
> depend on other conditions (requests pending, buffer status, etc.)? are
> there conditions when uart-speed changes are illegal?
> cheers,
> olli*
> ps.: i found the hardware-depended code is pretty scattered in the
> source files. there is ericsson specific functions in btd.c, hci.c and
> bluetooth.c. i feel that hw-specific code should be put into one source
> file per hw-device supported.
> --
> Oliver Kasten                                phone: +41/ 1/ 63-2 06 63
> ETH-Zurich                                     fax: +41/ 1/ 63-2 16 59
> Haldeneggsteig 4, IFW D48.1                  email: kasten@xxxxxxx.ch
> CH-8092 Zuerich, Switzerland           http://www.inf.ethz.ch/~kasten/

Those are some good points. Adding the initial speed option to the btd
command line is a good idea in the short run.

In the long run, what should we do about hardware-specific aspects of the
code? Should there be a hardware-specific driver for each type of hardware
(the way ethernet cards solve the problem), or should the bluetooth stack
try to detect the hardware type automatically (the way serial.c tries to
solve the problem), or is there a different, better way?

At a minimum, consolidating the hardware-specific code to one place would
be better than what we currently have.