my BlueUSB
After first sucessfully trying the USBHostShell of Peter Barrett, I continued with the BlueUSB which, according to what he hooked up to it was very powerfull.
The good
The library is light weight and indeed it did not have problems with any of my three BT radios. Also the inquiry discovered all devices I was interested in. This makes it a good starting point to build applications from.
The bad
The stack is very bare bone, it provides core functionality (L2CAP) but not the desirable SDP and especially RFCOMM. The program, as provided, was designed to be used for HID, especially the wiimote. For my purposes I need RFCOMM so I started the development of an RFCOMM layer. Everything I needed was on the Internet, specifications (bluetooth.org and ETSI) and examples (google code and open_bt). How hard can it be to add a few bytes to every packet? Well a lot harder than I initially thought.
The ugly
Lean as BlueUSB is, it lacks quite a few features. Most notably there is no support for fragmentation and recombination or control flow. The L2CAP works in basic mode so fragmentation and flow control are not required but the HCI should support recombination. Nowhere are packet sizes checked against the actual mtu's or buffer sizes. The structure of the library is a mixture of object-oriented concepts and flat C-code. The programmer needs to be aware of object sizes and alignment. The HCI layer appears to be both above and beneath the L2CAP layer which makes understanding the code a bit confusing. Also the state-machine of the L2CAP was incomplete so connections sometimes failed.
My contribution
Originally I just wanted to bolt an RFCOMM layer right on top of the L2CAP layer with minimal changes to the existing code. Meanwhile I have an RFCOMM layer and a simple SDP client running but it required quite a few changes to the existing code. To make things worse, it didn't make the code more understandable. A complete refactoring of the code, using more object oriented concepts would be a good idea but will take quite some time. For the time being however I will not try to improve the code any further unless the need arises.
Update 15.04.2011
I have done a lot of work on SDP. It should handlemultiple simultaneous connections now (as a client) and also the server is working. Windows Vista can query the services and reports it as a serial device. The next step is to make MBED accept incoming RFCOMM connections.
Update 4-5-2011
Finally have the RFCOMM server working (reasonably). It responds to SABM, PN, DISC, DM, MSC and RPN commands. Credit based data-flow works OK. Other data-flow is not implemented. The published demo allows a terminal like Putty to connect/disconnect and echo anything typed. Characters are buffered until CR or LF or buffer-full. I'm still struggling with a nasty bug in USBHost. Sometimes the bulk endpoint just blocks and nothing comes out of it anymore. I've traced the problem to something in the ISR, ProcessDoneQueue or Transfer. The problem is not random but always occurs in the same place in my program (after authentication when setting up an rfcomm connection with mbed as server, last thing to happen is change of encryption). I found out that enabling a LOG statement in ProcessDoneQueue cured the problem which made me think that it was timing related. Replacing the LOG with wait_us() also worked, even with delays a short as 0us or 1us, which make me think it is interrupt related. Somewhere in the program is a kind of race or deadlock condition but I cannot find it. I already sacrificed two weeks of my life to it and have decided to use the work-around as long as it works. If anyone has ideas please let me know. A good starting point is ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf the OHCI specification. I also looked at the USBLite stack from NXP but could not find anything like ProcessDoneQueue, in any case it does not run as part of the ISR. For those who want to improve the BT stack: The BT Core specification is almost mandatory reading (I used v2.0) and so is the additional specification for RFCOMM (both available from the BT SIG website). Very helpful is also the ETSI TS07.10 specification (ETSI TS 101369 v7.2.0), but a bit harder to get. A good introduction to RFCOMM is in 'Connect without cables' Bray/Thurman, Chapter 10 about RFCOMM can be found on the Internet. Some information about dlci's and the D and C/R bits is confusing and you should really read the real spec.
12 comments on my BlueUSB:
Please log in to post comments.
Excellent work. I was hoping someone had already done the RFCOMM SPP layer. If I understand correctly this means we'd be able to use the cheap $2.00 BT USB modules to give our MBED bluetooth serial right??
Thanks for your contributions!!!