Date   

Re: [Question] zephyr file transfer via BLE

우승우 <du5102@...>
 

Hi Carles

 

I have a question

 

NOW

 

Scenario

                               BLE file transfer                                    UART(file)

Android app (mcumgr) ----------------------à Nordic(nrf52810) ---------------à AP(zephyr OS)

 

refer to the following code you shared.

Check the smp server sample here: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/mgmt/mcumgr/smp_svr

And the corresponding Android libraries here: https://github.com/runtimeco/mcumgr-android

 

I am aiming to send a file from mobile to BLE and ultimately to transfer the file to UART.

 

smp_svr Is this code the AP code or the hex code that I need to put in Nordic?

 

I do think, I need both Nordic code and AP code.?

 

Thanks you

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Thursday, October 18, 2018 5:15 PM
To:
우승우 <du5102@...>; devel@...
Subject: Re: [Zephyr-devel] [Question] zephyr file transfer via BLE

 

Hi there,

 

I believe mcumgr will allow you to do what you need.

Check the smp server sample here: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/subsys/mgmt/mcumgr/smp_svr

And the corresponding Android libraries here: https://github.com/runtimeco/mcumgr-android

 

Carles

 

From: <devel@...> on behalf of 우승우 <du5102@...>
Date: Thursday, 18 October 2018 at 09:35
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] [Question] zephyr file transfer via BLE

 

Hi, This is seungwoo

 

I have a question

 

If you look at the site below, I can transfer BLE file using Nordic chip.

https://devzone.nordicsemi.com/f/nordic-q-a/33093/transfer-big-file-over-ble

 

nrf52-ble-image-transfer-demo çè Android-Image-Transfer-Demo   // file transfer

 

I am trying to develop a device with BLE functionality using nrf52810 in zephyr OS.

 

Like nrf52-ble-image-transfer-demo, Can I use zephyr with an application that can transfer files with Android?

 

Or I would like to ask if there is a case in which Zephyr tried to implement file transmission via BLE.

 

Thanks you


Re: usb device network on nrf52840 platform

cpmcparland@...
 

Andrezej, thanks for looking at this.  To keep things simple, I went back to the sample project:

samples/net/echo_server

With the exception of adding the first line, I don't believe I have changed anything from the zephyr clone I
made a few weeks ago (1_13_99).  Here's the prj.conf.

************************************************
#CONFIG_NEWLIB_LIBC=y
# Generic networking options
CONFIG_NETWORKING=y
CONFIG_NET_UDP=y
CONFIG_NET_TCP=y
#CONFIG_NET_IPV6=y
CONFIG_NET_IPV4=y
#CONFIG_NET_DHCPV4=y

# Kernel options
#CONFIG_ENTROPY_GENERATOR=y
CONFIG_TEST_RANDOM_GENERATOR=y
#CONFIG_INIT_STACKS=y

# Logging
CONFIG_NET_LOG=y
CONFIG_LOG=y
CONFIG_NET_STATISTICS=y
CONFIG_PRINTK=y

# Network buffers
CONFIG_NET_PKT_RX_COUNT=14
CONFIG_NET_PKT_TX_COUNT=14
CONFIG_NET_BUF_RX_COUNT=36
CONFIG_NET_BUF_TX_COUNT=36
CONFIG_NET_CONTEXT_NET_PKT_POOL=y

# IP address options
CONFIG_NET_IF_UNICAST_IPV6_ADDR_COUNT=3
#CONFIG_NET_IF_MCAST_IPV6_ADDR_COUNT=4
CONFIG_NET_MAX_CONTEXTS=10

# Network shell
CONFIG_NET_SHELL=y

# Network application options and configuration
CONFIG_NET_APP_SERVER=y
CONFIG_NET_CONFIG_SETTINGS=y
#CONFIG_NET_CONFIG_NEED_IPV6=y
CONFIG_NET_CONFIG_NEED_IPV4=y
#CONFIG_NET_CONFIG_MY_IPV6_ADDR="2001:db8::1"
#CONFIG_NET_CONFIG_PEER_IPV6_ADDR="2001:db8::2"
CONFIG_NET_CONFIG_MY_IPV4_ADDR="192.0.2.1"
CONFIG_NET_CONFIG_PEER_IPV4_ADDR="192.0.2.2"

***************************************************
When the first line is uncommented, I get compile-time errors like the following (simple variations not copied here-
but, I can send complete listing if needed).

