Date   
Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Immo Birnbaum
 

Hi Jukka,

thanks for the info, I looked at the YAML files of other platforms and eventually came across the "-netif:eth" switch. Once I had that integrated, I had a bit of a fight against the QEMU system configuration in conjunction with the UART pipe and SLIP drivers used by the networking tests, I eventually came up with a configuration in which both the UART console and the UART pipe driver work after fixing a minor bug in one of the instantiation macros of the Xilinx UART driver. Also, having the Ethernet controller driver perform polling reads/writes to a PHY that is non-existent in QEMU doesn't help the system booting. Fortunately, I had the PHY initialization as an optional switch in the driver's Kconfig file right from the start.

I don't have the exact number of tests performed available right now, but after all those changes, running sanitycheck for the tests/net branch resulted in a significant number of test cases being executed, of which only 2 or 3 failed - the actual tests all passed, but the test cases failed due to assertions. Obviously, more interfaces than expected are being created, in particular for test cases involving VLANs. I'll leave that branch as it is for now, as I'm currently doing my research regarding the two test cases in tests/kernel that currently fail.

Best regards,
Immo

Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Jukka Rissanen
 

Hi Immo,

for networking tests to run, I think you need to say

- netif:eth

in board yaml file (instead of just "- net")


Cheers,
Jukka

On Wed, 2020-02-26 at 04:54 -0800, Immo Birnbaum wrote:
Hi all,

here's my first update on the topic of the Zynq-7000 port, this is
the progress so far:

- Set up a fresh development VM which now uses the Zephyr SDK, which
works fine for the Cortex-A9.
- Forked the Zephyr repository and set up a feature branch, which can
be found here:
https://github.com/ibirnbaum/zephyr/tree/armv7_cortex_a
- Merged all of the changes/additions described above into the
current code base.
- Updated the AXI GPIO driver to match the GPIO driver API which was
heavily modified in the meantime.
- Kicked out my own GIC PL-390 interrupt controller driver and
switched over to Stephanos Ionannidis' GICv1 implementation,
including updated IRQ descriptors in the device tree files.
- I looked into the testsuite and ran tests on the QEMU Cortex-A9
target, plus a hand full of test cases on the actual hardware (as
downloading the binary to the board is still a manual process using
the Lauterbach TRACE software). The results don't look too bad, for
example, these are the results of the 'kernel' test suite:
* 86 test configurations selected, 8 configurations discarded due to
filters
* 24 tests skipped (e.g. SMP/ARMv8/userspace related test cases)
* Out of the 62 remaining test cases, 60 pass. One
(kernel.timer.tickless) fails to build due to an unresolved symbol
(z_clock_uptime). This is odd for two reasons: one, all other
'tickless'-related tests are skipped and two, the Local APIC timer
driver seems to be the only timer driver implementing this function.
To me, this looks more like a testsuite configuration issue? The
other failure is the arch.interrupt test case, which actually runs
but fails due to an assertion regarding the expected state of an IRQ
to be tested. This is due to the target IRQ selection logic only
being implemented for Cortex-M when it comes to the ARM architecture.
The following testsuites pass all test cases on the QEMU target which
aren't filtered out for whatever reason (I didn't blacklist anything
myself):
- lib
- misc
- portability
- posix
- shell
- subsys
- ztest
I'll have to look into the details as to why in some cases, more test
cases are filtered out than executed. In some cases, e.g. ARMv8-
specific stuff, it's pretty obvious, but in others I'm suspecting
that I ought to whitelist testcases or subsystems for testing, likely
in the target's YAML files? For example, despite having full Ethernet
support, the 'net' testsuite in its current state does pretty much
nothing.

I'll keep you updated and I'll look into the ongoing discussions and
the mechanics of pull requests, I could start simple, as for example,
the Xilinx TTC timer driver had a faulty prescaler calculation
routine. As this source file is already in the main repository, this
might be a good exercise for a pull request. Until then, I'd
appreciate any feedback if anyone feels like experimenting with my
fork of the repository.

Best regards,
Immo

