You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2021/01/19 11:59:10 UTC
[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
xiaoxiang781216 opened a new pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720
## Summary
and remove bthcisocket driver since uart shim driver can provide the same functionality but more flexible.
## Impact
The call sequence change from:
```
NuttX BT stack->BT HCI SOCKET
```
to
```
NuttX BT stack->BT UART->BT UART SHIM->BT HCI TTY
```
but the behaviour is same from userspace.
## Testing
btsak work as before.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
btashton commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762937459
I absolutely do not see how this is "more correct" . If you want to just do your own BT thing in userspace than fine just expose the UART and do it in userspace, but requiring that everything does this makes no sense as a long term plan. So if I have a SPI BT device do I now have to write a tty driver for it?
If people really want to go this way then we should just kill off the BT stack, but I would find that really disappointing.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762835680
> I'm not entirely convinced that the serial interface is better than the socket interface. I also don't really see much benefit of replacing it with something that involves more layers in between.
The packet transfered by socket is actually H4(UART) packet:
https://github.com/apache/incubator-nuttx/pull/2720/files#diff-cca4f6c2d4ffd2eac608b4ae978781ae34f011e20a4bab939ade11d7ca38dc3aL97-L116
https://github.com/apache/incubator-nuttx/pull/2720/files#diff-cca4f6c2d4ffd2eac608b4ae978781ae34f011e20a4bab939ade11d7ca38dc3aL218-L237
So it is more natural and correct to expose it through bt_uart driver and then reuse the same packet/unpacket logic for us:
https://github.com/apache/incubator-nuttx/blob/master/drivers/wireless/bluetooth/bt_uart.c#L209-L222
https://github.com/apache/incubator-nuttx/blob/master/drivers/wireless/bluetooth/bt_uart.c#L315-L332
> I'm curious what is the benefit you see on the tty interface over the socket based one.
we can support both NuttX BLE stack and external BT/BLE stack with the same tty driver:
1. NuttX BLE stack talk with the uart shim driver
2. External BT/BLE stack talk with the tty driver
More important, we can create a tty bridge driver to support BT and BLE stack from the different provider:
1. Without modifyingthe hardware driver
2. Without modifying the BT or BLE stack too
like this:
```
/dev/ttyHCI-BT bridge-+-/dev/ttyBT---Android bluedroid
|-/dev/ttyBLE--NuttX native stack
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
btashton commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762995775
> I think that a better, more roadmap friendly solution, would be a raw HCI interface. Brennan and Matias discusses this some time back but I am not sure what happened with that.
>
There is one and it works. It's a little special right now since you have to disable the internal host stack. This restriction will go away I just need to finish adding the logic to disable host stack control (if enabled) so it does not trample on the transactions.
Technically under Linux this would be the user channel which is raw but can assert user control of the interface, and the raw channel let's everything fight for control.
Also in my last change I think everything is also now routed so we can easily tap in to support the monitor channel.
These changes are on my list for probably after I get the mbed stuff working and more of the bl602 support in (although they seem to be making good progress internally which is awesome to see).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762999677
BTW, since old BT protocol is still supported by many chipset, it's important that RAW/monitor socket support BT traffic too before NuttX get native BT stack support.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762999677
BTW, since BT stack is still supported by many chipset, it's important that RAW/monitor socket support BT traffic too before NuttX get native BT stack support.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762997126
> I think that a better, more roadmap friendly solution, would be a raw HCI interface. Brennan and Matias discusses this some time back but I am not sure what happened with that.
>
> There should be very little difference between a standard raw socket interface and a non-standard UART interface.
RAW HCI sockets are supported and is what is used to integrate nimBLE to NuttX. It is kind of exactly the same interface used for the nimBLE port to Linux (for this reason, porting to NuttX was relatively easy). Other planned work was to add "newer" socket types (management and monitor, I believe) which is multi-user friendly (RAW socket requires exclusive access).
EDIT: Brennan already answered while writing this
> This whole discussion raises an issue of architectural control. How can we manage a coherent architecture and follow a consistent development roadmap if every one is free to go their own way and to corrupt the the architecture with a PR. I think in the long run, this lack of architectural control will damage the OS. There has to be some level of agreement and participation in such decisions by all parties that have an interest. Such critical decisions cannot be left to a simple PR, at least not in my opinion.
I agree that such changes are not to be taken lightly and I think that previous discussion towards own intentions is usually useful to validate if the idea goes inline with global consensus (maybe the consensus changes as a result of the discussion or maybe not). Also sometimes it is better to have a proof of concept (for example, a draft PR) so that the discussion is more based on actual code and not so much hand waving.
I thought about a few times that things are discussed and decided could be written down somewhere, but it is the kind of thing that always slips away.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] patacongo commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
patacongo commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762989860
I think that a better, more roadmap friendly solution, would be a raw HCI interface. Brennan and Matias discusses this some time back but I am not sure what happened with that.
There should be very little difference between a standard raw socket interface and a non-standard UART interface.
This whole discussion raises an issue of architectural control. How can we manage a coherent architecture and follow a consistent development roadmap if every one is free to go their own way and to corrupt the the architecture with a PR. I think in the long run, this lack of architectural control will damage the OS. There has to be some level of agreement and participation in such decisions by all parties that have an interest. Such critical decisions cannot be left to a simple PR, at least not in my opinion.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton merged pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
btashton merged pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762978508
Ok, I change the patch to enable hcitty to integrate with NuttX BLE stack, but keep the hcisock as before. Please take a look.
> > I tend to agree, this seems more of a preference than a clear benefit. It is good to add the option (is it was when the hcitty driver was added), but replacing one for the other does not really feel right.
>
> The only architecture on the Bluetooth roadmap is via the network. This has been discussed years ago, agreed to, and documented at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 for example.
>
> Previously Xiao Xiang had agreed not to included this alternative, off roadmap solution.
Yes, this patch is to enable NuttX BLE stack on top of hcitty.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] patacongo edited a comment on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
patacongo edited a comment on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762989860
I think that a better, more roadmap friendly solution, would be a raw HCI interface. Brennan and Matias discusses this some time back but I am not sure what happened with that.
There should be very little difference between a standard raw socket interface and a non-standard UART interface. Isn't that mostly just a difference in semantics?
This whole discussion raises an issue of architectural control. How can we manage a coherent architecture and follow a consistent development roadmap if every one is free to go their own way and to corrupt the the architecture with a PR. I think in the long run, this lack of architectural control will damage the OS. There has to be some level of agreement and participation in such decisions by all parties that have an interest. Such critical decisions cannot be left to a simple PR, at least not in my opinion.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] patacongo commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
patacongo commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762968868
>
>
> I tend to agree, this seems more of a preference than a clear benefit. It is good to add the option (is it was when the hcitty driver was added), but replacing one for the other does not really feel right.
The only architecture on the Bluetooth roadmap is via the network. This has been discussed years ago, agreed to, and documented at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 for example.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762999677
BTW, since BT stack is still supported by many chipset, it's important that RAW/monitor socket support BT traffic too.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-763000952
Also, not to continue derailing the PR analysis, but an important discussion is to decide what to do with NuttX's BLE host layer (I talked about this before). At least, it would be good to put something on the roadmap related to this (try to finish a proper socket-integrated host layer, remove it and embrace an external one?). At the moment I wonder how many real users does NuttX's host layer have and how many are actually using an external one. Anyway, just saying it may be good to start a thread/open an issue and discuss it.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] patacongo edited a comment on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
patacongo edited a comment on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762989860
I think that a better, more roadmap friendly solution, would be a raw HCI interface. Brennan and Matias discusses this some time back but I am not sure what happened with that.
There should be very little difference between a standard raw socket interface and a non-standard UART interface. Isn't that mostly just a difference in semantics? Socket vs. character driver semantics?
This whole discussion raises an issue of architectural control. How can we manage a coherent architecture and follow a consistent development roadmap if every one is free to go their own way and to corrupt the the architecture with a PR. I think in the long run, this lack of architectural control will damage the OS. There has to be some level of agreement and participation in such decisions by all parties that have an interest. Such critical decisions cannot be left to a simple PR, at least not in my opinion.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762952933
I tend to agree, this seems more of a preference than a clear benefit. It is good to add the option (is it was when the hcitty driver was added), but replacing one for the other does not really feel right.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] patacongo edited a comment on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
patacongo edited a comment on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762968868
>
>
> I tend to agree, this seems more of a preference than a clear benefit. It is good to add the option (is it was when the hcitty driver was added), but replacing one for the other does not really feel right.
The only architecture on the Bluetooth roadmap is via the network. This has been discussed years ago, agreed to, and documented at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 for example.
Previously Xiao Xiang had agreed not to included this alternative, off roadmap solution.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] btashton merged pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
btashton merged pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 edited a comment on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762835680
> I'm not entirely convinced that the serial interface is better than the socket interface. I also don't really see much benefit of replacing it with something that involves more layers in between.
The packet transfered by socket is actually H4(UART) packet:
https://github.com/apache/incubator-nuttx/pull/2720/files#diff-cca4f6c2d4ffd2eac608b4ae978781ae34f011e20a4bab939ade11d7ca38dc3aL97-L116
https://github.com/apache/incubator-nuttx/pull/2720/files#diff-cca4f6c2d4ffd2eac608b4ae978781ae34f011e20a4bab939ade11d7ca38dc3aL218-L237
So it is more natural and correct to expose it through bt_uart driver and then reuse the same packet/unpacket logic for us:
https://github.com/apache/incubator-nuttx/blob/master/drivers/wireless/bluetooth/bt_uart.c#L209-L222
https://github.com/apache/incubator-nuttx/blob/master/drivers/wireless/bluetooth/bt_uart.c#L315-L332
> I'm curious what is the benefit you see on the tty interface over the socket based one.
we can support both NuttX BLE stack and external BT/BLE stack with the same tty driver by config:
1. NuttX BLE stack talk with the uart shim driver
2. External BT/BLE stack talk with the tty driver
More important, we can create a tty bridge driver to support BT and BLE stack from the different provider at the runtime:
1. Without modifyingthe hardware driver
2. Without modifying the BT or BLE stack too
like this:
```
/dev/ttyHCI-BT bridge-+-/dev/ttyBT---Android bluedroid
|-/dev/ttyBLE--NuttX native stack
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 removed a comment on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 removed a comment on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762978080
Ok, I change the patch to enable hcitty to integrate with NuttX BLE stack, but keep the hcisock as before. Please take a look.
> > I tend to agree, this seems more of a preference than a clear benefit. It is good to add the option (is it was when the hcitty driver was added), but replacing one for the other does not really feel right.
>
> The only architecture on the Bluetooth roadmap is via the network. This has been discussed years ago, agreed to, and documented at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 for example.
>
> Previously Xiao Xiang had agreed not to included this alternative, off roadmap solution.
Yes, this patch is to enable NuttX BLE stack on top of hcitty.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] v01d commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
v01d commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762814949
I'm not entirely convinced that the serial interface is better than the socket interface. I also don't really see much benefit of replacing it with something that involves more layers in between. I'm curious what is the benefit you see on the tty interface over the socket based one.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #2720: board/sim: Support NuttX BLE stack through uart shim driver
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on pull request #2720:
URL: https://github.com/apache/incubator-nuttx/pull/2720#issuecomment-762978080
Ok, I change the patch to enable hcitty to integrate with NuttX BLE stack, but keep the hcisock as before. Please take a look.
> > I tend to agree, this seems more of a preference than a clear benefit. It is good to add the option (is it was when the hcitty driver was added), but replacing one for the other does not really feel right.
>
> The only architecture on the Bluetooth roadmap is via the network. This has been discussed years ago, agreed to, and documented at https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 for example.
>
> Previously Xiao Xiang had agreed not to included this alternative, off roadmap solution.
Yes, this patch is to enable NuttX BLE stack on top of hcitty.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org