Re: bleprph using HCI 4 wire
Hi Jeff, My responses are inline. On Tue, Jun 26, 2018 at 02:11:46AM +, Jeff Belz wrote: > All: > > > I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4 wire HCI. > I got one response that said I just have to change the syscfg setting in my > target to > > > > BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0 > BLE_HCI_TRANSPORT_UART: 1 > > 1. I can't find any documentation to what these lines do? The documentation for syscfg settings is in the packages themselves. Both of the above settings are defined by the @apache-mynewt-nimble/nimble/transport package. You can see the full list of settings in a project, along with their descriptions, with this command: newt target config show However, I don't think you will see either of these settings if you execute this command. From the dependency list you quoted, it looks like you are using an older version of Mynewt which does not support these two settings. I believe you are using Mynewt 1.3.0; you will want to upgrade to 1.4.0, released about one week ago. There was a long delay between the releases of 1.3.0 and 1.4.0, and I mistakenly forgot that 1.4.0 was not yet released when I wrote my original email. The latest version introduces some fairly major changes, so I suggest you upgrade as follows: 1. Download Newt 1.4.0 as described here: http://mynewt.apache.org/develop/get_started/native_install/index.html 2. Upgrade the Mynewt repos to 1.4.0 by running: newt upgrade inside your project directory. > 2. How can I make sure it's configuring the right UART? There is a syscfg setting defined by @apache-mynewt-nimble/nimble/transport/uart called `BLE_HCI_UART_PORT`. By default, this is defined to be 0. You can change its value if you need to use a different UART. > 3. Do I change the target syscfg or the one in the app folder? I recommend changing the target's syscfg. The target configuration overrides the app configuration, and it is best not to change a foreign repo except when necessary. The syscfg system is described in more detail here: http://mynewt.apache.org/develop/os/modules/sysinitconfig/sysinitconfig.html > 4. Do I really need the bootloader? If so, is there documentation to why, > I will eventually need to modify this. The boot loader is not strictly required, but much of the Mynewt infrastructure assumes it is present. When you are getting Mynewt up and running for the first time, I recommend you use the boot loader so that you can follow the documentation more closely. Chris
bleprph using HCI 4 wire
All: I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4 wire HCI. I got one response that said I just have to change the syscfg setting in my target to BLE_HCI_TRANSPORT_NIMBLE_BUILTIN: 0 BLE_HCI_TRANSPORT_UART: 1 1. I can't find any documentation to what these lines do? 2. How can I make sure it's configuring the right UART? 3. Do I change the target syscfg or the one in the app folder? 4. Do I really need the bootloader? If so, is there documentation to why, I will eventually need to modify this. Also do I need all the dependencies in the pkg.yml. I would think I do not need the controller, since that is the Broadcom. pkg.deps: - boot/split - boot/bootutil - kernel/os - mgmt/imgmgr - mgmt/newtmgr - mgmt/newtmgr/transport/ble -net/nimble/controller - net/nimble/host - net/nimble/host/services/ans - net/nimble/host/services/gap - net/nimble/host/services/gatt - net/nimble/host/store/config - net/nimble/transport/ram - sys/console/full - sys/log/full - sys/stats/full - sys/sysinit - sys/id
Re: shell commands for multiple instantiated modules
Not sure I have a strong opinion on this one. My initial reaction was option 1
but I can understand why some of the other options might be better.
> On Jun 25, 2018, at 4:07 AM, Michał Narajowski
> wrote:
>
> Hi Paul,
>
> IMO Option 1 seems like the best option here. I don't think the special
> command processing code will require a lot of work. Of course, if you think
> that Option 2 is better for your use case you can implement it and submit a
> PR.
>
> BR
> Michał Narajowski
>
> pon., 25 cze 2018 o 04:10 p...@wrada.com napisał(a):
>
>> I'm checking with the group on how folks have done this in the past in
>> case I am missing something. Also proposing how I would solve the problem
>> looking for feedback.
>>
>> I have a module that you may want to instantiate more than once (create
>> two or more objects). For example suppose I have a device driver that may
>> instantiate multiple times but with different context.
>>
>> I’m trying to determine how I will provide shell commands for them. I have
>> a few options.
>>
>> 1. use the first argument of the shell command as the object instance
>> and queue the object onto some list that I can search in the command to
>> execute the command on the right object
>> 2. Try to modify the the shell command to include a void * somewhere in
>> the registration and have the shell commands pass it back during execution.
>> 3. Have the callback return the module name string which I can cast
>> back or search for combining the flexibility of #1 and #2
>>
>> In the first option I would queue my instance objects on a queue and then
>> search for them by name or number
>>
>> * foo 0 reset
>> * foo 1 reset
>>
>> When there is only once instance (most typical) then the command has the
>> burden of carrying the extra notation or I have to provide provisional
>> processing to do some default behavior when the number is left out of the
>> command. For this functionality I need to queue the objects which is not
>> currently necessary (its only a few bytes for an SLIST).
>>
>> In the second choice I could have the following changes to shell
>>
>> * include a void * in the shell_register that is passed in the
>> callback like
>> * typedef int (*shell_cmd_func_t)(int argc, char *argv[], void
>> *arg);
>>
>> * int shell_register(const char *shell_name, const struct shell_cmd
>> *shell_commands, void *arg)
>>
>> * shell_register(“sample_object0", cmd, (void*) )
>>
>> * shell_register(“sample_object1", cmd, (void*) )
>> * Modify the internal definition of the shell module to have
>> * struct shell_module {
>> * const char *name;
>> * const struct shell_cmd *commands;
>> * void *arg;
>> * };
>>
>> In this method the commands would look like this
>>
>> * foo0 reset
>> * foo1 reset
>>
>> Of course, the first instance of this could also just be called foo and
>> then the latter could have numbers
>>
>> * Foo reset
>> * foo1 reset
>> * foo2 reset
>>
>> NOTE: because of mempools, logs and stats I already keep a char *name in
>> the object to differentiate each instance (e.g. foo0 foo1 etc). So I
>> already have the means to pass the name.
>>
>> In the 3rd option, it would not change any of the APIs to register or any
>> of the internal structures , but will still require a change to the
>> callback to pass the string back to the caller like this
>>
>> * typedef int (*shell_cmd_func_t)(int argc, char *argv[], const char
>> *shell_name);
>>
>> And I could cast that back to my object using something like
>>
>> Struct foo {
>> /* blah blah */
>> char name[32];
>> };
>>
>> Struct foo *pf = (struct foo*) ( (uint8_t*) shell_name - (int) ((struct
>> foo *) 0)->name))
>>
>> Or I could keep them on a list and search the list for a matching string
>> in shell_name.
>>
>> In short
>>
>> * Option 1 — requires no change to shell API. Requires queueing
>> objects and some special command processing code
>> * Option 2 — simple to use, but requires API change and an extra void
>> * storage for each shell module
>> * Option 3 — more complicated to use, requires API change but does not
>> require extra storage for each shell module
>>
>>
>>
>>
>>
>>
>>
>>
Re: Change to absolute package dependencies in core
+1 On Sun, Jun 24, 2018 at 7:45 AM, Jacob Rosenthal wrote: > TLDR > why not make all newt core packages dependencies absolute like > - "@apache-mynewt-nimble/nimble/host/util" > instead of relative as they are now > - nimble/host/util > > Whenever I need to fork locally to my project I have to do all this > manually which is annoying and error prone, especially in BSPs. Is there > any reason newt core deps are relative right now? > > Indeed, it would be valuable for the newt tool itself to promote forking, > as a major strength of newt is its dependency management. Something like > newt fork could just copy a dependency into your local directory structure. > But for now making manual forking easier would be nice. > > Any arguments against? >
Re: Retrieving hardware IDs in Mynewt
Hello, You can simply call the HAL routine, given you already know the size of the HWID for your MCU (using LEN below): #include uint8_t buf[LEN]; len_read = hal_bsp_hw_id(buf, LEN); "buf" will have the HWID and the len will be returned. If you want to do it in a portable manner, you can use hal_bsp_hw_id_len() to check the size for the target MCU and allocate enough space (that was added recently, so not available on older releases). Fabio On Mon, Jun 25, 2018, at 9:48 AM, Amr Bekhit wrote: > Hello, > > Is there any driver for retrieving CPU hardware IDs in mynewt? I can see > that there is a sys/id package, but I couldn't find any documentation for > it, nor any use of this library in the sample code. > > Amr
Retrieving hardware IDs in Mynewt
Hello, Is there any driver for retrieving CPU hardware IDs in mynewt? I can see that there is a sys/id package, but I couldn't find any documentation for it, nor any use of this library in the sample code. Amr
Re: shell commands for multiple instantiated modules
Hi Paul,
IMO Option 1 seems like the best option here. I don't think the special
command processing code will require a lot of work. Of course, if you think
that Option 2 is better for your use case you can implement it and submit a
PR.
BR
Michał Narajowski
pon., 25 cze 2018 o 04:10 p...@wrada.com napisał(a):
> I'm checking with the group on how folks have done this in the past in
> case I am missing something. Also proposing how I would solve the problem
> looking for feedback.
>
> I have a module that you may want to instantiate more than once (create
> two or more objects). For example suppose I have a device driver that may
> instantiate multiple times but with different context.
>
> I’m trying to determine how I will provide shell commands for them. I have
> a few options.
>
> 1. use the first argument of the shell command as the object instance
> and queue the object onto some list that I can search in the command to
> execute the command on the right object
> 2. Try to modify the the shell command to include a void * somewhere in
> the registration and have the shell commands pass it back during execution.
> 3. Have the callback return the module name string which I can cast
> back or search for combining the flexibility of #1 and #2
>
> In the first option I would queue my instance objects on a queue and then
> search for them by name or number
>
> * foo 0 reset
> * foo 1 reset
>
> When there is only once instance (most typical) then the command has the
> burden of carrying the extra notation or I have to provide provisional
> processing to do some default behavior when the number is left out of the
> command. For this functionality I need to queue the objects which is not
> currently necessary (its only a few bytes for an SLIST).
>
> In the second choice I could have the following changes to shell
>
> * include a void * in the shell_register that is passed in the
> callback like
> * typedef int (*shell_cmd_func_t)(int argc, char *argv[], void
> *arg);
>
> * int shell_register(const char *shell_name, const struct shell_cmd
> *shell_commands, void *arg)
>
> * shell_register(“sample_object0", cmd, (void*) )
>
> * shell_register(“sample_object1", cmd, (void*) )
> * Modify the internal definition of the shell module to have
> * struct shell_module {
> * const char *name;
> * const struct shell_cmd *commands;
> * void *arg;
> * };
>
> In this method the commands would look like this
>
> * foo0 reset
> * foo1 reset
>
> Of course, the first instance of this could also just be called foo and
> then the latter could have numbers
>
> * Foo reset
> * foo1 reset
> * foo2 reset
>
> NOTE: because of mempools, logs and stats I already keep a char *name in
> the object to differentiate each instance (e.g. foo0 foo1 etc). So I
> already have the means to pass the name.
>
> In the 3rd option, it would not change any of the APIs to register or any
> of the internal structures , but will still require a change to the
> callback to pass the string back to the caller like this
>
> * typedef int (*shell_cmd_func_t)(int argc, char *argv[], const char
> *shell_name);
>
> And I could cast that back to my object using something like
>
> Struct foo {
> /* blah blah */
> char name[32];
> };
>
> Struct foo *pf = (struct foo*) ( (uint8_t*) shell_name - (int) ((struct
> foo *) 0)->name))
>
> Or I could keep them on a list and search the list for a matching string
> in shell_name.
>
> In short
>
> * Option 1 — requires no change to shell API. Requires queueing
> objects and some special command processing code
> * Option 2 — simple to use, but requires API change and an extra void
> * storage for each shell module
> * Option 3 — more complicated to use, requires API change but does not
> require extra storage for each shell module
>
>
>
>
>
>
>
>
