[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] hi, hw-dependencies, and local uart-speed
Gordon McNutt wrote:
> 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: firstname.lastname@example.org
> > 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.
We are using our own BT hardware (Radio+Baseband) and we don't want to
implement the ericsson or digianswer specific commands. So we would
appreciate the hardware-specific code confined in one file.
I also think that there is a lot of time lost when the stack starts (due to
hardware problems after initialisation). Having the hardware-specific code in
one file would allow the hardwares (ours?) that do not have these problems to
have their stack start faster...
If you look at the BT stack, there is the "HCI RS232 Transport Layer", which
specifies how all these problems should be solved (uart initial setup +
negociation...) so, there should not be any hardware specific code anyway for
the next versions of these modules !