Date   

SPI Kconfig.nrfx changes in recent (1.13.99) clone - setting GPIO pins for SPI master now fails.

cpmcparland@...
 

My zephyr app, built on ver 1.13.0 with the following prj.cfg file:

CONFIG_FLOAT=y
CONFIG_FP_SHARING=y
CONFIG_NEWLIB_LIBC=y
CONFIG_HEAP_MEM_POOL_SIZE=16384

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_ASYNC=y
CONFIG_SPI_0_NAME="SPI_0"
CONFIG_SPI_0_OP_MODES=1
CONFIG_SPI_0_IRQ_PRI=0
CONFIG_SPI_NRFX=y
CONFIG_SPI_0_NRF_SPIM=y
CONFIG_SPI_0_NRF_SCK_PIN=28
CONFIG_SPI_0_NRF_MOSI_PIN=29
CONFIG_SPI_0_NRF_MISO_PIN=30
CONFIG_SPI_0_NRF_ORC=0xf

built and ran successfully on a nrf52840_pca10056 board.  I have recently updated to ver 1.13.99 and it no longer
gets through cmake because several symbols are no longer in the Kconfig.nrfx file for the SPI driver.  Namely,
CONFIG_SPI_0_SCK_PIN, _MOSI_PIN, and _MISO_PIN. I need to set these pins to coincide with target hardware,
Also, SPI_0_NAME seems to have disappeared.

Looking more closely at the Kconfig.nrfx files from both clones, the latest version has changed and does not include
symbols to set up these pins.  I guess I could edit the .config file, but that would be overwritten every time I run cmake.

Maybe I'm just out of phase here.  Is there a nrf spim driver update in progress?  Any help would be appreciated.

Thanks,
Chuck


Re: bt_le_scan of node in Mesh network

Martin <ma@...>
 

Hi!
Thanks, this looks exactly like what I was looking for. Even seems to
be easier than the NRF52 SDK-approach with the timing API.

Best Regards,
Martin
Am Mo., 15. Okt. 2018 um 08:25 Uhr schrieb <julian.schneider@ledcity.ch>:


Hi Martin,
We needed the same functionality that you are describing.

After some analysis of the BT Mesh subsystem in the Zephryr, we came to the same conclusion as Vinayak. The Mesh system is using the BT 4 features to receive packages itself, i.e. the Mesh subsystem starts scanning with bt_le_scan on initialization and registeres its own callback (bt_mesh_scan_cb in Zephyr/subsys/bluetooth/host/mesh/adv.c). The system does not allow a second (concurrent) call of bt_le_scan.

Hence, the only option is a small adaptation of the Zephyr source.
The Mesh scan callback only recognises Mesh specific scan packages and ignores the rest. Introducing an extra callback enabled us to receive all scan packages that are ignored by Mesh (see code snipped below).

Best,
Julian

Here is a code snippet of our adaptations of adv.c starting on line 253:
///////////////////changes here
//callback function pointer to be set from project code
void (*bt_mesh_scan_unprocressed_nonconn_ad_cb)(const bt_addr_le_t *addr, s8_t rssi,
struct net_buf_simple *buf, u8_t type_from_buf, u8_t data_len) = NULL;
/////////////////

static void bt_mesh_scan_cb(const bt_addr_le_t *addr, s8_t rssi,
u8_t adv_type, struct net_buf_simple *buf)
{
if (adv_type != BT_LE_ADV_NONCONN_IND) {
return;
}

BT_DBG("len %u: %s", buf->len, bt_hex(buf->data, buf->len));

while (buf->len > 1) {
struct net_buf_simple_state state;
u8_t len, type;

len = net_buf_simple_pull_u8(buf);
/* Check for early termination */
if (len == 0) {
return;
}

if (len > buf->len) {
BT_WARN("AD malformed");
return;
}

net_buf_simple_save(buf, &state);

type = net_buf_simple_pull_u8(buf);

buf->len = len - 1;

switch (type) {
case BT_DATA_MESH_MESSAGE:
bt_mesh_net_recv(buf, rssi, BT_MESH_NET_IF_ADV);
break;
#if defined(CONFIG_BT_MESH_PB_ADV)
case BT_DATA_MESH_PROV:
bt_mesh_pb_adv_recv(buf);
break;
#endif
case BT_DATA_MESH_BEACON:
bt_mesh_beacon_recv(buf);
break;
///////////////////changes here
default:
if (bt_mesh_scan_unprocressed_nonconn_ad_cb != NULL)
bt_mesh_scan_unprocressed_nonconn_ad_cb(addr,rssi,buf,type,len-1);
break;
/////////////////
}

net_buf_simple_restore(buf, &state);
net_buf_simple_pull(buf, len);
}
}