$cmake -DCONF_FILE="prj.conf overlay-netusb.conf" -DBOARD=nrf52840_pca10056 ../../
.... cmake completes successfully ...
$make
Scanning dependencies of target kobj_types_h_target
[  0%] Generating include/generated/kobj-types-enum.h, include/generated/otype-to-str.h
[  0%] Built target kobj_types_h_target
Scanning dependencies of target syscall_list_h_target
[  1%] Generating misc/generated/syscalls.json
[  1%] Generating include/generated/syscall_dispatch.c, include/generated/syscall_list.h
[  2%] Built target syscall_list_h_target
Scanning dependencies of target syscall_macros_h_target
[  2%] Generating include/generated/syscall_macros.h
[  2%] Built target syscall_macros_h_target
Scanning dependencies of target driver_validation_h_target
[  2%] Generating include/generated/driver-validation.h
[  2%] Built target driver_validation_h_target
Scanning dependencies of target offsets
[  2%] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj
[  3%] Linking C static library liboffsets.a
[  3%] Built target offsets
Scanning dependencies of target offsets_h
[  3%] Generating include/generated/offsets.h
[  3%] Built target offsets_h
Scanning dependencies of target app
[  3%] Building C object CMakeFiles/app.dir/src/echo-server.c.obj
[  4%] Building C object CMakeFiles/app.dir/src/udp.c.obj
[  4%] Building C object CMakeFiles/app.dir/src/tcp.c.obj
[  5%] Linking C static library libapp.a
[  5%] Built target app
Scanning dependencies of target zephyr
[  6%] Building C object zephyr/CMakeFiles/zephyr.dir/arch/common/isr_tables.c.obj
[  7%] Building C object zephyr/CMakeFiles/zephyr.dir/lib/thread_entry.c.obj
[  7%] Building C object zephyr/CMakeFiles/zephyr.dir/lib/crc/crc32_sw.c.obj
[  8%] Building C object zephyr/CMakeFiles/zephyr.dir/lib/crc/crc16_sw.c.obj
[  8%] Building C object zephyr/CMakeFiles/zephyr.dir/lib/crc/crc8_sw.c.obj
[  9%] Building C object zephyr/CMakeFiles/zephyr.dir/lib/mempool/mempool.c.obj
[  9%] Building C object zephyr/CMakeFiles/zephyr.dir/lib/rbtree/rb.c.obj
[ 10%] Building C object zephyr/CMakeFiles/zephyr.dir/misc/printk.c.obj
[ 11%] Building C object zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj
[ 11%] Building C object zephyr/CMakeFiles/zephyr.dir/soc/arm/nordic_nrf/nrf52/power.c.obj
[ 12%] Building C object zephyr/CMakeFiles/zephyr.dir/soc/arm/nordic_nrf/nrf52/soc.c.obj
[ 12%] Building C object zephyr/CMakeFiles/zephyr.dir/soc/arm/nordic_nrf/nrf52/mpu_regions.c.obj
[ 13%] Building C object zephyr/CMakeFiles/zephyr.dir/ext/hal/nordic/nrfx/mdk/system_nrf52840.c.obj
[ 13%] Building C object zephyr/CMakeFiles/zephyr.dir/ext/hal/nordic/nrfx_glue.c.obj
[ 14%] Building C object zephyr/CMakeFiles/zephyr.dir/ext/hal/nordic/nrfx/drivers/src/nrfx_systick.c.obj
[ 15%] Building C object zephyr/CMakeFiles/zephyr.dir/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c.obj

