An apology, Bluetooth Host development
First of all, my apologies for the dead LUFA download last night — it seems the upload was corrupted. Not very proffesional of me, but on the flipside it also masked a rather nasty new bug in the Host mode configuration descriptor search routines (since corrected) so it can’t be all bad. If you tried to download the new 090209 release already and can’t extract, try again now.
I’m currently working on the holy-grail of embedded hobby projects – $5 bluetooth. Presently, if you want bluetooth in your applications, you’re forced to pay out the sunshine-generator for $200 or more serial bluetooth modules. Granted, these modules make implementing bluetooth serial easy, but are expensive and inflexible. Actually, come to think of it, that’s the exact reason for choosing LUFA on a USB AVR over a FTDI or similar USB serial chip.
I haven’t proved that it is viable just yet, so no one get too excited. However, I’m able to send commands to the bluetooth controller in my cheap $5 (shipped!) bluetooth dongle to set the device name, enter discovery mode, set the device class and accept/reject/close connections to another bluetooth device. I’m now busy unravelling the Service Discovery Protocol used to indicate what services (analogous to USB device classes) a device implements.
Possible problems ahead would be buffering issues — mitigated by USB’s flow-control, since I can read and process as data streams in — and endpoint address issues. As stated previously, I don’t think the USB AVRs support having bidirectional non-control endpoints, however it may well turn out that I was wrong. Currently I’m trialling a system where the bidirectional pipe is frozen, its direction token changed and unfrozen, to get half-duplex bidirectional pipe capabilities.
Here’s what my PC currently sees when my board is plugged into a bluetooth adapter:
And the current debug output:
Device Attached. Getting Device Data. Bluetooth Dongle Detected. Getting Config Data. Bluetooth Dongle Enumerated. Device Name: LUFA Bluetooth Demo Allowing remote discovery... Waiting for events... Connection Request from device 00:1F:81:00:01:00 (DEAN-TOSHIBA) -- Device Class: 0x040201 -- Link Type: 0x01 Connection Complete to device 00:1F:81:00:01:00 (DEAN-TOSHIBA) -- Connection Handle: 0x0001 -- Link Type: 0x01 -- Encryption Type: 0x00 ACL Packet Received -- Connection Handle: 0x2001 -- Data Length: 0x000C -- Channel ID: 0x0001 -- Payload Length: 0x0008 L2CAP Connection Request Connection disconnected. -- Connection Handle: 0x0001 -- Reason: 0x13