Bluetooth Driver for Linux Kernel v.2.2.x ------------------------------------------ These files are work in progress. For more information on Bluetooth on Linux see http://developer.axis.com where you can find newer versions of the software. ==================================================================== Very brief description of new features: - !!! MAJOR number for BT driver has changed to 124 (previous : 62) !!! Please update device node (see below *** NEW ***) - Kernel support v 2.2 - Tested client functionality Still some work left, but at least we can connect two stacks and run ppp over the link. - Bug fixes from unplug fest - HCI emulation Previous release: - Better support for multipoint (untested) - More general parsing in SDP - Added client functionality (untested) - More fault detection - Support for initialization of BT hardware (Ericsson module/ Digianswer rs-dongle) ==================================================================== Currently the following problems with the BT stack kernel integration have been found. If you manage to repeat/fix a problem, please post to bluetooth-dev@axis.com or mattias.agren@axis.com * Lost sync in hci_receive_data() The setup here is a standard pc linux machine running the stack and is connected to a digianswer rs232 dongle using a null modem serial cable. The problem is that we sometimes get erroneous data fed into the hci state machine when transferring a lot of data on the link. If we get a byte that is not understood (e.g wrong uart header on a hci packet) we loose sync and must reset the state machine to find the start of a new hci packet. We think this is caused by overwriting of the flip buffers in the serial driver but we're not sure. * HW flow control In the BT hardware there are a certain amount of inbuffers of fixed size. (Digianswer : 2x339 bytes, Ericsson 10x800 bytes) After sending of a hci packet we must get an ack of that it has been sent on the physical link, this is done by sending an event to us with info about how many packets that was sent on each hci handle. In the stack this variable is called acl_num and is used to decide whether to queue an outgoing hci packet it into a software buffer or send it immediately to the hardware. The problem is that when we transfer a lot of data on the link this event suddenly stops coming (missed/never sent from HW?!?) which means we don't get an ack on the sent data which in turn means that we will buffer outgoing data forever... To overcome this problem we have added a timer that 'resets' this variable (by calling read_buffer_size()) if we couldn't send any data for a certain amount of time (e.g 1 s) ==================================================================== Things to do : * Voice - TCS layer - File handle in user mode for control/read/write of voice data * Make SDP more general i.e no static entries * More control from user mode application * Better documentation :) ==================================================================== Best regards Bluetooth team at Axis Communications. =================================================================== - Docs How do I run the stack as a LAN Accesspoint ? --------------------------------------------- # Unpack the tarball : tar xvzf # Make the bluetooth stack module cd bluetooth cd src make # Make the bluetooth application cd .. cd apps make # Insert the module: insmod bt.o # To get debug messages in kernel start another window and issue : tail -f /var/log/messages (or whatever file your kernel logger is set to use) # Then you have to create the file node (as root) for the bluetooth driver in user mode (this will be done from a script later on) *** NEW *** mknod /dev/ttyBT0 c 124 0 For now only use a single tty (ttyBT0) since multipoint functionality still is untested ! Then start the application (as root) : syntax : ./btd [options] options: -u sets which uart device that will be used by the stack default : ttyS0 -b sets which bluetooth device that will be used from application default : ttyBT0 -s sets uart speed 9600, 19200, 38400, 57600, 115200, 230400, 460800 default : 115200 baud -r sets application role (server or client) default : server -i hw specific initialization ericsson, digi (digianswer rs232 dongle) default : no init -m enters command line mode default : skip command line mode e.g if using ericsson module at 460800 baud and acting server ./btd -s 460800 -i ericsson if using HW that req no init and acting client with command line interface ./btd -r client if using non default devices ./btd -u /dev/ttyS2 -b /dev/ttyBT3 [options...] ==================================================================== Short description of new stack integration in kernel ---------------------------------------------------- 1) PPP over serial (standard way): user app (pppd) / \ -------| |------------------ \ / ------------- | tty | | <----> line discipline (PPP) ------------- | tty driver | (serial driver) ------------- / \ -------| |------------------ \ / UART 2) PPP over bluetooth: user app (pppd) / \ -------| |------------------ \ / ttyBT0 -------------- | tty | ldisc-> PPP ldisc ----------------------------------------------- | tty driver | (bluetooth driver) ------------- | | <------- | BT STACK | <----- | ADDED | | <--- | | ------------- | | | | ttyS0 | V V V | ldisc-> BT ldisc ----------------------------------------------- | tty driver | (serial driver) ------------- / \ --------| |------------------ \ / UART ttySx is a standard serial port tty. ttyBTx has a separate major nbr and has been registered to use bt driver as tty driver. ttySx is opened initially from a bluetooth control-application which sets the bt line discipline and keeps the tty open. When ttyBT is opened from pppd it is set to use ppp discipline which in turn uses the driver registered in its tty i.e the bt driver. At the stack top it acts like a serial driver for ppp At the bottom the stack acts like any line discipline used from the standard serial tty. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Glue Layers for stack - "APPLICATION" (here:ttyBT) --------------------------------------------- TOP | bt_recieve_top() | bt_write_top() | --------------------------------------------- ^ | | V T H E S T A C K ^ | | V ---------------------------------------------------- BOTTOM | bt_receive_lower_stack()| bt_write_lower_driver()| ---------------------------------------------------- "PHYSICAL DRIVER" (here:serial driver) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -