Date   

Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

vikrant8051 <vikrant8051@...>
 

Hi Aaron,

CONFIG_BT_MESH_LOW_POWER
CONFIG_BT_MESH_FRIEND

By enabling these parameters you could test LPN & Friend node features.
It has nothing to do with Flash storage.

But if your are planning to create complex n/w, then make sure that all dev kit will
get continuous power supply after Provisioning. Otherwise you have to re-provision NODE which
get disconnected from power.
---------------------------------------------------------------------------------------------------------------------------------------------



On Sun, Apr 22, 2018 at 5:08 AM, Aaron Xu <overheat1984@...> wrote:
Hi Vibrant,

Glad to know that zephyr have this road-map. Do you mean the  Friend & Low Power Node feature will be implemented in zephyr June 2018 with LTS tag ? 

Yes, I think this feature should be very useful for sensor, like environmental or motion sensors. I think remember two cases.
Forgot where to see this use case, It is a photo, a nice house with swimming pool, there are few outdoor temperature/humidity/motion sensors which are solar powered.

Another more reasonable use case is the industry use case. For example some factory need a lot of sensors, they prefer wired not wireless solution, even if they spend a lot of money on the very first set up.
Because the maintenance cost and reliability, but the most important is wired network can works for more then teen years and no need changing battery.
As SIG said, they want the Bluetooth Mesh enter the industry, I suppose it should be commercial, anyway for the industry sensor network on Bluetooth Mesh must works above 10 years with 2 AA batteries.
So I think the  Friend & LPNode feature should be the only solution for such kind of use case.


Regares,
Aaron





Vikrant More <vikrant8051@...> 于 2018年4月21日周六 22:34写道:
Hi Aaron,
I wanna too do that.

But to create complex mesh network, it is required that node should save provisioning & configuration data on
SoC flash. And I hope from next version onwards we could do that which is going to release in June 2018 with LTS tag.

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

....As per my understanding, once this PR get merged into Zephyr main project tree,
that will be the first step towards saving Mesh generated data on SoC flash. 

I'm not able to visualize where we could use Friend & Low Power Node feature in day to day life
experience, so ignore it. Do you have any such example, where we can use Friend & LPNode ?

regards,
vikrant


