Date   

Re: IDE / Debugging

Piotr Mienkowski
 

On 17.10.2017 19:03, Pushpal Sidhu wrote:
I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.
I've been using Eclipse <https://www.eclipse.org/> + "C/C++ Hardware
Debugging" plug-in for a while. It works flawlessly and is reasonably
easy to setup. If you are developing on ARM there is also "GNU MCU
Eclipse <https://gnu-mcu-eclipse.github.io/>" plug-in. I know I'm not
the only one as there is some - limited - support for using Eclipse with
Zephyr.

-- Piotr


Mesh sample fails w/ CONFIG_BT_HCI_VS_EXT=y

Steve Brown
 

The samples/bluetooth/mesh fails on my nrf52840_pca10056

Below is the debug output of both the failing and non-failing cases.

I bisected down to:
first bad commit: [aaeff3c165051c15dfa025f1aad82f333395b6d0] 
Bluetooth: Add basic host-side support for HCI vendor extension

Somewhere CONFIG_BT_HCI_VS_EXT defaults to "y". If I set it to "n" in prj.conf, all is well.

Steve

====== failing log ============
Initializing...
[bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002)
[bt] [INF] hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 1.9 Build 99
[bt] [INF] show_dev_info: Identity: cf:f1:b8:81:59:d0 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized
[bt] [INF] bt_mesh_prov_init: Device UUID: 00000000-0000-0000-0000-cff1b88159d0
[bt] [DBG] bt_mesh_scan_enable: (0x20001bb8)
[bt] [DBG] adv_thread: (0x200007f8) started
[bt] [DBG] bt_mesh_proxy_adv_start: (0x200007f8)
[bt] [DBG] adv_thread: (0x200007f8) Proxy Advertising up to 60000 ms
[bt] [DBG] bt_mesh_proxy_prov_enable: (0x20001bb8)
Mesh initialized
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x200007f8) adv_enabled 1
[bt] [DBG] adv_send: (0x200007f8) type 2 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] adv_send: (0x200007f8) count 3 interval 20ms duration 90ms
[bt] [DBG] pub_key_ready: (0x20000370) Local public key ready
ecc stack (real size 1324): unused 448 usage 876 / 1324 (66 %)
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 23: 00d05981b8f1cf00000000000000000000000000000000
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] unprovisioned_beacon_send: (0x20001bb8)
[bt] [ERR] unprovisioned_beacon_send: Unable to allocate beacon buffer

======== successful log =============
adv stack (real size 812): unused 384 usage 428 / 812 (52 %)
Kernel stacks:
main (real size 512): unused 272 usage 240 / 512 (46 %)
idle (real size 320): unused 272 usage 48 / 320 (15 %)
interrupt (real size 2048): unused 1616 usage 432 / 2048 (21 %)
workqueue (real size 2048): unused 1704 usage 344 / 2048 (16 %)
[bt] [DBG] bt_mesh_proxy_adv_start: (0x200007f8)
[bt] [DBG] gatt_proxy_advertise: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8) Advertising with NetId d47679433fdb104a
[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)
[bt] [DBG] adv_thread: (0x200007f8) Proxy Advertising up to -1 ms
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] secure_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) net_idx 0x0000 flags 0x00 NetID d47679433fdb104a
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) IV Index 0x00000005 Auth f40a41fab0af320b
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 22: 0100d47679433fdb104a00000005f40a41fab0af320b
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x200007f8) adv_enabled 0
[bt] [DBG] adv_send: (0x200007f8) type 2 len 22: 0100d47679433fdb104a00000005f40a41fab0af320b
[bt] [DBG] adv_send: (0x200007f8) count 1 interval 20ms duration 30ms
[bt] [DBG] beacon_complete: (0x200007f8) err 0
[bt] [DBG] adv_send: (0x200007f8) Advertising started. Sleeping 30 ms
[bt] [DBG] adv_send: (0x200007f8) Advertising stopped
adv stack (real size 812): unused 384 usage 428 / 812 (52 %)
Kernel stacks:
main (real size 512): unused 272 usage 240 / 512 (46 %)
idle (real size 320): unused 272 usage 48 / 320 (15 %)
interrupt (real size 2048): unused 1616 usage 432 / 2048 (21 %)
workqueue (real size 2048): unused 1704 usage 344 / 2048 (16 %)
[bt] [DBG] bt_mesh_proxy_adv_start: (0x200007f8)
[bt] [DBG] gatt_proxy_advertise: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8)
[bt] [DBG] net_id_adv: (0x200007f8) Advertising with NetId d47679433fdb104a
[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)
[bt] [DBG] adv_thread: (0x200007f8) Proxy Advertising up to -1 ms
[bt] [DBG] beacon_send: (0x20001bb8)
[bt] [DBG] secure_beacon_send: (0x20001bb8)
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) net_idx 0x0000 flags 0x00 NetID d47679433fdb104a
[bt] [DBG] bt_mesh_beacon_create: (0x20001bb8) IV Index 0x00000005 Auth f40a41fab0af320b
[bt] [DBG] bt_mesh_adv_send: (0x20001bb8) type 0x02 len 22: 0100d47679433fdb104a00000005f40a41fab0af320b
[bt] [DBG] bt_mesh_proxy_adv_stop: (0x200007f8) adv_enabled 0


