Hi,
While we’re doing the HAL changes, I’d like folks to check out the
I2C APIs, and provide any comments they have:
https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/hw/hal/include/hal/hal_i2c.h
I was relatively happy with these APIs, except for maybe the
I just checked in the split image code on develop. This involves changes to
apache-mynewt-core as well as a newt and newtmgr.
Generally, the should not affect any functionality or configuration of single
image builds. However, a few imgmgr and bootutil APIs have changed in
non-backward
Not sure if I am answering your question, and maybe you still consider this a
security hole, but the lengths are checked in different places depending on the
packet being received. For advertising channel packets, the lower-layer
routines (ones that get called before the packet is handed to the
Hi Tim,
On Wed, Aug 24, 2016 at 11:04:15PM +0100, Tim Hutt wrote:
> Hi,
>
> With the bleprph example, whenever a central connects it seems to use a
> small connection interval (like 50ms). I'd like a longer one (around
> 500ms).
[...]
To use different connection parameters, one of the two
Hi,
I've been looking through the code for ble_ll_rx_pkt_in(), and I can't see
anywhere where the length of `rxbuf` (`m->om_data`) is checked. The value
seems to be available in `m->om_len` but isn't read anywhere. Subsequent
functions just seem to assume that a packet is as large as it should