Re: Slip TCP connection between linux host and nrf52840

Andrei Emeltchenko <andrei.emeltchenko@...>
 

Hi,

On Thu, Oct 18, 2018 at 11:22:10AM -0700, cpmcparland@rtisys.org wrote:
All,

Thanks for the suggestions and sharing results.  I think I'll go with USB
network device solution.  I've tried the sample "samples/net/echo_server"
and, with the addition of the overlay-netusb(?) to the prj.config, it came
up and worked.  The current docs have the 3 additional linux side commands
to add the enumerated net device to the linux ip stack, bring it up and,
lastly, provide a route. 
Some Linux distros might do most of work configuring interfaces for you.

If you enable IPv4 autoconfiguration and LLMNR or mDNS you should be able
to access zephyr with short name "zephyr" or "zephyr.local".
We need to document this though...

Best regards
Andrei Emeltchenko

Adding the overlay config file in the cmake is a
nice trick, but took a bit of digging to find an example. I hope this
solution will be stable...will report on results.  It seems to have fewer
moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble
(hopefully bluetooth 5) net into a linux platform.  Initially tried
setting up a HCI connection to zephyr hci firmware running in the ble
dongle; but, couldn't get the HCI interface to come up on the linux side.
While wading through the btattach and config docs, I came across the usb
network device option.  Fortunately, I have sufficient resources on the
dongle to run a dual stack (ip/ble) and add an app to bring the stream
into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's
my plan at the moment.  But, I am curious about how others are dealing
with this issue....are folks using (or waiting for!) commercial ble/ip
gateways to bridge this gap or is there another solution I'm not aware of
yet?

Cheers,
Chuck


References

Visible links
1. https://lists.zephyrproject.org/g/devel/message/5263
2. mailto:cpmcparland@rtisys.org?subject=Private:%20Re:%20Re%3A%20%5BZephyr-devel%5D%20Slip%20TCP%20connection%20between%20linux%20host%20and%20nrf52840
3. mailto:devel@lists.zephyrproject.org?subject=Re:%20Re%3A%20%5BZephyr-devel%5D%20Slip%20TCP%20connection%20between%20linux%20host%20and%20nrf52840
4. https://lists.zephyrproject.org/mt/27261061/900599
5. https://lists.zephyrproject.org/g/devel/post
6. https://lists.zephyrproject.org/g/devel/editsub/900599
7. mailto:devel+owner@lists.zephyrproject.org
8. https://lists.zephyrproject.org/g/devel/unsub


Zephyr SDK 0.9.4-rc5 available for testing

Nashif, Anas
 

Hi,

A release candidate of the Zephyr SDK is available for general testing. It has the following changes since the 0.9.3 release:

 

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

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

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

 

The release can be found here: https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.4-rc5

 

 

Note:

Qemu for NIOS2 and RISCV are not compatible with current master of Zephyr and require additional changes that are maintained in pull request:

 

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

 

 

Please test that release and let us know if you find any issues.

 

Regards,

Anas

 

 

 


Re: Slip TCP connection between linux host and nrf52840

Paul Sokolovsky
 

Hello,

On Thu, 18 Oct 2018 11:22:10 -0700
cpmcparland@rtisys.org wrote:

All,
[]

ble/ipv6.  At least that's my plan at the moment.  But, I am curious
about how others are dealing with this issue...
I'm sure that someone without imagination would just stream data over
old good serial connection - either in textual form, as a sequence of
lines, or with some simple binary protocol.

From my side, I can only encourage people to play with something more
advanced than that - we need people to try that, report back results,
us fix it as needed. Oftentimes it's indeed a matter of docs
[1] (including common pitfalls and troubleshooting sections). So indeed,
without poking, too little and too slow will happen, so thanks for
trying it!


[1] I for one ate enough dogfood on playing with BLE IPSP support and
tried to provide detailed enough walkthru on setting it up in the
corresponding docs:
https://docs.zephyrproject.org/latest/samples/bluetooth/ipsp/README.html



Cheers,
Chuck
--
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


Re: Slip TCP connection between linux host and nrf52840

cpmcparland@...
 

Marti,

Not rude at all...will look over your web site.  Finding the right fit for a commercial
embedded, mostly software product is a tough problem.  Will be interested to see
where you folks fit in the "app stack".  Will contact foundries.io separately if I have
further product questions.

Cheers,
Chuck


Re: Slip TCP connection between linux host and nrf52840

Marti Bolivar <marti@...>
 

Hi Chuck,

On Thu, Oct 18, 2018 at 12:22 PM <cpmcparland@...> wrote:
All,

