Re: Explicitly disabling a feature

[Christopher Collins]

Oops... I didn't mean to reply-all.  Sorry for the spam...

Chris

On Tue, Aug 02, 2016 at 08:16:08PM -0700, Christopher Collins wrote:
> Hi Sterling,
> 
> Just a heads up - this commit breaks the "newt test" command.  The
> problem is that there is no app when a package is being tested.  The fix
> is really simple:
> 
> diff --git a/newt/builder/build.go b/newt/builder/build.go
> index 3d54f0e..383bb95 100644
> --- a/newt/builder/build.go
> +++ b/newt/builder/build.go
> @@ -373,16 +373,16 @@ func (b *Builder) PrepBuild() error {
> if appPkg != nil {
> appBpkg = b.Packages[appPkg]
> if appBpkg == nil {
> appBpkg = b.AddPackage(appPkg)
> }
> b.appPkg = appBpkg
> -   }
> 
> -   b.featureBlackList = append(b.featureBlackList,
> appBpkg.FeatureBlackList())
> -   b.featureWhiteList = append(b.featureWhiteList,
> appBpkg.FeatureWhiteList())
> +   b.featureBlackList = append(b.featureBlackList,
> appBpkg.FeatureBlackList())
> +   b.featureWhiteList = append(b.featureWhiteList,
> appBpkg.FeatureWhiteList())
> +   }
> 
> I didn't want to commit the fix since you might still be working on
> this.
> 
> I like the feature, though :).
> 
> Chris
> 
> 
> On Tue, Aug 02, 2016 at 03:21:39PM -0700, Sterling Hughes wrote:
> > OK - added:
> > 
> > pkg.feature_blacklist:
> >  ".*": SHELL
> > 
> > pkg.feature_whitelist:
> >  ".*newtmgr.*": SHELL
> > 
> > these two can be enabled in any of the top-level packages (app, bsp and 
> > target.)  where the key is the package name, and the value is the 
> > feature name.  if something is in the blacklist, it is ignored, unless 
> > it is also in the whitelist.
> > 
> > i’ve also added defines by default for every feature that is enabled.  
> > so if the SHELL feature is enabled, then FEATURE_SHELL is added to the 
> > compiler line.
> > 
> > in the case above, the SHELL feature would be hidden from every package, 
> > except for the newtmgr package, which would have the SHELL feature 
> > enabled, and the FEATURE_SHELL define provided.
> > 
> > this is available in the “develop” branch of newt.
> > 
> > 
> > On 2 Aug 2016, at 11:26, Sterling Hughes wrote:
> > 
> > > OK, I’m going to start this.
> > >
> > > One more thing I’ll be adding.
> > >
> > > It’s a common case for features to be used to create defines by 
> > > setting cflags.
> > >
> > > so, you define a feature “ADC_NRF52” and then you have a directive 
> > > like:
> > >
> > > pkg.cflags.ADC_NRF52: -DADC_NRF52
> > >
> > > I’m going to look at all created features, and automatically create 
> > > a set of defines for them, i.e.: ADC_NRF52 automatically creates the 
> > > -DFEATURE_ADC_NRF52 define at the compiler line.
> > >
> > > Sterling
> > >
> > > On 2 Aug 2016, at 2:36, Wayne Keenan wrote:
> > >
> > >> On 2 August 2016 at 01:48, Sterling Hughes <sterl...@apache.org> 
> > >> wrote:
> > >>
> > >>>
> > >>>>
> > >>>> I had lots more here about managing feature dependencies in 
> > >>>> general, but
> > >>>> ended up snipping it because it is a complex beast and I would need 
> > >>>> to
> > >>>> give
> > >>>> it more thought. In the meantime, I think the most important 
> > >>>> property for
> > >>>> maintainability is to blacklist globally and whitelist per package;
> > >>>> blacklisting individual packages doesn't scale with the number of
> > >>>> dependencies.
> > >>>>
> > >>>>
> > >>> Makes sense to me.  I think it will be easier/more understandable to 
> > >>> add a
> > >>> suppress features configuration variable than a “-“ before it.   
> > >>> I’ll add a
> > >>> blacklist, with the ability to globally blacklist a feature, and a
> > >>> whitelist.  The whitelist will take precedence over the blacklist.
> > >>>
> > >>>
> > >> I like this idea, and I'd like the Mynewt stats to be a feature that 
> > >> can be
> > >> black listed.
> > >> I ended up #ifdef'ing out all the stats to conserve RAM on the 
> > >> micro:bit
> > >> platform.
> > >>
> > >>
> > >>> It seems to me that these should only be specified at at the target 
> > >>> or
> > >>> application level, as digging through packages here seems insane in 
> > >>> terms
> > >>> of figuring out what’s going on, so I’ll restrict that — 
> > >>> unless people
> > >>> disagree?
> > >>>
> > >>>
> > >> I think supporting blacklisting or whitelisting at the BSP level 
> > >> would be
> > >> useful, for example, a 'blacklist all stats' setting in any kind of
> > >> micro:bit BSP is pretty much mandatory with the 16kb RAM limit and a
> > >> micropython interpreter running user scripts :)
> > >>
> > >>
> > >>
> > >>> Sterling
> > >>>

Re: bug+patch: Read By Group Type Response

[Christopher Collins]

On Mon, Jul 25, 2016 at 02:17:40PM -0700, Christopher Collins wrote:
> On Mon, Jul 25, 2016 at 12:09:13PM -0700, Mike Ryan wrote:
> > I discovered and patched a bug in the Read Group Type Response message
> > when using small MTUs. The details are recorded in the following pull
> > request:
> > 
> > https://github.com/apache/incubator-mynewt-core/pull/79
> > 
> > This issue appears to affect both master and develop.
> 
> Hi Mike,
> 
> Thanks for the pull request!  I am not able to reproduce this issue, so
> I must be doing something wrong.  I will add some more details to the
> pull request shortly.

Actually, I think I see what is happening.  This bug was fixed shortly
after 0.9.0 was released.  The fix has since been merged to master
(43143c9027aef473c22b2b6a6accaa4cfe1237c5, Jun 1).  Is
it possible that you are working with an older version of the code?  By
the way, I do realize it is difficult to keep up to date when the code
has changed so much recently!

Please let me know if you think there is still an issue here.  And
please keep finding bugs :).

Chris

Re: bug+patch: Read By Group Type Response

[Christopher Collins]

On Mon, Jul 25, 2016 at 12:09:13PM -0700, Mike Ryan wrote:
> I discovered and patched a bug in the Read Group Type Response message
> when using small MTUs. The details are recorded in the following pull
> request:
> 
> https://github.com/apache/incubator-mynewt-core/pull/79
> 
> This issue appears to affect both master and develop.

Hi Mike,

Thanks for the pull request!  I am not able to reproduce this issue, so
I must be doing something wrong.  I will add some more details to the
pull request shortly.

Chris

Re: BLE_HS_ENOMEM when trying to connect to a second peripheral

[Christopher Collins]

On Sat, Jul 23, 2016 at 09:32:59PM +, Marco Ferreira wrote:
> Here's the complete config in my code:
> 
>   
> 
> /* Configure the host. */  
>cfg = ble_hs_cfg_dflt;  
>cfg.max_hci_bufs = 16;  
>// cfg.max_connections = MAX_CONNECTIONS*3;  
>// cfg.max_gattc_procs = 5;  
>cfg.max_l2cap_chans = cfg.max_connections * 3;  
>// cfg.max_l2cap_sig_procs = 1;  
>// cfg.sm_bonding = 1;  
>// cfg.sm_our_key_dist = BLE_SM_PAIR_KEY_DIST_ENC;  
>// cfg.sm_their_key_dist = BLE_SM_PAIR_KEY_DIST_ENC;  
>// cfg.store_read_cb = ble_store_ram_read;  
>// cfg.store_write_cb = ble_store_ram_write;  
>   
>/* Populate config with the required GATT server settings. */  
>// cfg.max_attrs = 0;  
>// cfg.max_services = 0;  
>// cfg.max_client_configs = 0;  

Hmm, those settings look fine to me. Are you sure
-DNIMBLE_OPT_MAX_CONNECTIONS is set to 2? Are you setting it as a target
variable in the target's pkg.yml file?

Also, just to confirm, is is ble_gap_connect() that is returning
BLE_HS_ENOMEM?

Thanks, Chris

Re: NimBLE host - flat bufs vs. mbufs

[Christopher Collins]

Hello all,

I have gone ahead and updated the host API on develop to use mbufs
rather than flat bufs.  This was a fairly big update, so you might want
to hold off on pulling from develop until it is a good time to deal with
API changes.  I think the new API is an improvement over the old one,
but I would like to hear what others think.

The API documentation on the web site is now quite out of date.  I have
opened a pull request to bring it in line with the new API.

Thanks,
Chris

[jira] [Created] (MYNEWT-353) BLE Host - Timeout for ATT queued writes

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-353:
--

 Summary: BLE Host - Timeout for ATT queued writes
 Key: MYNEWT-353
 URL: https://issues.apache.org/jira/browse/MYNEWT-353
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


A peer performs a large attribute write by sending a series of ATT prepare 
write requests followed by an ATT execute write request.  If the execute write 
request never arrives, the queued prepare write requests remain resident on the 
receiving device.  The queued write should be cleared N seconds after the last 
received prepare write request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: NimBLE host - flat bufs vs. mbufs

[Christopher Collins]

On Tue, Jul 19, 2016 at 03:56:46PM +0200, Kevin Townsend wrote:
> I'm curious what you would have done for a simple FIFO where you are 
> likely storing 1 or 2 bytes at a time?  If there isn't a good match, 
> perhaps it's worth adding a very light weight FIFO or circular buffer 
> that can deal with very small records efficiently, but I might be 
> missing something that already exists?

Hi Kevin,

You are right - mbufs aren't a very good fit for lots of one- or
two-byte records.  There is a circular buffer implementation buried in
the libs/util package that you might find useful.  The relevant files
are:
* libs/util/include/util/cbmem.h
* libs/util/src/cbmem.c

A cbmem is initialized with a single flat buffer and can hold variable
sized records.

Chris

Re: NimBLE host - flat bufs vs. mbufs

[Christopher Collins]

On Tue, Jul 19, 2016 at 06:38:02AM -0700, will sanfilippo wrote:
> I am +1 for mbufs. While they do take a bit of getting used to, I
> think converting the host to use them is the way to go, especially if
> they replace a large flat buffer pool.
> 
> I also think we should mention that mbufs use a fair amount of
> overhead. I dont think that applies here as the flat buffer required
> for an ATT buffer is quite large (if I recall). But if folks want to
> use mbufs for other things they should be aware of this.

Good point.  Mbufs impose the following amount of overhead:

* First buffer in chain: 24 bytes (os_mbuf + os_mbuf_pkthdr)
* Subsequent buffers:16 bytes (os_mbuf)

Also, I didn't really explain it, but there is only one flat buffer in
the host that is being allocated: the ATT rx buffer.  This single buffer
is used for receives of all ATT commands and optionally for application
callbacks to populate with read responses.  The host gets by with a
single buffer because all receives are funneled into one task.  This
buffer is sized according to the largest ATT message the stack is built
to receive, with a spec-imposed cap of 515 bytes [*].  So, switching to
mbufs would probably save some memory here, but the savings wouldn't be
dramatic.

[*] This isn't totally true, as the ATT MTU can be as high as 65535.
However, the maximum size of an attribute is 512 bytes, which limits the
size of the largets message any ATT bearer would send.  The one
exception is the ATT Read Multiple Response, which can contain several
attributes.  However, this command is seldom used, and is not practical
with large attributes.  So, the current NimBLE code does impose an
artificial MTU cap of 515 bytes, but in practice I don't think it would
ever be noticed.

Chris

Re: Mynewt Demo - Bluetooth LE services written in MicroPython + Browser/WebBluetooth UI

[Christopher Collins]

On Mon, Jul 18, 2016 at 10:22:54PM +0100, Wayne Keenan wrote:
> Hi,
> 
> I've ported MicroPython and some handy Python libraries to Apache Mynewt;
>  there's a bit more to it but collectively this development effort is
> called BubblePy.
> 
> The most recent BubblePy Bluetooth LE GATT example I'd like to share with
> you demos the control of a Pimoroni Blinkt connected to an Arduino Primo,
> via BluetoothLE.
> The UI is browser based and communicates with the BLE device using Web
> Bluetooth.
> 
> You can view the source of the Blinkt demo, here:
> https://github.com/TheBubbleworks/BubblePy_Demo_Blinkt_BLE
> 
> There are links to further BubblePy info & examples in the README of that
> repo.
> 
> Of note, there are examples of custom BluetoothLE Physical Web beacons and
> GATT services that run on the BBC micro:bit (a 16kB RAM nRF51)

Very cool!

Chris

Re: Handling Notify/Indicate and CCCD Changes

[Christopher Collins]

Hello all,

I have just committed some NimBLE host API changes to the develop
branch.  These changes have been made as a result of issues raised in
this email thread.

Summary of changes:

1. Two new GAP event types:
* notify_tx: we sent out a notification or indication, or an
 indication transaction has completed (successfully or
 not).

* subscribe: peer has changed its subscription state for
 notifications or indications.

2. Old GAP event "notify" renamed to notify_rx.

3. Connection descriptor no longer included in GAP event struct.
   Instead, just the connection handle is indicated.  The application
   can perform a connection lookup if necessary (ble_gap_conn_find()).
   The exception is the "disconnect" event; this event still contains
   the connection descriptor, since a lookup cannot be performed on a
   connection that is no longer established..

First, a note about the third change- it is not related to this email
thread, but I snuck it in there anyway.  Prior to this change, most GAP
events contained a connection descriptor (struct ble_gap_conn_desc)
which contains a bunch information about the relevant connection.
Having the stack do a connection lookup for every GAP event could
potentially be a performance issue if there are lots of connections and
lots of GAP events.  It is easy enough for the application to perform
the lookup in the GAP callback, and the application may not need this
information each time an event occurs, so I think the new interface just
makes more sense.  The example BLE apps (bleprph, blecent, bletiny) have
been updated to use the new interface, so you might want to take a look
at their GAP event callbacks as a reference.

