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

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

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

Hi,

Today’s meeting minutes:

https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/

• Toolchain support, github overview:
• https://github.com/zephyrproject-rtos/zephyr/issues/5517

• Experiences shared from Metaware toolchain work:
• PR#22668 : Good feedback in the PR.
• Many primitives are supported in metaware, so no problems here
• most issues faced in relation to linker scripts, linker script are very gcc centric.
• Certain features used in gcc cannot be used in Metaware.
• Lot of time spend on things done in relation to binutils, such as mapping features from e.g. objcopy
• User space / section rename relies heavily on some advanced features of gcc
• Assembly code has difference

• When a toolchain is stated as supported, it means:
• Whole codebase compiles with that toolchain
• To ensure this is possible, the following should be ensured:
• Stick to standard C, ensure this through PR reviews
• Consider imposing rules regarding, e.g. gcc extensions
• There should be no to little need for assembly, as most things can be worked around in C.

Assembly should be isolated to special cases.

• Look at CMSIS-intrinsic, ARM C Language Extensions (ACLE), as those are supported in gcc, llvm, IAR compilers
• Minimize or remove the need for gcc preprocessing, one example is KConfig failures when trying to pre-process with IAR

• Documentation:
• Build system workflow is well described, but adding a new toolchain requires deeper knowledge.

• Toolchain abstraction in build system that must be addressed
• The abstraction of toolchains should be improved in Zephyr
• Use learnings from Metaware work.
• Evolve linker script to be more commercial toolchain friendly.
• experience with ICC, Compiling was fast, but failed on linking
• Python scripts makes lot of assumptions that are gcc/ld specific
• PR#22668 is a good starting point for introducing needed improvements.

• Oticon shared their experiences:
• Current toolchain abstraction is sufficient
• Oticon completely bypass toolchain / linking in Zephyr by using own and specialized linker script

• IAR support:
• IAR is willing to do work to ensure support for IAR
• Hello World is a first goal, acceptable to use gcc as linker.

Comment: should not be too difficult to also support IAR linker

• IAR linker can do optimizations not possible with gcc

• llvm/clang support:
• LLVM support: https://github.com/zephyrproject-rtos/zephyr/issues/3689
• Using llvm/clang PR: https://github.com/zephyrproject-rtos/zephyr/pull/22981
• llvm/clang bug: PR#22322

Actions

• Wayne: PR22668: Continue work, and use as base for better toolchain abstraction
• Thomas: IAR: Get basic hello world compiling, (linking with GCC)
• Everyone: Give feedback on PR#22688, and issue: #5517

Best regards

Torsten Tejlmand Rasmussen