Thanks for the suggestions and sharing results.  I think I'll go with USB network device solution.  I've tried the sample "samples/net/echo_server" and, with the addition of the overlay-netusb(?) to the prj.config, it came up and worked.  The current docs have the 3 additional linux side commands to add the enumerated net device to the linux ip stack, bring it up and, lastly, provide a route.  Adding the overlay config file in the cmake is a nice trick, but took a bit of digging to find an example. I hope this solution will be stable...will report on results.  It seems to have fewer moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble (hopefully bluetooth 5) net into a linux platform.  Initially tried setting up a HCI connection to zephyr hci firmware running in the ble dongle; but, couldn't get the HCI interface to come up on the linux side. While wading through the btattach and config docs, I came across the usb network device option.  Fortunately, I have sufficient resources on the dongle to run a dual stack (ip/ble) and add an app to bring the stream into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's my plan at the moment.  But, I am curious about how others are dealing with this issue....are folks using (or waiting for!) commercial ble/ip gateways to bridge this gap or is there another solution I'm not aware of yet?

Since you've asked, I guess it's not rude to note that my company (https://foundries.io/) does have Linux-based BLE/IP gateway software you can take a look at (with support for multiple architectures and boards). They're integrated with Zephyr; we provide detailed instructions in our docs for how to set them up etc. They work with nRF52840 on the Zephyr side, as well as other boards. The product is subscription-based but you get full source access.

Best,
Marti
 

Cheers,
Chuck


Re: Slip TCP connection between linux host and nrf52840

cpmcparland@...
 

All,

Thanks for the suggestions and sharing results.  I think I'll go with USB network device solution.  I've tried the sample "samples/net/echo_server" and, with the addition of the overlay-netusb(?) to the prj.config, it came up and worked.  The current docs have the 3 additional linux side commands to add the enumerated net device to the linux ip stack, bring it up and, lastly, provide a route.  Adding the overlay config file in the cmake is a nice trick, but took a bit of digging to find an example. I hope this solution will be stable...will report on results.  It seems to have fewer moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble (hopefully bluetooth 5) net into a linux platform.  Initially tried setting up a HCI connection to zephyr hci firmware running in the ble dongle; but, couldn't get the HCI interface to come up on the linux side. While wading through the btattach and config docs, I came across the usb network device option.  Fortunately, I have sufficient resources on the dongle to run a dual stack (ip/ble) and add an app to bring the stream into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's my plan at the moment.  But, I am curious about how others are dealing with this issue....are folks using (or waiting for!) commercial ble/ip gateways to bridge this gap or is there another solution I'm not aware of yet?

Cheers,
Chuck


Re: [Question] zephyr file transfer via BLE

Carles Cufi
 

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


[Question] zephyr file transfer via BLE

우승우 <du5102@...>
 

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: Slip TCP connection between linux host and nrf52840

Dominik.Kilian@...
 

Hi Chuck,

I was also trying to get slip network driver running on nRF. I was using it to create secure TLS connection. It was in TAP mode. I disabled logs, so the driver was the only user of UART. Generally connection was really unstable. I don't know if it was fault of software on PC or board side. I give up after few tries of getting it working more stable. Are you also want to use secure TLS connection over SLIP?

Regards,
   Dominik


Re: gPTP and usb network device

cpmcparland@...
 

Jukka,

Thanks for your suggestion.  was not aware that zephyr had sntp.  That may
well be a better solution.  We have two applications with very different time
constraints--none of which are at the ns. level.  One app needs roughly 10 ms.
resolution and a second would like to see something on the order of 50 - 100 usec.

BTW, are there any "standard" solutions for time sync (at any resolution) for BLE or
bluetooth 5?

Cheers,
Chuck


Re: gPTP and usb network device

Jukka Rissanen
 

Hi Chuck,

the gPTP is probably not a proper solution for this kind time sync as
it is normally meant to synchronize two devices with nanosecond
accuracy in industrial ethernet environments. The actual time value is
typically not that important in these TSN solutions, main thing is the
time synchronization between devices.

Have you considered using SNTP to synchronize the time, there is
already SNTP client supported in Zephyr? This has lower resolution but
it should be fine in normal applications.


Cheers,
Jukka

On Tue, 2018-10-16 at 12:09 -0700, cpmcparland@rtisys.org wrote:
I'm setting up a IP link between a debian platform and a bluetooth
usb dongle running
zephyr. usb network device interface appears to work fine with the
zephyr IP stack running in
the dongle. I want the dongle zephyr os to be time sync'd with the
linux system and
am thinking gPTP would be a good way to achieve this.....particularly
because its been
implemented on zephyr. There's a note that zephyr gPTP only works on
boards that
have ethernet hardware links. Am wondering if anyone has tried using
gPTP with
usb networking enabled? Since the usb interface will likely run at
1Mb/s+ between
linux and zephyr (on dongle), I would expect it to behave reasonably
well - at least for
my application's timing requirements. Any experience or thoughts?

Regards,
Chuck McP


Re: #nrf52840 #defines #nrf52840 #defines

Ryan Erickson
 

Hello Matthias,

By default the BL654 DVK does not connect the external 32 kHz clock.  In zephyr, the NRF52840 board files are setup to use the external 32 kHz clock.
You have 2 options:
  1. Follow the instructions in teh BL654 DVK user guide to connect the external 32 kHz clock
  2. Create a custom board file (which you should do anyway) and enable the internal 32 kHz RC oscillator 
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
# CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL is not set
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_500PPM=y

Regards,

Ryan


gPTP and usb network device

cpmcparland@...
 

I'm setting up a IP link between a debian platform and a bluetooth usb dongle running
zephyr.  usb network device interface appears to work fine with the zephyr IP stack running in
the dongle.  I want the dongle zephyr os to be time sync'd with the linux system and
am thinking gPTP would be a good way to achieve this.....particularly because its been
implemented on zephyr.  There's a note that zephyr gPTP only works on boards that
have ethernet hardware links.  Am wondering if anyone has tried using gPTP with
usb networking enabled?  Since the usb interface will likely run at 1Mb/s+ between
linux and zephyr (on dongle), I would expect it to behave reasonably well - at least for
my application's timing requirements.  Any experience or thoughts?

Regards,
Chuck McP


#nrf52840 #defines #nrf52840 #defines

Matthias Schuh <matthias.schuh@...>
 

Hello fellow mailinglist members,

I'm currently trying to get the samples "hci_uart" and "hci_usb" working on a laird654 module / Laird DVK-BL654-1.0 (nrf52480)
Both samples work on the nrf52480DK (pca10056) but refuse to work on the Laird654 module.

Regarding hci_uart I would like to transfer know-how I gained at the apache mynemt-os project: 
I got the respective sample from the apache newt project "blehci" working after configuring the nrf52480 to use the synthesized clock and modify the sleep clock accuracy:
In the newt world this was achieved via setting syscfg=XTAL_32768=0 syscfg=XTAL_32768_SYNTH=1:BLE_XTAL_SETTLE_TIME=0 syscfg=BLE_LL_OUR_SCA=250:BLE_LL_MASTER_SCA=1
I know these settings are newt specific but how could I achieve this for the zephyr samples ? 

Looking forward to your reply.

Best regards


Re: Slip TCP connection between linux host and nrf52840

Serafin Leschke <serafin.leschke@...>
 

Forward to list:

Hi Chuck


I tried this myself (and failed.). There is a separate net-tools repo: https://github.com/zephyrproject-rtos/net-tools


In there you find tunslip6.c which should configure the slip on the host side, but I was not successful in getting the communication to work. (The host did send a packet down the serial line but newer got a response).


So if anybody finds out how to do this, it would be great if it would find it's way into the documentation.


Best regards

Serafin


On 12/10/18 19:39, cpmcparland@... wrote:
Jukka,

Thanks, I was hoping that was the case.  Have found the slip.c code and am looking through it.
Not too many examples for slip and the ones I have seen all point to Qemu.  Any idea or pointers
as to where uart pipe gets created?  I'm guessing its buried somewhere in the Qemu board support
config files. 

Regards,
Chuck McP


Re: nRF5 GPIO stops working after some time

Mieruński, Mieszko <Mieszko.Mierunski@...>
 

Hello,

On nRF52840-DK pin 7 is used as CTS, it can be used freely after HWFC is disabled, for more information please look here

Please check bottom of the board, as there is information on which pins serve specific functions on DK.

 

Best Regards

Mieruński, Mieszko

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Saturday, October 13, 2018 2:36 PM
To: Gavrikov Paul <Paul.Gavrikov@...>; zephyr-devel@...
Cc: Lai Matthias <Matthias.Lai@...>; Głąbek, Andrzej <Andrzej.Glabek@...>; Mieruński, Mieszko <Mieszko.Mierunski@...>
Subject: Re: [Zephyr-devel] nRF5 GPIO stops working after some time

 

+ Andrzej, Mieszko

 

From: <devel@...> on behalf of Gavrikov Paul <Paul.Gavrikov@...>
Date: Friday, 12 October 2018 at 20:28
To: "zephyr-devel@..." <zephyr-devel@...>
Cc: Lai Matthias <Matthias.Lai@...>
Subject: [Zephyr-devel] nRF5 GPIO stops working after some time

 

Hi,

 

I have a very weird problem with my nRF52840-DK and Zephyr v1.13.0. Very simple code:

 

dev = device_get_binding(CONFIG_GPIO_P0_DEV_NAME);

 

            gpio_pin_configure(dev, 7, GPIO_PIN_ENABLE  | GPIO_DIR_OUT);

            gpio_pin_configure(dev, 3, GPIO_PIN_ENABLE  | GPIO_DIR_OUT);

 

            while(1) {

                        gpio_pin_write(dev, 3, false);

                        gpio_pin_write(dev, 7, false);

                        k_sleep(10);

                        gpio_pin_write(dev, 3, true);

                        gpio_pin_write(dev, 7, true);

                        k_sleep(10);

            }

 

So all I do is toggle Pin 3 and 7 every 10 msecs. Now if I let this code run it will work, but after some seconds Pin 7 will stop toggling, while Pin 3 keeps running. And after that point Pin 7 will never turn on again (not even if I press Reset). However if I disconnect and then reconnect power, it will start working for some seconds again.

It appears as if there as some Pins that work all the time and some Pins just stop working after some seconds. What is wrong?

 

 

Best,

Paul

 


Re: bt_le_scan of node in Mesh network

Julian, LEDCity.ch
 

Hi Martin,
We needed the same functionality that you are describing.

After some analysis of the BT Mesh subsystem in the Zephryr, we came to the same conclusion as Vinayak. The Mesh system is using the BT 4 features to receive packages itself, i.e. the Mesh subsystem starts scanning with bt_le_scan on initialization and registeres its own callback (bt_mesh_scan_cb in Zephyr/subsys/bluetooth/host/mesh/adv.c). The system does not allow a second (concurrent) call of bt_le_scan.

Hence, the only option is a small adaptation of  the Zephyr source.
The Mesh scan callback only recognises Mesh specific scan packages and ignores the rest. Introducing an extra callback enabled us to receive all scan packages that are ignored by Mesh (see code snipped below).

Best,
Julian

Here is a code snippet of our adaptations of adv.c starting on line 253:
///////////////////changes here
//callback function pointer to be set from project code
void (*bt_mesh_scan_unprocressed_nonconn_ad_cb)(const bt_addr_le_t *addr, s8_t rssi,
        struct net_buf_simple *buf, u8_t type_from_buf, u8_t data_len) = NULL;
/////////////////

static void bt_mesh_scan_cb(const bt_addr_le_t *addr, s8_t rssi,
                u8_t adv_type, struct net_buf_simple *buf)
{
    if (adv_type != BT_LE_ADV_NONCONN_IND) {
        return;
    }

    BT_DBG("len %u: %s", buf->len, bt_hex(buf->data, buf->len));

    while (buf->len > 1) {
        struct net_buf_simple_state state;
        u8_t len, type;

        len = net_buf_simple_pull_u8(buf);
        /* Check for early termination */
        if (len == 0) {
            return;
        }

        if (len > buf->len) {
            BT_WARN("AD malformed");
            return;
        }

        net_buf_simple_save(buf, &state);

        type = net_buf_simple_pull_u8(buf);

        buf->len = len - 1;

        switch (type) {
        case BT_DATA_MESH_MESSAGE:
            bt_mesh_net_recv(buf, rssi, BT_MESH_NET_IF_ADV);
            break;
#if defined(CONFIG_BT_MESH_PB_ADV)
        case BT_DATA_MESH_PROV:
            bt_mesh_pb_adv_recv(buf);
            break;
#endif
        case BT_DATA_MESH_BEACON:
            bt_mesh_beacon_recv(buf);
            break;
///////////////////changes here
        default:
            if (bt_mesh_scan_unprocressed_nonconn_ad_cb != NULL)       
                bt_mesh_scan_unprocressed_nonconn_ad_cb(addr,rssi,buf,type,len-1);
            break;
/////////////////
        }

        net_buf_simple_restore(buf, &state);
        net_buf_simple_pull(buf, len);
    }
}


Re: Slip TCP connection between linux host and nrf52840

Andrei Emeltchenko <andrei.emeltchenko@...>
 

On Fri, Oct 12, 2018 at 10:35:23AM -0700, cpmcparland@rtisys.org wrote:
Andrei,

THanks for the note....unfortuately, the USB interface is peripheral only.
Your device can be USB Ethernet dongle itself, no need to connect extra
stuff.

Best regards
Andrei Emeltchenko

2921 - 2940 of 8189