The first two changes came about as a result of this email thread.
Earlier, I mentioned that received indication-acks and changes in
subscription status might be signalled via calls to the appropriate GATT
access callback.  However, after some thought, I determined that it
is better to use the GAP callback for these occurrences.  My reasoning
is that I foresee there being many "GATT server" libraries which
implement one or more services (there is already one of these:
net/nimble/host/services/mandatory).  If indication and subscription
events were handled by the GATT callback, each of these libraries would
need to provide some sort of hook for the application to learn about
these events.  With the events being handled by the GAP callback
instead, these libraries can be self-contained and only focus on
implementing attribute reads and writes.

The details of these changes are below.  I have not updated the online
documentation yet, but I plan on doing that shortly.  Finally, I just
want to remind everyone that this is a community-driven project, so if
you see anything that could be improved, please don't hesitate to voice
your thoughts or submit a pull request.

Thanks,
Chris

#define BLE_GAP_EVENT_NOTIFY_RX 12
#define BLE_GAP_EVENT_NOTIFY_TX 13
#define BLE_GAP_EVENT_SUBSCRIBE 14

struct ble_gap_event {
/* [...] */
/**
 * Represents a received ATT notification or indication.
 *
 * Valid for the following event types:
 * o BLE_GAP_EVENT_NOTIFY_RX
 */
struct {
/** The contents of the notification or indication. */
void *attr_data;

/** The handle of the relevant ATT attribute. */
uint16_t attr_handle;

/** The number of data bytes contained in the message. */
uint16_t attr_len;

/** The handle of the relevant connection. */
uint16_t conn_handle;

/**
 * Whether the received command is a notification or an
 * indication;
 * o 0: Notification;
 * o 1: Indication.
 */
uint8_t indication:1;
} notify_rx;

/**
 * Represents a transmitted ATT notification or indication, or a
 * completed indication transaction.
 *
 * Valid for the following event types:
 * o BLE_GAP_EVENT_NOTIFY_TX
 */
struct {
/**
 * The status of the notification or indication transaction;
 * o 0: Command successfully sent;
 * o BLE_HS_EDONE:  Confirmation (indication ack) received;
 * o BLE_HS_ETIMEOUT:   Confirmation (indication ack) never
 *  received;
 * o Other return code: Error.
 */
int status;

/** The handle of the relevant connection. */
uint16_t conn_handle;

/** The handle of the relevant characterstic value. */
uint16_t attr_handle;

/**
 * Whether the transmitted command is a notification or an
 * indication;

Re: Scan Response and Timing

[Christopher Collins]

Hi Kevin,

On Sun, Jul 17, 2016 at 03:32:18PM +0200, Kevin Townsend wrote:
> Are there any examples of how to setup a Scan Response while 
> advertising? Apple, for example, recommends putting the Local Name and 
> TX Power in the scan response to free up space.  See section 3.4 of 
> https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

None of the example apps configure the scan response data (we should
change this).  It is relatively simple to configure response data: call
ble_gap_adv_rsp_set_fields()
(http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields/).
This function is more or less identical to ble_gap_adv_set_fields(),
except it configures response data rather than advertising data.

> PS: One other note with reference to the design guidelines from Apple: 
> many Apple devices are very specific about the timing requirements 
> (Section 3.5, 3.6, etc.) and devices that don't respect the limits may 
> not appear even if they are within the core specification limits. It 
> might be worth adding a section to the documentation on controlling the 
> key timing values (advertising interval, connection interval, etc.). 
> We're just looking into some of the details now that we have a basic app 
> running with DIS and Nordic UART, and I'm happy to contribute some 
> documentation in markdown as we track these details down, but it might 
> be worth considering having something easy to use in the core API to 
> control the various timing values in one central location.

Is there a particular API change that you are thinking of?  You're right
about there being are a lot of timing settings, and anything that makes
the API simpler would be an improvement.

Just for reference for other readers, here is what the advertise API
looks like today (comments removed for brevity; see referenced URL for
details):

http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start/

int
ble_gap_adv_start(
uint8_t  own_addr_type,
uint8_t  peer_addr_type,
  const uint8_t *peer_addr,
int32_t  duration_ms,
const struct ble_gap_adv_params *adv_params,
   ble_gap_event_fn *cb,
   void *cb_arg
)

http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gap/definitions/ble_gap_defs/

struct ble_gap_adv_params {
/*** Mandatory fields. */
uint8_t conn_mode;
uint8_t disc_mode;

/*** Optional fields; assign 0 to make the stack calculate them. */
uint16_t itvl_min;
uint16_t itvl_max;
uint8_t channel_map;
uint8_t filter_policy;
uint8_t high_duty_cycle:1;
};

Thanks,
Chris

Re: Handling Notify/Indicate and CCCD Changes

[Christopher Collins]

On Sat, Jul 16, 2016 at 12:10:14AM +0200, Kevin Townsend wrote:
> I don't think the disconnect is a massive issue at this point and worth 
> a lot of effort. There are higher priorities as you said, which gets a 
> +1 from me anyway, and it isn't entirely unreasonable based on the spec 
> (thanks for the reference!).
> 
> I think the following are probably worth the effort, though:
> 
> 1. Getting CCCD update events into a callback (important for power 
> management)
> 2. Alerting users of an indicate failure
> 
> A disconnect might seem valid for #2, but I would argue that this then 
> removes all of the value of indicate even existing!
> 
> Even if a failure does cause an eventual disconnect (up to 30s later!), 
> we still have no way to know if the cause of that failure was the lack 
> of an indicate response, or ... something else (power failure on the 
> Central, etc.).  Indicate significantly slows data throughput down in 
> BLE, but is the only means to have genuinely reliable transactions where 
> we can recover later, which is important transferring binary files or 
> other similar information. We should always know if an indicate write 
> passed or failed in my opinion, and tracking disconnect might be a good 
> indicator but isn't 100% reliable.
> 
> I'd of course be curious to hear other people's opinions on this!

I completely agree - these are essential features.  I'm looking at
adding both of those right now.

Thanks,
Chris

Re: Handling Notify/Indicate and CCCD Changes

[Christopher Collins]

Hi Kevin,

On Fri, Jul 15, 2016 at 04:50:14PM +0200, Kevin Townsend wrote:
> My apologies if I'm missing something in the documentation, but putting 
> an example together here we are almost done with a barebones app 
> implementing Nordic's UART service to reuse the apps we've published for 
> iOS, Android, OS X, Python, etc., which use Nordic UART as an easy 
> lowest common denominator.
>
> We had a couple questions though:

These are both very good questions.  Even if the functionality were
supported, it could just be documented poorly, so asking on the list is
always helpful for Mynewt!

> 1. How would we subscribe to CCCD changes on the peripheral side?

You're right - this is completely missing!  This was in a list of
changes that were needed for the host API, but somehow it slipped
through the cracks.  I will take a look at this today, but I imagine
this would be naturally implemented via a GATT access callback.

> The use case here is to know when the Central enables or disables the 
> notify/indicate bits (or really any changes) in the CCCD since we 
> probably want to keep sensor(s) powered off until they are actually 
> needed, i.e. when the Central starts subscribing to data from them. This 
> is an important power consideration in my opinion and the CCCD changes 
> to be easy to capture. Is this handled internally (which I would propose 
> reconsidering if true), or can the CCCD updates be easily captured?

It is handled entirely internally at the moment, but I agree that the
application needs to know when a peer changes a CCCD value.

> 2. How is a failed 'indicate' message handled?
> 
> Indicate generates an ACK, but are there any examples or documentation 
> around how to properly check for the response message to know if the 
> message arrived?

This is currently hidden from the application.  If any GATT procedure
times out, the host terminates the connection.  So, if the connection
stays up, that implies the indicate acknowledgement has been received.

The above explanation is a bit too weasely for my liking :).  I think it
would be good for the host to explicitly notify the application when an
indicate response is received.  Again, I think the right place for this
to happen is in a GATT access callback.

> Again, sorry if this is clearly documented or obvious in an example, but 
> I didn't spot anything looking around. I can read a characteristic 
> descriptor, but I think we we really need is a callback rather than 
> having to poll ... which may already be possible, though???

Not directly related to your question, but I don't think polling would
work because each peer gets its own copy of the CCCD set.  The host will
report a read error if you attempt a local read of a CCCD.

Thanks for asking about this; it is very helpful.  I will try to
implement both of these missing features today, and I'll send a message
to the dev list indicating the API changes.  In the meantime, if you (or
anyone) have any thoughts on how the API should look, please feel free
to chime in!

Chris

[jira] [Created] (MYNEWT-351) BLE Host - Delete completed GATT procedure before calling callback

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-351:
--

 Summary: BLE Host - Delete completed GATT procedure before calling 
callback
 Key: MYNEWT-351
 URL: https://issues.apache.org/jira/browse/MYNEWT-351
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


When a GATT procedure completes, its callback gets executed.  The procedure 
doesn't get deleted until after the callback. This is problematic if the 
application wants to initiate another procedure from within the callback and 
the GATT proc pool is empty.  We should copy the data necessary for the 
callback and delete the procedure, then call the callback.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-343) nffs crash at bootloader

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-343:
---
Attachment: nffs-inode-invalid-id.bin

Here is a bootloader crash using the latest NFFS from develop.  This was 
triggered by repeatedly upgrading the image on an Arduino Zero.  See attachment 
for a dump of the NFFS flash region (nffs-inode-invalid-id.bin).

{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=,
func=, e=) at os_fault.c:124
124asm("bkpt");
(gdb) whe
#0  __assert_func (file=, line=,
func=, e=) at os_fault.c:124
#1  0x21b0 in nffs_restore_inode (area_offset=,
area_idx=, disk_inode=) at nffs_restore.c:572
#2  nffs_restore_object (disk_object=0x200072c8) at nffs_restore.c:949
#3  nffs_restore_area_contents (area_idx=area_idx@entry=2)
at nffs_restore.c:1057
#4  0x2854 in nffs_restore_full (area_descs=area_descs@entry=0x2000736c)
at nffs_restore.c:1359
#5  0x04c6 in nffs_detect (area_descs=area_descs@entry=0x2000736c)
at nffs.c:606
#6  0x01e6 in setup_for_nffs () at boot.c:93
#7  main () at boot.c:173
(gdb) fr 1
#1  0x21b0 in nffs_restore_inode (area_offset=,
area_idx=, disk_inode=) at nffs_restore.c:572
572 
assert(nffs_hash_id_is_dir(inode_entry->nie_hash_entry.nhe_id));
(gdb) p/x inode
$9 = {ni_inode_entry = 0x200010c0, ni_seq = 0x1, ni_parent = 0x200010a8,
  ni_filename_len = 0x3, ni_filename = {0x62, 0x73, 0x74}}
(gdb) p/x *inode.ni_inode_entry
$10 = {nie_hash_entry = {nhe_next = {sle_next = 0x0}, nhe_id = 0x1008,
nhe_flash_loc = 0x22f}, nie_sibling_next = {sle_next = 0x0}, {
nie_child_list = {slh_first = 0x200019e8},
nie_last_block_entry = 0x200019e8, nie_lastblock_id = 0x200019e8},
  nie_refcnt = 0x1, nie_flags = 0xc4, reserved16 = 0x0}
{noformat}

> nffs crash at bootloader
> 
>
> Key: MYNEWT-343
> URL: https://issues.apache.org/jira/browse/MYNEWT-343
> Project: Mynewt
>  Issue Type: Bug
>  Components: NFFS
> Environment: Arduino Zero with NFFS
>Reporter: Marko Kiiskila
> Attachments: arduino_nffs.bin, nffs-inode-invalid-id.bin
>
>
> System asserts. I was switching between images.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=, line=, 
> func=, e=) at os_fault.c:124
> 124  asm("bkpt");
> (gdb) bt
> #0  __assert_func (file=, line=, 
> func=, e=) at os_fault.c:124
> #1  0x105e in nffs_hash_remove (entry=entry@entry=0x20001ad8)
> at nffs_hash.c:179
> #2  0x2ff2 in nffs_block_delete_from_ram (
> block_entry=block_entry@entry=0x20001ad8) at nffs_block.c:266
> #3  0x26f2 in nffs_restore_sweep () at nffs_restore.c:353
> #4  0x283e in nffs_restore_full (area_descs=area_descs@entry=0x2000736c)
> at nffs_restore.c:1400
> #5  0x04ca in nffs_detect (area_descs=area_descs@entry=0x2000736c)
> at nffs.c:606
> #6  0x01e8 in setup_for_nffs () at boot.c:93
> #7  main () at boot.c:173



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-350) BLE Host - Function to calculate required GATT server resources

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-350:
--

 Summary: BLE Host - Function to calculate required GATT server 
resources
 Key: MYNEWT-350
 URL: https://issues.apache.org/jira/browse/MYNEWT-350
 Project: Mynewt
  Issue Type: New Feature
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


Currently the developer has to guess how many attributes, services, etc. to 
configure the host with.  Better would be if there were a function that took an 
array of gatt service definitions and did the math itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-348) BLE Host - Function to register mandatory services

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-348:
--

 Summary: BLE Host - Function to register mandatory services
 Key: MYNEWT-348
 URL: https://issues.apache.org/jira/browse/MYNEWT-348
 Project: Mynewt
  Issue Type: Improvement
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


Currently the app needs to register the mandatory services (GAP and GATT) 
manually.  There should be a function which does this automatically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-349) BLE Host - API for gatt-service-changed

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-349:
--

 Summary: BLE Host - API for gatt-service-changed
 Key: MYNEWT-349
 URL: https://issues.apache.org/jira/browse/MYNEWT-349
 Project: Mynewt
  Issue Type: New Feature
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: NimBLE host API update

[Christopher Collins]

On Mon, Jul 11, 2016 at 05:53:27PM -0700, Christopher Collins wrote:
> Hello all,
> 
> For the past few weeks I have been hinting at a proposal for an updated
> NimBLE host API.  It has taken a bit longer than I expected, but I think
> the proposal is finally ready to unleash on the dev list.  I have not
> pushed any changes to master or develop; I wanted to give the community
> an opportunity to voice its approval, objections, and other feedback.
> 
> There are two ways to see the updated API:
> 
> 1. API reference on the Mynewt web site:
> http://mynewt.apache.org/develop/network/ble/ble_intro/
> 
> (Note: this is the "develop" version in the Version pulldown).
> 
> 2. The ble_hs_api branch in the Mynewt core repository
> (https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core).

FYI- the updated API has been pushed to the develop branch.  Users of
the develop branch may want to hold off on their next git pull unless
they are ready to update their apps to use the new API.

Please don't hesitate to ask for help if you run into any issues with
the changes.

Thanks,
Chris

Re: Flash overflow when building bletiny on nrf51dk

[Christopher Collins]

Hi Philip,

On Wed, Jul 13, 2016 at 12:56:19PM -0700, Philip Levis wrote:
> First off, I’m super excited about mynewt: an open-source BLE stack is
> tremendously valuable. Great work!

Good to hear!

> But I’ve run into a problem: I’m trying to get started and build
> bletiny for the nrf51dk. When it links bletiny.elf, it says that .text
> won’t fit in FLASH, it’s overflowing by 2392 bytes. So two questions:

It's a tight fit, but the nRF51dk should be able to accommodate bletiny.
Are you using Mynewt 0.9.0?

Here are a few things to check:

* Make sure your target is configured to use the "optimized" build
  profile; "debug" is too large.

* Have you enabled any additional logging or other debug features in
  your build target (e.g., by setting the LOG_LEVEL symbol)?

If these suggestions don't solve your problem, could you please send
the output of "newt target show" to the list?

Thanks,
Chris

[jira] [Created] (MYNEWT-347) BLE Host - GAP update params request should fall back to L2CAP update procedure

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-347:
--

 Summary: BLE Host - GAP update params request should fall back to 
L2CAP update procedure
 Key: MYNEWT-347
 URL: https://issues.apache.org/jira/browse/MYNEWT-347
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


Currently, the GAP update parameters procedure only sends the LE connection 
update HCI command.  This works if either of the following is true:

* The device is the master
* Both peers support the connection parameter update link layer procedure

If the device is a slave and the connection parameter update LL procedure is 
unsupported, the GAP procedure will fail.  Rather than failing, the GAP code 
should initiate the L2CAP update procedure.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-346) BLE Host - Allow secure connections without requiring legacy pairing

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-346:
--

 Summary: BLE Host - Allow secure connections without requiring 
legacy pairing
 Key: MYNEWT-346
 URL: https://issues.apache.org/jira/browse/MYNEWT-346
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


There are two options in nimble_opt.h:

* NIMBLE_OPT_SM
* NIMBLE_OPT_SM_SC

The first (sm) enables the security manager and legacy pairing.  The second 
(sm_sc) enables secure connections.  Secure connections requires the security 
manager, so when NIMBLE_OPT_SM_SC is enabled, NIMBLE_OPT_SM gets enabled 
automatically by nimble_opt_auto.h.

The user should be able to enable SC without also enabling legacy pairing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-345) BLE Host - Reduce size of event buffers

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-345:
--

 Summary: BLE Host - Reduce size of event buffers
 Key: MYNEWT-345
 URL: https://issues.apache.org/jira/browse/MYNEWT-345
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins


Currently, the size of each HCI event buffer is 260 bytes.  This is much larger 
than necessary.

The task is:
1. Determine the size of the largest event the controller will send.
2. Reduce the size of the HCI event buffers to the result from step 1.
3. (optional) Increase the default number of HCI event buffers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-344) BLE Host - Don't wake up every second

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-344:
--

 Summary: BLE Host - Don't wake up every second
 Key: MYNEWT-344
 URL: https://issues.apache.org/jira/browse/MYNEWT-344
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


The host currently wakes up once a second to see if there is any work to do.  
This is both stupid and wasteful in terms of power.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-96) Nimble stack configuration

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-96.
-
Resolution: Fixed

> Nimble stack configuration
> --
>
> Key: MYNEWT-96
> URL: https://issues.apache.org/jira/browse/MYNEWT-96
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>Affects Versions: v0_8_0_beta1
>Reporter: William San Filippo
>    Assignee: Christopher Collins
> Fix For: v0_10_0
>
>
> The current method of configuring various features/memory usage/etc in our 
> nimble stack is not exactly what we need as we need to have project (or 
> possibly bsp) configuration capability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-337) BLE host - Fragment data packets at the L2CAP

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-337.
--
Resolution: Fixed

Commit cd66efc0120d6a8a26a4c62ac82869d0de9b0b6e

> BLE host - Fragment data packets at the L2CAP
> -
>
> Key: MYNEWT-337
> URL: https://issues.apache.org/jira/browse/MYNEWT-337
> Project: Mynewt
>  Issue Type: Improvement
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>
> The L2CAP never fragments outgoing data packets; it only reassembles incoming 
> ones.  Rather than fragmenting, it just assumes the HCI and controller can 
> handle whatever it sends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-291) BLE Host - Split GATT attribute access function into more specific events

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-291.
--
Resolution: Fixed

> BLE Host - Split GATT attribute access function into more specific events
> -
>
> Key: MYNEWT-291
> URL: https://issues.apache.org/jira/browse/MYNEWT-291
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_9_0
>
>
> Nimble notifies the app that a characteristic or descriptor is being accessed 
> via an access callback.  The access callback takes a context parameter which 
> points to an instance of the following union:
> {noformat}
> union ble_gatt_access_ctxt {
> struct {
> const struct ble_gatt_chr_def *chr;
> void *data;
> int len;
> } chr_access;
> struct {
> const struct ble_gatt_dsc_def *dsc;
> void *data;
> int len;
> } dsc_access;
> };
> {noformat}
> This is problematic because the user may wish to point the _data_ fields to 
> read-only data, requiring them to "cast away const."  This looks questionable 
> in code, and is difficult to document in the user guide with a straight face.
> Instead, we should change the union to the following:
> {noformat}
> union ble_gatt_access_ctxt {
> struct {
> const struct ble_gatt_chr_def *chr;
> const void *data;
> int len;
> } chr_read;
> struct {
> const struct ble_gatt_chr_def *chr;
> void *data;
> int len;
> } chr_write;
> struct {
> const struct ble_gatt_dsc_def *dsc;
> const void *data;
> int len;
> } dsc_read;
> struct {
> const struct ble_gatt_dsc_def *dsc;
> void *data;
> int len;
> } dsc_write;
> };
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-296) BLE Host - Scanning procedures provide an incomplete set of parameters

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-296.
--
Resolution: Fixed

> BLE Host - Scanning procedures provide an incomplete set of parameters
> --
>
> Key: MYNEWT-296
> URL: https://issues.apache.org/jira/browse/MYNEWT-296
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>
> {code}
> int
> ble_gap_disc(uint32_t duration_ms, uint8_t discovery_mode,
>  uint8_t scan_type, uint8_t filter_policy,
>  ble_gap_disc_fn *cb, void *cb_arg)
> {code}
> We need to support all the parameters (scan interval, window, etc.).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MYNEWT-297) BLE Host - Scanning lasts longer than specified duration

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-297.
--
Resolution: Fixed

> BLE Host - Scanning lasts longer than specified duration
> 
>
> Key: MYNEWT-297
> URL: https://issues.apache.org/jira/browse/MYNEWT-297
> Project: Mynewt
>  Issue Type: Bug
>  Components: Nimble
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Bluetooth, multiple tasks and forwarding events

[Christopher Collins]

On Tue, Jul 12, 2016 at 09:10:41AM -0700, Christopher Collins wrote:
> I believe I have reproduced this issue.  I'll send an update when I
> have more information.

It appears my exuberance at finding a bug exceeds my skills as a
debugger.  I thought I was seeing the behavior you observed, but it
turned out it was just a bunch of misleading mistakes on my end.

After some thought, I realized that there is quite a bit of code that
uses the same dual-task structure you're using, without issue.  Namely,
bletiny initiates all its GATT procedures in the shell task, and not the
parent task.  The unit tests in ble_os_test.c also do something similar.

Sorry for the noise.  I would be very interested if you continue seeing
this issue.

Thanks,
Chris

Re: Things I'd like to see

[Christopher Collins]

On Mon, Jul 11, 2016 at 01:00:24PM -0700, Sterling Hughes wrote:
> Hey,
> 
> On 11 Jul 2016, at 12:45, Christopher Collins wrote:
> 
> > On Mon, Jul 11, 2016 at 11:01:45AM -0700, Sterling Hughes wrote:
> >> As Will points out, I’m OK if APIs are documented outside of the 
> >> code
> >> itself.  For the OS, I went through and added a bunch of Doxygen
> >> comments, but the function calls and their variants were fairly
> >> simple.  Function calls that take big enums as a parameter can be 
> >> very
> >> lengthy to document with doxygen, and I hate having them in the code
> >> itself.
> >
> > I'm not sure how to read this.  Are you saying API specifications
> > comments are a liability?
> >
> 
> I am saying that I dislike excessively doxygen’d source code.  It’s 
> fine to have a quick function spec at the top, but I’ve seen cases 
> where doxygen comments can span a full screen or more, for a single 
> function.  The example given was a function that takes an enum with a 
> lot of values, where every value would be documented in the doxygen 
> comments.
> 
> I’d prefer the API documentation outside of the source code in those 
> cases, as it inhibits readability of the actual source.  In general, 
> I’m fine with Doxygen comments, but I don’t find them particularly 
> useful — give me a simple API and sample code anyday - I can figure 
> out the rest.

I think we've been discussing slightly different things.  Here's my
take, not intended to challenge what you've said (which I almost
completely agree with).

* Learning materials (e.g., tutorials and example applications) serve a
  different purpose from reference documentation.

* Without a team dedicated to maintaining the reference documentation,
  it will always be out of date.

* The people who actually work on the code are the most knowledgable
  about the specifics of individual functions and data structures - the
  things that are described in the reference documentation.

* The developers look at their code much more often than they look at
  the web site.

* Doxygen comments are in the same files as the code they describe, so
  they can be verified when pull requests are reviewed.

Trying to keep the documentation on the web site up to date independent
of the source code is hopeless.  If the documentation is generated from
doxygen comments, at least there's a possibility of it being mostly
correct.  I don't think I would be bothered by a full page of doxygen
comments, but I accept that others may be.

Chris

NimBLE host API update

[Christopher Collins]

Hello all,

For the past few weeks I have been hinting at a proposal for an updated
NimBLE host API.  It has taken a bit longer than I expected, but I think
the proposal is finally ready to unleash on the dev list.  I have not
pushed any changes to master or develop; I wanted to give the community
an opportunity to voice its approval, objections, and other feedback.

There are two ways to see the updated API:

1. API reference on the Mynewt web site:
http://mynewt.apache.org/develop/network/ble/ble_intro/

(Note: this is the "develop" version in the Version pulldown).

2. The ble_hs_api branch in the Mynewt core repository
(https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core).

Aside from a few cosmetic updates, I believe all the changes are
captured in an email I sent to the list a few weeks back:
https://lists.apache.org/thread.html/3ed04678b908b8bdcd7ed29ec335bdf64bb1ff44de108900e87ff4c1@%3Cdev.mynewt.apache.org%3E

Very soon it will become a lot more difficult to make changes to the
API, so it is important that we get everything right this time.  Well,
that is a bit ambitious, but we should at least try to fix stuff that is
obviously wrong :). For this reason, I would like to ask everyone
interested to please spend some time looking at the updated API and
voice any thoughts you may have.  If you think anything looks
incomplete, incorrect, or just ugly, I would love to hear about it.
Even if you don't have an alternative to propose, your comments might
start a useful discussion that leads to a solution.  Questions are also
welcome in case something is confusing or unclear.

Finally, I just wanted to thank everyone who provided feedback when I
have asked for it in the past.  I am sure there have been times when I
failed to acknowledge contributions, but rest assured it is all very
much appreciated!

Thanks,
Chris

Re: Things I'd like to see

[Christopher Collins]

On Mon, Jul 11, 2016 at 11:01:45AM -0700, Sterling Hughes wrote:
> As Will points out, I’m OK if APIs are documented outside of the code
> itself.  For the OS, I went through and added a bunch of Doxygen
> comments, but the function calls and their variants were fairly
> simple.  Function calls that take big enums as a parameter can be very
> lengthy to document with doxygen, and I hate having them in the code
> itself.

I'm not sure how to read this.  Are you saying API specifications
comments are a liability?

> To me, the bigger things that make it easier to learn new APIs are:
> 
> - Consistent operation: i.e. don’t have callbacks and event queues, 
> don’t call functions from multiple different contexts.
> - Fewer Function Calls: Easier to learn and remember a few functions, 
> than 100’s of them.  Easier to have sample code cover all our APIs.
> - Sample Code: I mostly learn through sample code — i.e. I want to do 
> something, how do I do it.  I have no problem reading relatively complex 
> source code once I’ve got the basics up & running.  But there should 
> be plenty of sample code to have that easily running.

Agreed with all the above.

Chris

Re: Things I'd like to see

[Christopher Collins]

On Mon, Jul 11, 2016 at 08:51:10AM -0700, will sanfilippo wrote:
> I have mixed feelings about comments. In my view, it is OK to not
> comment the code heavily if there is a document that explains the
> code. Either is sufficient in my opinion. Of course, keeping to
> Doxygen style comments for public API is a good idea. Do we run
> doxygen automatically and can we see what the output looks like for
> mynewt? I generally use doxygen style comments for all of my functions
> but I have to admit I am not always consistent.

I think comments fall into two broad categories:

1. A specification of a function's or data structure's contract.
2. Explanatory comments that are intended to make code easier to follow.

