Re: HW configuration of Nimble (HCI)
Hi Oleg, On Wed, Nov 23, 2016 at 03:07:11PM +0300, Oleg Persidskiy wrote: > good time dear Engineers! > > Have a question about your newt Nimble (HCI) subproject. > (sorry I'm a newbie with newt ~ 1 day) Great! > During the test (I use nRF52 own board) faced with a problem , where I can > reconfigure > PORT IO pins, SPEED & etc. parameters ? > > nRF5x SoC has very flexible PIO configuration ability but I cannot set my > board paratemetrs to Nimble HCI driver (it default uses nRF52DK based board > configuration). > > Summary I need to > 1. decrease the HCI_UART speed to 19200 (long line capacity issue) > 2. remap IO pins Numbers: RX/TX/CTS/RTS according to my board. > 3. change Protocol 8 bit to 9 bit (w parity) This is one area of Mynewt that could definitely use some better documentation. To adjust these settings, you need to use the syscfg mechanism. In short, each package defines system-wide settings via something called syscfg. Your project can then override the default values of these settings in various packages, usually the app or target. For simplicity, I would recommend overriding these settings at the target level for now. Here is how you would override these settings. Note: For the following, I am assuming you are using the nRF52dk BSP. If you are not, the following will still probably work, but you may want to adjust the comments accordingly. * Create a file called "syscfg.yml" in your target directory (targets//syscfg.yml) * Add the following contents to this file: syscfg.vals: # @apache-mynewt-core/hw/bsp/nrf52dk UART_0_PIN_TX: UART_0_PIN_RX: UART_0_PIN_RTS: UART_0_PIN_CTS: # @apache-mynewt-core/net/nimble/transport/uart BLE_HCI_UART_BAUD: 19200 BLE_HCI_UART_DATA_BITS: 9 BLE_HCI_UART_STOP_BITS: (*) BLE_HCI_UART_PARITY:(**) Replace pin-num values as appropriate. I wasn't sure which values are appropriate for stop bits or parity. Valid parity values are: HAL_UART_PARITY_NONE, HAL_UART_PARITY_ODD, HAL_UART_PARITY_EVEN, This file will reconfigure your project as specified. You can see a list of all the settings in your project with the "newt target config " command. The settings are organized by their defining package. As indicated by the comments above, the settings in this case come from the nrf52dk BSP package and the nimble UART transport package. > > > Thanks you a lot! > > Oleg.
HW configuration of Nimble (HCI)
good time dear Engineers! Have a question about your newt Nimble (HCI) subproject. (sorry I'm a newbie with newt ~ 1 day) During the test (I use nRF52 own board) faced with a problem , where I can reconfigure PORT IO pins, SPEED & etc. parameters ? nRF5x SoC has very flexible PIO configuration ability but I cannot set my board paratemetrs to Nimble HCI driver (it default uses nRF52DK based board configuration). Summary I need to 1. decrease the HCI_UART speed to 19200 (long line capacity issue) 2. remap IO pins Numbers: RX/TX/CTS/RTS according to my board. 3. change Protocol 8 bit to 9 bit (w parity) Thanks you a lot! Oleg.
Re: Nimble HCI
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
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 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 >> 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
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 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
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
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
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_ 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?
