Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Let me clarify one thing: The approach we take is a pure userspace solution, it isn't related to NuttX kernel and no plan to upstream it. That is good to know. Thank you.  I will sleep better tonight. The major difference is where to put L2CAP/HCI code(userspace v.s. kernelspace) and it isn

Re: 答复: [External Mail]Re: defining a BLE GATT server

I'm agreeing with you Greg, anything that comes into Apps or the OS must use the socket API. Then we are in agreement.  I am a mother hen and will defend the OS architecture to the teeth (hmm.. hens.. teeth... sorry about the mixed metaphor). I don't get involved in most code changes.  I

RE: 答复: 答复: [External Mail]Re: defining a BLE GATT server

12:46 AM > To: dev@nuttx.apache.org > Subject: Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server > > > > Mr.Greg, I really don't understand why you are so angry, and there are so > > many verbal attacks. > > I just share a feasibility. What I expect is disc

答复: 答复: [External Mail]Re: defining a BLE GATT server

time. BRs, 发件人: Brennan Ashton 发送时间: 2020年8月27日 1:01 收件人: dev@nuttx.apache.org 主题: Re: 答复: [External Mail]Re: defining a BLE GATT server On Wed, Aug 26, 2020 at 9:56 AM Gregory Nutt wrote: > > Lets try to see how we can move this forward, I'm not f

Re: 答复: [External Mail]Re: defining a BLE GATT server

On Wed, Aug 26, 2020 at 9:56 AM Gregory Nutt wrote: > > Lets try to see how we can move this forward, I'm not fully sure I > > fully understand the implications of what you were saying about the > > packet protocol, but I think it is best that we focus the discussion > > on that in the GitHub issu

Re: 答复: [External Mail]Re: defining a BLE GATT server

On 8/26/2020 10:56 AM, Gregory Nutt wrote: Lets bring this back to a constructive place. An Chao I really appreciate the detailed information that you wrote, while I don't think it will be appropriate to include directly upstream it is still valuable to know how you are trying to use this and

Re: 答复: [External Mail]Re: defining a BLE GATT server

Lets bring this back to a constructive place. An Chao I really appreciate the detailed information that you wrote, while I don't think it will be appropriate to include directly upstream it is still valuable to know how you are trying to use this and it helps us make an informed decision movin

Re: 答复: [External Mail]Re: defining a BLE GATT server

> 发件人: Gregory Nutt > 发送时间: 2020年8月27日 0:30 > 收件人: dev@nuttx.apache.org > 主题: Re: 答复: [External Mail]Re: defining a BLE GATT server > > > What you should do is to coordinate and and cooperate with the NuttX > > team to get help from the community.

Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server

Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks. I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others. Yes, I am angry.  I am very pissed off that you completely igno

答复: 答复: [External Mail]Re: defining a BLE GATT server

ry Nutt 发送时间: 2020年8月27日 0:30 收件人: dev@nuttx.apache.org 主题: Re: 答复: [External Mail]Re: defining a BLE GATT server > What you should do is to coordinate and and cooperate with the NuttX > team to get help from the community. If you chose to go your own way > and not discussion or cooper

Re: 答复: [External Mail]Re: defining a BLE GATT server

What you should do is to coordinate and and cooperate with the NuttX team to get help from the community.  If you chose to go your own way and not discussion or cooperation with the team, then you are on your own.  That code will not come into the repository. If you want to do things correc

Re: 答复: [External Mail]Re: defining a BLE GATT server

As mentioned in the title, this is just an experimental project that needs to discuss further the implementation of the bluetooth stack. The implementation of bt stack in userspace does not conflict with the current architecture, this is just a choice. On the contrary, the complete BLE+MESH s

答复: [External Mail]Re: defining a BLE GATT server

ment. BRs, 发件人: Gregory Nutt 发送时间: 2020年8月26日 21:47 收件人: dev@nuttx.apache.org 主题: [External Mail]Re: defining a BLE GATT server On 8/24/2020 8:51 AM, Matias N. wrote: > Thanks for the heads up. Would be good to get Xiao Xiang's input on this > then. Maybe he already encountered this i

Re: defining a BLE GATT server

I fully agree with this. AF_BLUETOOTH is already in place, but it only implements "BTPROTO_L2CAP" all of the GATT and advertising/scanning related functionality is implemented over "BTPROTO_HCI" #define BTPROTO_L2CAP 0 #

Re: defining a BLE GATT server

On 8/24/2020 8:51 AM, Matias N. wrote: Thanks for the heads up. Would be good to get Xiao Xiang's input on this then. Maybe he already encountered this issue. For now I'm working on the Link Layer, looking at 4.0 spec as a start. If the host layer is reimplemented for 5.0 I understand it shouldn

Re: 答复: [External Mail]Re: defining a BLE GATT server

I will add my two cents as well.  I have already responded in comments on PR #1651, but I will copy my reponse here form continuity: I am in 100% agreement with Brennan and Matias. I am very opposed to this change because it violates all of the architectural principles that have been establish

Re: [External Mail]Re: defining a BLE GATT server

An Chao, thanks for the very detailed explanation of how Xiaomi has approach the BLE stack in NuttX, it is quite useful to know when discussing this. However, I agree with Brennan that it is better to maintain compatibility with Linux by exposing the stack via sockets. Best, Matias On Wed, Aug

Re: [External Mail]Re: defining a BLE GATT server

On Wed, Aug 26, 2020, 3:31 AM 安超 wrote: > > Hi Greg, Matias, > > The current implementation of Xiaomi’s Bluetooth stack is different with > the current architecture. > HCI transport layer communication will be based on /dev/ttyS* devices > instead of sockets, > > > > The stack module prefers like

Re: defining a BLE GATT server