The first group of comments generally appear above a function or data
type definition and use the doxygen format.  The second group is usually
in-line with a function body.

In my opinion, comments of the first variety are essential.  Someone
should not have to read code just to understand what inputs are allowed
and whether the function consumes a supplied resource on error, for
example.  In my opinion, there is no justification for not requiring
these type of comments.  

I don't have a strong opinion about the second kind of comments.  On the
plus side, when they are accurate and up to date, they can be quite
helpful for a person reading unfamiliar code.  Unfortunately, these
comments are often inaccurate and out of date, they can a slight
hindrance in reading for someone already familiar with the code, and
worst of all, they make it harder to change code when it needs to be
changed.  So I am happy with letting developers use this type of comment
at their own discretion.

> The other thing about comments and documentation: it is not easy to
> keep them in sync with the actual code. People change things and then
> the comments/documents get out of sync. While this is not a reason to
> not document/comment, it can sometimes be worse than having no
> comments/documentation.

Agreed.  The online documentation will always be out of date unless
there is an automated process to convert comments to documentation.

> The issue is always about enforcement; I think we need to have a
> conversation about how (and if we should) we enforce adherence to the
> coding standards we create.

Insofar as coding standards are useful at all, they need to be enforced.
If someone thinks an exception is warranted, they should provide
justification in the pull request or commit message.

Yes, this is just a lot of empty talk from me :).  I don't know the
right way to enforce coding standards without scaring off contributors.

Chris

[jira] [Resolved] (MYNEWT-323) Newt - Build options precedence hierarchy

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins resolved MYNEWT-323.

Resolution: Fixed
  Assignee: Christopher Collins

Precedence is defined as specified in the ticket description.  This feature 
applies to the following package settings:
* cflags
* aflags
* lflags

> Newt - Build options precedence hierarchy
> -
>
> Key: MYNEWT-323
> URL: https://issues.apache.org/jira/browse/MYNEWT-323
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>    Reporter: Christopher Collins
>        Assignee: Christopher Collins
> Fix For: v0_10_0
>
>
> When two packages specify conflicting build options, it is undefined which 
> one takes effect.  Worse, if two packages specify conflicting cflags (e.g., 
> "-DLOG_LEVEL=0" and "-DLOG_LEVEL=1"), gcc reports an error and aborts the 
> build.
> We should enforce a well-defined precedence hierarchy.  I'm thinking 
> something like this (lowest priority first):
> * Library
> * BSP
> * App
> * Target
> In the case of conflicting options, newt should discard all but the highest 
> priority.  Newt would need to do some simple parsing of cflags to identity 
> conflicts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: re-added repository.yml

[Christopher Collins]

On Sat, Jul 09, 2016 at 10:40:52AM -0700, Sterling Hughes wrote:
> hey,
> 
> i just re-added repository.yml to the master branch — it looks like it 
> was deleted (again).  Deleting this file in the master branch, breaks 
> newt install and newt upgrade for everyone who is using mynewt.
> 
> when merging to master, please remember to _not_ delete this file.  :-)

I see what happened.  It looks like repository.yml got erroneously added
to develop as part of a pull request.  When the mistake was noticed,
the file was deleted from develop.  This second change is what caused
the issue in the recent merge.

I will definitely try to make sure this doesn't happen when I merge in
the future, but I'm wondering if there is a better (i.e., foolproof) way
to enforce this.

Chris

[jira] [Created] (MYNEWT-341) BLE Host - Handle missing ACL data fragments

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-341:
--

 Summary: BLE Host - Handle missing ACL data fragments
 Key: MYNEWT-341
 URL: https://issues.apache.org/jira/browse/MYNEWT-341
 Project: Mynewt
  Issue Type: Bug
Reporter: Christopher Collins
Assignee: Christopher Collins






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Merge develop into master

[Christopher Collins]

Hello all,

I am planning on merging the apache-mynewt-core develop branch into
master later today.  I don't think this will affect anyone, since I
imagine everyone is either using a released version of Mynewt (0.9.0) or
the develop branch.  This merge will only affect you if you have
configured a Mynewt project to use the core master branch.

Major changes included in this merge are:
* NimBLE: Fixes for bugs discovered during UPF54.
* NFFS: New flash layout to improve detection speed.
* Core dump support.

The primary reason for this merge is that some major NimBLE host API
changes will likely be going in to the develop branch next week.  I
wanted to physically separate the upcoming changes from last month's
development efforts.

Please feel free to chime in if you have any questions or objections.

Thanks,
Chris

Re: Assert failed in ble_ll_hci.c:999

[Christopher Collins]

On Thu, Jul 07, 2016 at 06:37:46PM -0700, Simon Ratner wrote:
> So, the assert being where it is, would your bet be on a controller bug, a
> host bug, or the app corrupting os memory in some way? (I've certainly done
> my fair share of the latter ;)

Hi Simon,

It looks like this is caused by a bug in the stack.  This got introduced
a few weeks ago when the host started using a single
statically-allocated buffer for all its HCI commands rather than using
the event memory pool.

I have just committed a fix to develop which should prevent those
horrible looking crashes!

Thanks for the report.

Chris

Re: Bluetooth, multiple tasks and forwarding events

[Christopher Collins]

On Mon, Jul 04, 2016 at 02:48:30PM +0100, Wayne Keenan wrote:
> Hi,
> 
> I have 2 tasks:
> 
> 
> Task 1
> 
> Is the  'app_task_handler'
> It is the 'host parent task' that calls 'bl_hs_start' and
> It dispatches the OS_EVENT_T_TIMER events.
> That's all.
> 
> Task 2
> 
> Makes calls to  'ble_gatts_register_svcs' and 'ble_gap_adv_start'
> Registers callbacks that will be dispatched by 'gatt_svr_chr_handler'

Hi Wayne,

I would not expect any issues when you split up the tasks in this way.
The only real requirement is that there be a host parent task that calls
ble_hs_start() and handles OS_EVENT_T_TIMER events.  Other tasks should
be able to call into the host without issue.

What kind of behavior are you seeing?

Thanks,
Chris

[jira] [Created] (MYNEWT-339) BLE host - Retry when an ATT send fails due to mbuf shortage

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-339:
--

 Summary: BLE host - Retry when an ATT send fails due to mbuf 
shortage
 Key: MYNEWT-339
 URL: https://issues.apache.org/jira/browse/MYNEWT-339
 Project: Mynewt
  Issue Type: Improvement
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


The GATT layer should not give up so easily when the layer below it
(ATT) fails due to memory exhaustion - it should just try again a bit
later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-338) NFFS - Can't delete from a completely full file system

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-338:
--

 Summary: NFFS - Can't delete from a completely full file system
 Key: MYNEWT-338
 URL: https://issues.apache.org/jira/browse/MYNEWT-338
 Project: Mynewt
  Issue Type: Bug
  Components: NFFS
Reporter: Christopher Collins
Assignee: Christopher Collins


Deleting a file or directory requires writing an inode to the disk.  If the 
disk is completely full, there is not room for the deletion record, and the 
delete attempt will fail with an FS_EFULL error.

It should be sufficient to always ensure that at least one area has room for a 
deletion record.  All deletion records are the same size.  Once a deletion 
record is written, the previous inode entry and all children inodes or 
constituent data blocks can be removed during garbage collection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-337) BLE host - Fragment data packets at the L2CAP

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-337:
--

 Summary: BLE host - Fragment data packets at the L2CAP
 Key: MYNEWT-337
 URL: https://issues.apache.org/jira/browse/MYNEWT-337
 Project: Mynewt
  Issue Type: Improvement
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


The L2CAP never fragments outgoing data packets; it only reassembles incoming 
ones.  Rather than fragmenting, it just assumes the HCI and controller can 
handle whatever it sends.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Read rssi of established connection

[Christopher Collins]

On Sat, Jul 02, 2016 at 10:18:03AM -0700, Simon Ratner wrote:
[ble_hci_util_read_rssi()]
> Correct, the return value is 4, and the out param remains unchanged.

I have fixed this bug in develop.  Thanks again for reporting it.

A proper function for querying rssi will get added to the API soon.  At
the moment, I would just keep using ble_hci_util_read_rssi().  I imagine
the real function will be quite similar to this one.

Chris

Re: Read rssi of established connection

[Christopher Collins]

On Sat, Jul 02, 2016 at 10:18:03AM -0700, Simon Ratner wrote:
> Correct, the return value is 4, and the out param remains unchanged.
> 
> I am testing on nrf51; have tried calling it both directly from the
> EVENT_CONNECT callback, as well as some time later, just in case it was
> state-related. For the record, I am fairly certain it used to work
> not-too-long ago, so perhaps this is a recent breakage?

Bummer.  I will check it out.  Thanks for the heads up.

> In the descriptor is perfectly fine.

After thinking about it some more, I think it might be best to have a
dedicated function for querying the RSSI rather than putting it in the
connection descriptor.  The operation requires communication with the
controller, and I think there is some value in isolating
host-controller-communication when possible.

> For my own edification, is there a heartbeat of some sort while the
> connection is open, or is the value just representative of the last
> packet seen? Or a one-off value at time of establishment?

(Will, please chime in if I am talking nonsense)

It is the RSSI of the most recently received data packet.  If the peer
isn't sending any data, then the RSSI value won't get updated.

Chris

Re: Read rssi of established connection

[Christopher Collins]

On Sat, Jul 02, 2016 at 08:31:18AM -0700, Christopher Collins wrote:
> * ble_hci_util_read_rssi() should work.  4 (BLE_HS_EMSGSIZE) is an odd
> return code to be getting; it indicates that the host thinks the
> controller sent back an invalid command complete event in
> acknowledgement.  Just to clarify - you are getting 4 as the return code
> (and not as the retrieved rssi, e.g.)?

I should add that I don't have the necessary hardwrae handy at the
moment, or I would test it myself.  I hope to get a look at this later
today.

Chris

Re: Read rssi of established connection

[Christopher Collins]

On Sat, Jul 02, 2016 at 03:40:25AM -0700, Simon Ratner wrote:
> Hi devs,
> 
> Any plans to expose a way to read last-seen rssi of a connection?
> I found ble_hci_util_read_rssi(), but it seems to always return rc=4 for me.
> 
> Cheers,
> simon

Hi Simon,

Two things:

* Yes - we will need to add a function to the host interface which
allows the application to query the RSSI of a peer.  It might make sense
to just throw it into the big connection descriptor that
ble_gap_find_conn() retrieves.

* ble_hci_util_read_rssi() should work.  4 (BLE_HS_EMSGSIZE) is an odd
return code to be getting; it indicates that the host thinks the
controller sent back an invalid command complete event in
acknowledgement.  Just to clarify - you are getting 4 as the return code
(and not as the retrieved rssi, e.g.)?

Thanks,
Chris

Re: Disconnect reason wrong on local termination

[Christopher Collins]

