You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by will sanfilippo <wi...@runtime.io> on 2016/03/24 01:08:37 UTC
Nimble HCI
This is a discussion about the nimble HCI. I want to break this into two discussions: the HCI API and newt (package?) architecture. Be warned: might be a bit of a long read and I dont give alot of background details (otherwise would have been a much longer read!).
HCI API:
I was thinking about this in the context of a combined host/controller HCI and a separate HCI that is used by either a controller or host. If you look at an HCI layer that is used by either a controller or host the basic set of API that would need to provided are: transmit data, handle received data, transmit commands/events, handle received commands/events. The HCI itself does not really care if there is a host or controller “attached” to it; the API it provides are the same.
If you look at the combined host/controller HCI API, the above API would need one additional piece of information: whether this is a controller or host calling the API as the HCI code would need to know the proper event queue/API to call. What this means is that we would either need a separate set of API that the host and controller call or the HCI does get notified if this is a host or controller.
I spoke about this with a colleague and we both preferred the separate API approach. The API would look something like this:
host_tx_data
host_rx_data_callback
host_tx_cmd
host_rx_event_callback
controller_tx_data
controller_rx_data_callback
controller_tx_event
controller_rx_cmd_callback
NOTE: I used the term “callback” here to denote the fact that we would probably want to register a function with the HCI to call for received data/commands/events. We could have an API that the host or controller would need to implement but that would mean that the HCI would depend on the host and controller.
Comments?
NEWT ARCHITECTURE:
The other subject I wanted to discuss was how to architect this within the newt framework. Currently we have the BLE stack in net/nimble. This is separated into three basic packages: controller, host and “common nimble”. The common HCI interface code is in the net/nimble/src directory and is part of the net/nimble/ package. Two basic ideas I am considering are: the application informs the nimble package of the HCI that it wants (somehow). The combined host/controller HCI and the “physical” HCI interface code all reside in net/nimble.
The other option is to do something like this:
net/nimble/host
net/nimble/controller
net/nimble/hci_spi
net/nimble/hci_combined
net/nimble/hci_uart
The app would then specify which of these HCI it wanted. The controller and host code would have a required API and the hci_xxxx would provide that API. One thing that we discussed, but due to our lack of knowledge of the “physical” HCI specification we could not decide upon, is whether or not you would have multiple hci for the various physical interfaces or just one and there would be a way of specifying which interface you would need. This really depends (in our minds) on how much of the code would be common among these HCI. I suspect quite a bit but not sure. It migth also be easier with the newt tool to have separate HCI packages.
Anyway, starting with separate hci packages seems to be a good idea to me… Note that these separate HCI packages would depend on hw/hal and would use the appropriate HAL api. This assumes, of course, that the HALs provide the necessary set of API. Of course, these HCI packages could include other HAL’s or fancy drivers if desired and this could be specified by the app or could just be a different hci_xxx package.
Comments?
Re: Nimble HCI
Posted by Christopher Collins <cc...@apache.org>.
On Fri, Mar 25, 2016 at 10:10:47AM -0700, aditi hilbert wrote:
> Can the specific HCI package be part of the target definition instead
> of the app? That way apps could remain HCI-transport agnostic.
> Just a thought.
I do think that would be ideal. The only issue is that some code has to
initialize the specific HCI transport package being used. The target
does not contain any code, so this would need to be done by some other
package (e.g., the app).
I was thinking about some sort of "generic HCI facade" package (or
something) which initializes the correct HCI transport. That would
allow the app to be agnostic with regards to the HCI transport being
used. However, this started to feel way too complicated to justify
implementing it, so that's when I stopped thinking about it :). There
is probably a simpler solution that I haven't considered, so if anyone
has any ideas, please share them.
I think the example BLE apps (bletiny and bleprph) are exceptional in
that they are not developed for any specific platform. My thinking is
that most developers will know exactly which HCI transport they will be
using from the start, so this whole concern of mine may end up being a
nonissue.
Chris
Re: Nimble HCI
Posted by aditi hilbert <ad...@runtime.io>.
Can the specific HCI package be part of the target definition instead of the app? That way apps could remain HCI-transport agnostic.
Just a thought.
thanks,
aditi
> On Mar 24, 2016, at 11:58 PM, will sanfilippo <wi...@runtime.io> wrote:
>
> Yes, that is what I was proposing. I understand your annoyance; not sure if the app is the best place myself but it seems to be a reasonable place for now.
>
> Will
>
>> On Mar 24, 2016, at 10:10 AM, Christopher Collins <cc...@apache.org> wrote:
>>
>> On Wed, Mar 23, 2016 at 05:08:37PM -0700, will sanfilippo wrote:
>> [...]
>>
>> To summarize my understanding of your proposal (please let me know if I
>> got anything wrong!):
>>
>> 1. Create several independent HCI packages in the net/nimble directory.
>>
>>> net/nimble/hci_spi
>>> net/nimble/hci_combined
>>> net/nimble/hci_uart
>>
>> 2. Each HCI package exports the "ble_hci" API in its pkg.yml.
>>
>> # net/nimble/hci_spi/pkg.yml
>> pkg.apis: ble_hci
>>
>> 3. Both net/nimble/host and net/nimble/controller require the "ble"hci"
>> API in their pkg.yml files.
>>
>> # net/nimble/host/pkg.yml
>> pkg.req_apis: ble_hci
>>
>> 4. The app specifies the hard dependency on a specific HCI package.
>>
>> # apps/myapp/pkg.yml
>> pkg.deps: @apache-mynewt-core/net/nimble/hci_spi
>>
>> I like it. There is one annoyance, though: it is too bad that the app
>> has to depend on a specific HCI package. Using bletiny as an example,
>> it would be nice if this app could be HCI-transport-agnostic. However,
>> some piece of code has to initialize the specific HCI package being
>> used, and it makes sense that this would happen in the app, so I am not
>> sure this is an issue. It might be worthwhile to think a bit about how
>> we might solve this issue cleanly. The only solutions I can think of
>> add too much complexity to justify, in my opinion.
>>
>> Thanks,
>> Chris
>
Re: Nimble HCI
Posted by will sanfilippo <wi...@runtime.io>.
Yes, that is what I was proposing. I understand your annoyance; not sure if the app is the best place myself but it seems to be a reasonable place for now.
Will
> On Mar 24, 2016, at 10:10 AM, Christopher Collins <cc...@apache.org> wrote:
>
> On Wed, Mar 23, 2016 at 05:08:37PM -0700, will sanfilippo wrote:
> [...]
>
> To summarize my understanding of your proposal (please let me know if I
> got anything wrong!):
>
> 1. Create several independent HCI packages in the net/nimble directory.
>
>> net/nimble/hci_spi
>> net/nimble/hci_combined
>> net/nimble/hci_uart
>
> 2. Each HCI package exports the "ble_hci" API in its pkg.yml.
>
> # net/nimble/hci_spi/pkg.yml
> pkg.apis: ble_hci
>
> 3. Both net/nimble/host and net/nimble/controller require the "ble"hci"
> API in their pkg.yml files.
>
> # net/nimble/host/pkg.yml
> pkg.req_apis: ble_hci
>
> 4. The app specifies the hard dependency on a specific HCI package.
>
> # apps/myapp/pkg.yml
> pkg.deps: @apache-mynewt-core/net/nimble/hci_spi
>
> I like it. There is one annoyance, though: it is too bad that the app
> has to depend on a specific HCI package. Using bletiny as an example,
> it would be nice if this app could be HCI-transport-agnostic. However,
> some piece of code has to initialize the specific HCI package being
> used, and it makes sense that this would happen in the app, so I am not
> sure this is an issue. It might be worthwhile to think a bit about how
> we might solve this issue cleanly. The only solutions I can think of
> add too much complexity to justify, in my opinion.
>
> Thanks,
> Chris
Re: Nimble HCI
Posted by Christopher Collins <cc...@apache.org>.
I should have added: my response only addresses the "Newt aspects" of
your idea. I agree with the first part of your email and have nothing
to contribute there (the actual API supported by each of the HCI
packages).
Chris
On Thu, Mar 24, 2016 at 10:10:52AM -0700, Christopher Collins wrote:
> On Wed, Mar 23, 2016 at 05:08:37PM -0700, will sanfilippo wrote:
> [...]
>
> To summarize my understanding of your proposal (please let me know if I
> got anything wrong!):
>
> 1. Create several independent HCI packages in the net/nimble directory.
>
> > net/nimble/hci_spi
> > net/nimble/hci_combined
> > net/nimble/hci_uart
>
> 2. Each HCI package exports the "ble_hci" API in its pkg.yml.
>
> # net/nimble/hci_spi/pkg.yml
> pkg.apis: ble_hci
>
> 3. Both net/nimble/host and net/nimble/controller require the "ble"hci"
> API in their pkg.yml files.
>
> # net/nimble/host/pkg.yml
> pkg.req_apis: ble_hci
>
> 4. The app specifies the hard dependency on a specific HCI package.
>
> # apps/myapp/pkg.yml
> pkg.deps: @apache-mynewt-core/net/nimble/hci_spi
>
> I like it. There is one annoyance, though: it is too bad that the app
> has to depend on a specific HCI package. Using bletiny as an example,
> it would be nice if this app could be HCI-transport-agnostic. However,
> some piece of code has to initialize the specific HCI package being
> used, and it makes sense that this would happen in the app, so I am not
> sure this is an issue. It might be worthwhile to think a bit about how
> we might solve this issue cleanly. The only solutions I can think of
> add too much complexity to justify, in my opinion.
>
> Thanks,
> Chris
Re: Nimble HCI
Posted by Christopher Collins <cc...@apache.org>.
On Wed, Mar 23, 2016 at 05:08:37PM -0700, will sanfilippo wrote:
[...]
To summarize my understanding of your proposal (please let me know if I
got anything wrong!):
1. Create several independent HCI packages in the net/nimble directory.
> net/nimble/hci_spi
> net/nimble/hci_combined
> net/nimble/hci_uart
2. Each HCI package exports the "ble_hci" API in its pkg.yml.
# net/nimble/hci_spi/pkg.yml
pkg.apis: ble_hci
3. Both net/nimble/host and net/nimble/controller require the "ble"hci"
API in their pkg.yml files.
# net/nimble/host/pkg.yml
pkg.req_apis: ble_hci
4. The app specifies the hard dependency on a specific HCI package.
# apps/myapp/pkg.yml
pkg.deps: @apache-mynewt-core/net/nimble/hci_spi
I like it. There is one annoyance, though: it is too bad that the app
has to depend on a specific HCI package. Using bletiny as an example,
it would be nice if this app could be HCI-transport-agnostic. However,
some piece of code has to initialize the specific HCI package being
used, and it makes sense that this would happen in the app, so I am not
sure this is an issue. It might be worthwhile to think a bit about how
we might solve this issue cleanly. The only solutions I can think of
add too much complexity to justify, in my opinion.
Thanks,
Chris