PC Bluetooth to Prop Bluetooth using serial protocol is obviously one use.
I have a GPS with inbuilt Bluetooth to send GPS info to my laptop (and phone). I use the laptop for Navigation with my C-Maps on my boat. (also have chartplotter inc GPS and paper maps).
It would be nice to be able to receive this info via Bluetooth into the prop. It is just a one way set of ASCII characters. I expect it uses a serial simulated interface.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
They come apart really easily (there's barely anything holding them together!) and they are very convenient for soldering to a 4-pin male header. Best of all, they worked with my code without any modifications. Here's a Propeller scanning for nearby Bluetooth devices, using no external components other than the cheap dongle itself:
Still some software work to do before this meets Hanno's challenge conditions (especially the 100 kbps part...) but this is looking promising. I can already see a lot of use in even having a low-speed packet radio on a Prop for $2!
So far I'm using about 12 kB of RAM total, and 4 cogs. (3 for USB, 1 for the Bluetooth stack) I'm sure that can be optimized, but right now I'm just trying to get something put together that works. Bluetooth is pretty complex, and I'm new at this [noparse]:)[/noparse]
Wow- great job Micah! I'm very interested in using Bluetooth to "cut the cord" for ViewPort, 12Blocks, TBot, and potentially even a future PropScope. Main requirement for me is to send data from the Propeller to the pc.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Bergamot said...
Does anyone know if Bluetooth + USB HCI = Bluetooth HCI?
In other words, can you use this to talk to bluetooth keyboards/mice?
HCI is the Host Controller Interface, it's the spec that a Bluetooth adapter uses to talk to other devices. Common PC bluetooth dongles use a USB protocol that acts as a transport for HCI.
I think you're thinking of the HID (Human Interface Device) spec. Bluetooth HID is based on USB HID, but they're different specs. I'm interested in supporting HID, though, at least in a limited form. Bluetooth mouse/keyboard support would be cool, plus the Wii remotes use a protocol that's based on HID. I'm really excited about having the Propeller talking to Wiimotes without any PC involved.
Shouldn't be too much more work to get HID support.. just need to write a simple HID driver after I get L2CAP socket support implemented. Right now the bluetooth-host.spin object has some basic L2CAP support, but there's no way to access it from other cogs yet. I was planning on setting up a simple "socket"-like buffer object in hub memory, so that either Spin or Assembly code in other cogs can read/write data on L2CAP or RFCOMM sockets.
So uh.. short answer is "not yet, but soon I hope" [noparse]:)[/noparse]
I found a way to fix the packet loss in the USB host controller, at the expense of a little speed. Now the FT232 loopback test is running with 0% packet loss.
I've been implementing a socket layer in the Bluetooth stack with support for L2CAP and RFCOMM protocols. (L2CAP is a low-level datagram protocol like UDP, RFCOMM is a stream-oriented protocol that includes flow control and another layer of multiplexing. HID uses L2CAP, SPP and OBEX use RFCOMM.)
There's still some work left to do before this is actually useful, but I just got the receive end of RFCOMM working reliably. In this picture, you can see it gets 10-12 kilobytes per second at the moment, over a virtual Bluetooth serial port. Lots of room for optimization [noparse]:)[/noparse]
I just set this up to try and am amazed by the results. Great work.
I still get different results from different bluetooth chip manufacturers dongles. There still seems to be a problem in the control transfers where the prop does not respond with an ack.
Have put a USB analyzer on the link, would the Ellisys traces help you to fix it quick? Or shoud I investigate more myself ?
ribbotson said...
I just set this up to try and am amazed by the results. Great work.
I still get different results from different bluetooth chip manufacturers dongles. There still seems to be a problem in the control transfers where the prop does not respond with an ack.
Have put a USB analyzer on the link, would the Ellisys traces help you to fix it quick? Or shoud I investigate more myself ?
Cool, I'm glad it's mostly working [noparse]:)[/noparse]
If you have Ellisys traces showing the bug, I'd love to see them. We have the Ellisys analyzers at work, but I don't have any hardware analyzer at home- and I haven't tried bringing my Prop into work yet. So any traces you have would be really helpful!
It's possible the ACK bug is related to a recent change I made in order to try and fix the unreliable bulk IN transfers. The Prop has to send out an ACK before we actually know if the packet was received correctly, so originally this meant that CRC errors on received packets were unrecoverable. I made a change which ends up "deferring" the ACK by one packet. So we do each IN transfer at least twice- the first one is never ACKed, then the second one gets ACKed if the first was successful.
This has been working well for the devices I've tested so far, but I haven't done as much testing with this change as I had before making it. And it's certainly possible that some devices don't support recovering from CRC errors on control transfers. If that's the case, maybe I'll make ACK deferral optional, and enable it only for Bulk and Interrupt transfers.
The problem is exactly as you describe below with not ACKing the first packet, but the second. The traces are below. If others want to view they will ned to download the free viewing software from Ellisys website.
There are 3 files, address_ok is an startup with a MAX3421E and shows the ack of the first in packet of set address. address_pok is for a bluetoth dongle containing a CW6626F chip fom Conwise, and this works OK with the second ACK, this is also the same for a genuine CSR bluecore 4 chipset.
The third file address_nok is for a bluetoth dongle containing an AS3620A chip from ASC and this does not like the second ACK.
All traces show the frame counter is not incremented as you describe in the code. This does not seem to cause a problem
Note all these dongles show CSR in their VID and PID, but are different. ASC seem to all have the same "unique " bluetooth address, and I have found other differences to.
Better quality dongles are often based on the Broadcom chipset, but these also have a hub built in so will not work, The hub provides for bluetooth HID boot devices for keyboard and mouse, besides the HCI device.
Hope this helps,
Richard
I just checked in a patch to usb-fs-host.spin which adds the missing OUT status stage on control reads, and it enables the "deferred ACK" hack only for bulk and interrupt transfers.
I only have one USB device with me at the moment to test the new code on (A conwise bluetooth dongle) but it seems to work there. Please let me know if this fixes your devices. I'd be really happy to see new traces too [noparse]:)[/noparse]
I got some time to look at this again. All of the bluetooth dongles (ASC, Conwise, CSR) all enumerate and work the same now as you will see from the traces. Slightly disconcerting having double reads, but it seems to work OK.
It is two years since I programmed the prop, so I am pretty useless and these new problems I have may be mine rather than yours.
First I am trying to read the remote device name from a wiimote using wiimote-remote-name.spin, and get strange results. I only want the first 20 bytes to check it is really a Wiimote. Attached are the code and an updated version of bluetooth-host.
There are a lot of changes to wbluetooth host, to support not only the remote name, but also to support the outgoing connections the wiimote requires. I also made some changes because I was getting confused between handles, identifiers and cid names.
The second problem is when I bring up the wiimote. My program wiimote-blue does not work reliably. I am still looking into why, but wondered if you have some insight. The program connects to the wiimote, sets up the two HID channels and the receives the wiimote button data. I attach a trace of when it works.
Still I do have Wiimote working on prop (sometimes !) thanks to your code
Cool demo! It took a few tries, but I did get it working with one of the $2 Conwise adapters and a Wiimote [noparse]:)[/noparse]
I've been on vacation for the past week (and for about another week) so I haven't had time to do this quite yet, but I've been wanting to finish implementing a real 'socket' layer that will allow other modules to open L2CAP and RFCOMM sockets. I'm hoping we can implement a wiimote / HID module as a separate Spin object, and keep bluetooth-host.spin as non-application-specific as possible.
I haven't looked into why your demo only sometimes works- but I suspect it has to do with the pairing process. I only have authentication and PINs kind of half-implemented at the moment. I've heard that the Wiimotes like connecting with a PIN that's derived from the last three bytes of the host's BDADDR.
Oh, I forgot to reply about your remote name test!
I would recommend identifying wiimotes by Class Of Device rather than by name. I think this is what the wiiuse library does.
I wasn't too interested in remote names at the moment, so I saved some memory by using a smaller HCI event buffer. The remote name events are pretty big, so if you want to read remote names you'll need to increase MAX_EVT_SIZE in bluetooth-hciusb from 64 to 256.
I just tried that change, and it still doesn't work for me. Perhaps there's also some other HCI setting that needs to be changed first? Usually when I'm debugging something like this, I'll pour over the Bluetooth HCI spec a bit and/or stare at the USB debug logs. This may be less useful to you since you have a hardware analyzer, but if you swap out usb-fs-host-debug for usb-fs-host in the OBJ section of bluetooth-hciusb, you'll get serial output at 1 Mb/s that dumps out all USB transactions performed by the HCI layer.
Hi Micah,
I doubt a problem in the pairing, because this same sequence works fine on other bluetooth stacks. I think more likely timing or my rubbish programming.
The wiimote supports both soft and hard pairing. This is the soft pairing using the 1 and 2 buttons. The PIN is only used in the other pairing case where the wiimote makes an inbound connect.
I agree that the bluetooth-host.spin should remain generic, but does need to support outbound as well as inbound connections. Still need to get my head around the socket part !
The wiimote can be simple, but when people want to add nunchuck, audio, IR camera, motion Plus, I think you are right on a seperate wiimote object.
You are free to use, change, redistribute, discard any parts of my demo without attribution.
I've learnt a lot looking into your code, nice work.
How functional is this code at the moment? I ordered some of the cheap dealextreme bluetooth dongles and I'm wondering whether it would be doable to create a sort of serial to bluetooth transceiver, so it would receive using fullduplexserial or something like that, and then transmit and receive over bluetooth using Micah's usb and bluetooth code. Earlier in the thread there was a mention of high error rates or checksum failures - are those sorted out/decreased now?
Micrathene said...
How functional is this code at the moment? I ordered some of the cheap dealextreme bluetooth dongles and I'm wondering whether it would be doable to create a sort of serial to bluetooth transceiver, so it would receive using fullduplexserial or something like that, and then transmit and receive over bluetooth using Micah's usb and bluetooth code. Earlier in the thread there was a mention of high error rates or checksum failures - are those sorted out/decreased now?
Yes, the packet loss and CRC error issues have been sorted out.
I haven't had time to work on this in the past couple weeks. As it is, you can *almost* use it as a virtual bluetooth serial port. There's a bit of extra code necessary to implement sockets, but it's really close to being usable. Depending on how much you feel like hacking it, you can already use it to do some real-world communications.
Hopefully in the next couple weeks I'll get time to polish this up and get the virtual serial port fully working.
The code looks great !
I am impressed with all of the USB Services: Bluetooth, Storage, FT232, etc.
How is the Bluetooth Functionality ?
- Does the Bluetooth Ring support the Transmit as well as Receive ?
- Can I have (2) Propellers with Bluetooths exchanging Data via BT.Ring now ?
- Can I use the Propeller with Bluetooth to talk to my Laptop ?
The code looks great !
I am impressed with all of the USB Services: Bluetooth, Storage, FT232, etc.
How is the Bluetooth Functionality ?
- Does the Bluetooth Ring support the Transmit as well as Receive ?
- Can I have (2) Propellers with Bluetooths exchanging Data via BT.Ring now ?
- Can I use the Propeller with Bluetooth to talk to my Laptop ?
jlsilicon.
Thanks!
The plan is definitely to support all of the above. But right now the code is still in a bit of a rough state. Receive rings work, but they aren't tested very well. Transmit rings haven't been implemented yet. My most recent task was implementing a persistent keystore in EEPROM for keeping track of link keys, so bluetooth device pairings can survive power loss. But I've just been a bit of a lazy bum lately. I'll try to get to it soon [noparse]:)[/noparse]
Comments
PC Bluetooth to Prop Bluetooth using serial protocol is obviously one use.
I have a GPS with inbuilt Bluetooth to send GPS info to my laptop (and phone). I use the laptop for Navigation with my C-Maps on my boat. (also have chartplotter inc GPS and paper maps).
It would be nice to be able to receive this info via Bluetooth into the prop. It is just a one way set of ASCII characters. I expect it uses a serial simulated interface.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
They come apart really easily (there's barely anything holding them together!) and they are very convenient for soldering to a 4-pin male header. Best of all, they worked with my code without any modifications. Here's a Propeller scanning for nearby Bluetooth devices, using no external components other than the cheap dongle itself:
Still some software work to do before this meets Hanno's challenge conditions (especially the 100 kbps part...) but this is looking promising. I can already see a lot of use in even having a low-speed packet radio on a Prop for $2!
So far I'm using about 12 kB of RAM total, and 4 cogs. (3 for USB, 1 for the Bluetooth stack) I'm sure that can be optimized, but right now I'm just trying to get something put together that works. Bluetooth is pretty complex, and I'm new at this [noparse]:)[/noparse]
--Micah
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I don't know why someone did not try this years ago.
Parallax should make it the official USB host, and pour in some cash.
Gadgetgansgter should start including it in·the next platform module.
·
In other words, can you use this to talk to bluetooth keyboards/mice?
HCI is the Host Controller Interface, it's the spec that a Bluetooth adapter uses to talk to other devices. Common PC bluetooth dongles use a USB protocol that acts as a transport for HCI.
I think you're thinking of the HID (Human Interface Device) spec. Bluetooth HID is based on USB HID, but they're different specs. I'm interested in supporting HID, though, at least in a limited form. Bluetooth mouse/keyboard support would be cool, plus the Wii remotes use a protocol that's based on HID. I'm really excited about having the Propeller talking to Wiimotes without any PC involved.
Shouldn't be too much more work to get HID support.. just need to write a simple HID driver after I get L2CAP socket support implemented. Right now the bluetooth-host.spin object has some basic L2CAP support, but there's no way to access it from other cogs yet. I was planning on setting up a simple "socket"-like buffer object in hub memory, so that either Spin or Assembly code in other cogs can read/write data on L2CAP or RFCOMM sockets.
So uh.. short answer is "not yet, but soon I hope" [noparse]:)[/noparse]
--Micah
A co-worker was placing an order at dealextreme today, so I grabbed the same items.. I can't wait to play..
Thanks Micah..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New ICON coming, gotta wait for the INK to heal, now we have colour!
Unfreak'n believable stuff.. Can't wait to get the little time I have with my three current projects to get to play with this.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered? PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
I found a way to fix the packet loss in the USB host controller, at the expense of a little speed. Now the FT232 loopback test is running with 0% packet loss.
I've been implementing a socket layer in the Bluetooth stack with support for L2CAP and RFCOMM protocols. (L2CAP is a low-level datagram protocol like UDP, RFCOMM is a stream-oriented protocol that includes flow control and another layer of multiplexing. HID uses L2CAP, SPP and OBEX use RFCOMM.)
There's still some work left to do before this is actually useful, but I just got the receive end of RFCOMM working reliably. In this picture, you can see it gets 10-12 kilobytes per second at the moment, over a virtual Bluetooth serial port. Lots of room for optimization [noparse]:)[/noparse]
--Micah
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Looks like no one bothered to tell Micah that [noparse]:)[/noparse]
Amazing piece of work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I still get different results from different bluetooth chip manufacturers dongles. There still seems to be a problem in the control transfers where the prop does not respond with an ack.
Have put a USB analyzer on the link, would the Ellisys traces help you to fix it quick? Or shoud I investigate more myself ?
Cool, I'm glad it's mostly working [noparse]:)[/noparse]
If you have Ellisys traces showing the bug, I'd love to see them. We have the Ellisys analyzers at work, but I don't have any hardware analyzer at home- and I haven't tried bringing my Prop into work yet. So any traces you have would be really helpful!
It's possible the ACK bug is related to a recent change I made in order to try and fix the unreliable bulk IN transfers. The Prop has to send out an ACK before we actually know if the packet was received correctly, so originally this meant that CRC errors on received packets were unrecoverable. I made a change which ends up "deferring" the ACK by one packet. So we do each IN transfer at least twice- the first one is never ACKed, then the second one gets ACKed if the first was successful.
This has been working well for the devices I've tested so far, but I haven't done as much testing with this change as I had before making it. And it's certainly possible that some devices don't support recovering from CRC errors on control transfers. If that's the case, maybe I'll make ACK deferral optional, and enable it only for Bulk and Interrupt transfers.
Thanks!
--Micah
There are 3 files, address_ok is an startup with a MAX3421E and shows the ack of the first in packet of set address. address_pok is for a bluetoth dongle containing a CW6626F chip fom Conwise, and this works OK with the second ACK, this is also the same for a genuine CSR bluecore 4 chipset.
The third file address_nok is for a bluetoth dongle containing an AS3620A chip from ASC and this does not like the second ACK.
All traces show the frame counter is not incremented as you describe in the code. This does not seem to cause a problem
Note all these dongles show CSR in their VID and PID, but are different. ASC seem to all have the same "unique " bluetooth address, and I have found other differences to.
Better quality dongles are often based on the Broadcom chipset, but these also have a hub built in so will not work, The hub provides for bluetooth HID boot devices for keyboard and mouse, besides the HCI device.
Hope this helps,
Richard
I just checked in a patch to usb-fs-host.spin which adds the missing OUT status stage on control reads, and it enables the "deferred ACK" hack only for bulk and interrupt transfers.
I only have one USB device with me at the moment to test the new code on (A conwise bluetooth dongle) but it seems to work there. Please let me know if this fixes your devices. I'd be really happy to see new traces too [noparse]:)[/noparse]
Thanks!
--Micah
It is two years since I programmed the prop, so I am pretty useless and these new problems I have may be mine rather than yours.
First I am trying to read the remote device name from a wiimote using wiimote-remote-name.spin, and get strange results. I only want the first 20 bytes to check it is really a Wiimote. Attached are the code and an updated version of bluetooth-host.
There are a lot of changes to wbluetooth host, to support not only the remote name, but also to support the outgoing connections the wiimote requires. I also made some changes because I was getting confused between handles, identifiers and cid names.
The second problem is when I bring up the wiimote. My program wiimote-blue does not work reliably. I am still looking into why, but wondered if you have some insight. The program connects to the wiimote, sets up the two HID channels and the receives the wiimote button data. I attach a trace of when it works.
Still I do have Wiimote working on prop (sometimes !) thanks to your code
Thanks,
Richard
Cool demo! It took a few tries, but I did get it working with one of the $2 Conwise adapters and a Wiimote [noparse]:)[/noparse]
I've been on vacation for the past week (and for about another week) so I haven't had time to do this quite yet, but I've been wanting to finish implementing a real 'socket' layer that will allow other modules to open L2CAP and RFCOMM sockets. I'm hoping we can implement a wiimote / HID module as a separate Spin object, and keep bluetooth-host.spin as non-application-specific as possible.
I haven't looked into why your demo only sometimes works- but I suspect it has to do with the pairing process. I only have authentication and PINs kind of half-implemented at the moment. I've heard that the Wiimotes like connecting with a PIN that's derived from the last three bytes of the host's BDADDR.
Thanks again!
--Micah
I would recommend identifying wiimotes by Class Of Device rather than by name. I think this is what the wiiuse library does.
I wasn't too interested in remote names at the moment, so I saved some memory by using a smaller HCI event buffer. The remote name events are pretty big, so if you want to read remote names you'll need to increase MAX_EVT_SIZE in bluetooth-hciusb from 64 to 256.
I just tried that change, and it still doesn't work for me. Perhaps there's also some other HCI setting that needs to be changed first? Usually when I'm debugging something like this, I'll pour over the Bluetooth HCI spec a bit and/or stare at the USB debug logs. This may be less useful to you since you have a hardware analyzer, but if you swap out usb-fs-host-debug for usb-fs-host in the OBJ section of bluetooth-hciusb, you'll get serial output at 1 Mb/s that dumps out all USB transactions performed by the HCI layer.
--Micah
I doubt a problem in the pairing, because this same sequence works fine on other bluetooth stacks. I think more likely timing or my rubbish programming.
The wiimote supports both soft and hard pairing. This is the soft pairing using the 1 and 2 buttons. The PIN is only used in the other pairing case where the wiimote makes an inbound connect.
I agree that the bluetooth-host.spin should remain generic, but does need to support outbound as well as inbound connections. Still need to get my head around the socket part !
The wiimote can be simple, but when people want to add nunchuck, audio, IR camera, motion Plus, I think you are right on a seperate wiimote object.
You are free to use, change, redistribute, discard any parts of my demo without attribution.
I've learnt a lot looking into your code, nice work.
Enjoy your vacation
Cheers,
Richard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://forums.parallax.com/showthread.php?p=650217
meow, i have my own topic now? (sorta)
Yes, the packet loss and CRC error issues have been sorted out.
I haven't had time to work on this in the past couple weeks. As it is, you can *almost* use it as a virtual bluetooth serial port. There's a bit of extra code necessary to implement sockets, but it's really close to being usable. Depending on how much you feel like hacking it, you can already use it to do some real-world communications.
Hopefully in the next couple weeks I'll get time to polish this up and get the virtual serial port fully working.
--Micah
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I always have someone watching my back.
The latest code is always in my Subversion repository:
svn.navi.cx/misc/trunk/propeller/usb-host/
--Micah
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I always have someone watching my back.
The code looks great !
I am impressed with all of the USB Services: Bluetooth, Storage, FT232, etc.
How is the Bluetooth Functionality ?
- Does the Bluetooth Ring support the Transmit as well as Receive ?
- Can I have (2) Propellers with Bluetooths exchanging Data via BT.Ring now ?
- Can I use the Propeller with Bluetooth to talk to my Laptop ?
jlsilicon.
Thanks!
The plan is definitely to support all of the above. But right now the code is still in a bit of a rough state. Receive rings work, but they aren't tested very well. Transmit rings haven't been implemented yet. My most recent task was implementing a persistent keystore in EEPROM for keeping track of link keys, so bluetooth device pairings can survive power loss. But I've just been a bit of a lazy bum lately. I'll try to get to it soon [noparse]:)[/noparse]
--Micah