On Thu, Jun 30, 2016 at 12:39:00PM -0700, Simon Ratner wrote:
> Hi devs,
> 
> I've been looking at the reasons I get in BLE_GAP_EVENT_DISCONNECT to make
> sure I cover all edge cases, and this is what I see (on an nrf51-based
> board):
> 
>   switch (ctxt->disconnect.reason) {
> case BLE_HS_ENOTCONN:
>   /* I see this when the local host has terminated the connection.
> Feels like this should
>* be BLE_HS_HCI_ERR(BLE_ERR_CONN_TERM_LOCAL) instead, per spec.

I thought reporting the HCI error code for locally-terminated
connections would be confusing.  However, I have to admit I am not
really sure what I was thinking there... consistently reporting the HCI
reason code seems to make more sense.  If there are no objections from
anyone else, I will make this change to develop shortly.

Thanks,
Chris

Re: Disconnect reason wrong on local termination

[Christopher Collins]

On Thu, Jun 30, 2016 at 01:31:00PM -0700, Simon Ratner wrote:
> It is sometimes hard to tell if they are "expected", but below are a couple
> of sample traces.
> 
> Based on the timestamps, I would say the first two are expected (device was
> slow to respond), while the last one is unexpected. In the last trace, the
> gatt op failed for another reason (rc=6 i.e. BLE_HS_ENOMEM... as an aside,
> any idea which specific resource it may have run out of?)

My guess is that the BLE_HS_ENOMEM is caused by a lack of mbufs.  The
problem is not too few gattc procedures; if it were, the initial call to
ble_disc_svc_by_uuid() would have returned the error instead.

This tells me two things:

1. We need to be more efficient with mbufs.  In particular, nimble
should be able to operate with smaller (and hence more) mbufs.  This is
something we have known about for a while but haven't gotten a chance to
address yet.  At the moment, nimble requires large mbufs (>= 260 bytes).
This obviously has an impact on the size of the mbuf pool your
application can allocate.

2. The GATT layer should not give up so easily when the layer below it
(ATT) fails due to memory exhaustion.  It should just try again a bit
later.

If I recall, your application is scanning most of the time.  I have not
initated many GATT procedures while scanning, and I think this might be
causing the mbuf shortage, so this is something I will be messing with.

In the meantime, you might try the following:

* Increase the number of mbufs allocated to msys, if your platform has
capacity for it.

* Disable logging (perhaps a non-starter, I know).  Logging to the
console is quite slow, and mbufs are being held in queues rather than
being processed while your application is logging.

Re: Query current state of master and slave

[Christopher Collins]

On Wed, Jun 29, 2016 at 05:45:58PM -0700, Simon Ratner wrote:
> For example:
> 
>   ble_gap_is_adv
>   ble_gap_is_disc
>   ble_gap_is_connecting
> 
> You get the idea.
> 
> As a concrete example, I want the master to be scanning whenever it isn't
> handling a connection. Ditto for slave/advertising. Some commands require
> current op to be aborted (e.g. ble_gap_disc_cancel), and some events cause
> the op to be aborted internally (e.g. incoming connection, or timed
> advertising/scanning). This makes it cumbersome to track current state
> accurately from the app code.
> 
> I am thinking something as simple as exposing ble_gap_master.op /
> ble_gap_slave.op. With this, one could check current state and take
> appropriate action as part of the event loop or timed callout.
> 
> Thoughts?

Sure, that sounds like a good idea.  I will add it to the API proprosal
that I will be publishing soon.

Thanks,
Chris

Re: Clarification on ble_gattc_*_by_uuid calls

[Christopher Collins]

On Mon, Jun 27, 2016 at 04:13:09PM -0700, Simon Ratner wrote:
> Hi Chris,
> 
> One quick clarification question: after receiving a callback with any
> error status, do you guarantee that the callback will never be called
> again (including with a NULL svc param)?

Hi Simon,

Yes, that is the expected behavior.  If the callback is executed with a
non-null error argument, or with a null svc / attr / etc. argument, then
the GATT procedure is complete.  If that callback gets called again, it
should only be because it is associated with an additional GATT
procedure.

Chris

Re: Adding CLI seems to fail

[Christopher Collins]

On Fri, Jun 24, 2016 at 11:59:49AM -0400, David G. Simmons wrote:
> The trouble  arises at this point. No device is ever registered for
> the USB port, so using minicom (or screen, etc.) isn’t an option as
> there is not device. I’ve tried everything I can think of, from
> removing the STLINK jumpers to plugging in both USB (STLINK and USER),
> etc. but still no joy.

Hi David,

You'll need to make sure the FTDI virtual COM port driver is installed
on your machine (http://www.ftdichip.com/Drivers/VCP.htm).  With the
driver present, plugging a USB cable into your computer should cause a
tty device to be added to /dev.

You have two options with the nRF52dk: 1) the virtual COM port, or 2)
the UART pins.  You get the virtual COM port "for free" when you power
your board via USB.  On OS X, this interface has a name beginning with
/dev/tty.usbmodem.  Alternatively, to use the UART pins, you need to
connect a three-wire serial cable to the RX, TX, and ground pins on the
board.

The virtual COM port is easier to set up, but the UART pins seem more
reliable.  In my experience, the virtual COM port sometimes gets "locked
up"; it won't send or receive data.  I should add that I don't know if
this is a problem with my computer, Mynewt, or the nRF52dk, so take it
with a grain of salt.

Chris

[jira] [Closed] (MYNEWT-326) ble_gattc_*_by_uuid callbacks called twice (with bogus data)

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins closed MYNEWT-326.
--
Resolution: Not A Problem

Yes, you are correct - the second callback indicates that the discovery 
operation is complete.  You can determine that the procedure has successfully 
completed by checking the following:

* rc == 0
* service pointer is null

If your callback only gets executed once, and the parameters are as defined 
above, that means the peer device does not support the service you are 
interested in.

The reason for this somewhat awkward interface is that a device is allowed to 
support two different services with the same UUID.  To resolve this ambiguity, 
the callback gets executed with special values indicating discovery is complete.

That said, perhaps the interface could be improved.  I hadn't considered using 
a nonzero status code to indicate service complete, but BLE_HS_EDONE may make 
more sense than 0.

> ble_gattc_*_by_uuid callbacks called twice (with bogus data)
> 
>
> Key: MYNEWT-326
> URL: https://issues.apache.org/jira/browse/MYNEWT-326
> Project: Mynewt
>  Issue Type: Bug
>  Components: ble
>Affects Versions: v0_9_0
>Reporter: Simon Ratner
>
> Here's a log extract (mod=64 lines are mine, printed from relevant callbacks):
> {noformat}
> 1060:[ts=1035136ssb, mod=4 level=1] GAP procedure initiated: connect; 
> addr_type=1 addr=47:b3:03:b7:5f:c6 scan_itvl=16 scan_window=16 itvl_min=24 
> itvl_max=40 latency=0 supervision_timeout=256 min_ce_len=16 max_ce_len=768 
> our_addr_ty
> 2351:[ts=2295728ssb, mod=64 level=1] connection established; status=0 
> handle=1 peer_id_addr=47:b3:03:b7:5f:c6 peer_ota_addr=47:b3:03:b7:5f:c6 
> conn_itvl=40 conn_latency=0 supervision_timeout=256
> 2372:[ts=2316224ssb, mod=4 level=1] GATT procedure initiated: discover 
> service by uuid; uuid=0304-2aae-4d26-ad6203e9a8637ebd
> 2460:[ts=2402112ssb, mod=64 level=2] found svc; 
> uuid=0304-2aae-4d26-ad6203e9a8637ebd start_handle=40 end_handle=65535
> 2491:[ts=2432368ssb, mod=64 level=2] found svc; 
> uuid=--3065-30653015 start_handle=32768 end_handle=8192
> {noformat}
> Steps:
> 1. Connect
> 2. Call {{ble_gattc_disc_svc_by_uuid}} with a specific uuid
> 3. Observe callback invoked twice, the second time with {{end_handle < 
> start_handle}} which is obviously invalid and subsequently fails with 
> BLE_HS_EINVAL when passed to other gatt functions. 
> The {{error}} param is null in both invocations. Skimming the code, perhaps 
> this has something to do with 
> https://github.com/apache/incubator-mynewt-core/blob/develop/net/nimble/host/src/ble_gattc.c#L1346?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

OS_EINVAL vs. OS_INVALID_PARM

[Christopher Collins]

Hello all,

I noticed libs/os/include/os/os.h defines the following two error codes:

OS_EINVAL = 2,
OS_INVALID_PARM = 3,

Do these error codes convey different results?  After a brief look
through the code, my impression is that they mean the same thing.  If
that is the case, I think one of the error codes should be removed.  My
personal preference would be to keep OS_EINVAL just because EINVAL has a
well understood meaning.

Thanks,
Chris

[jira] [Updated] (MYNEWT-323) Newt - Build options precedence hierarchy

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-323:
---
Component/s: (was: t)

> Newt - Build options precedence hierarchy
> -
>
> Key: MYNEWT-323
> URL: https://issues.apache.org/jira/browse/MYNEWT-323
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>    Reporter: Christopher Collins
> Fix For: v0_10_0
>
>
> When two packages specify conflicting build options, it is undefined which 
> one takes effect.  Worse, if two packages specify conflicting cflags (e.g., 
> "-DLOG_LEVEL=0" and "-DLOG_LEVEL=1"), gcc reports an error and aborts the 
> build.
> We should enforce a well-defined precedence hierarchy.  I'm thinking 
> something like this (lowest priority first):
> * Library
> * BSP
> * App
> * Target
> In the case of conflicting options, newt should discard all but the highest 
> priority.  Newt would need to do some simple parsing of cflags to identity 
> conflicts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-323) Newt - Build options precedence hierarchy

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-323:
--

 Summary: Newt - Build options precedence hierarchy
 Key: MYNEWT-323
 URL: https://issues.apache.org/jira/browse/MYNEWT-323
 Project: Mynewt
  Issue Type: Bug
  Components: t, Newt
Reporter: Christopher Collins


When two packages specify conflicting build options, it is undefined which one 
takes effect.  Worse, if two packages specify conflicting cflags (e.g., 
"-DLOG_LEVEL=0" and "-DLOG_LEVEL=1"), gcc reports an error and aborts the build.

We should enforce a well-defined precedence hierarchy.  I'm thinking something 
like this (lowest priority first):
* Library
* BSP
* App
* Target

In the case of conflicting options, newt should discard all but the highest 
priority.  Newt would need to do some simple parsing of cflags to identity 
conflicts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: boot_serial support

[Christopher Collins]

On Sat, Jun 18, 2016 at 11:38:02AM +0200, Kevin Townsend wrote:
> Hi Marko,
> 
> Thanks for getting this into the development branch! ... I was just 
> setting things up to test it out, and I had a look at the code directly 
> on github in the 'develop' branch, but despite my project being on 
> '0-dev' it doesn't pull the changes locally when I run 'newt upgrade'. 

Unfortunately, pulling from git manually (as you did) is currently the
only way to get the latest changes.  This is a known shortcoming, and
there is a fix planned (https://issues.apache.org/jira/browse/MYNEWT-307).

Thanks,
Chris

[jira] [Updated] (MYNEWT-241) Diffucult to use newt to download code to two devices

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-241:
---
Component/s: Newt

> Diffucult to use newt to download code to two devices
> -
>
> Key: MYNEWT-241
> URL: https://issues.apache.org/jira/browse/MYNEWT-241
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Reporter: Paul Dietrich
>
> I have two arduinos hooked up to my system. When I do a newt target download, 
> I don't know which one (or can't figure out how to specify) it getting 
> downloaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYNEWT-238) newt target build succeeds without a project defined.

[Christopher Collins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYNEWT-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Collins updated MYNEWT-238:
---
Component/s: Newt

> newt target build succeeds without a project defined.
> -
>
> Key: MYNEWT-238
> URL: https://issues.apache.org/jira/browse/MYNEWT-238
> Project: Mynewt
>  Issue Type: Bug
>  Components: Newt
>Reporter: Paul Dietrich
>
> target_test_hcsr04
>   arch=cortex_m0
>   bsp=hw/bsp/arduino_zero
>   compiler=arm-none-eabi-m0
>   compiler_def=debug
>   name=target_test_hcsr04
>   vers=0.0.1
> consider this above.  when I run 
> Pauls-MacBook-Pro-2:larva paulfdietrich$ newt target build target_test_hcsr04
> Successfully run!
> but nothing was compiled or build
>  Obviously I am missing a project, but that didn't seem to matter to new tool



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Base a custom bsp on an existing one

[Christopher Collins]

Hi Wayne,

On Fri, Jun 17, 2016 at 02:28:26PM +0100, Wayne Keenan wrote:
> or perhaps I'll break up my app into parts that can be independently
> included as dependencies in the pkg.deps section of pkg.yml.

> > Is it possible to use 'features' to include/exclude subdirectories of
> > source and include under app/myapp/  ?
> >
> > For example, I may have an app which *can* use bluetooth if available, but
> > I may want to have a target with a hardware platform that doesn't have
> > bluetooth so I don't want to compile any app code that depends on Nimble
> >
> > although  "#ifdef'ing FEATURE_NAME" the whole contents of many .c/.h files
> > out is possible I don't see it as desirable.

As you suspected, those are your only two options at the moment.  The
design of newt favors the approach where you break your app into several
packages, since newt's "fundamental unit" is the package, rather than
the directory or file.

After removing the bluetooth-dependent parts of your app and putting
them in separate packages, there are two ways to conditionally include
them in your project:

1. #ifdefs
* A newt "feature" gets defined if your app will be using bluetooth
  (e.g., BLE).

* The bluetooth-dependent library only get included as
  a dependency if the bluetooth feature is defined, e.g.,

pkg.deps.BLE: 

* A preprocessor symbol gets defined if the BLE feature is defined,
  e.g.,

pkg.cflags.BLE: -DBLE_PRESENT

* All calls into the BLE-dependent library are enclosed in ifdefs,
  e.g.,

#ifdef BLE_PRESENT
initialize_ble();
#endif

2. Stub library
* You create two packages: my_ble_pkg and my_ble_stub.  Both of
  these packages expose the same interface via identically-named
  header files.

* The app chooses which package it depends on based on the presence
  of a feature:

pkg.deps.BLE: my_ble_pkg
pkg.deps.NO_BLE: my_ble_stub

* The my_ble_pkg contains a real implementation.  The stub package
  just contains function stubs which return not-supported error
  codes or similar.

* The BSP defines of the BLE or NO_BLE features.

The advantage of the stub library approach is that you don't need to
litter your app code with ifdefs.  However, it may not be practical to
design the app so that it is entirely ignorant of whether BLE is
supported.

I think there is some room for improvement in this area of newt, but I
don't know what the right fix would be.  I think as people build Mynewt
projects we will start to see what functionality is missing.  Any
thoughts you may have on the subject are very welcome, of course.

Thanks,
Chris

Re: Tx power is always advertised as 0dBm on nrf51

[Christopher Collins]

Hi Simon,

On Thu, Jun 09, 2016 at 02:53:14PM -0700, Simon Ratner wrote:
[...]
> The above doesn't seem to have an effect on the contents of the advertising
> packet; it still advertises 0dBm. The comment in
> https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/src/ble_hs_adv.c#L188
> implies that this should be handled automatically, and the provided value
> is ignored. Is this implemented as described, or am I doing something wrong?
> 
> The actual tx power does change, for what it's worth - I see the expected
> difference in received signal between +4, 0, -12, -20.

As currently implemented, the nimble controller always indicates an
advertising power of 0.  I don't want to speak for Will who is more
familiar with this part of the code, but I believe this is intentional,
as the nimble link layer does not expect the transmit power to be
changed "behind its back." Apps are not expected to make direct calls to
the BLE drivers.  Rather, the intended client is the BLE link layer.
Since an interface into the transmit power has not been added to the
Nimble API yet, I don't blame you for trying!  I imagine that when
a transmit power interface is added to nimble, the adverising power
setting will get reported as configured.

Chris

[ANNOUNCE] Apache Mynewt 0.9.0-incubating released

[Christopher Collins]

Hello all,

The Apache Mynewt team is pleased to announce the first release of
Apache Mynewt: 0.9.0-incubating.

Apache Mynewt is a community-driven module OS for constrained, embedded
applications.  Mynewt provides a real-time operating system, flash file
system, network stacks, and support utilities for real-world embedded
systems.

The release is available here:
http://www.apache.org/dyn/closer.lua/incubator/mynewt/apache-mynewt-0.9.0-incubating

We welcome your help and feedback. For more information on the project
and how to get involved, visit the project website at
http://mynewt.incubator.apache.org/

Regards,
The Apache Mynewt team

Disclaimer:
Apache Mynewt is an effort undergoing incubation at The Apache Software
Foundation (ASF) sponsored by the Apache Incubator PMC. Incubation is
required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process have stabilized in a manner consistent with other successful
ASF projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate that
the project has yet to be fully endorsed by the ASF.

Re: New Demo for stm32F3Discovery Based on Blinky

[Christopher Collins]

On Mon, Jun 06, 2016 at 12:42:38PM -0700, marko kiiskila wrote:
> I would leave blinky as is. It is beneficial to have a sample that
> shows that you can have applications which don’t need any platform
> specific changes.

I agree.  Blinky is Mynewt's "hello world" applications.hhC, and I think
it is important that it remain as simple as possible.

> As for the mynewt_pinwheel demo, you could check that into
> mynewt-stm32f3 repository as a separate app. The particular layout of
> those LEDs is specific for the STM32F3 discovery board, so to me it
> would make sense to keep the app in the same repository as the
> matching BSP.
> 
> What do you think?

I'm not David, but that sounds good to me.

Chris

[RESULT][VOTE] Release Apache Mynewt 0.9.0-incubating-rc3

[Christopher Collins]

Hello all,

Voting for Apache Mynewt 0.9.0-incubating-rc3 is now closed.  The
release has passed.  The vote breakdown is as follows:

+1 Jim Jagielski(binding)
+1 John D. Ament(binding)
+1 Justin Mclean(binding)
+1 Sterling Hughes  (binding)

Total: +4

Thank you to all who voted.

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Mynewt 0.9.0-incubating-rc3

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 0.9.0. Given that it is version 0.x, it is still a bit of a beta.
This is the third release candidate for Mynewt 0.9.0 (rc3).  A summary
of what changed between the prior release candidates can be found in the
respective [CANCEL][VOTE] emails:
* rc1: https://lists.apache.org/thread.html/Zunmlysgs7hcywt
* rc2: https://lists.apache.org/thread.html/Zkeq5fu5s6r05tu

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.

[VOTE] thread:
https://lists.apache.org/thread.html/b01d7ebb991bfc8a3913cb623743ba68297694faf8fc15508d064ff9@1464633264@%3Cdev.mynewt.apache.org%3E

[RESULT][VOTE] thread:
https://lists.apache.org/thread.html/0ff6875703299d1f9b2e22fb43b3271ab102d8e6441e71575736fdde@%3Cdev.mynewt.apache.org%3E

[DISCUSS] thread:
https://lists.apache.org/thread.html/fbd7acb28c25bdb4e4d7c4bb7cb6ffa4236cc3e1cdc3999b5f07aced@1464633342@%3Cdev.mynewt.apache.org%3E


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).
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.10.5
 * Linux 3.19.0 (Ubuntu 14.04)

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc3/

The commits under consideration are as follows:

blinky:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
commit: b9a65d46d21c370f56ee934d4f24267ec62722ec

core:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
commit: 054efdb9d9bb14b01f30d3184c9129e3cfd275c9

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: f0a27b6294c25b85c2a7a1e465c5d36ef467054d

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc3/apache-mynewt-newt-bin-linux-0.9.0-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc3/apache-mynewt-newt-bin-osx-0.9.0-incubating.tgz


The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc3

[Christopher Collins]

On Mon, May 30, 2016 at 11:34:24AM -0700, Christopher Collins wrote:
> [X] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...

Chris

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

[Christopher Collins]

On Thu, Jun 02, 2016 at 02:25:33PM +0200, Stephane D'Alu wrote:
> Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting 
> advertisement, which seems to be: pinkey missing.
> 
> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 
> ocf=0x0 status=5
> 
> I'm using bleprph (0.9-dev) as template, which is already using 
> BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such 
> pinkey requirement. Any idea on what is wrong?

Hi Stephane,

Unfortunately, it appears you are the victim of a few red herrings :).
I will attempt to explain what is going on below.  First, the solution
is to increase the max_client_configs setting by at least two, e.g.,

cfg.max_client_configs = 8;

I believe this change will make the problem go away.

As for the cause of the errors:

> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6

The nimble host uses its own set of error codes, separate from the HCI
error codes.  Your confusion is understandable, as we haven't documented
the host error codes anywhere!  This is something we'll need to get on
right away.  The host error codes are defined in
net/nimble/host/include/host/ble_hs.h.  An error code of 6 indicates
memory exhaustion.  In this case, the host did not pre-allocate enough
client characteistic configuration descriptors (CCCDs) for a single
connection, so it prevented the application from performing a
connectable advertisement.

You need to increase max_client_configs by 2 (rather than 1) because the
host maintains a cache of CCCDs that aren't tied to any connection.  The
formula is:

subscribable-charactericteristics * (max-connections + 1)

Where "subscribable-characteristics" is the number of characteristics
supporting notifications or indications.

The other error:

> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 
> ocf=0x0 status=5

This is caused by a bug in the hci debug output code.  The event being
logged here is the no-op that the controller sends on startup.  The
no-op is the only event which does not have a status field.  The debug
code assumes all events have statuses, and it prints a bogus value here.
This should be an easy fix, and I'll look at it shortly.

Finally, your email sparked a few thoughts.  These are just some musings
that need some more thought, but it will help me to write them down, so
I hope you'll humor me and allow me to do so :).

1. We need better diagnostics.  It would be great if a message was
printed to the debug log indicating exactly what failed when you
attempted to advertise.

2. It is too difficult to get all the configuration settings correct.
I'm wondering if we should have the application pass its service table
to ble_hs_init().  That way, the correct values for max_services,
max_attrs, and max_client_configs can all be derived from the table.
One complication here is that the application is currently allowed to
register its services in several steps (multiple calls to
ble_gatts_register_svcs(), each time passing a different table).  I
suppose the options are to either a) remove support for multistage
registration, or b) maintain the current configuration behavior, and
make the new service table method optional.

Thanks,
Chris

Re: Adding service to bleprph

[Christopher Collins]

On Wed, Jun 01, 2016 at 07:24:01PM +0200, Stephane D'Alu wrote:
> Hello again,
> 
> I was trying to add a service/characteristic to the bleprph example, and 
> thought it would be as simple as:
> 
> * add a gatt_svr_chr_access_ function
> * add the service definition in gatt_svr_svcs
> * increase some configuration values (max_services, max_attrs)
>to be safe
> 
> Once done, I'm not able to discover services anymore.
> Did I miss something?
> 
> (Using gcc 4.9.2, and newt 0.9.0)

Hi Stephane,

That is indeed all you should need to do.  However, when I apply your
patch, I observe the same results.  I'll get back to you after I spend
some time debugging this.

Thanks,
Chris

Re: GDB scripts

[Christopher Collins]

On Wed, Jun 01, 2016 at 10:04:05AM -0700, Vipul Rahane wrote:
> Hello,
> 
> While debugging a bunch of things, I felt the need for a few gdb scripts to 
> print out the data structures that we would use regularly. I was thinking of 
> creating a common gdb script which would contain different functions. This 
> could reside in "libs/util" since we do not have a “tools" directory.
> 
> The developer would then just source the common script.
> 
> All suggestions are welcome.

Some gdb scripts are sorely needed, and I think that is a great idea.  I
wrote some small gdb macros ("functions"?) for inspecting mbufs; if you
create one or more gdb scripts, I'll follow your lead and add mine.

Chris

Re: Triggering GATT Notification's

[Christopher Collins]

On Wed, Jun 01, 2016 at 07:04:02AM +0100, Wayne Keenan wrote:
> Because I'm creating a 'ble_gatt_svc_def' at runtime these are the steps
> I'm having todo to be able to keep hold of the characteristic handle in
> order to be able to call 'ble_gatts_chr_updated(handle)' to send the
> notification when needed:
> 
> 1. When initialising the 'ble_gatt_chr_def' the  'arg' field is set to a
> marker value.
> 
> 2. In my 'gatt_svr_register_cb' callback if a ble_gatt_chr_def.arg marker
> value is found then the 'ctxt->chr_reg.def_handle' is stashed in a global
> var.

That will work, but as you say, the need for the "marker arg" is a bit
unwieldy.  I think you are correct - there isn't currently a good way to
do this.  There is an alternative approach that I came up with, but I am
not sure it is an improvement over what you are currently doing, so it
has been relegated to the bottom of this email!

After reading your email and looking at the code some more, I think
there are a few changes that need to be made to the nimble host
immediately:

1. The characteristic-registration-callback should receive a pointers to
both the service definition and the characteristic definition (currently
it only receives a pointer to the characteristic definition).  Without
the service in hand, it is impossible to identify the characteristic by
UUIDs.

2. (As you mentioned) A function to retrieve the attribute handles
corresponding to the characteristic with a specified
service-UUID/characteristic-UUID pair.

In addition, this is not directly related to the problem being
discussed, but I noticed we need a third change:

3. The characteristic access callback also needs to receive a pointer to
the service definition (rather than just a pointer to the characteristic
definition).  This chnage is needed for the same reason as 1 above: so
that the characteristic can be reliably identified by UUID.

[...]
> Is it safe to cache the 'union ble_gatt_register_ctxt *ctxt' pointer
> given as a parameter 'gatt_svr_register_cb' to use later?

No, it is not safe.  The ctxt object is located on the stack, so you
need to make copies of anything you might need later.

> Being able to call Newt GATT API's like the following would help alleviate
> steps 1,2 and help with step 3:
> 
> a) uuit16_t gatt_get_handle_for_chr(serviceUUID, charUUID)

Agreed.

> b) int gatt_write_chr(uint16_t handle, void* data, uint len, bool
> sendNotificationIfEnabled);

There is the following function:

int
ble_att_svr_write_local(uint16_t attr_handle, void *data,
uint16_t data_len);

When a characteristic is written via this function call, the subsequent
characteristic access callback indicates that the write was done locally
by specifying a connection handle of BLE_HS_CONN_HANDLE_NONE (0x).

The above function will always send notifications to all clients who are
subscribed to the corresponding characteristic.  Perhaps the
characteristic access callback should have the option of disabling
notifications for a particular write.  Alternatively, If you want to
update a characteristic without sending any notifications, you can
always bypass the nimble stack entirely and just write directly to the
attribute data.

[...]

Thanks again for you feedback.  It is very much appreciated.

Chris

-

As promised, below is a technique that eliminates the need for the
marker arg.  As I said, it is a bit too ugly for me to recommend with a
straight face, but I thought I should include it for.. I don't know...
some reason :).  The technique identifies characteristics by memory
address.

#define SVC_IDX_GAP 0
#define CHR_IDX_GAP_DEV_NAME0
#define CHR_IDX_GAP_APPEARANCE  1

static const struct ble_gatt_svc_def my_svcs[] = {
[SVC_IDX_GAP] = {
/*** Service: GAP. */
.type = BLE_GATT_SVC_TYPE_PRIMARY,
.uuid128 = BLE_UUID16(BLE_GAP_SVC_UUID16),
.characteristics = (struct ble_gatt_chr_def[]) {
[CHR_IDX_GAP_DEV_NAME] = {
/*** Characteristic: Device Name. */
.uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_DEVICE_NAME),
.access_cb = gatt_svr_chr_access_gap,
.flags = BLE_GATT_CHR_F_READ,
},

[CHR_IDX_GAP_APPEARANCE] = {
/*** Characteristic: Appearance. */
.uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_APPEARANCE),
.access_cb = gatt_svr_chr_access_gap,
.flags = BLE_GATT_CHR_F_READ,
},