Upcoming Event: Zephyr Project: Dev Meeting - Thu, 02/27/2020 8:00am-9:00am, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 27 February 2020, 8:00am to 9:00am, (GMT-08:00) America/Los Angeles

Where:https://zoom.us/j/993312203

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description: Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Stephanos Ioannidis
 

Hi Immo,

 

Thanks for looking into this.

 

For the time being, I believe focusing on the following issues would help in getting these changes upstream-ed:

 

  1. Getting all applicable tests to pass
    1. At least, all applicable `kernel` tests must pass.
    2. Some tests (e.g. `benchmark` and `interrupt`) may require additional work to pass (see #22669 and #22670).
  2. Cleaning up commits (all the usual stuff)
    1. Breaking changes into more manageable chunks/commits
    2. Squashing commits that should really be one commit

 

The following are some ongoing issues that could be noteworthy:

 

  • Refactor ARM interrupt system (Cortex-A & Cortex-R) (#22718)
  • Implement benchmark tests for Cortex-R and Cortex-A (#22669)
  • Implement GIC-based ARM interrupt tests (#22670)
  • arch: arm: aarch32: Allow selecting compiler instruction set (#22741)
  • AArch64 / Cortex-A port improvements / TODO (#22411)
  • soc: arm64: Add support for Xilinx ZynqMP APU (#22418)

 

There is also the #arch-arm channel on the Slack where we discuss ARM arch development topics.

 

Regards,

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of Immo Birnbaum via Lists.Zephyrproject.Org
Sent: Wednesday, February 26, 2020 9:55 PM
To: devel@...
Cc: devel@...
Subject: Re: [Zephyr-devel] ARMv7 Cortex-A port for Xilinx Zynq7000

 

Hi all,

here's my first update on the topic of the Zynq-7000 port, this is the progress so far:

- Set up a fresh development VM which now uses the Zephyr SDK, which works fine for the Cortex-A9.
- Forked the Zephyr repository and set up a feature branch, which can be found here: https://github.com/ibirnbaum/zephyr/tree/armv7_cortex_a
- Merged all of the changes/additions described above into the current code base.
- Updated the AXI GPIO driver to match the GPIO driver API which was heavily modified in the meantime.
- Kicked out my own GIC PL-390 interrupt controller driver and switched over to Stephanos Ionannidis' GICv1 implementation, including updated IRQ descriptors in the device tree files.
- I looked into the testsuite and ran tests on the QEMU Cortex-A9 target, plus a hand full of test cases on the actual hardware (as downloading the binary to the board is still a manual process using the Lauterbach TRACE software). The results don't look too bad, for example, these are the results of the 'kernel' test suite:
* 86 test configurations selected, 8 configurations discarded due to filters
* 24 tests skipped (e.g. SMP/ARMv8/userspace related test cases)
* Out of the 62 remaining test cases, 60 pass. One (kernel.timer.tickless) fails to build due to an unresolved symbol (z_clock_uptime). This is odd for two reasons: one, all other 'tickless'-related tests are skipped and two, the Local APIC timer driver seems to be the only timer driver implementing this function. To me, this looks more like a testsuite configuration issue? The other failure is the arch.interrupt test case, which actually runs but fails due to an assertion regarding the expected state of an IRQ to be tested. This is due to the target IRQ selection logic only being implemented for Cortex-M when it comes to the ARM architecture.
The following testsuites pass all test cases on the QEMU target which aren't filtered out for whatever reason (I didn't blacklist anything myself):
- lib
- misc
- portability
- posix
- shell
- subsys
- ztest
I'll have to look into the details as to why in some cases, more test cases are filtered out than executed. In some cases, e.g. ARMv8-specific stuff, it's pretty obvious, but in others I'm suspecting that I ought to whitelist testcases or subsystems for testing, likely in the target's YAML files? For example, despite having full Ethernet support, the 'net' testsuite in its current state does pretty much nothing.

I'll keep you updated and I'll look into the ongoing discussions and the mechanics of pull requests, I could start simple, as for example, the Xilinx TTC timer driver had a faulty prescaler calculation routine. As this source file is already in the main repository, this might be a good exercise for a pull request. Until then, I'd appreciate any feedback if anyone feels like experimenting with my fork of the repository.

Best regards,
Immo

Re: ARMv7 Cortex-A port for Xilinx Zynq7000

Immo Birnbaum
 

Hi all,

here's my first update on the topic of the Zynq-7000 port, this is the progress so far:

- Set up a fresh development VM which now uses the Zephyr SDK, which works fine for the Cortex-A9.
- Forked the Zephyr repository and set up a feature branch, which can be found here: https://github.com/ibirnbaum/zephyr/tree/armv7_cortex_a
- Merged all of the changes/additions described above into the current code base.
- Updated the AXI GPIO driver to match the GPIO driver API which was heavily modified in the meantime.
- Kicked out my own GIC PL-390 interrupt controller driver and switched over to Stephanos Ionannidis' GICv1 implementation, including updated IRQ descriptors in the device tree files.
- I looked into the testsuite and ran tests on the QEMU Cortex-A9 target, plus a hand full of test cases on the actual hardware (as downloading the binary to the board is still a manual process using the Lauterbach TRACE software). The results don't look too bad, for example, these are the results of the 'kernel' test suite:
* 86 test configurations selected, 8 configurations discarded due to filters
* 24 tests skipped (e.g. SMP/ARMv8/userspace related test cases)
* Out of the 62 remaining test cases, 60 pass. One (kernel.timer.tickless) fails to build due to an unresolved symbol (z_clock_uptime). This is odd for two reasons: one, all other 'tickless'-related tests are skipped and two, the Local APIC timer driver seems to be the only timer driver implementing this function. To me, this looks more like a testsuite configuration issue? The other failure is the arch.interrupt test case, which actually runs but fails due to an assertion regarding the expected state of an IRQ to be tested. This is due to the target IRQ selection logic only being implemented for Cortex-M when it comes to the ARM architecture.
The following testsuites pass all test cases on the QEMU target which aren't filtered out for whatever reason (I didn't blacklist anything myself):
- lib
- misc
- portability
- posix
- shell
- subsys
- ztest
I'll have to look into the details as to why in some cases, more test cases are filtered out than executed. In some cases, e.g. ARMv8-specific stuff, it's pretty obvious, but in others I'm suspecting that I ought to whitelist testcases or subsystems for testing, likely in the target's YAML files? For example, despite having full Ethernet support, the 'net' testsuite in its current state does pretty much nothing.

I'll keep you updated and I'll look into the ongoing discussions and the mechanics of pull requests, I could start simple, as for example, the Xilinx TTC timer driver had a faulty prescaler calculation routine. As this source file is already in the main repository, this might be a good exercise for a pull request. Until then, I'd appreciate any feedback if anyone feels like experimenting with my fork of the repository.

Best regards,
Immo

Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

Jukka Rissanen
 

Hi Holger,

one option is use the generic GSM modem, which uses PPP to connect to
modem, instead of offloading the IP stack to the modem. In that case
one can send DTLS data via the modem. Unfortunately the modem you
mentioned (Quectel BC68) does not seem to support PPP mode.

Cheers,
Jukka

On Wed, 2020-02-26 at 02:04 -0800, Holger Gräf wrote:
Hi Billy,

thanks for the reply. I still have to clean up the driver a bit, then
I will create the PR.

With regard to the second message, thanks for the hint. I have
already stumbled upon these commands, but according to the manual
they are specific to Huawei's IoT platform, which I don't use. I have
the impression that it's based on LwM2M, but I would like to be able
to use DTLS encryption regardless of the protocol I use (UDP, TCP or
the higher level COAPS or LwM2M).

That's why I'm looking for a way to use Zephyr's mbedtls with my
offloaded sockets. Any help would be very much appreciated :-)

All the best,

Holger

Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

Holger Gräf
 

Hi Billy,

thanks for the reply. I still have to clean up the driver a bit, then I will create the PR.

With regard to the second message, thanks for the hint. I have already stumbled upon these commands, but according to the manual they are specific to Huawei's IoT platform, which I don't use. I have the impression that it's based on LwM2M, but I would like to be able to use DTLS encryption regardless of the protocol I use (UDP, TCP or the higher level COAPS or LwM2M).

That's why I'm looking for a way to use Zephyr's mbedtls with my offloaded sockets. Any help would be very much appreciated :-)

All the best,

Holger

Zephyr 2.2.0-rc2 tagged

Johan Hedberg
 

Hi Zephyr developers,

We have now tagged the second release candidate for Zephyr 2.2: 2.2.0-rc2.

We’re currently at 0 high priority bugs and 21 medium priority bugs. This is already close to the requirements for rc3 and the final release, which are 0 and 20 respectively.

Developers are requested to continue testing the release, filing bugs, and addressing any remaining bugs that are assigned to you. I would also encourage subsystem owners to take a look at their respective sections in doc/releases/release-notes-2.2.rst and submit updates in case your subsystem is still missing a change summary since the last release.

Looking at the original release schedule, it seems likely that we’ll need to push the final release from the end of this week to some time next week - we will discuss this in this week’s TSC call.

The full release log for 2.2.0-rc2 can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.2.0-rc2

More details about Zephyr releases is found here:
https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

Thanks to everybody who has contributed to this release!

Johan

Re: How do I get to know about plans on on-going or future features?

Carles Cufi
 

Hi Alex,

 

Thanks for your interest in Zephyr.

I think you should begin by defining an area you want to contribute in: kernel, filesystems, drivers, protocol stacks, etc.

In order to find out which features are missing I think one good way is to look through the “Enhancements” and “Feature Requests” GitHub issues:

 

Enhancements:

https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement

 

Feature Requests:

https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aissue+is%3Aopen+label%3A%22feature+request%22

 

Once you define the area you want to contribute in, you can combine the above labels with an area label and browse through the issues.

As soon as you find an issue you would like to work on, you can then write on the mailing list asking if there is someone else planning to work or working already on it.

 

Another category that might be of interest to you is the “Good first issue”, which we have tried to use for issues that are not overly complicated and that can serve as a starting point to someone like you looking to become a contributor:

https://github.com/zephyrproject-rtos/zephyr/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen++label%3A%22Good+first+issue%22+

 

Thanks,

 

Carles

 

From: devel@... <devel@...> On Behalf Of Alexander Syvak via Lists.Zephyrproject.Org
Sent: 24 February 2020 14:11
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] How do I get to know about plans on on-going or future features?

 

Hi!

 

I am new to Zephyr projet, and I'd like to contribute.

 

There are many features had been implemented by the moment.

There are features are being implemented at the moment.

Finally, there are features to be implemented.

 

How do I know about the last two groups of features? About plans on them?

 

Where do I start?

 

Regards,

Alex.

Re: How can west commands be executed when doing ‘west update’?

Bolivar, Marti
 

Hello,

I believe the west issue covering this feature request is:
https://github.com/zephyrproject-rtos/west/issues/320

Please take a look and feel free to comment!

Thanks,
Marti

"Li, Jun R via Lists.Zephyrproject.Org"
<jun.r.li=intel.com@...> writes:

Hey,

I would like to copy some environment setting scripts to the top directory of my project by using west commands when the command “west update” runs. So far, I can run “west <my_cmd>“ to do that but I hope to let it run automatically while west updating repos.


Thank you!

Jun


How can west commands be executed when doing ‘west update’?

Li, Jun R
 

Hey,

I would like to copy some environment setting scripts to the top directory of my project by using west commands when the command “west update” runs. So far, I can run “west <my_cmd>“ to do that but I hope to let it run automatically while west updating repos.


Thank you!

Jun

Does Nordic’s SPI driver support easyDMA?

Li, Jun R
 

Hey,

Anyone has experience on enabling easyDMA for nRF52’s SPI master?

Thank you!

Jun

API meeting: cancelled today

Carles Cufi
 

Hi all,

Due to several contributors being unavailable today and myself having an additional commitment I have decided to cancel this week's API meeting.
Next week the meeting will take place as usual.

Thanks,

Carles

Cancelled Event: Zephyr Project: APIs - Tuesday, 25 February 2020 #cal-cancelled

devel@lists.zephyrproject.org Calendar <devel@...>
 

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, 25 February 2020
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/177647878

Organizer: devel@...

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/177647878

Or iPhone one-tap :
    US: +16465588656,,177647878# or +16699006833,,177647878# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 177 647 878
    International numbers available: https://zoom.us/zoomconference?m=ioAR9GK1OE5LkN1ojt-heTCl7yPcJrhY


 Live meeting minutes: https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit?usp=sharing

How do I get to know about plans on on-going or future features?

Alexander Syvak
 

Hi!

I am new to Zephyr projet, and I'd like to contribute.

There are many features had been implemented by the moment.
There are features are being implemented at the moment.
Finally, there are features to be implemented.

How do I know about the last two groups of features? About plans on them?

Where do I start?

Regards,
Alex.

Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

William Fish
 

A quick internet search brought up a manual which gave a basic DLTS example:
https://www.quectel.com/UploadImage/Downlad/Quectel_BC95-G&BC68_AT_Commands_Manual_V1.1.pdf

BC95-G&BC68_AT_Commands_Manual -- Pg 122 
 
Register to Huawei’s IoT Platform with DTLS
 
AT+CGATT? //Query the PS service attach status.
+CGATT:1 //Attached to the PS service.
OK
 
AT+NCDP= 180.101.147.115,5684 //Set IoT platform IP address and port. The port is 5684.
OK
 
AT+QSECSWT=1 //Encryption using standard DTLS.
OK
 
AT+QSETPSK=201703230000024,0123456789ABCDEF0123456789ABCDEF
OK //Set PSK ID and PSK.
 
AT+QREGSWT? //Query the registration mode.
+QREGSWT:0 //Manual registration mode.
OK
 
AT+QLWSREGIND=0 //Start to register to the IoT platform.
OK
 
+QLWEVTIND:0 //Successful registration indication.

Re: How to use DTLS with offloaded socket if the underlying modem does not support DTLS

William Fish
 

Holger,
Great if you have created a driver...you may want to create a PR so that it gets reviewed by the Dev community The man that should be able to help is Mike Scott.

Billy..

How to use DTLS with offloaded socket if the underlying modem does not support DTLS

Holger Gräf
 

Dear all,

I have adapted the Sara R4 modem driver (zephyr/drivers/modem/ublox-sara-r4.c) in Zephyr in order to control a Quectel BC68 NB-IoT modem. The aim is to use this with Zephyr's LwM2M engine. Without DTLS everything works fine.

Now I want to add DTLS encryption to my setup, but I have not managed to figure out how to implement this with the socket offload API used by the modem driver (note that the Quectel modem I use does not itself support DTLS sockets).

Is there any easy way to implement this?

Thanks and all the best,

Holger

Re: Zephyr ble nrf52840 how to enable indications

Lawrence King
 

Hi Teijo

 

I’m not sure if this code fragment solves your problem

 

 

        /** @brief LE connection parameter update request.

         *

         *  This callback notifies the application that a remote device

         *  is requesting to update the connection parameters. The

         *  application accepts the parameters by returning true, or

         *  rejects them by returning false. Before accepting, the

         *  application may also adjust the parameters to better suit

         *  its needs.

         *

         *  It is recommended for an application to have just one of these

         *  callbacks for simplicity. However, if an application registers

         *  multiple it needs to manage the potentially different

         *  requirements for each callback. Each callback gets the

         *  parameters as returned by previous callbacks, i.e. they are not

         *  necessarily the same ones as the remote originally sent.

         *

         *  @param conn Connection object.

         *  @param param Proposed connection parameters.

         *

         *  @return true to accept the parameters, or false to reject them.

         */

static bool le_param_req(struct bt_conn *conn, struct bt_le_conn_param *param)

{

        time_stamp_print();

        printf("le_param_req() - interval_min=%d, interval_max=%d, latency=%d, timeout=%d\n", param->interval_min, param->interval_min, param->latency, param->timeout);

        return(true);

}

        /** @brief The parameters for an LE connection have been updated.

         *

         *  This callback notifies the application that the connection

         *  parameters for an LE connection have been updated.

         *

         *  @param conn Connection object.

         *  @param interval Connection interval.

         *  @param latency Connection latency.

         *  @param timeout Connection supervision timeout.

         */

static void le_param_updated(struct bt_conn *conn, u16_t interval, u16_t latency, u16_t timeout)

{

        time_stamp_print();

        printf("le_param_updated() - interval=%d, latency=%d, timeout=%d", interval, latency, timeout);

        if (interval==6) {

                // the Android Pixel3 requests this first

                printf("\n");

                return;

        }

        if (interval==39) {

                // the Samsung J7 requests this

                return;

        }

        if (interval==36) {

                // the iPad and the Pixel3 requests this

                printf("\n");

                return;

        }

        printf(" - UNKNOWN interval=%d\n",interval);

}

 

#if defined(CONFIG_BT_SMP)

        /** @brief Remote Identity Address has been resolved.

         *

         *  This callback notifies the application that a remote

         *  Identity Address has been resolved

         *

         *  @param conn Connection object.

         *  @param rpa Resolvable Private Address.

         *  @param identity Identity Address.

         */

static void identity_resolved(struct bt_conn *conn,

                                  const bt_addr_le_t *rpa,

                                  const bt_addr_le_t *identity)

{

        time_stamp_print();

        printf("identity_resolved() - called\n");

}

#endif /* CONFIG_BT_SMP */

 

#if defined(CONFIG_BT_SMP) || defined(CONFIG_BT_BREDR)

        /** @brief The security level of a connection has changed.

         *

         *  This callback notifies the application that the security level

         *  of a connection has changed.

         *

         *  @param conn Connection object.

         *  @param level New security level of the connection.

         *  @param err Security error. Zero for success, non-zero otherwise.

         */

static void security_changed(struct bt_conn *conn, bt_security_t level,

                                 enum bt_security_err err)

{

        time_stamp_print();

        printf("security_changed() - level=%d, err=%d\n", level, err);

        // if the iphone selects pair then level==2 otherwise level==1 and err==8

        if (level==2) {

        }

}

#endif /* defined(CONFIG_BT_SMP) || defined(CONFIG_BT_BREDR) */

 

static struct bt_conn_cb conn_callbacks = {

        .connected = connected,

        .disconnected = disconnected,

        .le_param_req=le_param_req,

        .le_param_updated=le_param_updated,

#if defined(CONFIG_BT_SMP)

        .identity_resolved=identity_resolved,

#endif /* CONFIG_BT_SMP */

#if defined(CONFIG_BT_SMP) || defined(CONFIG_BT_BREDR)

        .security_changed=security_changed,

#endif /* defined(CONFIG_BT_SMP) || defined(CONFIG_BT_BREDR) */

};

 

 

main()

{

        rc = bt_enable(bt_ready);

        if (rc != 0) {

                printf("blue_init() - bt_enable() failed (err %d)\n", rc);

                return;

        }

        bt_conn_cb_register(&conn_callbacks);

}

 

At the time I wrote this code the examples in the zephyr never set the callbacks beyond .connected and .disconnected so it took me a while to figure out that there were more callbacks available from the bt stack.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: devel@... <devel@...> On Behalf Of Teijo Kauppi
Sent: Friday, February 21, 2020 6:21 AM
To: devel@...
Subject: [Zephyr-devel] Zephyr ble nrf52840 how to enable indications

 

Hi,

 

I've tinkering with bluetooth/peripheral and bluetooth/central_hr/ examples and i have a questions:

1. How i enable indications in central code so that function vnd_ccc_cfg_changed in peripheral is called so cental can receive indications?

2. In central side subscribe_params have notify callback but no indication. I assumed that callback is for both notify and indication. if not is there another way to receive indications

 

Thanks

Zephyr ble nrf52840 how to enable indications

Teijo Kauppi <teijo.kauppi@...>
 

Hi,

I've tinkering with bluetooth/peripheral and bluetooth/central_hr/ examples and i have a questions:
1. How i enable indications in central code so that function vnd_ccc_cfg_changed in peripheral is called so cental can receive indications?
2. In central side subscribe_params have notify callback but no indication. I assumed that callback is for both notify and indication. if not is there another way to receive indications

Thanks