In file included from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/nrfx.h:37:0,
                 from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:32:
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:161:5: error: expected declaration specifiers or ‘...’ before ‘(’ token
     ((NRF_USBD_EPIN_CHECK(ep) ? NRFX_USBD_EPIN_BITPOS_0 : NRFX_USBD_EPOUT_BITPOS_0) \
     ^
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/./nrfx_glue.h:65:23: note: in definition of macro ‘NRFX_STATIC_ASSERT’
         static_assert(expression, "assertion failed")
                       ^~~~~~~~~~
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:185:20: note: in expansion of macro ‘NRFX_USBD_EP_BITPOS’
 NRFX_STATIC_ASSERT(NRFX_USBD_EP_BITPOS(NRFX_USBD_EPIN1)  == USBD_EPDATASTATUS_EPIN1_Pos );
                    ^~~~~~~~~~~~~~~~~~~

... more similar errors...

In file included from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/nrfx.h:37:0,
                 from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:32:
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c: In function ‘usbd_dmareq_process’:
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:1397:50: warning: passing argument 1 of ‘atomic_and’ from incompatible pointer type [-Wincompatible-pointer-types]
                     (void)(NRFX_ATOMIC_FETCH_AND(&m_ep_dma_waiting, ~(1U << pos)));
                                                  ^
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/./nrfx_glue.h:186:58: note: in definition of macro ‘NRFX_ATOMIC_FETCH_AND’
 #define NRFX_ATOMIC_FETCH_AND(p_data, value)  atomic_and(p_data, value)
                                                          ^~~~~~
In file included from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/include/kernel_includes.h:21:0,
                 from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/include/kernel.h:17,
                 from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/./nrfx_glue.h:139,
                 from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/nrfx.h:37,
                 from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:32:
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/include/atomic.h:248:28: note: expected ‘atomic_t * {aka int *}’ but argument is of type ‘uint32_t * {aka long unsigned int *}’
 static inline atomic_val_t atomic_and(atomic_t *target, atomic_val_t value)
                            ^~~~~~~~~~
zephyr/CMakeFiles/zephyr.dir/build.make:257: recipe for target 'zephyr/CMakeFiles/zephyr.dir/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c.obj' failed

... more similar errors...

I know echo_server does not require newlib; but my app may.  This is the same behavior I see in my project.
Thought focusing on a sample project would help keep things a bit clearer.

Cheers,
Chuck McP


Re: usb device network on nrf52840 platform

Puzdrowski, Andrzej
 

Hi

 

I’m unable to reproduce this problem – I mean that I did not encounter problem compiling usbd along with newlibc.

Can you point prj.conf you used, or even the project?

 

From: devel@... [mailto:devel@...] On Behalf Of cpmcparland@...
Sent: Tuesday, November 06, 2018 12:41 AM
To: devel@...
Subject: Re: [Zephyr-devel] usb device network on nrf52840 platform

 

Well, as is usually the case, as soon as I'm convinced I'm stuck and send off a note, I try something else and make a bit
of progress......sigh.  The new project I was trying to integrate with an ecm usb network device interface had the following in prj.conf:

CONFIG_NEWLIB_LIBC=y

As soon as I removed that line, nrfx_usbd.c compiled - as did everything else.  The requirement for newlib may have been historical
and possibly irrelevant now.  I was doing some testing with a 3rd party source code package.  But, I don't know if this constitutes an
issue with the newlib code in the present distribution (1_13_99).  Can't say that my code is now functional, but the bizarre compiler behavior has disappeared. 
So, I think an interaction with the current newlib code is the cause of my initial problem.

Any comments on this are appreciated.  I may need newlib for compatibility reasons later on....would like to understand what's going on
here.

Regards,
Chuck McP


Re: usb device network on nrf52840 platform

cpmcparland@...
 

Well, as is usually the case, as soon as I'm convinced I'm stuck and send off a note, I try something else and make a bit
of progress......sigh.  The new project I was trying to integrate with an ecm usb network device interface had the following in prj.conf:

CONFIG_NEWLIB_LIBC=y

As soon as I removed that line, nrfx_usbd.c compiled - as did everything else.  The requirement for newlib may have been historical
and possibly irrelevant now.  I was doing some testing with a 3rd party source code package.  But, I don't know if this constitutes an
issue with the newlib code in the present distribution (1_13_99).  Can't say that my code is now functional, but the bizarre compiler behavior has disappeared. 
So, I think an interaction with the current newlib code is the cause of my initial problem.

Any comments on this are appreciated.  I may need newlib for compatibility reasons later on....would like to understand what's going on
here.

Regards,
Chuck McP


usb device network on nrf52840 platform

cpmcparland@...
 

Has anyone had any luck adding usb device networking to a project outside of samples/net/echo_server ?
I have built the above project with -DCONF_FILE="prj.conf overlay-netusb.conf" and it appears to work correctly.
But, when I add the overlay-netusb.conf file to another project - in particular, samples/net/sntp_client, the file nrfx_usbd.c
fails to compile.

The compile problem shows up when compiling nrfx_usbd.c (which compiles fine in the echo_server project).  There are
a number of complaints; but I suspect they have the same root cause - undiscovered as yet!

In file included from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/nrfx.h:37:0,
                 from /home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:32:
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:161:5: error: expected declaration specifiers or ‘...’ before ‘(’ token
     ((NRF_USBD_EPIN_CHECK(ep) ? NRFX_USBD_EPIN_BITPOS_0 : NRFX_USBD_EPOUT_BITPOS_0) \
     ^
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/./nrfx_glue.h:65:23: note: in definition of macro ‘NRFX_STATIC_ASSERT’
         static_assert(expression, "assertion failed")
                       ^~~~~~~~~~
/home/mcp/ZephyrProjects/zephyr-1_13_99/zephyr/ext/hal/nordic/nrfx/drivers/src/nrfx_usbd.c:185:20: note: in expansion of macro ‘NRFX_USBD_EP_BITPOS’
 NRFX_STATIC_ASSERT(NRFX_USBD_EP_BITPOS(NRFX_USBD_EPIN1)  == USBD_EPDATASTATUS_EPIN1_Pos );
                    ^~~~~~~~~~~~~~~~~~~

From what I can see, macro processor can't find a symbol it needs for evaluation.  I think most of the include files are actually static and not created by cmake.
So, I don't expect any problems there. The .config files generated for both projects are the same viz. networking and the generated dts .h files for both projects are identical.

Has anyone integrated USB device networking into a non sample project.

Thanks,
Chuck McP


Re: Zephyr SDK 0.9.5 Release

Marti Bolivar <marti@...>
 

Thanks!

On Mon, Nov 5, 2018 at 1:07 PM Kumar Gala <kumar.gala@...> wrote:

We don’t need DTC greater than 1.4.6, so Mac & Windows should still be ok. Mostly updated the SDK version to get additional warning checks.

- k

On Nov 5, 2018, at 11:59 AM, Nashif, Anas <anas.nashif@...> wrote:

Re DTC, I will Kumar and Carles answer.
Re OpenOCD: The Zephyr SDK was always Linux only. For Mac/Windows we currently have no solution beside the documentation.

Anas

-----Original Message-----
From: Marti Bolivar [mailto:marti@...]
Sent: Monday, November 5, 2018 12:32 PM
To: Nashif, Anas <anas.nashif@...>
Cc: devel@...; announce@...
Subject: Re: [Zephyr-devel] Zephyr SDK 0.9.5 Release

Hi Anas,

On Mon, Nov 5, 2018 at 8:21 AM Nashif, Anas <anas.nashif@...> wrote:

Hi,

As announced a few weeks ago, we have been working on a new version of the SDK with updates mostly to the host tools.

This release of the SDK has the following changes as compared with 0.9.3:



· New QEMU release (based on 3.0.0+git 19b599f7664b2ebfd0f405fb79c14dd241557452)

· Qemu installation now has all needed ROMs and BIOS files to support connecting Ethernet drivers such as the Intel e1000.

· New OpenOCD based master with Zephyr related changes (commit: 05e0d633)

· New DTC version 1.4.7+git (commit 2e930b7f8f6421638869a04b00297034c42e1a82)

· Upgrade arc binutils to 2018.03-rc2



The above changes and especially the Qemu related items require that you move to the new SDK ASAP, earlier version will not work with the master tree.

How are Windows and Mac users supposed to update DTC?

- macOS via HomeBrew seems to be on 1.4.7 exactly, and you mention commit 2e930b7, which is ahead of that tag in git://git.kernel.org/pub/scm/utils/dtc/dtc.git
- Windows via chocolatey looks like it's on some v1.4.7 commit that's not in the upstream tree (dtc --version shows "1.4.7-g79c2a3d9-dirty"
on my Windows machine)

Similar questions for openocd; do macOS and Windows users need to build their own? I looked at the openocd commit history around that time and there seem to be some generic RTOS support patches as well as nRF related patches, so I'm curious what windows/mac users are missing out on.

Thanks,
Marti



Re: Zephyr SDK 0.9.5 Release

Kumar Gala
 

We don’t need DTC greater than 1.4.6, so Mac & Windows should still be ok. Mostly updated the SDK version to get additional warning checks.

- k

On Nov 5, 2018, at 11:59 AM, Nashif, Anas <anas.nashif@...> wrote:

Re DTC, I will Kumar and Carles answer.
Re OpenOCD: The Zephyr SDK was always Linux only. For Mac/Windows we currently have no solution beside the documentation.

Anas

-----Original Message-----
From: Marti Bolivar [mailto:marti@...]
Sent: Monday, November 5, 2018 12:32 PM
To: Nashif, Anas <anas.nashif@...>
Cc: devel@...; announce@...
Subject: Re: [Zephyr-devel] Zephyr SDK 0.9.5 Release

Hi Anas,

On Mon, Nov 5, 2018 at 8:21 AM Nashif, Anas <anas.nashif@...> wrote:

Hi,

As announced a few weeks ago, we have been working on a new version of the SDK with updates mostly to the host tools.

This release of the SDK has the following changes as compared with 0.9.3:



· New QEMU release (based on 3.0.0+git 19b599f7664b2ebfd0f405fb79c14dd241557452)

· Qemu installation now has all needed ROMs and BIOS files to support connecting Ethernet drivers such as the Intel e1000.

· New OpenOCD based master with Zephyr related changes (commit: 05e0d633)

· New DTC version 1.4.7+git (commit 2e930b7f8f6421638869a04b00297034c42e1a82)

· Upgrade arc binutils to 2018.03-rc2



The above changes and especially the Qemu related items require that you move to the new SDK ASAP, earlier version will not work with the master tree.

How are Windows and Mac users supposed to update DTC?

- macOS via HomeBrew seems to be on 1.4.7 exactly, and you mention commit 2e930b7, which is ahead of that tag in git://git.kernel.org/pub/scm/utils/dtc/dtc.git
- Windows via chocolatey looks like it's on some v1.4.7 commit that's not in the upstream tree (dtc --version shows "1.4.7-g79c2a3d9-dirty"
on my Windows machine)

Similar questions for openocd; do macOS and Windows users need to build their own? I looked at the openocd commit history around that time and there seem to be some generic RTOS support patches as well as nRF related patches, so I'm curious what windows/mac users are missing out on.

Thanks,
Marti



Re: Zephyr SDK 0.9.5 Release

Nashif, Anas
 

Re DTC, I will Kumar and Carles answer.
Re OpenOCD: The Zephyr SDK was always Linux only. For Mac/Windows we currently have no solution beside the documentation.

Anas

-----Original Message-----
From: Marti Bolivar [mailto:marti@...]
Sent: Monday, November 5, 2018 12:32 PM
To: Nashif, Anas <anas.nashif@...>
Cc: devel@...; announce@...
Subject: Re: [Zephyr-devel] Zephyr SDK 0.9.5 Release

Hi Anas,

On Mon, Nov 5, 2018 at 8:21 AM Nashif, Anas <anas.nashif@...> wrote:

Hi,

As announced a few weeks ago, we have been working on a new version of the SDK with updates mostly to the host tools.

This release of the SDK has the following changes as compared with 0.9.3:



· New QEMU release (based on 3.0.0+git 19b599f7664b2ebfd0f405fb79c14dd241557452)

· Qemu installation now has all needed ROMs and BIOS files to support connecting Ethernet drivers such as the Intel e1000.

· New OpenOCD based master with Zephyr related changes (commit: 05e0d633)

· New DTC version 1.4.7+git (commit 2e930b7f8f6421638869a04b00297034c42e1a82)

· Upgrade arc binutils to 2018.03-rc2



The above changes and especially the Qemu related items require that you move to the new SDK ASAP, earlier version will not work with the master tree.

How are Windows and Mac users supposed to update DTC?

- macOS via HomeBrew seems to be on 1.4.7 exactly, and you mention commit 2e930b7, which is ahead of that tag in git://git.kernel.org/pub/scm/utils/dtc/dtc.git
- Windows via chocolatey looks like it's on some v1.4.7 commit that's not in the upstream tree (dtc --version shows "1.4.7-g79c2a3d9-dirty"
on my Windows machine)

Similar questions for openocd; do macOS and Windows users need to build their own? I looked at the openocd commit history around that time and there seem to be some generic RTOS support patches as well as nRF related patches, so I'm curious what windows/mac users are missing out on.

Thanks,
Marti


Re: [Zephyr-announce] [Zephyr-devel] Zephyr SDK 0.9.5 Release

Marti Bolivar <marti@...>
 

Hi Carles,

On Mon, Nov 5, 2018 at 10:46 AM Cufi, Carles <Carles.Cufi@...> wrote:

Hi Martí,

-----Original Message-----
From: announce@...
<announce@...> On Behalf Of Marti Bolivar
Sent: 05 November 2018 18:32
To: Nashif, Anas <anas.nashif@...>
Cc: devel@...; announce@...
Subject: Re: [Zephyr-announce] [Zephyr-devel] Zephyr SDK 0.9.5 Release

Hi Anas,

On Mon, Nov 5, 2018 at 8:21 AM Nashif, Anas <anas.nashif@...>
wrote:

Hi,

As announced a few weeks ago, we have been working on a new version of
the SDK with updates mostly to the host tools.

This release of the SDK has the following changes as compared with
0.9.3:



· New QEMU release (based on 3.0.0+git
19b599f7664b2ebfd0f405fb79c14dd241557452)

· Qemu installation now has all needed ROMs and BIOS files to
support connecting Ethernet drivers such as the Intel e1000.

· New OpenOCD based master with Zephyr related changes (commit:
05e0d633)

· New DTC version 1.4.7+git (commit
2e930b7f8f6421638869a04b00297034c42e1a82)

· Upgrade arc binutils to 2018.03-rc2



The above changes and especially the Qemu related items require that
you move to the new SDK ASAP, earlier version will not work with the
master tree.


How are Windows and Mac users supposed to update DTC?

- macOS via HomeBrew seems to be on 1.4.7 exactly, and you mention
commit 2e930b7, which is ahead of that tag in
git://git.kernel.org/pub/scm/utils/dtc/dtc.git
- Windows via chocolatey looks like it's on some v1.4.7 commit that's
not in the upstream tree (dtc --version shows "1.4.7-g79c2a3d9-dirty"
on my Windows machine)
Windows is on 1.4.7 exactly. I created and updated the package myself 2 weeks ago. The dirty is there because there's a patch to make it work on Windows.
OK, thanks. So the dtc question is the same on Windows as on macOS
(and remains open): what should users do to get this latest version?
Will vanilla 1.4.7 continue to work?

Thanks,
Marti


Carles


Re: [Zephyr-announce] [Zephyr-devel] Zephyr SDK 0.9.5 Release

Carles Cufi
 

Hi Martí,

-----Original Message-----
From: announce@...
<announce@...> On Behalf Of Marti Bolivar
Sent: 05 November 2018 18:32
To: Nashif, Anas <anas.nashif@...>
Cc: devel@...; announce@...
Subject: Re: [Zephyr-announce] [Zephyr-devel] Zephyr SDK 0.9.5 Release

Hi Anas,

On Mon, Nov 5, 2018 at 8:21 AM Nashif, Anas <anas.nashif@...>
wrote:

Hi,

As announced a few weeks ago, we have been working on a new version of
the SDK with updates mostly to the host tools.

This release of the SDK has the following changes as compared with
0.9.3:



· New QEMU release (based on 3.0.0+git
19b599f7664b2ebfd0f405fb79c14dd241557452)

· Qemu installation now has all needed ROMs and BIOS files to
support connecting Ethernet drivers such as the Intel e1000.

· New OpenOCD based master with Zephyr related changes (commit:
05e0d633)

· New DTC version 1.4.7+git (commit
2e930b7f8f6421638869a04b00297034c42e1a82)

· Upgrade arc binutils to 2018.03-rc2



The above changes and especially the Qemu related items require that
you move to the new SDK ASAP, earlier version will not work with the
master tree.


How are Windows and Mac users supposed to update DTC?

- macOS via HomeBrew seems to be on 1.4.7 exactly, and you mention
commit 2e930b7, which is ahead of that tag in
git://git.kernel.org/pub/scm/utils/dtc/dtc.git
- Windows via chocolatey looks like it's on some v1.4.7 commit that's
not in the upstream tree (dtc --version shows "1.4.7-g79c2a3d9-dirty"
on my Windows machine)
Windows is on 1.4.7 exactly. I created and updated the package myself 2 weeks ago. The dirty is there because there's a patch to make it work on Windows.

Carles


Re: Zephyr SDK 0.9.5 Release

Marti Bolivar <marti@...>
 

Hi Anas,

On Mon, Nov 5, 2018 at 8:21 AM Nashif, Anas <anas.nashif@...> wrote:

Hi,

As announced a few weeks ago, we have been working on a new version of the SDK with updates mostly to the host tools.

This release of the SDK has the following changes as compared with 0.9.3:



· New QEMU release (based on 3.0.0+git 19b599f7664b2ebfd0f405fb79c14dd241557452)

· Qemu installation now has all needed ROMs and BIOS files to support connecting Ethernet drivers such as the Intel e1000.

· New OpenOCD based master with Zephyr related changes (commit: 05e0d633)

· New DTC version 1.4.7+git (commit 2e930b7f8f6421638869a04b00297034c42e1a82)

· Upgrade arc binutils to 2018.03-rc2



The above changes and especially the Qemu related items require that you move to the new SDK ASAP, earlier version will not work with the master tree.

How are Windows and Mac users supposed to update DTC?

- macOS via HomeBrew seems to be on 1.4.7 exactly, and you mention
commit 2e930b7, which is ahead of that tag in
git://git.kernel.org/pub/scm/utils/dtc/dtc.git
- Windows via chocolatey looks like it's on some v1.4.7 commit that's
not in the upstream tree (dtc --version shows "1.4.7-g79c2a3d9-dirty"
on my Windows machine)

Similar questions for openocd; do macOS and Windows users need to
build their own? I looked at the openocd commit history around that
time and there seem to be some generic RTOS support patches as well as
nRF related patches, so I'm curious what windows/mac users are missing
out on.

Thanks,
Marti


Zephyr SDK 0.9.5 Release

Nashif, Anas
 

Hi,

As announced a few weeks ago, we have been working on a new version of the SDK with updates mostly to the host tools.

This release of the SDK has the following changes as compared with 0.9.3:

 

·       New QEMU release (based on 3.0.0+git 19b599f7664b2ebfd0f405fb79c14dd241557452)

·       Qemu installation now has all needed ROMs and BIOS files to support connecting Ethernet drivers such as the Intel e1000.

·       New OpenOCD based master with Zephyr related changes (commit: 05e0d633)

·       New DTC version 1.4.7+git (commit 2e930b7f8f6421638869a04b00297034c42e1a82)

·       Upgrade arc binutils to 2018.03-rc2

 

The above changes and especially the Qemu related items require that you move to the new SDK ASAP, earlier version will not work with the master tree. In Zephyr, we have made the following changes based on the new SDK:

 

·       RISCV32 Qemu is now using a different machine type. Qemu-riscv32 is now an alias to the hifive1 board which can be run in Qemu as well.

·       NIOS2 Qemu is now using a different UART driver

·       ARM Qemu is now supported by two machine types:

o   mps2_an385: This one will be the default target for sanitycheck and will be used for testing kernel features. This machine type does have MPU support and will enable userspace testing on ARM

o   lm3s6965evb: This is the machine type we have now, we will keep it for compatibility and testing some networking and Bluetooth related features. It might be obsoleted in favor of the above in the future.

 

CI will be updated with the new SDK and sanitycheck will require the new SDK to pass, meaning that if you run sanitycheck locally you will need this SDK. We now made this version required for building Zephyr.

 

 

The SDK can be downloaded from here:

 

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.5

 

Previous release (0.9.4) has more change description:

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.4

 

 

Direct link to the SDK binary:

 

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/download/0.9.5/zephyr-sdk-0.9.5-setup.run

 

Note: All of the changes above are in https://github.com/zephyrproject-rtos/zephyr/pull/10136.

 

If you have any questions or have any issues with the new SDK, please lets us know or file a bug.

 

Regards,

Anas

 

 

 

 


Re: ARP request with 0.0.0.0 source ip

"K.I.R.A.
 

Add erhernet_init in init_func of your device. ARP table will be initialized.
Resolved.

---Original---
From: "魏学波"<38900484@...>
Date: Sat, Nov 3, 2018 11:09 AM
To: "devel"<devel@...>;
Subject: ARP request with 0.0.0.0 source ip

Hi Community guys,

I am using Ethernet device to do communication.
There's a confusion.
When sending a ARP request to find other device, Ethernet stack always fills source ip address with 0.0.0.0.
I'm not sure if it's a problem. As of now, after DHCP, communication is blocked.

Have you met this case?

Best Regards,
Bub Wei


Re: #nrf52840 #ble unstable connection #nrf52840 #ble

Randy Chou <rchou3@...>
 

Hi Vinayak,
I enable HCI_CORE_DEBUG to got some logs in the link
1. UART log. 
2. air log.

Thanks,
Randy


Re: [Zephyr-users] BT840F EV mesh without crystal

Venkat Rao Vallapaneni <vallapaneni@...>
 

Hi Vinayak,

Thanks. With this PR, it works fine.

Rgds,
Venkat.

On 02/11/18 7:45 PM, Chettimada, Vinayak Kariappa wrote:

FYI: https://github.com/zephyrproject-rtos/zephyr/pull/11038

I have discovered a regression related to RCOSC non-blocking startup, please try the PR and comment as necessary in the PR.

- Vinayak

-----Original Message-----
From: <users@...> on behalf of Venkat Rao Vallapaneni <vallapaneni@...>
Date: Thursday, 25 October 2018 at 4:14 PM
To: "users@..." <users@...>
    


ARP request with 0.0.0.0 source ip

"K.I.R.A.
 

Hi Community guys,

I am using Ethernet device to do communication.
There's a confusion.
When sending a ARP request to find other device, Ethernet stack always fills source ip address with 0.0.0.0. 
I'm not sure if it's a problem. As of now, after DHCP, communication is blocked. 

Have you met this case?

Best Regards,
Bub Wei


Re: Using BLE IPSP with a Smartphone or Tablet as Host

Michael Scott
 

Hi Häring,

On 11/2/18 2:02 PM, Cufi, Carles wrote:

Hi Häring,

 

I believe that neither Android nor iOS support IPSP, so this might not be possible at all.

That said I’ve copied a couple of people to this thread who might have more information.

One issue that I can think of: several bluetooth/6lowpan crash bugs were submitted for the 4.12 kernel.   For testing you could backport them, but to gain generic support across mass devices they would need to be running a fairly new-ish kernel.

- Mike


 

Regards,

 

Carles

 

From: <devel@...> on behalf of "Häring Benjamin (haej)" <haej@...>
Date: Friday, 2 November 2018 at 14:27
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] Using BLE IPSP with a Smartphone or Tablet as Host

 

Hello everyone

 

I would like to wirelessly connect some sensor nodes with IPv6 to a smartphone or tablet. I plan to use 6LoWPAN over BLE with the help of IPSP. I have already successfully put the IPSP sample project into operation and tested it. This is basically what I tried to accomplish. Now I want to replace the Linux host with a smartphone or tablet. For this procedure, I did some research on the internet and found this post in the Nordic Forum:

https://devzone.nordicsemi.com/f/nordic-q-a/25337/6lowpan-with-android-ios-mobile-devices

 

According to this thread, it is not possible to do this with an iOS or Android mobile device. However, this post is already older than 1 year. Nevertheless, I cannot find any further information on this topic.

 

Has anyone tried or implemented anything similar before? Does anyone have more information on this?

 

Regards

Benjamin

-- 
Michael Scott
Embedded Software Engineer at Foundries.io
"microPlatforms™ for Connected Products"
E: mike@...
W: https://www.foundries.io


Re: Using BLE IPSP with a Smartphone or Tablet as Host

Carles Cufi
 

Hi Häring,

 

I believe that neither Android nor iOS support IPSP, so this might not be possible at all.

That said I’ve copied a couple of people to this thread who might have more information.

 

Regards,

 

Carles

 

From: <devel@...> on behalf of "Häring Benjamin (haej)" <haej@...>
Date: Friday, 2 November 2018 at 14:27
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] Using BLE IPSP with a Smartphone or Tablet as Host

 

Hello everyone

 

I would like to wirelessly connect some sensor nodes with IPv6 to a smartphone or tablet. I plan to use 6LoWPAN over BLE with the help of IPSP. I have already successfully put the IPSP sample project into operation and tested it. This is basically what I tried to accomplish. Now I want to replace the Linux host with a smartphone or tablet. For this procedure, I did some research on the internet and found this post in the Nordic Forum:

https://devzone.nordicsemi.com/f/nordic-q-a/25337/6lowpan-with-android-ios-mobile-devices

 

According to this thread, it is not possible to do this with an iOS or Android mobile device. However, this post is already older than 1 year. Nevertheless, I cannot find any further information on this topic.

 

Has anyone tried or implemented anything similar before? Does anyone have more information on this?

 

Regards

Benjamin


Re: Highlights from the TSC meeting during ELCE

Nashif, Anas
 

Rationale:

-          Slack offers the project more control (for example fighting spam)

-          Very good Integration with GitHub and other platforms we use (Shippable). We are trying a few apps that would make it easier for us to keep control of the number of PRs and almost replaces the need to receiving emails from GH

-          Feature-rich: We are a software project, not being able to share code snippets in a clean way is a major issue on IRC.

-          Offers permanent connection to everybody: Not everyone can afford a permanent connect to follow discussions that happened while they are asleep. Slack gives developer a way to keep up with discussions and conversations and makes it possible for everyone to connect with each other.

-          Many other Pros, google for slack vs irc, for example: https://www.slant.co/versus/4553/4557/~slack_vs_irc

-          It is 2018 J

 

If you want to try it go to https://tinyurl.com/y8eusuhs. Btw, this workspace has been active for almost 2 years now.

 

The TSC will have the final vote next week.

 

Anas

 

 

From: Perez-Gonzalez, Inaky
Sent: Monday, October 29, 2018 2:21 PM
To: Nashif, Anas <anas.nashif@...>; devel@...
Cc: tsc@...
Subject: RE: Highlights from the TSC meeting during ELCE

 

Thanks for the summary, Anas

 

>> 4.       We are considering a new communication platform to replace IRC. Candidates are Slack and gitter. This has not been decided yet, if you have any feedback, please let us know.

 

I'd like to ask what is the rationale behind IRC replacement, what is trying to be solved?

 

IRC is:

- easy to access for everyone from every platform

- well integrated into everyone's favourite messaging client

- does not depend on a single corporation (looking at you, Slack)

 


Re: [RFC] k_poll_signal name and MISRA

Flavio Ceolin
 

Hi,

Hello,

On Mon, 29 Oct 2018 08:48:46 +0100
"Erwan Gouriou" <erwan.gouriou@...> wrote:

Making different names is good, but then I think one should be able to
identify quickly which is struct and which isn't,
What about k_struct_poll_signal or k_poll_signal_struct ?
Well, that should be simple: a noun is a struct, so k_poll_signal
remains a structure. A subroutine which performs action should contain
a verb. To avoid tautology, it may be k_poll_signal_set(). Or perhaps,
signals are raised? Then k_poll_signal_raise().
Agree, other projects I've seen do this.


That's a basic idea which many projects follow, and which is mostly,
but not consistently, seems to be followed by Zephyr. As many other
things in Zephyr, such conventions would rather be formalized.
Yeah, we need to formalize it.


Flavio, one good way to approach questions like this is to do some
research/analysis and offer 3-4 alternative variants for people to
choose from (or base further alternatives on). Fairly speaking, I didn't
reply earlier in this thread, because I wanted to do such an analysis
myself, but as usual, it's backlogged by other tasks.
Yeah, I came up with something I used to see in EFL. Next time I'll
present more options. To be honest, I just raised this question thinking
that this had already been discussed but not applied.


A variant presented above is just a "low-hanging" one. We could go
further, e.g.

2. Challenge the name "signal", it may be confusing.
3. Challenge the "_poll" infix part of the name, that's again
confusing due to noun/verb ambiguity.

Thanks,
Paul


On Thu, 25 Oct 2018 at 22:07, Flavio Ceolin <flavio.ceolin@...>
wrote:

Hi guys,

MISRA-C rule 5.7 says that a tag name shall be a unique identifier,
also reuse tag names is an undefined behavior recognized in C99
(Section 6.7.2.3).

It happens that we have in Zephyr both a struct and a function
called k_poll_signal (there may be others cases in the project),
the question is, what it is preferable, change the function to
something like, k_pll_signal_signal() or change the struct nam ? In
the latter, what is the suggestion ? Remembering that I'll follow
this pattern if necessary.


Regards,
Flavio Ceolin






--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Regards,
Flavio Ceolin

3441 - 3460 of 8790