/* [...] */

0, /* No more characteristics in this service. */
}
0, /* No more services. */
},
};


static void
gatt_svr_register_cb(uint8_t op, union ble_gatt_register_ctxt *ctxt,
 void *arg)
{
switch (op) {
case BLE_GATT_REGISTER_OP_CHR:
if 

Re: Triggering GATT Notification's

[Christopher Collins]

Hi Wayne,

On Tue, May 31, 2016 at 12:59:20PM +0100, Wayne Keenan wrote:
> Hi,
> 
> I have a custom GATT service working with read/write all ok; now I am
> looking at adding notify support.
> 
> On my first look thru the newt source my first take was that the app needs
> to cache the GATT registrations in 'gatt_svr_register_cb' to obtain the
> chr_val_handle and also track BLE_GAP_EVENT_CONN events and keep hold of
> the conn_handles's
>  so at a later point it can trigger a notification (for one for more
> clients) by calling:
> ble_gattc_notify(uint16_t conn_handle, uint16_t chr_val_handle)
> 
> 
> My first reaction to that is that I must be wrong as that perhaps too much
> duplicated state in the app.
> 
> Is there something simpler like   'ble_send_notify(char_handle, data, len)'
>  that will notify all connected clients ?

There are a few ways to send notifications:

1. The stack sends them automatically to subscribed clients when a
   characteristic value changes.  The client subscribes to notifications
   (or indications) for a particular characteristic by writing to the
   corresponding client characteristic configuration descriptor (CCCD).

2. The way you don't like :).  Call ble_gattc_notify() for each
   connection-characteristic pair that needs to be sent.  These
   notifications are sent "at will": the clients don't need to subscribe
   to the characteristic via a write to the CCCD, and the characteristic
   value doesn't need to change.  As you indicated, the application will
   need to keep track of both the connection handles and characteristic
   value handles.

3. Somewhat closer to what you are asking for:

int
ble_gattc_notify_custom(uint16_t conn_handle, uint16_t att_handle,
void *attr_data, uint16_t attr_data_len)

   The difference between this and option two above is that the
   contents of the notification are specified explicitly by the
   application rather than read from a characteristic.  The attribute
   handle need not even map to characteristic (though it probably
   should).

The nimble stack hasn't gotten a lot of practical use, so there are
undoubtedly some aspects of the API that are lacking common sense.  Now
is the perfect time to make changes to the API while Mynewt is still in
its beta phase, and input like yours is extremely valuable.  If you have
the time, I was hoping you could add some more details concerning what
you as an application developer would like to see exposed by the nimble
host.

You mentioned a function which would send a custom notification to all
connected devices.  Is this exactly what you are looking for, or were
you just trying to make a compromise with nimble's current API?

An additional facility that the host needs to provide is: a means for
the application to discover who is currently connected.  As you
indicated in your email, currently it is up to the application to cache
this information, which is certainly not ideal.  This is something that
will need to get added in the next release.

Please don't hesitate to complain about anything else that seems to be
missing from the API :).

Thanks,
Chris

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

On Sun, May 29, 2016 at 10:56:09AM -0700, Christopher Collins wrote:
> The CMSIS-CORE files that Mynewt bundles fall into two categories:
[...]
> 2. Functional changes were made by ARM mbed before the BSD license
>was added; the oldest revisions containing the BSD license text
>are different from those in Mynewt.
> 
> The files in category 2 are the ones causing issues for us now.  Since
> the versions of these files in Mynewt are not directly derived from
> revisions containing the BSD license, I don't know what we can
> reasonably claim.

Specifically, the following files in the mynewt core repo are
problematic:

libs/cmsis-core/src/cmsis_nvic.c
hw/bsp/nrf51dk-16kbram/include/bsp/cmsis_nvic.h
hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h

The last four (the header files) are almost identical to one another,
and for simplicity I am considering them a single file in this email.

I'm attaching git diffs between the following two revisions:
a: commit when BSD license text was added (mbed repo)
b: first commit to the mynewt core repo.

The Mynewt files are "b" in the attached diffs.  That is, "+++" are
changes added by Mynewt; "---" is removed by mbed.

Thanks,
Chris
diff --git 
a/5b8ab176:libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/cmsis_nvic.h
 
b/e08882916788cee7cb2540604f8f6ec166a1c654:hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
old mode 100644
new mode 100755
index e1fd1a3..78d0417
--- 
a/5b8ab176:libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/cmsis_nvic.h
+++ 
b/e08882916788cee7cb2540604f8f6ec166a1c654:hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
@@ -1,48 +1,40 @@
-/* mbed Microcontroller Library
- * CMSIS-style functionality to support dynamic vectors
- 
***
- * Copyright (c) 2011 ARM Limited. All rights reserved.
- * All rights reserved.
+/**
+ * Copyright (c) 2015 Stack Inc.
  *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ *   http://www.apache.org/licenses/LICENSE-2.0
  *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- * 3. Neither the name of STMicroelectronics nor the names of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* mbed Microcontroller Library - cmsis_nvic
+ * Copyright (c) 2009-2011 ARM Limited. All rights reserved.
  *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
ARE
- * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
- * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
- * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- 
***
- */ 
+ * CMSIS-style functionality to support dynamic vectors
+ */
 
 #ifndef MBED_CMSIS_NVIC_H
 #define MBED_CMSIS_NVIC_H
 
-#define NVIC_NUM_VECTORS  (16 + 32)   // CORE + MCU Peripherals
-#define NVIC_USER_IRQ_OFFSET  16
+#include 
 
-#include "nrf51822.h"
-#include "cmsis.h"
+#define NVIC_NUM_VECTORS  (16 + 38)   // CORE + MCU Peripherals
+#define NVIC_USER_IRQ_OFFSET  16
 
+#include "nrf52xxx/nrf52.h"
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+void NVIC_Relocate(void);
 void NVIC_SetVector(IR

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

Thanks again, Justin.  My responses are inline below.  I rearranged your
email such that your first finding comes last, since it is the most
difficult to address :).

On Sun, May 29, 2016 at 11:23:25AM +1000, Justin Mclean wrote:
[...]

> The core release notes is out of data and talks about March release
> with the next release being in April and it being the "second source
> release”.The readme is also not up to date, and the supported board
> list seem to be missing a few boards?

The outdated release notes is definitely our screw up.  However, the
list of supported platforms in the readme file looks correct to me.  The
only discrepancy I see is that the Arduino 101 isn't mentioned in the
list, but I think that is correct since this target is not fully
supported yet.  Is there another one that I missed?

> The newt release notes are also out of date and refers to the "first
> source release”.

Darn.  We should have caught this one as well.

> I would suggest that the artefact names be renamed to include “mynewt”
> not “newt” especially the core one for the next release.

That sounds reasonable.  I think we should just add "mynewt" to all
three component names, but I am interested in hearing others' thoughts.

> For core is there now any way we can improve on this situation?  "This
> product bundles additional files from CMSIS-CORE, but these files are
> missing licensing information.”

Yes, this one is indeed troubling.  To provide some background:

Recent CMSIS-CORE releases contain the BSD license text, but the older
releases do not, so it is possible that the distributor simply forgot to
add the license text in the older releases.  Back when the CMSIS-CORE files were
added to Mynewt core, we added versions which lacked the BSD license text.

The CMSIS-CORE files that Mynewt bundles fall into two categories:
1. Revisions exist which are identical to those which were
   originally included in Mynewt; the only difference being the
   addition of the BSD license.

2. Functional changes were made by ARM mbed before the BSD license
   was added; the oldest revisions containing the BSD license text
   are different from those in Mynewt.

The licensing issue was easy to solve for the "category 1" files: we
just replaced our old copies of these files with the corresponding
BSD-licensed revisions.

The files in category 2 are the ones causing issues for us now.  Since
the versions of these files in Mynewt are not directly derived from
revisions containing the BSD license, I don't know what we can
reasonably claim.  Intuitively, I feel like the Mynewt copies of these
files are "more or less" derived from the revisions containing the BSD
text, but obviously that is not a legal argument!

Do you have suggestions on how best to proceed?

(In case I gave the opposite impression, I agree that keeping things in
their current state is not a solution).

Thanks,
Chris

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

Hi David,

On Sat, May 28, 2016 at 06:05:10PM -0700, David Moshal wrote:
> how do I find the name of the target?

newt target show

e.g.,

[ccollins@iori:~/tmp/newttest]$ newt target show
targets/blink_nordic
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=debug
targets/my_blinky_sim
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=optimized

The "targets/" prefix is optional.  To run the my_blinky_sim target, I
would execute the following command:

newt run my_blinky_sim

Chris

Re: How to determine the length of received data in a GATT callback

[Christopher Collins]

Hi James,

On Sat, May 28, 2016 at 12:53:14PM -0700, James Howarth wrote:
> Hi,
> 
> Looking at the peripheral callback gatt_svr_chr_access_gatt, is there a way
> to determine the length of data received?
> 
> Here's the whole function definition.
> 
> static int
> gatt_svr_chr_access_gatt(uint16_t conn_handle, uint16_t attr_handle,
> uint8_t op,
>  union ble_gatt_access_ctxt *ctxt, void *arg)

The length of the received data is contained in the ctxt->chr_access.len
field.  For example, bleprph handles an incoming write of the
gap-reconnect-address characteristic as follows:

case BLE_GAP_CHR_UUID16_RECONNECT_ADDR:
assert(op == BLE_GATT_ACCESS_OP_WRITE_CHR);
if (ctxt->chr_access.len != sizeof bleprph_reconnect_addr) {
return BLE_ATT_ERR_INVALID_ATTR_VALUE_LEN;
}
memcpy(bleprph_reconnect_addr, ctxt->chr_access.data,
   sizeof bleprph_reconnect_addr);
break;

The code validates the length of the incoming data immediately after the
assert() invocation.

Chris

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

On Sat, May 28, 2016 at 01:38:48PM -0700, Sterling Hughes wrote:
> $ newt run  
> 
> Will do this for you.  No need to call binary directly. 

If you are building for real hardware (i.e., not sim), then you need to
add a version number to the end of the command.  So, the command would
look something like this:

newt run myblinky 0

If you leave off the 0, you will get a cryptic and intimidating error
message.

I was thinking we might want to make the version number optional.  When
people use the run command, most of the time they probably don't care
what version number the produced image has.

Chris

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

On Fri, May 27, 2016 at 07:56:39PM -0700, Christopher Collins wrote:
> [X] +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)

[DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

Hello all,

This thread is for any and all discussion regarding the release of
apache-mynewt-0.9.0-incubating-rc2.  All feedback is welcome.

Thanks,
Chris

[VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 0.9.0. Given that it is version 0.x, it is still a bit of a beta.
This is the second release candidate for Mynewt 0.9.0 (rc2); voting for
rc1 was cancelled due to a packaging mishap involving the newt source.

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).
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.10.5
 * Linux 3.19.0 (Ubuntu 14.04)

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc2/

The commits under consideration are as follows:

blinky:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
commit: 82f09fa2cc4c67fb30165ef6be0291aa76e6213e

core:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
commit: 48df9b088c50cfc97d2518a823294ace761633d6

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: 0afe655414bbefc922d2adfddf238479bedac5c0

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc2/apache-newt-bin-linux-0.9.0-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc2/apache-newt-bin-osx-0.9.0-incubating.tgz


The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC 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,
Chris

[CANCEL][VOTE] Release Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

Hello all,

Voting for the release of 0.9.0-incubating-rc1 has been cancelled due to
some incorrectly packaged source [*].

Sorry for the confusion, and thank you to everyone who voted.  A second
release candidate will be put up for a vote on the dev list shortly.

Thanks,
Chris

[*] For the newt release, a subdirectory was packaged rather than the
entire repo.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

Hello all,

I would like to make an open request to the PMC community: if you have
the time, could you please take a look at this release candidate and
cast a vote?  This release contains some critical bug fixes, so we would
like to release it if possible.

I can tell from all the traffic that there is a lot going on right now.
All votes, positive and negative, are greatly appreciated.

Chris

On Sun, May 22, 2016 at 11:52:15AM -0700, Christopher Collins wrote:
> Hello,
> 
> The Apache Mynewt Incubator PPMC has approved a proposal to release
> Apache Mynewt 0.9.0-incubating. We now kindly request that the Incubator
> PMC members review and vote on this incubator release.
> 
> 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.
> 
> The highlights of this release are:
> * Bug fixes for the bleprph example app.  The bugs are described
>   under "known issues" here:
>   https://cwiki.apache.org/confluence/display/MYNEWT/RN-0.8.0-incubating)
> 
> * NimBLE stack: BLE pairing and bonding support
> * These features are now enabled by default, and are available
>   in the example BLE apps: bleprph and bletiny.
> 
> * NimBLE stack: Eddystone beacon support
> 
> * Boot loader: The file system no longer fills up after repeated
>   image upgrades.
> 
> [VOTE] thread:
> https://lists.apache.org/thread.html/Za581nzdkku97cr
> 
> [VOTE RESULT] thread:
> https://lists.apache.org/thread.html/Z9ezdety3cst2d5
> 
> [DISCUSS] thread:
> https://lists.apache.org/thread.html/Zse8zizsjwcnfz4
> 
> 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).
> 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.10.5
>  * Linux 3.19.0 (Ubuntu 14.04)
> 
> The release candidate to be voted on is available at:
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/
> 
> The commits under consideration are as follows:
> 
> blinky:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
> commit: 82f09fa2cc4c67fb30165ef6be0291aa76e6213e
> 
> core:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
> commit: 48df9b088c50cfc97d2518a823294ace761633d6
> 
> newt:
> repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
> commit: 0afe655414bbefc922d2adfddf238479bedac5c0
> 
> In addition, the following newt convenience binaries are available:
> linux: 
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-linux-0.9.0-incubating.tgz
> osx: 
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-osx-0.9.0-incubating.tgz
> 
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS
> 
> The vote is open for at least 72 hours.
> 
> [ ] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because…
> 
> Thanks,
> Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: BLE Stack

[Christopher Collins]

