RFCOMM Data: T E S T
Thanks everyone for their input on the future of the LUFA documentation I asked about last time – some very good feedback posted, and I’ve moved the discussion over to the LUFA mailing list for more input and so I don’t lose track of any ideas.
There’s still a LOT of work to do to get it done, but today I had a major win in my Bluetooth code. This is the minimal log put out by the demo when I connect to it with my Linux laptop:
Connection Request from Device 11:11:11:11:11:11.
Connection Complete to Device 11:11:11:11:11:11.
RFCOMM Data: 0x54 (T) 0x45 (E) 0x53 (S) 0x54 (T) 0x0A ()
Disconnection Complete to Device 11:11:11:11:11:11.
There has never been such sweeter words. Again, still major portions of the code to work on, but I can now send my board data just by echoing into a virtual RFCOMM device using Linux’s rfcomm tool. I don’t think I’m the first to do this on an embedded platform without the use of a full OS, but I think I might be the first one crazy enough to write the whole lot by himself.
As mentioned previously, the code written at the moment only works for a small subset of the overall functionality – most notably, the stack can’t initiation a connection to other Bluetooth devices yet (need to add it to the HCI layer) and the RFCOMM code is similarly one way at present. All good things come to those who wait however, so stay tuned.
Sounds very sweet mate!
Cant wait to see it in action. I am currently investing into an AT90USBKey to experiment with USB.
Hi Dean,
Great!!!!!
Mirko
Hi Dean,
My goal is to use LUFA in my AVR project in witch I use one AVR ATmega32.
Suppose that I’ll implement my project with one ARV chip that support USB host…
Than I want even connect a BT dongle to my projet for control it by a java Midlet, do you think that it will be possilbe to add LUFA as a library? Or the chip that host LUFA must be completely dedicated to BT dongle interface?
Mirko Ugolini
Mirko,
Yes, it would be possible to use LUFA in your application, but only if you replaced the ATMEGA32 with either the AT90USB1287 or AT90USB647 so that you can host the Bluetooth dongle. You could of course add on the second AVR to your project and interface with it via the USART, I2C or SPI buses, but you might as well just port your code to the USB AVR and same money.
The Bluetooth code should not be *too* intensive on the AVR, so plenty of cycles left over for your application. You just need to run the Bluetooth and USB service tasks periodically (as fast as possible) but unlike software USB stacks like VUSB, LUFA and the Bluetooth code requires very little CPU time when no data is being transferred.
Cheers!
– Dean