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

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

In response to...
In the long run, what should we do about hardware-specific aspects of the
We are using our own BT hardware (Radio+Baseband) and we don't want to
implement the ericsson or digianswer specific commands.

In the long run there should be no need.  It would still be good to have
code in a Linux stack for coping with this, however (I'll explain why in a

Given that the HW manufacturer's to date (AFAIK) have provided both UART,
and USB interfaces one must assume that they never intended that people use
them to develop RS-232 BT devices to attach to a PC.

The UART interface is intended for use in embedded development where
minimizing overhead is advantageous, having no error correction on the
transport mechanism is acceptable (because the very short traces can be laid
out to avoid noise), and having to know exactly what hardware is attached is
no big deal (because that's just the way the device is built).  So providing
the UART interface is advantageous to HW developers (i.e. BT baseband/module

The USB interface handles all of these issues well and is a better choice
than RS-232 for PC products because it is fully Plug and Play while RS-232
BT devices would essentially need a manual user installation process.

Now, enter the Axis Linux stack that is being developed for both PC and
embedded use.  Uh... This stack should be useable regardless of the HW type,
but shouldn't hedge its bets on USB because an RS-232 controller is much
cheaper and easier to implement in an embedded design than a USB controller.

--- AXIS ET. AL.
Separate the hardware specific functions as best you can and make it obvious
what needs to be done to add/change HW types.  Also, provide an easy way for
switching between UART, RS-232, and as easy as can be done USB.

Realize that there is a use for the RS-232 transport layer as well as the
UART and USB transport layers, then offer it.  DO NOT, however, offer it at
the expense of the UART transport layer, but rather make the module be
configurable to use either (i.e. HW configurable via configuration pins, not
RS-232 messages).
Also, if you make a version that is pin compatible with another
manufacturer's then by all means emulate their vendor specific commands as
much as makes reasonable sense (and they don't have justification to get
upset about).

-----Original Message-----
From: owner-bluetooth-dev@xxxxxxx.com
[mailto:owner-bluetooth-dev@xxxxxxx.com]On Behalf Of Gordon McNutt
Sent: Friday, October 20, 2000 9:17 AM
To: Oliver Kasten
Cc: bluetooth-dev@xxxxxxx.com
Subject: 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.