On Tue, May 24, 2016 at 03:15:22PM +0400, Vitya Gnatyuk wrote:
> I make up your stack in EmBitz 0.42 with apps\bleprph example. But an one
> error has occurred: undefined reference to `__vector_tbl_reloc__'
> What I can do with it?

Hi Vitya,

Are you using the "newt" tool to build your project, as documented here:
http://mynewt.apache.org/os/get_started/project_create/ ?  It sounds
like you are using the EmBitz IDE instead of newt.  It should certainly
possible to build Mynewt projects without using newt, but it is not
something that we have tried before, and it is not the recommended
setup.

The particular error you are seeing appears to be caused by the
appropriate bsp code not getting linked in to your project.  The newt
tool handles this for you automatically.  If you would like to forgo
using the newt tool, then you will need to manually point your build
tool at all your project's dependencies.

Chris

Re: Respond to a write characteristic

[Christopher Collins]

On Mon, May 23, 2016 at 09:22:42PM -0700, James Howarth wrote:
> Hi Chris,
> 
> Looking at the LightBlue app on my iPhone, it tells me the response is 'null'.

Hmm... I am not sure.  A write response does not contain any data of its
own; all write responses are alike.  Is it possible lightblue displays
that due to an attempt to read a characteristic (as opposed to write)?

Unfortunately I am not equipped to test this out at the moment, but I'll
take a look tomorrow.  That said, I don't believe there is anything
wrong with your code.

Chris

Re: Respond to a write characteristic

[Christopher Collins]

Hi James,

On Mon, May 23, 2016 at 02:24:15PM -0700, James Howarth wrote:
> Hi,
> 
> I am looking to issue a response to a write characteristic, and seem to be
> just getting a null response.
> 
[...]
> static int
> gatt_svr_p_command_cb(uint16_t conn_handle, uint16_t attr_handle, uint8_t
> op,
>  union ble_gatt_access_ctxt *ctxt, void *arg)
> {
> static uint8_t command_int = 0x05;
> ctxt->chr_access.data = _int;
> ctxt->chr_access.len = 1;
> 
> return 0;
> }

That should do the trick. As long as the function returns 0, the write
response should get sent.

What do you mean by null response?

Chris

[VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

Hello,

The Apache Mynewt Incubator PPMC has approved a proposal to release
Apache Mynewt 0.9.0-incubating. We now kindly request that the Incubator
PMC members review and vote on this incubator release.

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.

The highlights of this release are:
* Bug fixes for the bleprph example app.  The bugs are described
  under "known issues" here:
  https://cwiki.apache.org/confluence/display/MYNEWT/RN-0.8.0-incubating)

* NimBLE stack: BLE pairing and bonding support
* These features are now enabled by default, and are available
  in the example BLE apps: bleprph and bletiny.

* NimBLE stack: Eddystone beacon support

* Boot loader: The file system no longer fills up after repeated
  image upgrades.

[VOTE] thread:
https://lists.apache.org/thread.html/Za581nzdkku97cr

[VOTE RESULT] thread:
https://lists.apache.org/thread.html/Z9ezdety3cst2d5

[DISCUSS] thread:
https://lists.apache.org/thread.html/Zse8zizsjwcnfz4

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).
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.10.5
 * Linux 3.19.0 (Ubuntu 14.04)

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/

The commits under consideration are as follows:

blinky:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
commit: 82f09fa2cc4c67fb30165ef6be0291aa76e6213e

core:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
commit: 48df9b088c50cfc97d2518a823294ace761633d6

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: 0afe655414bbefc922d2adfddf238479bedac5c0

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-linux-0.9.0-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-osx-0.9.0-incubating.tgz

The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because…

Thanks,
Chris

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT][VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

Hello all,

Voting for Apache Mynewt 0.9.0-incubating-rc1 is now closed.  The
release has passed this step of the process.  The vote breakdown is as
follows:

+1 Marko Kiiskila
+1 Christopher Collins
+1 Will san Filippo
+1 Sterling Hughes

Total: +4

We can now call a vote on the general@incubator list.

Thank you to all who voted.

Thanks,
Chris

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

All,

It is certainly not a big problem, but it is best if discussion about
the release goes in the [DISCUSS] thread rather than the [VOTE] thread.
Reserving the [VOTE] thread for votes makes it easy for lazy people such
as myself to produce a tally when the vote closes.

Please don't interpet this petty admonition as a request to stop the
conversation!

Thanks,
Chris

On Fri, May 20, 2016 at 09:05:40PM +0200, Kevin Townsend wrote:
> Hi Will,
> 
> Great, thanks.  I don't expect BLE emulation like the HAL layer, but it 
> is nice to be able to build to test shell commands and some basic logic 
> like DSP algorithms on the orientation sensors, etc.
> 
> K.
> 
> On 20/05/16 20:03, will sanfilippo wrote:
> > All:
> >
> > I committed a fix for the native ble build. Basically had to add a bunch of 
> > stubs to the phy and also include the xcvr.h header file. If there are any 
> > other issues please let me know.
> >
> > Will
> >
> >> On May 19, 2016, at 7:38 AM, Kevin Townsend  wrote:
> >>
> >> Hi Chris,
> >>
> >> Sorry this may be an old issue then so feel free to ignore. I understand
> >> that native emulation of the BLE stack doesn't currently work and there are
> >> other priorities, but copying that one file at least allows me to build a
> >> basic project to test some custom shell commands and make sure the command
> >> parsing works as expected etc.
> >>
> >> I'll wait for some feedback though to know what he plans are around nimble
> >> plus native mode. It was a 30 second issue to fix with my artificial test 
> >> case
> >> today but maybe there are other issues I'm not aware of down the road since
> >> I haven't started digging into nimble yet.
> >>
> >> K.
> 

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

On Wed, May 18, 2016 at 11:26:50PM -0700, Christopher Collins wrote:
> [X] +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)

Thanks,
Chris

[jira] [Created] (MYNEWT-297) BLE Host - Scanning lasts longer than specified duration

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-297:
--

 Summary: BLE Host - Scanning lasts longer than specified duration
 Key: MYNEWT-297
 URL: https://issues.apache.org/jira/browse/MYNEWT-297
 Project: Mynewt
  Issue Type: Bug
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYNEWT-295) BLE Host - Persist client characteristic configuration for bonded peers

[Christopher Collins (JIRA)]

Christopher Collins created MYNEWT-295:
--

 Summary: BLE Host - Persist client characteristic configuration 
for bonded peers
 Key: MYNEWT-295
 URL: https://issues.apache.org/jira/browse/MYNEWT-295
 Project: Mynewt
  Issue Type: New Feature
  Components: Nimble
Reporter: Christopher Collins
Assignee: Christopher Collins


h2. Current Behavior
When a peer enables notifications or indications via a write to a client 
characteristic configuration descriptor, the change only lasts for the lifetime 
of the connection.

h2. Proposed Change
The current behavior is correct for non-bonded connections.  However, for 
bonded peers, the values of the client characteristic configuration descriptors 
should persist across connections.  Here are a few notes about the desired 
behavior:
* The persisted configuration is restored when a bonded connection is restored.
* The peripheral should remember whether a characteristic changed, even if 
particular peer is not connected.  When the peer connects and the client 
characteristic configuration is restored, a notification or indication should 
be sent immediately if appropriate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Correct way to specify custom UUID's

[Christopher Collins]

On Thu, May 19, 2016 at 12:57:53PM -0700, James Howarth wrote:
> Hi Chris,
> 
> A)  Thanks for the style tips.  I always appreciate those.
> 
> B)  The device seems to be stuck in trying to register attributes loop,
> similar to what had happened when I didn't have enough attributes
> supported.  Because I have just changed the UUID of the attribute I had
> working before, I don't expect this to be the same problem.

Hmm, I am not sure.  I think I would need to see more code.  Could you
please send the full service definition?

Thanks,
Chris

Re: Correct way to specify custom UUID's

[Christopher Collins]

On Thu, May 19, 2016 at 11:57:45AM -0700, James Howarth wrote:
> I'm not quite sure how to define a custom 128 bit UUID and pass it to
> .uuid128.
> 
> I thought it might be a global variable e.g.
> static uint8_t UUID_BASE[16] = {0x03, 0x04, 0x00, 0x00, 0x2A, 0xAE,
> 0x4D,
> 0x26, 0xAD, 0x62, 0x03, 0xE9, 0xA8, 0x63, 0x7E, 0xBD};
> 
> And then pass this to the service like:
> .uuid128 = UUID_BASE,
> 
> However this does not seem to work.  Any suggestions appreciated.

Hi James,

That is the correct way to specify a 128-bit UUID.  What goes wrong when
you try it?

I also wanted to add a few nitpicks.  None of these are issues that will
prevent your code from working, but I wanted to mention them in case you
want to come back to them later and for the benefit of other readers.

1. You might want to declare the uuid array as const, since it is a
read-only value.  This will allow the linker to place this data in flash
rather than RAM (which is generally more scarce).  Unfortunately, this
requires that you add a (void *) cast to the service definition, since
the service descriptor's uuid128 pointer is non-const [*].

2. I recommend against using all-caps for that variable name.
Generally, all-caps is reserved for macros.  Macros don't obey the usual
rules of the C language, so it is helpful to have a visual indication
that something is actually a macro rather than a regular identifier.

Thanks,
Chris

[*] Nimble and a lot of other Mynewt code has eschewed "const".  I think
there are some places in the nimble host where using const would
simplify the API by obviating the need for casts, so I think we should
change this in the next release.

Re: Procedure for changing power level

[Christopher Collins]

On Thu, May 19, 2016 at 11:12:39AM -0700, James Howarth wrote:
> Hi Chris,
> 
> I think it needs to be a signed int right, as txpwer can be negative, does
> that sound right?

Yes, good catch (thanks also, Kevin!).

In that case, you should declare the tx power variable as an int8_t.

Chris

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

On Wed, May 18, 2016 at 11:28:03PM -0700, Christopher Collins wrote:
> Hello all,
> 
> This thread is for any and all discussion regarding the release of
> apache-mynewt-0.9.0-incubating.  All feedback is welcome.

There is one thing I really should have mentioned in the vote email.  If
you want to try out 0.9.0, change your project.yml file so that the
"vers" field for all the repositories points to "0.9.0" (it probably
specifies "0-latest" at the moment).

For example:

repository.apache-mynewt-core:
type: github
vers: 0.9.0
user: apache
repo: incubator-mynewt-core

Then run "newt upgrade":

[ccollins@ccollins-mac:~/tmp/proj2]$ newt upgrade
apache-mynewt-core
Would you like to upgrade repository apache-mynewt-core from 0.8.0-none to 
0.9.0-none ? [Yn] y

All testing is greatly appreciated.

Thanks,
Chris

Re: [DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

On Thu, May 19, 2016 at 11:30:05AM +0200, Kevin Townsend wrote:
> I'm running in 'develop' which may not be the right branch, but 
> switching a bare bones BLE project to 'native' as a BSP generates this 
> error:
> 
> $ newt build bleuart
> Building target targets/bleuart
> Compiling ble_ll_adv.c
> Error: ble_ll_adv.c:24:22: fatal error: ble/xcvr.h: No such file or 
> directory
> compilation terminated.
> 
> Copying the header from here 
> (https://github.com/apache/incubator-mynewt-core/tree/develop/net/nimble/drivers/nrf51/include/ble)
>  
> solves this but the file should probably exist in 
> net/nimble/drivers/native as well, right?
> 
> If 'develop' corresponds to 0.9.0-rc1 I can submit a pull request if 
> develop is the right branch for this?

Hi Kevin,

The develop branch should be identical to the release candidate, so any
issues you are seeing also exist in 0.9.0-rc1.  Just for my own
clarification, is the issue you describe new to 0.9.0-rc1?  I was under
the impression that native support for the nimble controller
has never worked, and that it has been on the todo list for a while.

If you have a fix for the compiler error, then I am sure a pull request
would probably be welcome.  Will is more familiar with the nimble
controller, so I think I will let him and others chime in.

Thanks,
Chris

[DISCUSS] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

Hello all,

This thread is for any and all discussion regarding the release of
apache-mynewt-0.9.0-incubating.  All feedback is welcome.

Thanks,
Chris

[VOTE] Release Apache Mynewt 0.9.0-incubating-rc1

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of Apache
Mynewt 0.9.0. Given that it is version 0.x, it is still a bit of a beta.

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).
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.10.5
 * Linux 3.19.0 (Ubuntu 14.04)

The release candidate to be voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/

The commits under consideration are as follows:

blinky:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-blinky
commit: 82f09fa2cc4c67fb30165ef6be0291aa76e6213e

core:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-core
commit: 48df9b088c50cfc97d2518a823294ace761633d6

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: 0afe655414bbefc922d2adfddf238479bedac5c0

In addition, the following newt convenience binaries are available:
linux: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-linux-0.9.0-incubating.tgz
osx: 
https://dist.apache.org/repos/dist/dev/incubator/mynewt/apache-mynewt-0.9.0-incubating/rc1/apache-newt-bin-osx-0.9.0-incubating.tgz


The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/dev/incubator/mynewt/KEYS

The vote is open for at least 72 hours and passes if a majority of at
least three +1 PPMC 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,
Chris

Re: Problem with GATT service definition

[Christopher Collins]

On Wed, May 18, 2016 at 08:28:16PM -0700, James Howarth wrote:
> Hi Chris,
> 
> You are 100% right, and I realized after I had just it send, it was a
> copy/paste error.

No worries.  I think the problem is that bleprph is trying to allocate
more attributes than it is configured for.  Bleprph's default
configuration cuts it really close.  I would try increasing the
max_attrs setting from 32 to something more comfortable (e.g., 48).
This will give some extra room for more characteristics in the future.
This setting is configured in main() with the following line:

cfg.max_attrs = 48;

Chris

Re: Trouble running bleprh example

[Christopher Collins]

On Mon, May 16, 2016 at 09:29:37PM -0700, James Howarth wrote:
> Hi Chris,
> 
> Thanks.  I'm getting closer.
> 
> Using the 'LightBlue Explorer' app:
> 
>- I can see the nimble-bleprh device
>- nim-bleprh appears to be advertising no services.
>- When I try and connect to the nRF52, the app times out.

Are you using LightBlue for the iPhone or for OS X?  We have observed
an apparent bug in the CoreBluetooth implemention in OS X which results
in a disconnect shortly after the connection is established.  I am not
sure if this bug has been fixed in the latest OS X release.

The bug is related to the data-length-extension link layer procedure.
When the nimble device initiates this procedure, the mac replies with a
malformed packet.  You can disable the data length extension feature by
modifying the
repos/apache-mynewt-core/net/nimble/controller/include/controller/ble_ll.h
file as follows:

FROM:
#define  BLE_LL_CFG_FEAT_DATA_LEN_EXT

TO:
//#define  BLE_LL_CFG_FEAT_DATA_LEN_EXT

I.e., comment out the line which defines the
BLE_LL_CFG_FEAT_DATA_LEN_EXT symbol.

(disabling features such as this one has been made easier in more recent
code, but for now you need to modify the code directly).

>- After I connect once, it takes a couple of minutes, before the nimble
>device will show up in my app, I thought it was supposed to be instant.

The bleprph app should resume advertising as soon as the connection is
broken.  However, it does not advertise while it is still connected to
something.  Are you saying LightBlue does not show the device when you
tell it to scan?

Chris

Re: Trouble running bleprh example

[Christopher Collins]

Hi James,

On Mon, May 16, 2016 at 10:49:10AM -0700, James Howarth wrote:
> Hi,
> 
> I am trying to get the bleprph example up and running on a Nordic nRF52
> PDK.  But I can't seem to see the device using the LightBlue app running on
> my iPhone.
[...]

Hi James,

I'm pretty sure I know what the problem is - the application task's
stack is overflowing right out the gate.  I'm afraid I have to take the
blame for this one; the default logging settings use a lot of stack, and
I don't often test with them. 

The fix is simple: increase the application stack size from 200 to 288
words.  You can do this by changing apps/bleprph/src/main.c as follows:

#define BLEPRPH_STACK_SIZE  (OS_STACK_ALIGN(288))

This change has already been made to the development branch, but it
didn't make it into the previous release.  Using the develop branch
instead of fixing the bug yourself is also an option; you can do so by
changing your project.yml as follows:

FROM:

repository.apache-mynewt-core:
type: github
vers: 0-latest
user: apache
repo: incubator-mynewt-core

TO:

repository.apache-mynewt-core:
type: github
vers: 0-dev
user: apache
repo: incubator-mynewt-core

(change the "vers" field).

Then upgrade your packages with "newt upgrade", e.g.,

[ccollins@iori:~/tmp/myproj]$ newt upgrade
apache-mynewt-core
Would you like to upgrade repository apache-mynewt-core from 0.7.9-none to 
0.0.0-none ? [Yn] y

Naturally, this branch is quite unstable!

Chris