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

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,

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

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

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

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

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

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

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

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 

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

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

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);
    }
}

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