Re: [VOTE] Release Apache Mynewt 1.10.0-rc1 and Apache NimBLE 1.5.0-rc1
+1 (binding) Best, Michał pon., 2 maj 2022 o 22:05 Andrzej Kaczmarek napisał(a): > +1 (binding) > > > > On Mon, 2 May 2022 at 18:40, Vipul wrote: > > > +1 (binding) > > > > Regards, > > Vipul Rahane > > > > On Mon, May 2, 2022 at 2:02 AM Łukasz Rymanowski < > > lukasz.rymanow...@codecoup.pl> wrote: > > > > > +1 (binding) > > > > > > Best > > > Łukasz > > > > > > On Sat, 30 Apr 2022 at 09:58, Jerzy Kasenberg > > > wrote: > > > > > > > > +1 (binding) > > > > > > > > best regards > > > > Jerzy > > > > > > > > pt., 29 kwi 2022 o 11:49 Szymon Janc > > > napisał(a): > > > > > > > > > > +1 (binding) > > > > > > > > > > There are couple of issues mentioned in release notes but those can > > be > > > > > fixed in point release. > > > > > > > > > > > > > > > On Mon, 25 Apr 2022 at 00:45, Szymon Janc wrote: > > > > > > > > > > > Hello all, > > > > > > > > > > > > I am pleased to be calling this vote for the source release of > > > > > > Apache Mynewt 1.10.0 and Apache NimBLE 1.5.0. > > > > > > > > > > > > Apache Mynewt is a community-driven, permissively licensed open > > > source > > > > > > initiative for constrained, embedded applications. Mynewt > provides > > a > > > > > > real-time operating system, flash file system, network stacks, > and > > > > > > support utilities for real-world embedded systems. > > > > > > > > > > > > Apache NimBLE is Bluetooth Low Energy 5.3 stack from Apache > Mynewt. > > > > > > > > > > > > This release is coordinated release of Apache Mynewt and NimBLE. > > > Future > > > > > > NimBLE releases may be released separately depending on needs. > > > > > > > > > > > > For full release notes for both Mynewt and NimBLE, please visit > the > > > Apache > > > > > > Mynewt Wiki: > > > > > > https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes > > > > > > > > > > > > Apache Mynewt and Apache NimBLE release candidates were tested as > > > follows: > > > > > > 1. Manual execution of the Mynewt test plan: > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan > > > > > > The test results can be found at: > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/MYNEWT/1.10.0+Test+Results > > > > > > 2. Manual execution of the NimBLE test plan: > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/MYNEWT/Apache+NimBLE+Test+Plan > > > > > > The test results can be found at: > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/MYNEWT/NimBLE+1.5.0+Test+Results > > > > > > > > > > > > Note that this testing is not yet complete and more results > > > will show > > > > > > while > > > > > > voting is ongoing. > > > > > > > > > > > > 2. The full unit test suite for both releases was executed via > > > "newt > > > > > > test all" > > > > > > with no failures. This testing was performed on the > following > > > > > > platforms: > > > > > >* Fedora Linux 35 > > > > > > > > > > > > The release candidate to be voted on is available at: > > > > > > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/ > > > > > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.5.0/rc1/ > > > > > > > > > > > > The commits under consideration are as follows: > > > > > > blinky: > > > > > > repos: https://github.com/apache/mynewt-blinky > > > > > > commit d2dcd79fb9fad8fb6cb63b0e338cb81b995fc0f9 > > > > > > core: > > > > > > repos: https://github.com/apache/mynewt-core > > > > > > commit 71c228891d02891a6be765d53e7a3874edc59074 > > > > > > newt: > > > > > > repos: https://github.com/apache/mynewt-newt > > > > > > commit 874afdfa6f4738646bad29d9d7119a68dc7b0128 > > > > > > newtmgr: > > > > > > repos: https://github.com/apache/mynewt-newtmgr > > > > > > commit c3cc444a278471b5ca5293607526e05295ded0e4 > > > > > > nimble: > > > > > > repos: https://github.com/apache/mynewt-nimble > > > > > > commit 21d59b8b40c232d6746778dda6b91cf0c0edba83 > > > > > > > > > > > > In addition, the following newt and newtmgr convenience binaries > > are > > > > > > available: > > > > > > linux: > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-linux-1.10.0.tgz > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-linux-1.10.0.tgz > > > > > > > > > > > > osx: > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-osx-1.10.0.tgz > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newtmgr-bin-osx-1.10.0.tgz > > > > > > > > > > > > windows: > > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.10.0/rc1/apache-mynewt-newt-bin-windows-1.10.0.tgz > > > > > > > > > > > >
Re: [VOTE] Release Apache Mynewt 1.7.0-rc2 and Apache NimBLE 1.2.0-rc2
+1 (binding) pt., 2 sie 2019 o 09:46 Jerzy Kasenberg napisał(a): > +1 (binding) > > pon., 29 lip 2019 o 13:39 Szymon Janc napisał(a): > > > Hello all, > > > > I am pleased to be calling this vote for the source release of > > Apache Mynewt 1.7.0 and Apache NimBLE 1.2.0. > > > > Apache Mynewt is a community-driven, permissively licensed open source > > initiative for constrained, embedded applications. Mynewt provides a > > real-time operating system, flash file system, network stacks, and > > support utilities for real-world embedded systems. > > > > Apache NimBLE is Bluetooth Low Energy 5.0 stack from Apache Mynewt. > > > > This release is coordinated release of Apache Mynewt and NimBLE. Future > > NimBLE releases may be released separately depending on needs. > > > > For full release notes for both Mynewt and NimBLE, please visit the > Apache > > Mynewt Wiki: > > https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes > > > > Apache Mynewt and Apache NimBLE release candidates were tested as > follows: > > 1. Manual execution of the Mynewt test plan: > > https://cwiki.apache.org/confluence/display/MYNEWT/ > > Apache+Mynewt+Test+Plan > > The test results can be found at: > > > https://cwiki.apache.org/confluence/display/MYNEWT/1.7.0+Test+Results > > 2. Manual execution of the NimBLE test plan: > > https://cwiki.apache.org/confluence/display/MYNEWT/ > > Apache+NimBLE+Test+Plan > > The test results can be found at: > > https://cwiki.apache.org/confluence/display/MYNEWT/ > > NimBLE+1.2.0+Test+Results > > > > Note that this testing is not yet complete and more results will > show > > while voting is ongoing. > > > > 2. The full unit test suite for both releases was executed via > > "newt test all" with no failures. This testing was performed on the > > following platforms: > >* OS X 10.14 > >* Fedora Linux 30 > > > > The release candidate to be voted on is available at: > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/ > > https://dist.apache.org/repos/dist/dev/mynewt/apache-nimble-1.2.0/rc2/ > > > > The commits under consideration are as follows: > > blinky: > > repos: https://github.com/apache/mynewt-blinky > > commit 1007e978f2655b3e054099ff8600d147a79b369b > > core: > > repos: https://github.com/apache/mynewt-core > > commit b7a5474d569d5b67152d1773627ddda010c080a3 > > newt: > > repos: https://github.com/apache/mynewt-newt > > commit 80bcba727dfe828dcb1f8da522f0502377d18fd4 > > newtmgr: > > repos: https://github.com/apache/mynewt-newtmgr > > commit a222bac117793db7b8444acfb744dcb822a6f448 > > nimble: > > repos: https://github.com/apache/mynewt-nimble > > commit 5371a45890604d32564c6384eb00dfee74ee7d13 > > > > In addition, the following newt and newtmgr convenience binaries are > > available: > > linux: > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/ > > apache-mynewt-newt-bin-linux-1.7.0.tgz > > < > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/apache-mynewt-newt-bin-linux-1.7.0.tgz > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/ > > apache-mynewt-newtmgr-bin-linux-1.7.0.tgz > > < > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/apache-mynewt-newtmgr-bin-linux-1.7.0.tgz > > > > > > osx: > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/ > > apache-mynewt-newt-bin-osx-1.7.0.tgz > > < > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/apache-mynewt-newt-bin-osx-1.7.0.tgz > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/ > > apache-mynewt-newtmgr-bin-osx-1.7.0.tgz > > < > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/apache-mynewt-newtmgr-bin-osx-1.7.0.tgz > > > > > > windows: > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/ > > apache-mynewt-newt-bin-windows-1.7.0.tgz > > < > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/apache-mynewt-newt-bin-windows-1.7.0.tgz > > > > > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/ > > apache-mynewt-newtmgr-bin-windows-1.7.0.tgz > > < > https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.7.0/rc2/apache-mynewt-newtmgr-bin-windows-1.7.0.tgz > > > > > > The release candidate is signed with a GPG key available at: > > https://dist.apache.org/repos/dist/dev/mynewt/KEYS > > > > The vote is open for at least 72 hours and passes if a majority of at > > least three +1 PMC votes are cast. > > > > [ ] +1 Release this package > > [ ] 0 I don't feel strongly about it, but don't object > > [ ] -1 Do not release this package because... > > > > Anyone can participate in testing and voting, not just committers, > > please feel free to try out the release candidate and provide your > > votes. > > > > A separate [DISCUSS] thread will be opened to talk about this release
Re: [VOTE] Release Apache Mynewt 1.6.0-rc2 and Apache NimBLE 1.1.0-rc2
+1 (binding) śr., 3 kwi 2019 o 12:39 Miguel Azevedo napisał(a): > > +1 binding > > On Wed, 3 Apr 2019, 11:31 Fabio Utzig, wrote: > > > > [ ] +1 Release this package > > > [ ] 0 I don't feel strongly about it, but don't object > > > [ ] -1 Do not release this package because... > > > > +1 (binding) > >
Re: BLE Mesh Vendor Models
Hi Jennifer, Yes, you can implement custom Mesh vendor models for both roles. I'm not aware of any Server role limitations for foundation models. You can find implementation of client roles for foundation models inside `mynewt-nimble/nimble/host/mesh/src/shell.c`. It shouldn't be a problem to use a Mesh Node as a Relay and also connect to some non-mesh device. Mesh usually uses Advertising Bearer to communicate between devices but there is also a GATT Bearer which needs a connection to communicate. But then you need a GATT Proxy Node so that nodes that do not support GATT Bearer can talk to the connected device. Hope that helps. BR Michał Narajowski sob., 9 mar 2019 o 06:35 Jennifer Gibbs napisał(a): > > Hello, > > Is it possible to implement custom BLE Mesh vendor models for both Server and > Client roles? Is the Server Role limitation only for foundation models? > > Is it possible to have a Mesh _Server be an active Relay in the Mesh while > also connecting to a device outside of the Mesh? I’m assuming we’re using the > Advertising Bearer inside the mesh….I could also solve my current problem by > making the external device a low power node in the Mesh as well but currently > have it implemented external to the Mesh as a connectable beacon. > > Thank you, > > Jennifer Gibbs > Laird Connectivity, FAE III > 913-744-6015 > jennifer.gi...@lairdtech.com >
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*) &obj0)
>
> * shell_register(“sample_object1", cmd, (void*) &obj1)
> * 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: [RFC] Mesh uses multi advertising instances.
Hi Aditya,
BLE_ROLE_BROADCASTER should not have an impact on this. There is only one
place in the code where this is used:
include/nimble/nimble_opt_auto.h:37:#define NIMBLE_BLE_ADVERTISE
\
(MYNEWT_VAL(BLE_ROLE_BROADCASTER) || MYNEWT_VAL(BLE_ROLE_PERIPHERAL))
Best regards
Michał Narajowski
pt., 18 maj 2018 o 14:02 Aditya Xavier napisał(a):
> Hi Michał,
>
> A correction.
>
> It seems its out of the two BLE_ROLE* flags, its only BLE_ROLE_BROADCASTER
> that has an adverse effect.
> Enabling BLE_ROLE_BROADCASTER stops the device from receiving messages.
>
> Thanks,
> Aditya Xavier.
>
>
>
>
> > On 18-May-2018, at 3:44 PM, Aditya Xavier wrote:
> >
> > Hi Michał,
> >
> > Yes, that is what you should be seeing, because the message is being
> sent to the GROUP; originator receives it as well.
> > If you change it to the destination / target address, you wouldn’t see
> Received.
> >
> > To test this, you would require two devices.
> >
> > Assuming Device A and B.
> >
> > With all three flags disabled and unique address ( node_address in
> mesh_init.c Line 28).
> > Device A ( button Pressed ) -> Device B should say in the Log Received.
> ( Model callback method - mesh_init.c Line 78 )
> > Device B ( button Pressed ) -> Device A should say in the Log Received.
> >
> > With all three flags enabled and unique node_address.
> > Device A ( button Pressed )-> Device B will not receive any message.
> > Device B ( button Pressed )-> Device A will not receive any message.
> >
> > With only BLE_ROLE* flags disabled on Device B and all three flags
> disabled on Device B, and unique node_address.
> > Device A ( button Pressed )-> Device B should say in the Log Received.
> > Device B ( button Pressed )-> Device A will not receive any message.
> >
> > Thanks,
> > Aditya Xavier.
> >
> >
> >> On 18-May-2018, at 3:23 PM, Michał Narajowski <
> michal.narajow...@codecoup.pl> wrote:
> >>
> >> Hi Aditya,
> >>
> >> I enabled these flags:
> >>
> >> BLE_ROLE_BROADCASTER: 1
> >> BLE_ROLE_PERIPHERAL: 1
> >> BLE_EXT_ADV: 1
> >>
> >> And this is what i see after pushing the button a few times:
> >>
> >> 045120 #mesh-onoff STATUS
> >> 045121 #mesh-onoff STATUS: Sent !
> >> 045123 Received
> >> 045263 #mesh-onoff STATUS
> >> 045264 #mesh-onoff STATUS: Sent !
> >> 045266 Received
> >> 045402 #mesh-onoff STATUS
> >> 045402 #mesh-onoff STATUS: Sent !
> >> 045404 Received
> >> 045535 #mesh-onoff STATUS
> >> 045536 #mesh-onoff STATUS: Sent !
> >> 045538 Received
> >> 046559 #mesh-onoff STATUS
> >> 046559 #mesh-onoff STATUS: Sent !
> >> 046561 Received
> >> 046601 #mesh-onoff STATUS
> >> 046602 #mesh-onoff STATUS: Sent !
> >> 046604 Received
> >> 046627 #mesh-onoff STATUS
> >> 046628 #mesh-onoff STATUS: Sent !
> >> 046630 Received
> >> 046656 #mesh-onoff STATUS
> >> 046656 #mesh-onoff STATUS: Sent !
> >> 046658 Received
> >>
> >>
> >>
> >> Is this what I should see? What are your symptoms?
> >>
> >> Best regards
> >> Michał Narajowski
> >>
> >> pt., 18 maj 2018 o 11:47 Aditya Xavier
> napisał(a):
> >>
> >>> Hi Łukasz,
> >>>
> >>> Disabling only the following flags in syscfg.yml allows the device to
> >>> receive but not send mesh messages.
> >>>
> >>> BLE_ROLE_BROADCASTER: 1
> >>> BLE_ROLE_PERIPHERAL: 1
> >>>
> >>> Disabling BLE_EXT_ADV: 1, flag allows the device to send and receive
> mesh
> >>> messages.
> >>>
> >>> And as I said earlier enabling all three of them, does not allow the
> >>> device to send / receive mesh messages.
> >>>
> >>> It is quite possible its a mistake on my end. Would be grateful if you
> let
> >>> me know what am I doing wrong :)
> >>>
> >>> Thanks,
> >>> Aditya Xavier.
> >>>
> >>>
> >>>> On 18-May-2018, at 2:59 PM, Aditya Xavier
> wrote:
> >>>>
> >>>> Hi Łukasz,
> >>>>
> >>>> Am actually sending it to the Group Address.
> >>>>
> >>>> In main.c :- Line 27
> >>>> void button_cb(struct os_event *ev)
> >>>> {
&
Re: [RFC] Mesh uses multi advertising instances.
Hi Aditya,
I enabled these flags:
BLE_ROLE_BROADCASTER: 1
BLE_ROLE_PERIPHERAL: 1
BLE_EXT_ADV: 1
And this is what i see after pushing the button a few times:
045120 #mesh-onoff STATUS
045121 #mesh-onoff STATUS: Sent !
045123 Received
045263 #mesh-onoff STATUS
045264 #mesh-onoff STATUS: Sent !
045266 Received
045402 #mesh-onoff STATUS
045402 #mesh-onoff STATUS: Sent !
045404 Received
045535 #mesh-onoff STATUS
045536 #mesh-onoff STATUS: Sent !
045538 Received
046559 #mesh-onoff STATUS
046559 #mesh-onoff STATUS: Sent !
046561 Received
046601 #mesh-onoff STATUS
046602 #mesh-onoff STATUS: Sent !
046604 Received
046627 #mesh-onoff STATUS
046628 #mesh-onoff STATUS: Sent !
046630 Received
046656 #mesh-onoff STATUS
046656 #mesh-onoff STATUS: Sent !
046658 Received
Is this what I should see? What are your symptoms?
Best regards
Michał Narajowski
pt., 18 maj 2018 o 11:47 Aditya Xavier napisał(a):
> Hi Łukasz,
>
> Disabling only the following flags in syscfg.yml allows the device to
> receive but not send mesh messages.
>
> BLE_ROLE_BROADCASTER: 1
> BLE_ROLE_PERIPHERAL: 1
>
> Disabling BLE_EXT_ADV: 1, flag allows the device to send and receive mesh
> messages.
>
> And as I said earlier enabling all three of them, does not allow the
> device to send / receive mesh messages.
>
> It is quite possible its a mistake on my end. Would be grateful if you let
> me know what am I doing wrong :)
>
> Thanks,
> Aditya Xavier.
>
>
> > On 18-May-2018, at 2:59 PM, Aditya Xavier wrote:
> >
> > Hi Łukasz,
> >
> > Am actually sending it to the Group Address.
> >
> > In main.c :- Line 27
> > void button_cb(struct os_event *ev)
> > {
> >mesh_msg_send(MODEL_ID_CBOR_ACTION, GROUP_ADDR, "HELLO WORLD", 12);
> >
> > }
> >
> > And its relevant method :-
> >
> > In mesh_init.c :- Line 138.
> > void mesh_msg_send(uint16_t model_id, uint16_t target_address, char
> *tmsg, uint16_t tlen)
> > {
> >struct os_mbuf *msg = NET_BUF_SIMPLE(10 + tlen);
> >struct bt_mesh_msg_ctx ctx = {
> >.net_idx = net_idx,
> >.app_idx = app_idx,
> >// .addr = node_address,
> >// .addr = GROUP_ADDR,
> >.addr = target_address,
> >.send_ttl = BT_MESH_TTL_MAX,
> >};
> >
> >
> >
> > Which I registered here :-
> > In mesh_init.c :- Line 129.
> > * Add model subscription */
> >bt_mesh_cfg_mod_sub_add_vnd(net_idx, node_address, node_address,
> GROUP_ADDR,
> >MOD_LF, CID_VENDOR, NULL);
> >
> > Also, I believe the mesh_msg_send is correctly because it works
> correctly when I switch off the following flags.
> >
> > BLE_ROLE_BROADCASTER: 1
> > BLE_ROLE_PERIPHERAL: 1
> > BLE_EXT_ADV: 1
> >
> > Please do correct me if am wrong.
> >
> > Thanks,
> > Aditya Xavier.
> >
> >> On 18-May-2018, at 2:53 PM, Łukasz Rymanowski <
> lukasz.rymanow...@codecoup.pl> wrote:
> >>
> >> Hi Aditya,
> >>
> >> Sending to destination with same address as source will result in
> sending
> >> msg to source. It will not go into the air.
> >>
> >> Best
> >> Łukasz
> >>
> >> On Thu, 17 May 2018 at 12:21, Aditya Xavier
> wrote:
> >>
> >>> Hi Łukasz,
> >>>
> >>> Sorry for the late reply.
> >>>
> >>> I created a test application for BLE + MESH co-existence, to test the
> >>> functionality and your patch.
> >>>
> >>> The following are my observations.
> >>>
> >>> 1. On enabling any of the following flags, MESH is unable to send
> /
> >>> receive messages don’t work. (Using mesh_model_send)
> >>>
> >>> BLE_ROLE_BROADCASTER: 1
> >>> BLE_ROLE_PERIPHERAL: 1
> >>> BLE_EXT_ADV: 1
> >>>
> >>> 2. Incase using the same Node_Address on two devices, send/
> receive
> >>> messages don't work. ( This might be as per protocol specifications,
> am not
> >>> aware)
> >>>
> >>> You can try the application to verify the same.
> >>> 1. Do remember the node_address value should be unique. You can
> >>> change the same in mesh_init.c
> >>> 2. You can enable BLE / mesh by changing the relevant value in
> >>> headers.h ( ble_enable and mesh_enable )
> >>>
> >>>
> >>> Please let me know your findings and in case
Re: [RFC] Mesh uses multi advertising instances.
Hi Aditya, Mesh is using Adv extensions under the hood if you have Łukasz's patch and enable BLE_EXT_ADV and set BLE_MULTI_ADV_INSTANCES to at least 1. Blemesh_shell has a command "init" which initializes mesh stack and starts advertising Unprovisioned Mesh Beacon. I tested this now and I noticed a bug. Here is a patch for that bug: https://pastebin.com/gbyX8H56 Please apply it on top of Łukasz's branch. Hope that helps. Let us know how it works for you. BR, Michał 2018-04-06 11:09 GMT+02:00 Aditya Xavier : > Hi Michał / Łukasz, > > I have been trying to understand the blemesh_shell, and I fail to understand > how / where it is using the Advertisement extensions. > > Basically, could you point me towards the difference if I need to implement, > in order to use blemesh instead. > > From what I gathered / understood after going through the code is that > blemesh_shell basically allows various functions to be triggered through > shell commands. > > Thanks, > Aditya Xavier. > > >> On 03-Apr-2018, at 3:54 PM, Michał Narajowski >> wrote: >> >> Hi Aditya, >> >> Please set BLE_MESH: 1 and BLE_MESH_SHELL: 1 and you should be able to >> use both btshell and mesh shell. Let us know how that works for you. >> >> Best regards >> Michał >> >> 2018-04-03 7:56 GMT+02:00 Aditya Xavier : >>> Hi Łukasz, >>> >>> Any pointers, as to what needs to be implemented from the blemesh_shell app >>> ? >>> >>> >>> Thanks, >>> Aditya Xavier. >>> >>>> On 02-Apr-2018, at 11:34 PM, Łukasz Rymanowski >>>> wrote: >>>> >>>> Second thought >>>> >>>> Aditya, >>>> Since I did not test it a lot, would it be possible to give us feedback how >>>> it works for you? >>>> >>>> Best >>>> Lukasz >>>> >>>> >>>> >>>> >>>> On Mon, Apr 2, 2018, 20:01 Łukasz Rymanowski >>>> >>>> wrote: >>>> >>>>> Hi Aditya. >>>>> >>>>> On Mon, Apr 2, 2018, 19:14 Aditya Xavier wrote: >>>>> >>>>>> Hi Łukasz, >>>>>> >>>>>> Is there anything special required to get this working along with BLE ? >>>>> >>>>> >>>>>> For e.g. would the btshell app code for ADV_EXT work along with mesh with >>>>>> the provided patches ? >>>>>> >>>>> >>>>> In addition to configuration mentioned in PR commit message, the btshell >>>>> app would have to enable ble mesh and ble mesh shell (check blemesh_shell >>>>> app for that) >>>>> >>>>>> >>>>>> Mesh and BLE seems to compile however, am currently unable to get Mesh >>>>>> working. >>>>>> >>>>>> Also, any reason why this was not accepted yet ? >>>>>> >>>>> >>>>> People are busy with other stuff I guess. I think it will be merged >>>>> eventually. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Aditya Xavier. >>>>>> >>>>> >>>>> Best >>>>> Lukasz >>>>> >>>>> >>>>>> >>>>>>> On 20-Mar-2018, at 12:57 AM, Sterling Hughes < >>>>>> sterling.hughes.pub...@gmail.com> wrote: >>>>>>> >>>>>>> +1 - this is great, thanks Lukasz! >>>>>>> >>>>>>> On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I saw people asking around about possibility to advertise with non-mesh >>>>>>>> data while mesh is running on Mynewt. Well this is possible to do but >>>>>> of >>>>>>>> course it brings a lot of risk for mesh operations and especially for >>>>>>>> friendship scenario. However I went ahead and added support for this in >>>>>>>> Mynewt and I'm interested in how it works for you. >>>>>>>> >>>>>>>> So here is a PR which makes use of multi instances from BT5 Advertising >>>>>>>> extensions and basically allows you to create additional instances >>>>>> which >>>>>>>> contains non-mesh data. >>>>>>>> >>>>>>>> https://github.com/apache/mynewt-nimble/pull/8 >>>>>>>> >>>>>>>> Instructions on how to enable it you can find in the commit message. >>>>>>>> >>>>>>>> Comments are welcome >>>>>>>> >>>>>>>> Best >>>>>>>> Łukasz >>>>>> >>>>>> >>> >
Re: [RFC] Mesh uses multi advertising instances.
Hi Aditya, Please set BLE_MESH: 1 and BLE_MESH_SHELL: 1 and you should be able to use both btshell and mesh shell. Let us know how that works for you. Best regards Michał 2018-04-03 7:56 GMT+02:00 Aditya Xavier : > Hi Łukasz, > > Any pointers, as to what needs to be implemented from the blemesh_shell app ? > > > Thanks, > Aditya Xavier. > >> On 02-Apr-2018, at 11:34 PM, Łukasz Rymanowski >> wrote: >> >> Second thought >> >> Aditya, >> Since I did not test it a lot, would it be possible to give us feedback how >> it works for you? >> >> Best >> Lukasz >> >> >> >> >> On Mon, Apr 2, 2018, 20:01 Łukasz Rymanowski >> wrote: >> >>> Hi Aditya. >>> >>> On Mon, Apr 2, 2018, 19:14 Aditya Xavier wrote: >>> Hi Łukasz, Is there anything special required to get this working along with BLE ? >>> >>> For e.g. would the btshell app code for ADV_EXT work along with mesh with the provided patches ? >>> >>> In addition to configuration mentioned in PR commit message, the btshell >>> app would have to enable ble mesh and ble mesh shell (check blemesh_shell >>> app for that) >>> Mesh and BLE seems to compile however, am currently unable to get Mesh working. Also, any reason why this was not accepted yet ? >>> >>> People are busy with other stuff I guess. I think it will be merged >>> eventually. >>> Thanks, Aditya Xavier. >>> >>> Best >>> Lukasz >>> >>> > On 20-Mar-2018, at 12:57 AM, Sterling Hughes < sterling.hughes.pub...@gmail.com> wrote: > > +1 - this is great, thanks Lukasz! > > On 19 Mar 2018, at 6:36, Łukasz Rymanowski wrote: > >> Hi All, >> >> I saw people asking around about possibility to advertise with non-mesh >> data while mesh is running on Mynewt. Well this is possible to do but of >> course it brings a lot of risk for mesh operations and especially for >> friendship scenario. However I went ahead and added support for this in >> Mynewt and I'm interested in how it works for you. >> >> So here is a PR which makes use of multi instances from BT5 Advertising >> extensions and basically allows you to create additional instances which >> contains non-mesh data. >> >> https://github.com/apache/mynewt-nimble/pull/8 >> >> Instructions on how to enable it you can find in the commit message. >> >> Comments are welcome >> >> Best >> Łukasz >
Re: Ble mesh questions
Hi Li-Chun,
We still didn't get the picture. Please try using some hosting website
like Imgur and send us the link to the picture.
Best regards
Michał Narajowski
2018-03-29 13:20 GMT+02:00 Li-Chun Ko :
> Attached it again here.
>
> Łukasz Rymanowski 於 2018年3月29日 週四 下午6:33 寫道：
>>
>> Hi Lichun
>>
>> On 29 March 2018 at 12:28, Li-Chun Ko wrote:
>> > Hi Łukasz,
>> >
>> > I am using the ADV bearer.
>> >
>> > I don't have the log at hand but you should get all the information from
>> > the picture I attached in my previous email. It was captured by a low
>> > cost
>> > Nordic sniffer.
>>
>> Could you resend picture you mentioned? It looks like it is missing in
>> your first email (at least I did not get it)
>>
>> >
>> > I used bascally the same steps that were mentioned in the BLE mesh
>> > tutroial
>> > except I changed the UUID and I also built the bootloader at the same
>> > time
>> > (I don't know why without compiling the bootloader the serial interface
>> > of
>> > the mesh node doesn't seem to work; I haven't got a chance to take a
>> > further look so now I always compile them together).
>> > Below are the detailed steps. I will share the configuration with you
>> > once
>> > I can reach my computer.
>> >
>> > Cheers,
>> > Lichun
>> > __
>> > newt new my_mesh
>> > cd my_mesh/
>> > newt install -v
>> > newt target create blemesh
>> > newt target set blemesh app=@apache-mynewt-core/apps/blemesh
>> > newt target set blemesh bsp=@apache-mynewt-core/hw/bsp/nrf52dk
>> > newt target set blemesh build_profile=optimized
>> > newt target set blemesh syscfg=BLE_MESH_PB_GATT=1:BLE_
>> > MESH_DEV_UUID='(uint8_t[16]){0x33, 0x19, 0}'
>> > newt target create nrf52_boot
>> > newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
>> > newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
>> > newt target set nrf52_boot build_profile=optimized
>> > newt build nrf52_boot
>> > newt build blemesh
>> > newt create-image blemesh 1.0.0
>> > newt load blemesh
>> >
>> > Łukasz Rymanowski 於 2018年3月29日 週四 下午5:02
>> > 寫道：
>> >
>> >> Hi Lichun,
>> >>
>> >> On 29 March 2018 at 10:42, Li-Chun Ko wrote:
>> >> > Hi all,
>> >> >
>> >> > I am running blemesh with mynewt 1.3.0 on Nordics pca 10040. Here
>> >> > are
>> >> two
>> >> > questions I have:
>> >> >
>> >> > 1. Is it correct that the current mynewt release doesn't support the
>> >> > Provisioner's role? I wasn't able to find a way to do so.
>> >> >
>> >>
>> >> This is correct. Provisioner is not supported in Mynewt. However if
>> >> you want to test mesh wit two Mynewt devices, I suggest to use
>> >> blemesh_shell application which gives you a way to hardcode mesh
>> >> credentians by using "provision" command.
>> >>
>> >> > 2. I tried to use the mesh stack from Noridc to play the
>> >> > Provisioner's
>> >> role
>> >> > but it seems the device cannot decode the unprovisioning beacon
>> >> generated by
>> >> > mynewt's mesh stack correctly. I captured the beacon with wireshark
>> >> > 2.5.1
>> >> > and noticed that the tool cannot parse the beacon correctly either.
>> >> > The
>> >> > AdvData can be recognized as mesh beacon but the content is showed as
>> >> > "unknown data". I am thinking there might be some PDU format issues
>> >> > (I
>> >> > suspect the length field of the mesh beacon which is 24 bytes is
>> >> incorrect)
>> >> > but I am not sure. I have attached a photo as the reference and
>> >> > hopefully
>> >> > someone can help check.
>> >> >
>> >>
>> >> That is interesting. I did not test against Nordic stack but was
>> >> testing against PTS tool and some other implementation and have not
>> >> seen such issue.
>> >> Could you share your target configuration ("newt target show > >> name>") and wireshark logs?
>> >>
>> >> BTW What bearer uses Nordic stack?
>> >>
>> >> > Br,
>> >> > Lichun
>> >>
>> >> Thanks
>> >> Łukasz
>> >>
>>
>>
>> Best
>> Łukasz
[RFC] hw/bsp: Clean up NRFX config on nrf52840 #936
Hi all, I created a PR that cleans up the NRFX configuration. https://github.com/apache/mynewt-core/pull/936 There are several reasons why we should fix this: - it makes the whole configuration cleaner and easier to port, removes redundancy (see PWM configuration) - we are using nrfx_config which was designed for this purpose - this approach results in shorter compilation commands If everyone is okay with this I will fix other bsps too. Comments are welcome. Best regards, Michał Narajowski
Re: BLEMESH PB GATT
Hi Aditya,
Please use BLE_MESH_PB_GATT: 0 and BLE_MESH_GATT_PROXY: 0. But "0"
should work too. What other settings do you have? You can use "newt
target show " to show target settings.
Best regards,
Michał Narajowski
2018-02-23 13:17 GMT+01:00 Aditya Xavier :
> Thanks for quick reply !
>
> With BLE_MESH_PB_GATT: FALSE and BLE_MESH_GATT_PROXY: FALSE, build fails for
> the app.
>
> Error: repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c: In function
> 'proxy_send':
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:852:21: error:
> unused variable 'om' [-Werror=unused-variable]
> struct os_mbuf *om;
> ^~
> At top level:
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:126:3: error:
> 'gatt_svc' defined but not used [-Werror=unused-variable]
> } gatt_svc = MESH_GATT_NONE;
>^~~~
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:95:41: error:
> 'proxy_adv_param' defined but not used [-Werror=unused-variable]
> static const struct ble_gap_adv_params *proxy_adv_param = &fast_adv_param;
> ^~~
> repos/apache-mynewt-core/net/nimble/host/mesh/src/proxy.c:83:40: error:
> 'slow_adv_param' defined but not used [-Werror=unused-const-variable=]
> static const struct ble_gap_adv_params slow_adv_param = {
> ^~
> cc1: all warnings being treated as errors
>
> With BLE_MESH_PB_GATT: “0” and BLE_MESH_GATT_PROXY: “0”, build is successful.
> However, device restarts.
>
> 00 Unhandled interrupt (2), exception sp 0x20001280
> 00 r0:0x r1:0x r2:0x8000 r3:0xe000ed00
> 00 r4:0x00019a3f r5:0x r6:0x r7:0x
> 00 r8:0x r9:0x r10:0x r11:0x
> 00 r12:0x lr:0x8add pc:0x8aec psr:0x6100
> 00 ICSR:0x00421802 HFSR:0x CFSR:0x
> 00 BFAR:0xe000ed38 MMFAR:0xe000ed34
> 00 Assert @ 0x19a3f
>
>
>
>> On 23-Feb-2018, at 5:26 PM, Andrzej Kaczmarek
>> wrote:
>>
>> Hi Aditya,
>>
>> On Fri, Feb 23, 2018 at 12:50 PM, Aditya Xavier wrote:
>>> Hi Mynewt Team,
>>>
>>>
>>>I have been going through and testing the BLEMESH sample app.
>>>
>>>Turning on only one device, which does not have BLE_MESH_GATT_PROXY
>>> & BLE_MESH_PB_GATT flag, still allows the Silicon Labs application to scan
>>> and connect to it.
>>>
>>>Correct me if am wrong, but I thought only those devices with
>>> BLE_MESH_PB_GATT should be scannable / connectable by the Silicon Labs app.
>>>
>>>Am I missing something ?
>>>
>>>For reference am using the master branch.
>>
>> Did you disable GATT PB and proxy flags in your target settings? If
>> not then these are enabled by default in Mesh package so blemesh will
>> work with app from Silicon Labs.
>>
>>> Thanks and Regards,
>>> Aditya Xavier
>>
>> Best regards,
>> Andrzej
>
Merging Friend support PR into master
Hi all, This is a heads up to the community that I've been porting Mesh Friend support from Zephyr recently and want to merge this into master soon. Here is the PR: https://github.com/apache/mynewt-core/pull/693 I know this is a huge PR and this is not ideal, but Friend support along with precertification fixes just requires that amount of work and there was no point in trying to split this up. This PR only touches mesh code and passed the regression tests. So this PR features: - Friend support - Configuration Client support - GATT Proxy fixes - Low Power node fixes - various other fixes Comments are welcome. BR Michał Narajowski
Re: [VOTE] Release Apache Mynewt 1.2.0-rc1
+1 (binding) 2017-09-11 9:51 GMT+02:00 Łukasz Rymanowski : > +1 (binding) > > Łukasz > > On 10 September 2017 at 20:49, aditi hilbert wrote: >> +1 >> >> thanks, >> aditi >> >>> On Sep 8, 2017, at 11:54 AM, Szymon Janc wrote: >>> >>> Hello all, >>> >>> I am pleased to be calling this vote for the source release of >>> Apache Mynewt 1.2.0. >>> >>> Apache Mynewt is a community-driven, permissively licensed open source >>> initiative for constrained, embedded applications. Mynewt provides a >>> real-time operating system, flash file system, network stacks, and >>> support utilities for real-world embedded systems. >>> >>> For full release notes, please visit the Apache Mynewt Wiki: >>> https://cwiki.apache.org/confluence/display/MYNEWT/Release+Notes >>> >>> This release candidate was tested as follows: >>> 1. Manual execution of the Mynewt test plan: >>> >>> https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Test+Plan >>> The test results can be found at: >>> https://cwiki.apache.org/confluence/display/MYNEWT/1.2.0+Test+Results >>> 2. The full unit test suite for this release was executed via "newt >>> test all" with no failures. This testing was performed on the >>> following platforms: >>> * OS X 10.11.5 >>> * Ubuntu Linux 17.04 >>> >>> The release candidate to be voted on is available at: >>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/ >>> >>> The commits under consideration are as follows: >>> blinky: >>> repos: https://github.com/apache/mynewt-blinky >>> commit 5ade7990e81ebfb6b9801fd56b7ea32774747ced >>> core: >>> repos: https://github.com/apache/mynewt-core >>> commit e511aa733ee0d5740484738036618332ed45475b >>> newt: >>> repos: https://github.com/apache/mynewt-newt >>> commit 3a3e87d754e63cbcf2e49b49c20847dc3c19e655 >>> newtmgr: >>> repos: https://github.com/apache/mynewt-newtmgr >>> commit 8bc55635bbac12c036b25b4968ee0f48c1f06e52 >>> >>> In addition, the following newt convenience binaries are available: >>> linux: >>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-linux-1.2.0.tgz >>> osx: >>> https://dist.apache.org/repos/dist/dev/mynewt/apache-mynewt-1.2.0/rc1/apache-mynewt-bin-osx-1.2.0.tgz >>> >>> The release candidate is signed with a GPG key available at: >>> https://dist.apache.org/repos/dist/dev/mynewt/KEYS >>> >>> The vote is open for at least 72 hours and passes if a majority of at >>> least three +1 PMC votes are cast. >>> >>> [ ] +1 Release this package >>> [ ] 0 I don't feel strongly about it, but don't object >>> [ ] -1 Do not release this package because... >>> >>> Anyone can participate in testing and voting, not just committers, >>> please feel free to try out the release candidate and provide your >>> votes. >>> >>> A separate [DISCUSS] thread will be opened to talk about this release >>> candidate. >>> >>> Thanks, >>> Szymon Janc >>> >>
Generating CMake files from Newt
Hi, I recently saw a JIRA ticket MYNEWT-120 about support for generating IDE project files and decided to try to integrate CMake files generation into newt. CMake can generate makefiles, Eclipse project files, Sublime Text project files and more. And it is supported by CLion IDE and recently by Visual Studio. An additional motivation was that Eclipse (which I currently use) is very slow when using build output parser. I submitted a WIP code for this functionality (https://github.com/apache/mynewt-newt/pull/88). It allows you to generate a CMakeLists.txt file for a specified target with a command: "newt target cmake ". Suggestions regarding command naming and code placement are welcome. Right now only compilation is supported and it's not yet 100% the same as in "newt build" but it's close. I tried to use CLion with this functionality and it works pretty well. I can compile, jump to definitions, find usages, jump to includes etc. Also, the appropriate syscfg.h is included. I can change the target by running the "newt tagret cmake" and then hitting "Reload CMake" in CLion. I also tried using it with Eclipse. Generated Eclipse project works ok, you can compile, jump to definitions and all that. Only the target change part is trickier. I had to close, reopen project (not Eclipse, just the project) and reindex files to be able to jump to appropriate syscfg.h. Let me know what you think about it and where can we go next. BR Michał Narajowski
gdb plugin for Mynewt to view task information
Hi, I've been working on a plugin for gdb that would allow the debugger to access information about each individual task running on the system. This can be useful in many scenarios e.g. when debugging deadlocks. Screenshot from Eclipse: http://imgur.com/Xm0tv4i I created it as a separate project, as it was easier to develop that way. You can find the source code on my Github page: https://github.com/michal-narajowski/mynewt-gdb-plugin/. It was a lot of fun figuring out how the registers are recorded on the stack, and I wouldn't be able to do this without extra help from Andrzej Kaczmarek. Kudos to you! For now, only Cortex M4 is supported. To use the plugin: - Build the library (project includes makefiles and Visual Studio project, although I tested only the Linux makefile) then: - Run "newt debug --extrajtagcmd "-rtos path/to/plugin.so" " - Allow the system to run for a moment, then suspend it in gdb - Run "info thread" or - Run "newt -n debug --extrajtagcmd "-rtos path/to/plugin.so" " - Start debugger under Eclipse (info on how to set it up with Mynewt can be found here: https://www.codecoup.pl/blog/hacking-mynewt-in-eclipse/) - Suspend the system and view the information about tasks I'm looking for answers to some questions: * Where to put the code? * Should we integrate it into Mynewt? * How to integrate it? Best regards Michał Narajowski
Re: [VOTE] Release Apache Mynewt 1.1.0-rc2
+1 (binding) 2017-07-30 23:33 GMT+02:00 will sanfilippo : > >> On Jul 27, 2017, at 3:47 PM, Szymon Janc wrote: >> >> [ ] +1 Release this package >> [ ] 0 I don't feel strongly about it, but don't object >> [ ] -1 Do not release this package because… >> > > +1 binding > >
[RFC] MYNEWT-430: Segger's SystemView working with Mynewt (PR #344)
Hi, this PR adds support for SystemView. It introduces tracing API as an abstraction layer. To test this: 1. Download Segger's SystemView app from their website 2. Copy the description file from sys/sysview/SYSVIEW_Mynewt.txt to the /description/ directory of SystemView, e.g. "/opt/SEGGER/SystemView/Description/" 3. Build target with OS_SYSVIEW: 1 4. Launch app and start recording events Comments are welcome BR, Michał
