This doesn't seem to be the case. With hci event size of 70 and msys1 block size of 80, I get segfaults. Increasing both to 274 works ok -- I'll try to track down the actual minimum, but someone more familiar with the changes that went in may have an easier time with that.
In either case, there should probably be an assert somewhere if the stack implicitly relies on some minimum memblock size. On 6 Sep. 2017 08:52, "Łukasz Rymanowski" <[email protected]> wrote: > Hi Simon > > On Sep 6, 2017 5:48 PM, "Simon Ratner" <[email protected]> wrote: > > Perfect, this will do. > > I assume I need to enable BLE_EXT_ADV for these. Is it safe to > reduce BLE_HCI_EVT_BUF_SIZE back to 70 if I am not using large > advertisements? > > > It should be Ok. > > > > On 5 Sep. 2017 23:43, "Szymon Janc" <[email protected]> wrote: > > > Hi Simon, > > > > On 6 September 2017 at 05:33, Simon Ratner <[email protected]> wrote: > > > Hi Szymon, > > > > > > I'd like to take you up on that offer of docs, or at least a pointer in > > the > > > right direction of where to find the new multi-adv hci commands. > > > > Those are standard HCI commands and events from Bluetooth Core Spec 5.0 : > > LE Set Advertising Set Random Address Command > > LE Set Extended Advertising Parameters Command > > LE Set Extended Advertising Data Command > > LE Set Extended Scan Response Data Command > > LE Set Extended Scan Response Data Command > > LE Advertising Set Terminated Event > > LE Scan Request Received Event > > > > All those have 'advertising handle' which allows to configure multiple > > instances (with both legacy or Ext Advertising PDUs). > > Note that spec seems to a bit unclear on what are allowed values for > > advertising handle (as it seems to be configured from > > host side) - currently in Mynewt allowed values for those are 0 to > > MAX_ADVERTISING_INSTANCES. > > > > You can find helpers for constructing those from host in > ble_hs_hci_priv.h > > > > -- > > pozdrawiam > > Szymon K. Janc > > >