On Sat, Apr 21, 2018 at 3:43 PM, Aaron Xu <overheat1984@...> wrote:
Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:
Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
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.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[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-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron







Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

Aaron Xu <overheat1984@...>
 

Hi Vibrant,

Glad to know that zephyr have this road-map. Do you mean the  Friend & Low Power Node feature will be implemented in zephyr June 2018 with LTS tag ? 

Yes, I think this feature should be very useful for sensor, like environmental or motion sensors. I think remember two cases.
Forgot where to see this use case, It is a photo, a nice house with swimming pool, there are few outdoor temperature/humidity/motion sensors which are solar powered.

Another more reasonable use case is the industry use case. For example some factory need a lot of sensors, they prefer wired not wireless solution, even if they spend a lot of money on the very first set up.
Because the maintenance cost and reliability, but the most important is wired network can works for more then teen years and no need changing battery.
As SIG said, they want the Bluetooth Mesh enter the industry, I suppose it should be commercial, anyway for the industry sensor network on Bluetooth Mesh must works above 10 years with 2 AA batteries.
So I think the  Friend & LPNode feature should be the only solution for such kind of use case.


Regares,
Aaron





Vikrant More <vikrant8051@...> 于 2018年4月21日周六 22:34写道:

Hi Aaron,
I wanna too do that.

But to create complex mesh network, it is required that node should save provisioning & configuration data on
SoC flash. And I hope from next version onwards we could do that which is going to release in June 2018 with LTS tag.

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

....As per my understanding, once this PR get merged into Zephyr main project tree,
that will be the first step towards saving Mesh generated data on SoC flash. 

I'm not able to visualize where we could use Friend & Low Power Node feature in day to day life
experience, so ignore it. Do you have any such example, where we can use Friend & LPNode ?

regards,
vikrant


On Sat, Apr 21, 2018 at 3:43 PM, Aaron Xu <overheat1984@...> wrote:
Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:
Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
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.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[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-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron






Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

vikrant8051 <vikrant8051@...>
 

Hi Aaron,
I wanna too do that.

But to create complex mesh network, it is required that node should save provisioning & configuration data on
SoC flash. And I hope from next version onwards we could do that which is going to release in June 2018 with LTS tag.

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

....As per my understanding, once this PR get merged into Zephyr main project tree,
that will be the first step towards saving Mesh generated data on SoC flash. 

I'm not able to visualize where we could use Friend & Low Power Node feature in day to day life
experience, so ignore it. Do you have any such example, where we can use Friend & LPNode ?

regards,
vikrant


On Sat, Apr 21, 2018 at 3:43 PM, Aaron Xu <overheat1984@...> wrote:
Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:
Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
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.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[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-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron






Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

Aaron Xu <overheat1984@...>
 

Hi Vikrant,

Perfect! I have use Silicon Labs Bluetooth Mesh Android App to provision my network and control those "Lights".
Thank you for your great help!

I noticed that zephyr has implemented friend and low power nodes for Bluetooth mesh.
I want to step forward to evaluation a more complex Bluetooth mesh network. Any hits on this?

Regards,
Aaron


2018-04-18 0:29 GMT+08:00 Vikrant More <vikrant8051@...>:

Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant
On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
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.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[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-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron





Re: #BluetoothMesh guest key implementation #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Fri, Apr 20, 2018, vikrant8051 wrote:
https://www.bluetooth.com/bluetooth-technology/topology-options/le-mesh/mesh-faq

As per this link, under the heading of #VisitorAttacks we could see :

"*Visitor attacks* are prevented by giving guests and visitors temporary
and limited access to the network using a separate set of keys. These guest
keys have a limited lifetime."

How to implement guest key concept with #ZephyrBluetoothMesh ?
It's more of a provisioner issue than a Zephyr issue. On the Zephyr side
all you need to do is make sure your configuration allows at least two
network keys. Then you need to make your provisioner add the key to all
nodes, including the guest node, for the duration that you want the
guest to have access, and then go and remove the key from all nodes once
you want to revoke access (it doesn't matter if the guest is not around
anymore since no other node has that key). You'd probably also want to
do the same thing with the application key, i.e. use a separate one for
the guest (I think that's what's meant by "set of keys" instead of
talking about a single key).

Johan


#BluetoothMesh guest key implementation #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,


As per this link, under the heading of #VisitorAttacks we could see :

"Visitor attacks are prevented by giving guests and visitors temporary and limited access to the network using a separate set of keys. These guest keys have a limited lifetime."

How to implement guest key concept with #ZephyrBluetoothMesh ?

Thank You !!



Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

Steve Brown
 

Hi Johan,

Some more detail.

On Wed, 2018-04-18 at 16:30 -0600, Steve Brown wrote:
Hi Johan,

On Wed, 2018-04-18 at 11:32 -0700, Johan Hedberg wrote:
Hi Steve,

On Wed, Apr 18, 2018, Steve Brown wrote:
I tracked this down to Zephyr and bisected the problem to commit
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6

Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
Do you have more details on this? Is there a bug with the patch, or
just
something else that needs to be tuned somewhere?

Johan
I think the patch exposes a problem with meshctl. Vikrant offers that
the SILABS App works fine and also uses GATT for provisioning and
configuration. Meshctl provisions fine, but hangs on discovery for
the
configuration service.

I think the problem is with meshctl's discovery filter. I'm not
familiar enough with the filter stuff to understand what's going on.

While meshctl is hanging on discovery, if I scan with bluetoothctl
and
connect to the node, the callback in meshctl fires and it does a get-
composition and proceeds normally.

That's all the detail I've got.

Steve

I added some instrumentation to parse_service_data and
parse_mesh_service_data.

The data type that gets passed to parse_mesh_service_data in data[0] is
0x00 while the function is expecting 0x01 (CONN_TYPE_IDENTITY), the
value of connection.type. That test fails and the function returns
false. No connection is made to the node.

Device property changed ServiceData
update_device_info called
parse_service_data target 00001827-0000-1000-8000-00805f9b34fb
parse_service_data failed
parse_service_data target 00001828-0000-1000-8000-00805f9b34fb
parse_service_data : parse_mesh_service_data
parse_mesh_service_data data[0]:0x00 discovering:0x01 cnx.type:0x01

Does BT_MESH_NODE_IDENTITY_STOPPED get passed as the connection type?

Steve


Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

Steve Brown
 

Hi Johan,

On Wed, 2018-04-18 at 11:32 -0700, Johan Hedberg wrote:
Hi Steve,

On Wed, Apr 18, 2018, Steve Brown wrote:
I tracked this down to Zephyr and bisected the problem to commit
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6

Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
Do you have more details on this? Is there a bug with the patch, or
just
something else that needs to be tuned somewhere?

Johan
I think the patch exposes a problem with meshctl. Vikrant offers that
the SILABS App works fine and also uses GATT for provisioning and
configuration. Meshctl provisions fine, but hangs on discovery for the
configuration service.

I think the problem is with meshctl's discovery filter. I'm not
familiar enough with the filter stuff to understand what's going on.

While meshctl is hanging on discovery, if I scan with bluetoothctl and
connect to the node, the callback in meshctl fires and it does a get-
composition and proceeds normally.

That's all the detail I've got.

Steve


Zephyr news, 18 April 2018

Marti Bolivar
 

Hello,

This is the 18 April 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

An HTML version with additional links is available here:

https://opensourcefoundries.com/blog/2018/04/18/zephyr-news-20180418/

Contents are broken down like this:

- **Highlights**
- Important changes: ABI/API breaks and some features
- New features: non-exhaustive descriptions of new features
- Bug fixes: non-exhaustive list of fixed bugs
- **Individual changes**: a complete list of patches, sorted
chronologically and categorized into areas, like:
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

This newsletter covers changes in Zephyr between these two
commits:

- 9bde3c06e ("tests: build_all: Add LPS22HB and LSM6DSL sensors build
test"), Apr 10 2018
- 4c400e876 ("net: ipv6: Fix crash from malformed fragment payload"),
Apr 17 2018

Important Changes
-----------------

Userspace calling convention change:

System calls from userspace on ARM targets now expect all
arguments to be passed via registers, instead of mixing stack and
registers as done previously.

DTS alias renames:

Various DTS aliases with underscores ('_') in their names were
renamed to use dash ('-') instead. Apparently, underscores were
technically always illegal to use in alias names. This change
avoids a dtc warning in newer versions. In-tree users were
updated; any out of tree applications using the old names will
need changes as well.

WiFi:

The initial outline for Zephyr's WiFi suport was
merged. Initial definitions were added in the following
areas:

- device driver skeleton in drivers/wifi
- a mostly stubbed out main header file, include/net/wifi.h
- WiFi network management in include/net/wifi_mgmt.h,
including definitions for events from so-called "offloaded"
devices (which are separate cores that implement WiFi
funcionality and communicate with the IC running Zephyr
via a higher-level protocol)
- shell support for controlling the network management API in
subsys/net/ip/l2/wifi_shell.c, which can be selected with
CONFIG_NET_L2_WIFI_SHELL. The initial commands are "wifi
connect", "wifi disconnect", and "wifi scan".

This is the groundwork for future changes completing the
generic framework and adding individual device drivers.

Device tree bindings for GPIO keys and LEDs:

Generic device tree bindings for GPIO-based buttons ("keys") and
LEDs were added in dts/bindings/gpio/gpio-keys.yaml and
dts/bindings/gpio/gpio-leds.yaml respectively.

The initial users are STM32-based boards, which now have device
tree nodes for their buttons and onboard LEDs defined.

Features
--------

Architectures:

ARM cores now flush the instruction pipeline after switching
privilege levels, to prevent execution of pre-fetched
instructions with the previous privilege.

Boards:

SoC support was added for the Cortex M4 core which is present in
the imx7d SoC. The Zephyr image must be loaded and run by an A7
core also present on the SoC. Initial board support was added for
the Colibri iMX7D as "colibri_imx7d_m4".

Sanitycheck now runs on hifive1.

96b_carbon_nrf51 now uses the new nRF SPIS driver.

Userspace mode was enabled by default for sam_e70_xplained.

Device tree:

Device tree bindings for STM32 GPIOs were defined, and all
STM32-based boards now have GPIO device nodes.

Drivers:

The native POSIX Ethernet driver now supports network statistics
collection, extending support for the Ethernet interface network
statistics framework that was recently merged.

The driver for the KW41Z BLE and 802.15.4 chip now supports the
OpenThread L2 layer, and received changes to its RNG source which
now feed its (slow and blocking) entropy source's output into the
Xoroshiro PRNG.

The nRF SPI drivers now appear to be completely supported. There
are three available drivers: spi_nrfx_spi.c is a master-only
driver for older devices (or devices with anomalies) without
direct memory access (DMA) support, spi_nrfx_spim.c is a master
driver for devices with DMA support, and spi_nrfx_spis.c is a
driver for the experimental SPI slave API which uses DMA.

Bug Fixes
---------

The k_malloc() and k_calloc() calls in the mempool implementation
now properly check for overflow in all configurations.

A pair of patches fixing IPv6 crashes were merged.

Following reports of confusion, the Windows installation guide
has been restructured to make it easier for new users to
understand what their choices are.

A few sample applications (BT's hci_usb, as well as USB's dfu and
wpanusb) now use the Kconfig knobs CONFIG_USB_DEVICE_VID and
CONFIG_USB_DEVICE_PID to configure the USB vendor and product
IDs. These knobs say they "MUST be configured by vendor"
(e.g. http://docs.zephyrproject.org/reference/kconfig/CONFIG_USB_DEVICE_VID.html);
they default to 0x2FE3 and 0x100 respectively. The VID 0x2FE3
doesn't appear to be allocated by the USB-IF.

The wpanusb sample and ENC28J60 Ethernet driver received fix-ups,
and, in the ENC28J60 case, optimizations.

The number of interrupts on the nRF52840 SoC was fixed.

PWM was disabled on nucleo_f103rb, fixing some test build breaks
and continuing Zephyr's move towards a consistent set of default
board configurations.

CONFIG_CUSTOM_LINKER_SCRIPT, which allows the user to override
the linker scripts provided by Zephyr itself, was fixed. This had
been broken since the transition to CMake, so it seems to have
few, if any, active users.

The Atmel SAM0 flash driver's build is fixed when
CONFIG_FLASH_PAGE_LAYOUT is disabled.

A concurrency fix to the SPI driver core was merged.

Individual Changes
==================

Patches by area (105 patches total):

- Arches: 5
- Bluetooth: 1
- Boards: 8
- Build: 1
- Continuous Integration: 1
- Device Tree: 11
- Documentation: 10
- Drivers: 22
- External: 2
- Kernel: 3
- Libraries: 1
- Maintainers: 2
- Miscellaneous: 2
- Networking: 22
- Samples: 6
- Scripts: 1
- Storage: 1
- Testing: 6

Arches (5):

- 81633023 arch: Add imx7d m4 soc support
- 397e52f0 arch: nrf52: Correct the number of IRQs in nRF52840
- 1aa123d0 arm: nucleo_f103rb: Do not enable PWM by default
- 4d5fbbc5 arch: arm: Flush pipeline after switching privilege levels
- 09a8810b arm: userspace: Rework system call arguments

Bluetooth (1):

- b6d912ab Bluetooth: hci_usb: Use USB Device defined VID / PID

Boards (8):

- 85e8eaa9 boards/arm: add support for colibri_imx7d_m4 board
- a9d7b1ff boards: hifive1: Add missing board yaml file
- 5319e009 boards: arduino_due, nrf52_pca20020: Add "ram" and "flash" properties
- c542c0e3 boards: dts: Cleanup aliases
- 9c032eb1 boards/arduino101: Enable UART 0 controller
- 1d27d27a boards: 96_carbon_nrf51: Update SPI driver default configuration
- 7c6cf201 boards: stm32: add button and leds gpio definitions
- 95126d1a boards: sam_e70_xplained: Enable userspace

Build (1):

- c1aa9d16 cmake: Fix CONFIG_CUSTOM_LINKER_SCRIPT

Continuous Integration (1):

- c84235ee sanitycheck: Exit on load errors

Device Tree (11):

- 708b59b9 dts: stm32: stm32f469 is a stm32f429 derivative
- e7ab1d30 dts: stm32: Populate gpio nodes for stm32f4 series
- 8e5cf5fe dts: stm32: Populate gpio nodes for stm32f0 series
- dbc3c024 dts: stm32: Populate gpio nodes for stm32f1 series
- a4c426ab dts: stm32: Populate gpio nodes for stm32f3 series
- a78adcdd dts: stm32: Populate gpio nodes for stm32l4 series
- 50bf306f dts: stm32: Populate gpio nodes for stm32l0 series
- 93318f9f yaml: rename cell_string clocks
- 6c92e556 dts: bindings: add bindings for stm32 gpio
- 2b4cb5a7 dts: provide yaml bindings for led and gpio keys
- 4fe3a977 dts: gpio: create gpio dt-bingings and inlude in stm32 dtsi files

Documentation (10):

- a02e78d3 doc: fix note for forcing a CI recheck
- f6a25cfd docs: network-management-api: update a changed function name
- 70a5bded doc: network-management-api: clarify intended event listening usage
- 5e9563ab doc: usb: Move USB sections to USB Stack
- 556e5329 doc: Make code consistent lowering case
- a660fcb3 doc: Add USB documentation identifiers and links
- 88b66b58 doc: getting_started: Make it more obvious how to follow the guide
- 05f02bd0 docs: group the GPIO_* flags into logical groups.
- 5e9f7cb2 doc: fix misspellings in Kconfig files
- 50468605 doc: Fix path in documentation about uncrustify.cfg

Drivers (22):

- 346165b2 serial: Add imx uart driver shim
- 05893ec5 wpanusb: Assign USB Product ID to 802.15.4 over USB
- c925bf51 wpanusb: Remove unneeded configuration option
- 32e089d2 wpanusb: Remove old hardcoded VID / PID
- a68a177c wpanusb: Use DEBUG syslog level
- e295836b usb: dfu: Use USB Device defined VID / PID
- 42902e58 drivers/ethernet: Fix and clean a bit ENC28J60 driver
- 669d4a8c drivers/ethernet: Optimize memory read/write operations in ENC28J60
- e8bc0632 drivers/ethernet: Reduce runtime context size in ENC28J60 driver
- 3e048f6d drivers: eth: native_posix: Add ethernet statistics support
- 7738a501 drivers: ieee802154: Add auto-ack support to KW41Z driver
- 9f7470e2 drivers: ieee802154: Add OpenThread modifications to KW41Z driver
- c563e331 drivers: entropy: Change KW41Z to use XOROSHIRO for RNG source
- 8b839b4e drivers/wifi: Add files skeleton for adding WiFi drivers
- 998c79d0 drivers: spi: Add shim for nrfx SPIM driver
- 7a9c4cbd drivers: spi: Align nrfx_spi shim with the nrfx_spim one
- 8c5b16cc drivers: flash: atmel sam0: Fix compilation without page
layout support
- 5976afe9 drivers: spi: Correct a typo in spi_nrfx_spi.c
- 1143606c drivers/spi: Fix context lock behavior
- ffb2bcbb drivers/spi: Slave async calls require recv frames as
successful status
- ecd08111 drivers: spi: Add shim for nrfx SPIS driver
- 5991cea1 drivers: spi: Add missing periods in Kconfig.nrfx

External (2):

- 3afc2b6c ext/hal/nxp/imx: Import the nxp imx7 freertos bsp
- ea1d14e5 hal: nordic: Move nrfx IRQ related stuff from SPI shim to nrfx_glue

Kernel (3):

- 79d151f8 kernel: Fix building of k_thread_create
- b902da35 kernel: mempool: Check for overflow in k_malloc()
- 85dcc97d kernel: mempool: Always check for overflow in k_calloc()

Libraries (1):

- 51a20907 newlib: Fix compiler warning when using Newlib

Maintainers (2):

- f8248d4f CODEOWNERS: Add @pfalcon as a maintainer of BSD Sockets subsystem
- a534aa6a CODEOWNERS: update owners

Miscellaneous (2):

- c7f5cc9b license: fix spdx identifier in a few files
- be6bf293 syslog: net: Fix multiple network interface selection for IPv4

Networking (22):

- 61cd96ee net: l2: ethernet: fix kconfig
- 1146ba1f net: app: server: Create IPv4 listener also if IPv6 is enabled
- c1e7fd76 net: stats: Add infrastructure for collecting ethernet stats
- c90b9f53 net: shell: Print ethernet statistics
- 03b24082 subsys: net: ip: l2: openthread: Fixed compiler errors and warnings
- 00885bbf OpenThread: Normalize IEEE802.15.4 driver name for use by L2 layers
- 292033c1 openthread: kw41z: Adding echo/server project config files
for KW41Z OT
- 6f57c03a net: app: Always set relevant sa_family when starting a TCP server
- ac661a07 net: tcp: Cancel fin_timer in FIN_WAIT_2 instead FIN_WAIT_1
- 6d387ec9 net: Remove the need for an l2 on offloaded drivers
- c7d5e872 net: Don't call l2->enable for offload devices
- 93ac7ce6 net/mgmt: Move NET_EVENT_INFO_MAX_SIZE into net core's private header
- 7bde51d8 net/mgmt: Add initial WiFi management API definitions
- dc81659b net/wifi: Select dependencies to get wifi mgmt working
- 17b923ae net: wifi: Add a wifi.h to hold WiFi definitions
- eab3f168 net/mgmt/wifi: Add dedicated net mgmt hooks for WiFi offload devices
- c995bfe7 net/wifi: Add a shell module for controlling WiFi devices
- da8af393 net: if: Add helper to select src interface for a IPv4 dst addr
- 2bb179b7 net: shell: Use correct network interface for IPv4 ping
- a91c46ff net: app: Select local IP address properly if multiple interfaces
- 2563c373 net: ipv6: Fix crash from NULL fragment pointer access
- 4c400e87 net: ipv6: Fix crash from malformed fragment payload

Samples (6):

- f9159ab6 samples/telnet: Fix accessing iface ipv4 config
- 435d1738 samples: net: stats: Print ethernet statistics
- cd6a3f04 samples: coap_client: fix net mgmt event handler
- 023ae27d samples: telnet: fix net mgmt event handler
- 79c4a5b4 samples: net: coap_client: Fix compile error
- 3aa3e976 samples: net: coap: Solved the payload issue in coap GET Method

Scripts (1):

- 3b529ca3 scripts: extract_dts_inlcudes: generate cells for gpio

Storage (1):

- 50893349 subsys: nffs: Unlock mutex before returning

Testing (6):

- 0d83900d tests: net: mld: fix net mgmt event handler
- 3718684e tests: net: dhcpv4: fix net mgmt event handler
- 3c8b3875 tests: kernel: threads: Additional tests for set_priority
- 1f45f79d tests: mempool: Add overflow checks
- f2177bfb tests: net: Make "app" tests dependent on netif
- 25e5c60c tests/net: utils: increase min RAM requirement to 24K


zephyr thread.

novello
 

I waold like to know if there is an application note that explain haw to make an application with  some thread that are static.Every thread will have an fixed address space.

 Every task will have  a Statically Allocated RAM?

Best Regards

Novello G



Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

Johan Hedberg
 

Hi Steve,

On Wed, Apr 18, 2018, Steve Brown wrote:
I tracked this down to Zephyr and bisected the problem to commit
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6

Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV
Do you have more details on this? Is there a bug with the patch, or just
something else that needs to be tuned somewhere?

Johan


Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

Steve Brown
 

Hi Vikrant,

On Wed, 2018-04-18 at 07:06 -0600, Steve Brown wrote:
Hi Vikrant,

On Wed, 2018-04-18 at 15:02 +0530, vikrant8051 wrote:
Hi,

I am not able to provision my Devices which is executing sample
example at
$/zephyr/samples/boards/nrf52/mesh/onoff-app/

http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/R
EA
DME.html

But able to provision it using Silicon Labs Bluetooth Mesh App.

Is it bug from meshctl (BlueZ) side ?

Thank You !!

I looked at this too. Provisioning seems to complete, but the proxy
service isn't discovered. Meshctl just seems to hang waiting for the
discovery to succeed.

While this is happening, if I use bluetoothctl to scan and then
connect
to the node, the callback in meshctl fires and it starts up and
functions as expected. It appears that something is amiss with the
discovery filter.

I believe that the SILABS App uses advertising bearer for
provisioning,
so it's not conclusive that it working and meshctl failing is
definitely a Bluez issue. I checkout an early March version of Bluez
and Zephyr. The problem is still there.

samples/bluetooth/mesh fails in the same way.

I'm not sure where to go from here.

Steve
I tracked this down to Zephyr and bisected the problem to commit
d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6

Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV

Steve


Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

vikrant8051 <vikrant8051@...>
 

Hi Steve,

Yes, you are right that #meshctl completes provisioning & fails after that.

Silicon Labs still uses PB-GATT like #meshctl for provisioning & configuration of DEVICE.

BlueZ 5.48 #meshctl was perfectly working with Zephyr Mesh DEVICEs.
But suddenly this old version as well as BlueZ 5.49  are not working as expected with latest Zephyr version examples.

So I don't know where is bug exactly present. 

Thank You !!



On Wed, Apr 18, 2018 at 6:36 PM, Steve Brown <sbrown@...> wrote:
Hi Vikrant,

On Wed, 2018-04-18 at 15:02 +0530, vikrant8051 wrote:
> Hi,
>
> I am not able to provision my Devices which is executing sample
> example at
> $/zephyr/samples/boards/nrf52/mesh/onoff-app/
>
> http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/REA
> DME.html
>
> But able to provision it using Silicon Labs Bluetooth Mesh App.
>
> Is it bug from meshctl (BlueZ) side ?
>
> Thank You !!
>
>
I looked at this too. Provisioning seems to complete, but the proxy
service isn't discovered. Meshctl just seems to hang waiting for the
discovery to succeed.

While this is happening, if I use bluetoothctl to scan and then connect
to the node, the callback in meshctl fires and it starts up and
functions as expected. It appears that something is amiss with the
discovery filter.

I believe that the SILABS App uses advertising bearer for provisioning,
so it's not conclusive that it working and meshctl failing is
definitely a Bluez issue. I checkout an early March version of Bluez
and Zephyr. The problem is still there.

samples/bluetooth/mesh fails in the same way.

I'm not sure where to go from here.

Steve





Re: not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

Steve Brown
 

Hi Vikrant,

On Wed, 2018-04-18 at 15:02 +0530, vikrant8051 wrote:
Hi,

I am not able to provision my Devices which is executing sample
example at
$/zephyr/samples/boards/nrf52/mesh/onoff-app/

http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/REA
DME.html

But able to provision it using Silicon Labs Bluetooth Mesh App.

Is it bug from meshctl (BlueZ) side ?

Thank You !!

I looked at this too. Provisioning seems to complete, but the proxy
service isn't discovered. Meshctl just seems to hang waiting for the
discovery to succeed.

While this is happening, if I use bluetoothctl to scan and then connect
to the node, the callback in meshctl fires and it starts up and
functions as expected. It appears that something is amiss with the
discovery filter.

I believe that the SILABS App uses advertising bearer for provisioning,
so it's not conclusive that it working and meshctl failing is
definitely a Bluez issue. I checkout an early March version of Bluez
and Zephyr. The problem is still there.

samples/bluetooth/mesh fails in the same way.

I'm not sure where to go from here.

Steve


not able to complete #BluetoothMesh provisioning & configuration process using #meshctl (5.49) #bluetoothmesh #meshctl

vikrant8051 <vikrant8051@...>
 

Hi,

I am not able to provision my Devices which is executing sample example at
$/zephyr/samples/boards/nrf52/mesh/onoff-app/

http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/README.html

But able to provision it using Silicon Labs Bluetooth Mesh App.

Is it bug from meshctl (BlueZ) side ?

Thank You !!


Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

Marti Bolivar
 

Hi Vikrant,

Thanks for this pointer! I was wondering the same thing, the docs for
the other mesh apps
(http://docs.zephyrproject.org/samples/bluetooth/mesh/README.html and
http://docs.zephyrproject.org/samples/bluetooth/mesh_demo/README.html)
are a bit thin on the step-by-steps. I had no idea there was a
board-specific app with more detailed docs.

Thanks,
Marti

On Tue, Apr 17, 2018 at 12:29 PM, vikrant8051 <vikrant8051@gmail.com> wrote:
Hi Aaron,

This may help you,

http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/README.html


You could provision your node based on above example using either #meshctl
utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant

On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@gmail.com> wrote:

Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

http://docs.zephyrproject.org/application/application.html#eclipse-debugging

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board,
like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the
"zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****

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.11 Build 99

[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)

[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000,
manufacturer 0x05f1

[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-00000000dddd

Mesh initialized

adv stack (real size 812): unused 516 usage 296 / 812 (36 %)

Kernel stacks:

main (real size 512): unused 276 usage 236 / 512 (46 %)

idle (real size 320): unused 272 usage 48 / 320 (15 %)

interrupt (real size 2048): unused 1648 usage 400 / 2048 (19 %)

workqueue (real size 2048): unused 1736 usage 312 / 2048 (15 %)

ecc stack (real size 1324): unused 448 usage 876 / 1324 (66 %)

prio recv thread stack (real size 748): unused 632 usage 116 / 748
(15 %)

recv thread stack (real size 2348): unused 2136 usage 212 / 2348
(9 %)

adv stack (real size 812): unused 472 usage 340 / 812 (41 %)

Kernel stacks:

...

Kernel stacks:

...

I can see those printf information in the red, look it works. but what's
the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it!

Regards,
Aaron



Re: [Zephyr-devel] How to evaluate the "zephyr\samples\bluetooth\mesh"?

vikrant8051 <vikrant8051@...>
 

Hi Aaron,

This may help you,



You could provision your node based on above example using either #meshctl utility from BlueZ 5.49 or Silicon Labs #BluetoothMesh Android App.

Regards,
vikrant

On Tue, Apr 17, 2018, 1:46 PM Aaron Xu <overheat1984@...> wrote:
Hi,

I follow the "Eclipse debugging" instructions, which can be found here:

And I tried some bluetooth samples in zephyr on NORDIC pca10040 board, like Beacon, mesh demo, they are works.

But those message keep printing on my terminal(serial), when I try the "zephyr\samples\bluetooth\mesh"

***** Booting Zephyr OS v1.11.0-710-g09a8810b3 *****
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.11 Build 99
[bt] [INF] show_dev_info: Identity: ee:ef:34:8d:7f:97 (random)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x05f1
[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-00000000dddd
Mesh initialized
adv stack (real size 812):      unused 516      usage 296 / 812 (36 %)
Kernel stacks:
main      (real size 512):      unused 276      usage 236 / 512 (46 %)
idle      (real size 320):      unused 272      usage 48 / 320 (15 %)
interrupt (real size 2048):     unused 1648     usage 400 / 2048 (19 %)
workqueue (real size 2048):     unused 1736     usage 312 / 2048 (15 %)
ecc stack (real size 1324):     unused 448      usage 876 / 1324 (66 %)
prio recv thread stack (real size 748): unused 632      usage 116 / 748 (15 %)
recv thread stack (real size 2348):     unused 2136     usage 212 / 2348 (9 %)
adv stack (real size 812):      unused 472      usage 340 / 812 (41 %)
Kernel stacks:
...
Kernel stacks:
...
 
I can see those printf information in the red, look it works. but what's the next coming information?
What should I do next? flash more then one board?
Please give me some advise or a documentation, I will appreciate it! 

Regards,
Aaron




Network offload sample

Vakul Garg <vakul.garg@...>
 

Hi

I am looking for a network offload (CONFIG_NET_OFFLOAD) sample application.
I want to integrate a connectivity module (e.g. running zephyr's openthread stack as NCP - network control processor) with an apps mcu running zephyr with CONFIG_NET_OFFLOAD.

My questions:

1. Is the network offload feature designed to ultimately target integration of NCP?

2. The openthread supports spinnel protocol between host MCU and NCP. Why we don't have spinnel implementation in zephyr?
I see that spinnel IETF draft has expired. Is it not the plan to standardize the interface between apps mcu and connectivity module?

Regards

Vakul


Re: Device Firmware Update + Zephyr + #bluetoothmesh

Rodrigo Peixoto
 

That is great Vikrant.

I was thinking they couldn't work together. I will do as you said.

Thank you. 

Best regards,
Rodrigo Peixoto 

Ayna - [Embedded systems design house]


On Sat, 14 Apr 2018 at 02:49 Vikrant More <vikrant8051@...> wrote:


On Sat, Apr 14, 2018, 11:18 AM Vikrant More <vikrant8051@...> wrote:
Hi Rodrigo,

You can start with this,


You have to integrate SMP_Server demo example in your current #BluetoothMesh project.

It will be tedious process, so my advice is to start with simple example.

For example, edit $zephyr/samples/subsys/mgmt/mcumgr/smp_svr so that it will blink LED1 on your board & flash it along with mcuboot as per link I have provided.

Then re-edit same smp_svr, so that it will blink LED2 on your board & now try to upgrade this using #DFU_OTA feature. This will help you lot to understand over all process. 

Regards, 
vikrant

On Sat, Apr 14, 2018, 3:07 AM Rodrigo Peixoto <rodrigopex@...> wrote:

Hi guys,

is it possible to use the Nordic DFU feature in conjunction to Zephyr. I need to upgrade the nodes of a BT mesh network and it would be amazing if I could.

If it isn't, is there any alternative to that?

Thank you. Best regards,

Rodrigo Peixoto. Ayna - [Embedded systems design house]


Re: Device Firmware Update + Zephyr + #bluetoothmesh

vikrant8051 <vikrant8051@...>
 



On Sat, Apr 14, 2018, 11:18 AM Vikrant More <vikrant8051@...> wrote:
Hi Rodrigo,

You can start with this,


You have to integrate SMP_Server demo example in your current #BluetoothMesh project.

It will be tedious process, so my advice is to start with simple example.

For example, edit $zephyr/samples/subsys/mgmt/mcumgr/smp_svr so that it will blink LED1 on your board & flash it along with mcuboot as per link I have provided.

Then re-edit same smp_svr, so that it will blink LED2 on your board & now try to upgrade this using #DFU_OTA feature. This will help you lot to understand over all process. 

Regards, 
vikrant

On Sat, Apr 14, 2018, 3:07 AM Rodrigo Peixoto <rodrigopex@...> wrote:

Hi guys,

is it possible to use the Nordic DFU feature in conjunction to Zephyr. I need to upgrade the nodes of a BT mesh network and it would be amazing if I could.

If it isn't, is there any alternative to that?

Thank you. Best regards,

Rodrigo Peixoto. Ayna - [Embedded systems design house]

2061 - 2080 of 2788