Re: IDE / Debugging

Carles Cufi
 

Hi Pushpal,

We are in the process of switching from Make/Kbuild to CMake. Once this transition is complete it should be possible to generate IDE projects from CMake itself, although the focus initially is on being able to compile from the command-line with CMake first.

As someone mentioned before, Segger Embedded Studio (SES) is a good option and hopefully we’ll get closer to integrating with it and others as the CMake transition ends and we can focus on that area.

Regards,

Carles

On 17/10/2017, 19:03, "zephyr-devel-bounces@lists.zephyrproject.org on behalf of Pushpal Sidhu" <zephyr-devel-bounces@lists.zephyrproject.org on behalf of psidhu.devel@gmail.com> wrote:

Hi All,

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.
Preferably something on Windows (so no ddd unless WSL quickly gets to
a better place with USB support).

- Pushpal
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: IDE / Debugging

Pushpal Sidhu
 

Thanks for the suggestion Justin.

Haha, by old school, I meant they are very far removed from CLI
debugging through gdb (which is what I'm used to) as they've been
using tools like IAR for a while. So maybe not old school, but maybe
cli-adverse.

- Pushpal

On Tue, Oct 17, 2017 at 10:07 AM, Justin Watson <jwatson5@gmail.com> wrote:
I would look into Segger https://www.segger.com/. They make a great debugger
and they have a debugger IDE. I use it with Zephyr and I code with Sublime
text. Some peripherals can't be debugged with "printf" statements. Don't be
so quick to call them old-school. A professional firmware engineer knows the
value of a debugger, and frankly shouldn't be without it.

On Tue, Oct 17, 2017 at 10:03 AM Pushpal Sidhu <psidhu.devel@gmail.com>
wrote:

Hi All,

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.
Preferably something on Windows (so no ddd unless WSL quickly gets to
a better place with USB support).

- Pushpal
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: IDE / Debugging

Justin
 

I would look into Segger https://www.segger.com/. They make a great debugger and they have a debugger IDE. I use it with Zephyr and I code with Sublime text. Some peripherals can't be debugged with "printf" statements. Don't be so quick to call them old-school. A professional firmware engineer knows the value of a debugger, and frankly shouldn't be without it.


On Tue, Oct 17, 2017 at 10:03 AM Pushpal Sidhu <psidhu.devel@...> wrote:
Hi All,

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.
Preferably something on Windows (so no ddd unless WSL quickly gets to
a better place with USB support).

- Pushpal
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


IDE / Debugging

Pushpal Sidhu
 

Hi All,

I'm trying to convince my company to switch to Zephyr, but the lack of
an actual IDE with a nice graphical debugger startles them (these are
old-school type firmware people who have gotten used to IDEs).

Is there anything people are doing? The biggest stopper is probably
the graphical debugging ability that they may lose e.g. IAR.
Preferably something on Windows (so no ddd unless WSL quickly gets to
a better place with USB support).

- Pushpal


drivers: gpio: deprecate GPIO_PIN_ENABLE, GPIO_PIN_DISABLE

Piotr Mienkowski
 

Hi all,

I plan to rework GPIO API to fix the issue #2529
https://github.com/zephyrproject-rtos/zephyr/issues/2529. But first I
would like to clean it up a bit.

One thing which is confusing and feels inconsistent are GPIO_PIN_ENABLE,
GPIO_PIN_DISABLE configuration constants.

/*
 * GPIO_PIN_(EN-/DIS-)ABLE are for pin enable / disable.
 *
 * Individual pins can be enabled or disabled
 * if the controller supports this operation.
 */

According to the existing implementation - but not necessarily
description - they are meant to give control over the pin to the GPIO
module or let the pin be controlled by a peripheral. However, this
overlaps functionality provided by the pinmux driver.

Especially GPIO_PIN_DISABLE seems a dangerous option to have since it
gives back control over the pin to a peripheral however gives no way to
choose which peripheral it should be. Pin could become an input or an
output. Pinmux driver handles this in a clean way.

It may be the case that the original meaning of the two constant was
different and they were simply incorrectly implemented. E.g.
GPIO_PIN_DISABLE could mean disconnect pin from the pad. I believe some
SoC support this. If this is the case such option still should go to the
pinmux driver not GPIO one.

In any case the both constants are almost universally ignored by the
existing GPIO device drivers. Out of 17 drivers only 2 take
GPIO_PIN_ENABLE option into account. So in the majority case running
gpio_*_configure function always sets the pin in GPIO mode.

To remove current inconsistencies I propose to deprecate
GPIO_PIN_ENABLE, GPIO_PIN_DISABLE configuration constants. I have
prepared a relevant PR:

https://github.com/zephyrproject-rtos/zephyr/pull/4379

I'm posting this to the list as this is about API and I would like the
topic to have a bit more visibility.

Comments are most welcome.

Regards,
Piotr


Re: public ID addresses

Johan Hedberg
 

Hi Tamra,

On Tue, Oct 17, 2017, Johan Hedberg wrote:
I might be wrong, but I don't think a public address is what you're
looking for, since that address space is formally managed by companies.
Instead, I think you're looking to get a persistent address that stays
the same over reboots. A static random address is also an Identity
Address, so that would fit the bill.

The Nordic controllers come with a pre-programmed static address in
their FICR register, but there's no standard way of reading it from
there through HCI. Luckily, we've now got our own HCI vendor extensions
available which have a command for this. If you build your controller
image out of the latest master branch you will get vendor extensions
support included there. For the host side, I've just pushed a pull
request which adds what's needed:

https://github.com/zephyrproject-rtos/zephyr/pull/4371
This PR is merged now, so simply rebuilding and flashing your nRF51 &
Quark SE Zephyr images from the upstream master branch should yield a
solution where the Bluetooth address remains the same.

Johan


Re: Bluetooth mesh - node with 2 elements - Not enough tailroom for TransMIC

laczenJMS
 

Hi Johan,

Setting CONFIG_BT_MESH_ADV_BUF_COUNT to 7 solved the issue.

Thanks,

Jehudi

2017-10-17 12:26 GMT+02:00 Johan Hedberg <johan.hedberg@intel.com>:

Hi Jehudi,

On Tue, Oct 17, 2017, Laczen JMS wrote:
Thanks for the response. I couldn't find CONFIG_BT_MESH_TX_SEG_COUNT
as configuration option, but I tried changing
CONFIG_BT_MESH_TX_SEG_MSG_COUNT which defaults to 1. I changed it to
10 but I am still getting the Not enough tailroom message. I am using
both 16k and 32k nrf51822, at the moment I am testing with the 32k
version.
Sorry, there's an internal define called BT_MESH_TX_SEG_COUNT, but it
actually gets its value from a different Kconfig variable. From the
transport.h header file:

#define BT_MESH_TX_SEG_COUNT (CONFIG_BT_MESH_ADV_BUF_COUNT - 3)
#define BT_MESH_TX_SDU_MAX (BT_MESH_TX_SEG_COUNT * 12)

So you'll want to increase CONFIG_BT_MESH_ADV_BUF_COUNT by 1 most
likely.

Johan


Re: Bluetooth mesh - node with 2 elements - Not enough tailroom for TransMIC

Johan Hedberg
 

Hi Jehudi,

On Tue, Oct 17, 2017, Laczen JMS wrote:
Thanks for the response. I couldn't find CONFIG_BT_MESH_TX_SEG_COUNT
as configuration option, but I tried changing
CONFIG_BT_MESH_TX_SEG_MSG_COUNT which defaults to 1. I changed it to
10 but I am still getting the Not enough tailroom message. I am using
both 16k and 32k nrf51822, at the moment I am testing with the 32k
version.
Sorry, there's an internal define called BT_MESH_TX_SEG_COUNT, but it
actually gets its value from a different Kconfig variable. From the
transport.h header file:

#define BT_MESH_TX_SEG_COUNT (CONFIG_BT_MESH_ADV_BUF_COUNT - 3)
#define BT_MESH_TX_SDU_MAX (BT_MESH_TX_SEG_COUNT * 12)

So you'll want to increase CONFIG_BT_MESH_ADV_BUF_COUNT by 1 most
likely.

Johan


Re: Bluetooth mesh - node with 2 elements - Not enough tailroom for TransMIC

laczenJMS
 

Hi Johan,

Thanks for the response. I couldn't find CONFIG_BT_MESH_TX_SEG_COUNT
as configuration option, but I tried changing
CONFIG_BT_MESH_TX_SEG_MSG_COUNT which defaults to 1. I changed it to
10 but I am still getting the Not enough tailroom message. I am using
both 16k and 32k nrf51822, at the moment I am testing with the 32k
version.

Kind regards,

Jehudi

2017-10-17 11:41 GMT+02:00 Johan Hedberg <johan.hedberg@intel.com>:

Hi Jehudi,

On Tue, Oct 17, 2017, Laczen JMS wrote:
I am trying to make a bluetooth mesh zephyr node with 2 elements.
After provisioning (which assigns 2 node adresses) meshctl ask for the
composition data. This fails with Not enough tailroom for TransMIC:

[bt] [DBG] dev_comp_data_get: (0x20001950) net_idx 0x0000 app_idx 0xfffe src 0x0
[bt] [ERR] bt_mesh_model_send: Not enough tailroom for TransMIC

What configuration option do I need to change (I am working on nrf51822) ?
I think you need to change CONFIG_BT_MESH_TX_SEG_COUNT. IIRC it defaults
to 3, and with your two elements you've created a composition data that
doesn't fit in three segments anymore. Increasing the SEG_COUNT to 4
will probably fix the issue. Note that this will also increase the
runtime memory consumption, so hopefully that doesn't go over your
limits (IIRC you had 16k?).

Johan


Re: public ID addresses

Johan Hedberg
 

Hi Tamara,

On Sun, Oct 15, 2017, Tamra Oyama wrote:
Does anyone know how to make a device ID public instead of random?

I ran the bluetooth sample, scan_adv, provided by zephyr. Below is what
happens when I run it.

Starting Scanner/Advertiser Demo
[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [INF] show_dev_info: Identity: e3:d8:c2:29:0a:04 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000,
manufacturerf
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized

In the part where it says (random), does anyone know how to make this a
public address or assign an address to the device (tinyTILE in this case)?

Also, would it be possible to instead of using a temporary static random
address, assign an address to the device?
I might be wrong, but I don't think a public address is what you're
looking for, since that address space is formally managed by companies.
Instead, I think you're looking to get a persistent address that stays
the same over reboots. A static random address is also an Identity
Address, so that would fit the bill.

The Nordic controllers come with a pre-programmed static address in
their FICR register, but there's no standard way of reading it from
there through HCI. Luckily, we've now got our own HCI vendor extensions
available which have a command for this. If you build your controller
image out of the latest master branch you will get vendor extensions
support included there. For the host side, I've just pushed a pull
request which adds what's needed:

https://github.com/zephyrproject-rtos/zephyr/pull/4371

Johan


Re: Bluetooth mesh - node with 2 elements - Not enough tailroom for TransMIC

Johan Hedberg
 

Hi Jehudi,

On Tue, Oct 17, 2017, Laczen JMS wrote:
I am trying to make a bluetooth mesh zephyr node with 2 elements.
After provisioning (which assigns 2 node adresses) meshctl ask for the
composition data. This fails with Not enough tailroom for TransMIC:

[bt] [DBG] dev_comp_data_get: (0x20001950) net_idx 0x0000 app_idx 0xfffe src 0x0
[bt] [ERR] bt_mesh_model_send: Not enough tailroom for TransMIC

What configuration option do I need to change (I am working on nrf51822) ?
I think you need to change CONFIG_BT_MESH_TX_SEG_COUNT. IIRC it defaults
to 3, and with your two elements you've created a composition data that
doesn't fit in three segments anymore. Increasing the SEG_COUNT to 4
will probably fix the issue. Note that this will also increase the
runtime memory consumption, so hopefully that doesn't go over your
limits (IIRC you had 16k?).

Johan


Bluetooth mesh - node with 2 elements - Not enough tailroom for TransMIC

laczenJMS
 

Hi,

I am trying to make a bluetooth mesh zephyr node with 2 elements.
After provisioning (which assigns 2 node adresses) meshctl ask for the
composition data. This fails with Not enough tailroom for TransMIC:

[bt] [DBG] dev_comp_data_get: (0x20001950) net_idx 0x0000 app_idx 0xfffe src 0x0
[bt] [ERR] bt_mesh_model_send: Not enough tailroom for TransMIC

What configuration option do I need to change (I am working on nrf51822) ?

Kind regards,

Jehudi


Re: Mesh: gatt_proxy feature bit not being set in mesh/cfg.c:hb_send & comp_get_page_0

Johan Hedberg
 

Hi Steve,

On Sun, Oct 15, 2017, Steve Brown wrote:
The code to conditionally set the gatt_proxy feature bit seems to be
missing in these two functions.
You're right. It's an oversight that needs fixing.

It looks like friend is also missing from comp_get_page_0.
Friend support is not yet complete (there's just a very basic and
incomplete skeleton for it), so this is less of an issue. Something
worth fixing as well though.

Can somebody familiar with the code tell me if this a problem.
I've submitted a PR to fix this:

https://github.com/zephyrproject-rtos/zephyr/pull/4345

That said, you seem to be starting to have a fairly good grasp of the
code, so I welcome you to try to submit fixes/improvements yourself as
well. Even if the fix isn't 100% correct at first we'll sort that out in
the code review phase.

Johan


public ID addresses

Tamra Oyama <tamrako@...>
 

Hi everyone,

Does anyone know how to make a device ID public instead of random?

I ran the bluetooth sample, scan_adv, provided by zephyr. Below is what happens when I run it.

Starting Scanner/Advertiser Demo
[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [INF] show_dev_info: Identity: e3:d8:c2:29:0a:04 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturerf
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
Bluetooth initialized

In the part where it says (random), does anyone know how to make this a public address or assign an address to the device (tinyTILE in this case)?

Also, would it be possible to instead of using a temporary static random address, assign an address to the device?

Any help or insight would be awesome!

Thank you,
Tamra


Mesh: gatt_proxy feature bit not being set in mesh/cfg.c:hb_send & comp_get_page_0

Steve Brown
 

The code to conditionally set the gatt_proxy feature bit seems to be
missing in these two functions.

It looks like friend is also missing from comp_get_page_0.

Can somebody familiar with the code tell me if this a problem.

Thanks,

Steve


Re: Is there tutorials for Zephyr ticker/mayfly?

loquat3
 

Thank you for comments.

I want to custum a nordic RF driver.
It seem that, need a tunning ticker/mayfly.

By the way, is there a plan to replace it? What time is it?

2017-10-12 4:43 GMT+09:00 Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>:

Hi biwa,

Please be aware that ticker/mayfly are not Zephyr OS public interfaces,
i.e. applications/samples shall not use them and they will not follow the API deprecation rules,
implementation and functions are private to controller subsystem, and subject to change.

Comments are inline below...

> On 11 Oct 2017, at 16:19, biwa <sjbiwa@...> wrote:
>
> Thanks for all.
>
> I can not understand ticker/mayfly yet.
>
> My 'UNCLEAR POINT' is,
> :ticker
> What is node?
A ticker node is a timeout or expiry object. This is a node as in a node in a linked list.
> What is user?
A ticker user is an identification number of the execution context that is calling the ticker APIs.
As mentioned before from historical reasons the implementation being barebones,
call to APIs are identified using user ids for context-safety.
> What is slot?
Slot represents the desired time space (duration) occupancy in the timeline by the requesting
ticker node’s timeout callback.
> What is TRIGGER/WORKER/JOB?
These are the ticker's execution contexts.
Trigger is the execution context asserted/signalled/ready to process a timeout.
Trigger could be a timer ISR.
Worker execution context is the one calling the timeout callbacks of the the expired ticker node.
Job execution context handles the ticker’s scheduling operations, all API calls get processed in
this context.
By “execution context” I am referring to the likes of ISRs, threads, tasks, tasklets, and work queues so on.
>
> :mayfly
> What is CALLEE/CALLER?
Callee as in callee function. Caller as in caller of the callee function.
>
>

Regards,
Vinayak


Re: [Zephyr-devil] Tiny tile Zephyr implementation

Graham Stott <gbcstott1@...>
 

Jie,

 

Which version of Zephyr are you using?  I am still on 1.8.0 as I want to keep a stable version while doing my development.  Looking at the code for 1.9.1, I see that there are many changes in the CONFIG files. If you are not using 1.9.1 you should try it with BOARD=tinytile.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Friday, October 13, 2017 12:50 PM
To: Nashif, Anas <anas.nashif@...>
Cc: Graham Stott <gbcstott1@...>; Li, Jun R <jun.r.li@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Anas,

You are right, the only successful flashing with tinytile was using the make BOARD=tinytile command. That was through ttyACM0 with the flyswatter2. For some reason, it was difficult for me to open ACM0 consistently even though dmesg | grep tty shows that ttyACM0 is open. Also, with the flyswatter both ttyUSB0 and ttyUSB1 is open along with ttyACM0. As Graham suggested cleaning up the CONFIG setting would fix the tinytile build. With the ftdi cable for make BOARD=tinytile, the same issue persists.

What works:

With make BOARD=arduino_101 command I am using the ftdi cable. It works perfectly fine, so  I'm basically treating tinytile as the arduino. I am opening minicom through ttyUSB0.

 

Thanks,

Jie

 

On Fri, Oct 13, 2017 at 9:36 AM, Nashif, Anas <anas.nashif@...> wrote:

Which serial device do you connect minicom to? How is the device connected to your host? TinyTILe board is configured to use USB CDC, so the console output is on ttyACM, if you flash the Arduino board image, the console will use the UART device.

 

Anas

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Friday, October 13, 2017 2:58 PM
To: Graham Stott <gbcstott1@...>; Li, Jun R <jun.r.li@...>; zephyr-devel@...


Subject: Re: [Zephyr-devel] [Zephyr-devil] Tiny tile Zephyr implementation

 

 

On Fri, Oct 13, 2017 at 6:47 AM Li, Jun R <jun.r.li@...> wrote:

 Yeah sorry I meant "make BOARD=tinytile". Although it works and applications can flash with this command. When I open minicom to view the outputs. Minicom freezes. This does not happen with make BOARD=arduino_101

Please try “make BOARD=tinytile”. The board name should be exactly same as “boards/x86/tinytile”.

 

From: <zephyr-devel-bounces@...> on behalf of Jie Zhou <zhoujie@...>
Date: Friday, October 13, 2017 at 01:16
To: Graham Stott <gbcstott1@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: Re: [Zephyr-devel] [Zephyr-devil] Tiny tile Zephyr implementation

 

Hey Graham,

 

Thanks for the help! It worked. To flash on tinyTILE, do make BOARD=arduino_101 flash. Since they are using the same Intel curie chip, it will work. Interesting that BOARD=tinyTILE doesn't work, maybe someone should look into that.

 

Sincerely,

Jie

 

On Wed, Oct 11, 2017 at 7:16 PM, Jie Zhou <zhoujie@...> wrote:

Hi Graham,

 

Hmm interesting, which CONFIG settings? Also I want to use tinyTILE for a bluetooth application that I am working on. I need tinyTILE for its wearable size. For flashing on to tinyTILE, all of the bluetooth sample examples provided by zephyr does the same thing; application flashes fine, but when I open minicom to view the outputs, minicom freezes. This holds true for even Hello World the last time I ran that. If you ever get around testing with the curieNano let me know.

 

Thanks,

Jie

 

On Wed, Oct 11, 2017 at 7:07 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

My board is in use at this time so I cannot do this test for you. However I did look at  the Bluetooth beacon sample and I see that it is setting some Bluetooth related CONFIG  settings that are not tested in the BOARD=tileTile make. They are tested  in the arduino_101 make. I suggest you do a make of the Bluetooth beacon sample using BOARD=Arduino_101 and see if that helps.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 6:09 PM


To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

 

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

 

Thank you very much,

Jie 

 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 

 

 

 

 


Re: [Zephyr-devil] Tiny tile Zephyr implementation

Jie Zhou <zhoujie@...>
 

Hi Anas,

You are right, the only successful flashing with tinytile was using the make BOARD=tinytile command. That was through ttyACM0 with the flyswatter2. For some reason, it was difficult for me to open ACM0 consistently even though dmesg | grep tty shows that ttyACM0 is open. Also, with the flyswatter both ttyUSB0 and ttyUSB1 is open along with ttyACM0. As Graham suggested cleaning up the CONFIG setting would fix the tinytile build. With the ftdi cable for make BOARD=tinytile, the same issue persists.

What works:
With make BOARD=arduino_101 command I am using the ftdi cable. It works perfectly fine, so  I'm basically treating tinytile as the arduino. I am opening minicom through ttyUSB0.

Thanks,
Jie

On Fri, Oct 13, 2017 at 9:36 AM, Nashif, Anas <anas.nashif@...> wrote:

Which serial device do you connect minicom to? How is the device connected to your host? TinyTILe board is configured to use USB CDC, so the console output is on ttyACM, if you flash the Arduino board image, the console will use the UART device.

 

Anas

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Jie Zhou
Sent: Friday, October 13, 2017 2:58 PM
To: Graham Stott <gbcstott1@...>; Li, Jun R <jun.r.li@...>; zephyr-devel@lists.zephyrproject.org


Subject: Re: [Zephyr-devel] [Zephyr-devil] Tiny tile Zephyr implementation

 

 

On Fri, Oct 13, 2017 at 6:47 AM Li, Jun R <jun.r.li@...> wrote:

 Yeah sorry I meant "make BOARD=tinytile". Although it works and applications can flash with this command. When I open minicom to view the outputs. Minicom freezes. This does not happen with make BOARD=arduino_101

Please try “make BOARD=tinytile”. The board name should be exactly same as “boards/x86/tinytile”.

 

From: <zephyr-devel-bounces@lists.zephyrproject.org> on behalf of Jie Zhou <zhoujie@...>
Date: Friday, October 13, 2017 at 01:16
To: Graham Stott <gbcstott1@...>, "zephyr-devel@lists.zephyrproject.org" <zephyr-devel@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] [Zephyr-devil] Tiny tile Zephyr implementation

 

Hey Graham,

 

Thanks for the help! It worked. To flash on tinyTILE, do make BOARD=arduino_101 flash. Since they are using the same Intel curie chip, it will work. Interesting that BOARD=tinyTILE doesn't work, maybe someone should look into that.

 

Sincerely,

Jie

 

On Wed, Oct 11, 2017 at 7:16 PM, Jie Zhou <zhoujie@...> wrote:

Hi Graham,

 

Hmm interesting, which CONFIG settings? Also I want to use tinyTILE for a bluetooth application that I am working on. I need tinyTILE for its wearable size. For flashing on to tinyTILE, all of the bluetooth sample examples provided by zephyr does the same thing; application flashes fine, but when I open minicom to view the outputs, minicom freezes. This holds true for even Hello World the last time I ran that. If you ever get around testing with the curieNano let me know.

 

Thanks,

Jie

 

On Wed, Oct 11, 2017 at 7:07 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

My board is in use at this time so I cannot do this test for you. However I did look at  the Bluetooth beacon sample and I see that it is setting some Bluetooth related CONFIG  settings that are not tested in the BOARD=tileTile make. They are tested  in the arduino_101 make. I suggest you do a make of the Bluetooth beacon sample using BOARD=Arduino_101 and see if that helps.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 6:09 PM


To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

 

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

 

Thank you very much,

Jie 

 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 

 

 

 


4821 - 4840 of 8333