-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIM: Add support Linux HCI Socket as BLE adaptor #1655
Conversation
fead667
to
ee643e1
Compare
Very nice addition! BTW, can we also expose L2CAP sockets? In that case we could fully use the simulator to test GATT for example. |
Should not be a problem as the host side will queue based on the Linux network stack settings. I would do a select on the socket but there is not a real good way to handle this across the simulation boundary. This is basically the same thing we do for X11 and netdev.
There is no need, this lets us hook in a the the controller level so the NuttX Bluetooth stack should be providing the L2CAP on top of this. I just added a little more to handle reading the ACL packets from the controller, it should already be handling sending them out. |
@v01d Just verified a GATT connection with this and was able to see the ACL send and recv through the the host and NuttX, so I think the L2CAP stuff should work fine on top of this. |
Very nice, indeed. Could you also support a USB Bluetooth HCI dongle with libusb and feed that into the stack as well? |
I would think that Sebastian Ene's pre-emption changes could support better realtime response. |
I was worried about issuing a blocking read on the host socket inside a NuttX thread. If you have any thoughts on that the logic is rather isolated, I just was not sure how to do this. |
So right now the physical transport is agnostic since Linux takes care of that exposing a generic HCI interface, on my machine I have a fairly standard PCIe form factor dual Bluetooth Wifi chip and the Bluetooth half of it is USB. The downside of this is it is Linux specific, but I also get to put Wireshark in the middle at the controller level which means it gets to snoop on the encryption. If you want something more cross platform then yeah libusb is probably the way to go, the Xiaomi patch actually implemented a libusb interface for I think a standard CSR dongle. Instead of adding the tty interface on top it could be wired into the stack as a normal device. I do all my development on Linux and my interest is a little further up the stack so I probably would not implement this myself, but I would review it. |
Yeah, you are right. There is probably more involved. I did experiment with a configuration where I implemented simulated serial device drivers on a pthread which avoided the blocking issue in the simulation main thread. But I never worked through all of the issues. I bet Sebastien Ene could make that kind of device driver model work. |
Great! |
LGTM |
* Public Function Prototypes | ||
****************************************************************************/ | ||
|
||
int bthcisock_host_send(int fd, uint8_t pkt_type, uint8_t *data, size_t len); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we merge into up_internal.h? since all other drivers put the function prototype there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are functions that cross the Host NuttX boundary, I don't really want to expose these interfaces to other drivers. VPN kit for instance also carries its own header file in the vpnkit folder.
Hi Brennan, this is a great addition! Kudos!!! |
@acassis I would like to leave this in the board readme for now and write a more cohesive document on the Bluetooth stack and testing once we get more of it solidified. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signed-off-by: Brennan Ashton <[email protected]>
@xiaoxiang781216 I think I have addressed all of your comments. With the |
LGTM. |
LGTM |
@btashton The HCISOCKET(BTPROTO_HCI) work very well for BT and BLE, but it seem that the socket with BTPROTO_SCO can't work as expected. Do you have any idea to simulate the SCO capability? |
Summary
There is also support on a Linux Host for attaching the Bluetooth hardware from the host to the NuttX Bluetoooth stack via the HCI Socket interface over the User Channel. This is enabled in the bthcisock configuration. In order to use this you must give the nuttx elf additional capabilities:
sudo setcap 'cap_net_raw,cap_net_admin=eip' ./nuttx
You can then monitor the HCI traffic on the host with wireshark or btmon:
sudo btmon
Impact
This enables much more powerful testing on the simulation target than we have with the null driver.
Testing
In the simulation:
...