Ah, ok, it was much more complex than what I thought. Thanks for the explanation! On Mon, Aug 24, 2020, at 20:10, Brennan Ashton wrote: > On Mon, Aug 24, 2020 at 3:56 PM Matias N. wrote: > > > That's quite a strange stack arrangement. If you go to the BLE spec, the > > L2CAP sits above the HCI

Re: defining a BLE GATT server

On Mon, Aug 24, 2020 at 3:56 PM Matias N. wrote: > That's quite a strange stack arrangement. If you go to the BLE spec, the > L2CAP sits above the HCI layer. > I would guess that the arrow between L2CAP and Bluez actually speaks the > HCI protocol and the "HCI sockets" allow you to directly call

Re: defining a BLE GATT server

I also think D-Bus does not seem to be appropriate for small systems. It is overkill. Also, having a library implementing all functionality and then a daemon using that library would be the best way. As Brennan mentions, in many use cases (such as mine) I would only have a single bluetooth appli

Re: defining a BLE GATT server

> I think you are missing something here, the interface that needs to be > supported is not L2CAP, it is HCI. So you suggest to implement L2CAP in userspace? I'm confused when you mention that there's a L2CAP socket already and HCI socket needs to be added. Just to be clear, I have this stack i

Re: defining a BLE GATT server

On Mon, Aug 24, 2020 at 2:25 PM Gregory Nutt wrote: > > >>> I have been puzzling through the Goobledegook GATT server (GGK, > >>> https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus > >>> interface. It is GPLv3 so not a candidate for porting. And also not > >>> much use for und

Re: defining a BLE GATT server

I have been puzzling through the Goobledegook GATT server (GGK, https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus interface. It is GPLv3 so not a candidate for porting. And also not much use for understanding APIs since the OS interface is hidden inside of the Bluez D-Bus int

Re: defining a BLE GATT server

On Mon, Aug 24, 2020 at 1:40 PM Matias N. wrote: > > > > I have been puzzling through the Goobledegook GATT server (GGK, > > https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus > > interface. It is GPLv3 so not a candidate for porting. And also not > > much use for understandin

Re: defining a BLE GATT server

> I have been puzzling through the Goobledegook GATT server (GGK, > https://github.com/moovel/gatt-server fork). It uses the Bluez D-Bus > interface. It is GPLv3 so not a candidate for porting. And also not > much use for understanding APIs since the OS interface is hidden inside > of the B

Re: defining a BLE GATT server

> I see that there is an ioctl interface for the bluetooth network > driver, but I don't think this is really a good idea. GATT is really > something that should be handled in userspace. Yes, I've been using what exists at the host layer in NuttX, via the btsak application. While it opens a soc

Re: defining a BLE GATT server

On 8/24/2020 2:20 PM, Brennan Ashton wrote: On Mon, Aug 24, 2020 at 12:34 PM Gregory Nutt wrote: Some of the things you have speculated about would be contrary to these principles. The basic wireless rules are: 1. Network sockets are used to communicate with complex wireless networks (like bl

Re: defining a BLE GATT server

On Mon, Aug 24, 2020 at 12:34 PM Gregory Nutt wrote: > > Some of the things you have speculated about would be contrary to these > principles. The basic wireless rules are: > > 1. Network sockets are used to communicate with complex wireless > networks (like bluetooth) > > 2. Character drivers sh

Re: defining a BLE GATT server

Thanks for the heads up. Would be good to get Xiao Xiang's input on this then. Maybe he already encountered this issue. You should also be aware of the wireless architectural principles of https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397 Some of the things you hav

Re: defining a BLE GATT server

Thanks for the heads up. Would be good to get Xiao Xiang's input on this then. Maybe he already encountered this issue. For now I'm working on the Link Layer, looking at 4.0 spec as a start. If the host layer is reimplemented for 5.0 I understand it shouldn't invalidate the LL in principle. But fo

Re: defining a BLE GATT server

Also, I understand that Xiaomi intends to replace the entire Bluetooth stack with a newer BT 5.0 stack.  I don't know if that is still a plan of record or not, but you probably should coordinate Bluetooth architectural changes with Xiao Xiang in any event.

Re: defining a BLE GATT server

You're right, maybe I'm caught on the callback interface because that is how it is implemented now, but in the end there's always a packet you process. I still wonder if also having L2CAP in kernel would be better since it deals with multiple connection handling, packet fragmentation and so on

Re: defining a BLE GATT server

You're right, maybe I'm caught on the callback interface because that is how it is implemented now, but in the end there's always a packet you process. I still wonder if also having L2CAP in kernel would be better since it deals with multiple connection handling, packet fragmentation and so on (to

Re: defining a BLE GATT server

On Sun, Aug 23, 2020, 8:45 PM Matias N. wrote: > Hi Brennan, > > Yes, as I understand the host layer is actually from (early?) Zephyr code. > > The way you suggest it should be done sounds very reasonable. However I > wonder if this is > always the right approach. Right now the HCI layer is using

Re: defining a BLE GATT server

Hi Brennan, Yes, as I understand the host layer is actually from (early?) Zephyr code. The way you suggest it should be done sounds very reasonable. However I wonder if this is always the right approach. Right now the HCI layer is using work queues to handle communication with different priori

Re: defining a BLE GATT server

Personally I think the abstraction is in the wrong place. In most systems including Linux you provide HCI, L2CAP and RFCOMM sockets from the kernel, then all the GATT and connection management logic is moved into a daemon that runs in user space. Some devices do not exposed HCI so the kernel implem

defining a BLE GATT server

Hi, I'm continuing work on BLE on the NRF52832 and I would like to instantiate a GATT server (to eventually provide HID over GATT for providing a bluetooth mouse). Looking at the upper layers of BLE in NuttX you can see that it ends up in a network device which exposes different functionality v