Date   

Errors generated when build a sample using clang6.0 #west

istuoli@...
 

Hello!
I want to build samples/subsys/power/device_pm using clang6.0 so I do as follows:
1、export ZEPHYR_TOOLCHAIN_VARIANT=llvm
2、mkdir build and cd build
3、cmake -DBOARD=reel_board ..
4、make
Then, I got some errors:

[ 95%] Linking C executable zephyr_prebuilt.elf
clang-6.0: warning: argument unused during compilation: '--specs=nosys.specs' [-Wunused-command-line-argument]
clang-6.0: warning: argument unused during compilation: '-u _OffsetAbsSyms' [-Wunused-command-line-argument]
clang-6.0: warning: argument unused during compilation: '-u _ConfigAbsSyms' [-Wunused-command-line-argument]
clang-6.0: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
/usr/local/bin/ld.lld: error: linker.cmd:189: { expected, but got ALIGN_WITH_INPUT
>>>  _bt_channels_area : ALIGN_WITH_INPUT SUBALIGN(4)
>>>                      ^
clang-6.0: error: ld.lld command failed with exit code 1 (use -v to see invocation)
zephyr/CMakeFiles/zephyr_prebuilt.dir/build.make:101: recipe for target 'zephyr/zephyr_prebuilt.elf' failed
make[2]: *** [zephyr/zephyr_prebuilt.elf] Error 1
CMakeFiles/Makefile2:557: recipe for target 'zephyr/CMakeFiles/zephyr_prebuilt.dir/all' failed
make[1]: *** [zephyr/CMakeFiles/zephyr_prebuilt.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Then I turn to west and do:
west build -b reel_board ..
Some similar errors were generated:

[127/132] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf 
: && ccache /usr/local/bin/clang --target=arm-none-eabi   --specs=nosys.specs zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj  -o zephyr/zephyr_prebuilt.elf  -Wl,-T zephyr/linker.cmd -Wl,-Map=/home/lt/zephyrproject/zephyr/samples/subsys/power/device_pm/build/zephyr/zephyr_prebuilt.map -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/common/libarch__common.a zephyr/arch/arch/arm/core/libarch__arm__core.a zephyr/arch/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a zephyr/arch/arch/arm/core/cortex_m/mpu/libarch__arm__core__cortex_m__mpu.a zephyr/lib/libc/minimal/liblib__libc__minimal.a zephyr/lib/posix/liblib__posix.a zephyr/soc/arm/nordic_nrf/nrf52/libsoc__arm__nordic_nrf__nrf52.a zephyr/boards/arm/reel_board/libboards__arm__reel_board.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/i2c/libdrivers__i2c.a zephyr/drivers/serial/libdrivers__serial.a modules/nordic/lib..__modules__hal__nordic.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -L"/usr/lib/gcc/x86_64-linux-gnu/7.4.0" -L/home/lt/zephyrproject/zephyr/samples/subsys/power/device_pm/build/zephyr -lgcc -fshort-enums -mthumb -mcpu=cortex-m4 -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-section=alignment -u_OffsetAbsSyms -u_ConfigAbsSyms -nostdlib -static -no-pie -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -mabi=aapcs -march=armv7e-m && :
clang-6.0: warning: argument unused during compilation: '--specs=nosys.specs' [-Wunused-command-line-argument]
clang-6.0: warning: argument unused during compilation: '-u _OffsetAbsSyms' [-Wunused-command-line-argument]
clang-6.0: warning: argument unused during compilation: '-u _ConfigAbsSyms' [-Wunused-command-line-argument]
clang-6.0: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
/usr/local/bin/ld.lld: error: zephyr/linker.cmd:189: { expected, but got ALIGN_WITH_INPUT
>>>  _bt_channels_area : ALIGN_WITH_INPUT SUBALIGN(4)
>>>                      ^
clang-6.0: error: ld.lld command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
ERROR: command exited with status 1: /usr/local/bin/cmake --build /home/lt/zephyrproject/zephyr/samples/subsys/power/device_pm/build


Is there any suggestion?
Thanks a lot!


Help with porting to the new GPIO API

Carles Cufi
 

Hi all,

As you might know there is a new GPIO API under development in the topic-gpio branch. All drivers should now be ported but the actual users of the GPIO API, which are spread all over the tree, need porting.

The following issue tracks progress with porting those users:

https://github.com/zephyrproject-rtos/zephyr/issues/20017

Our plan is to make the new GPIO API the default for Zephyr 2.2, but in order to achieve that we need to port all users of the API first.

* If you are already assigned to porting one or more users in the issue above, please consider submitting a PR against topic-gpio as early as you can
* If you know the code for any of the unassigned users, or want to learn more about the new GPIO API, feel free to assign yourself (send me an email and I will update the issue) and work on a PR

You can find useful tips for porting to the new API in this comment:

https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497

Feel free to reply to this email or join the #gpio channel on Slack if you have questions.

Thanks in advance!

Carles


Building MCUBoot with a DTS overlay file

Lawrence King
 

Hello:

 

I am not sure if this issue should be asked here, or in the MCUBoot mailing list, but I will start by asking here.

 

I want to change the partitions in my nrf52840, this is easy when building a zephyr system, I simply put an overlay file with my new partition table in the project directory, cmake finds it and uses it, and all is good. I tried the same thing when building mcuboot, it doesn’t work, although it looks like it should work.

 

I downloaded the latest mcuboot code from JuulLabs ‘git clone https://github.com/JuulLabs-OSS/mcuboot.git’.  And after running the appropriate mcuboot setup scripts I built mcuboot for zephyr.

In the project directory mcuboot/boot/zephyr I ran ‘west build -b nrf52840_mdk’, the build completes west flash is successful and the bootloader is running on the board as expected. Now I want to change the partition table (and of course the keys). I created a file nrf52840_mdk.overlay in the mcuboot/boot/zephyr directory (I also tried putting the overlay in the boards subdirectory):

 

&flash0 {

        /*

         * For more information, see:

         * http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions

         */

        partitions {

                compatible = "fixed-partitions";

                #address-cells = <1>;

                #size-cells = <1>;

 

                boot_partition: partition@0 {

                        label = "mcuboot";

                        reg = <0x000000000 0x0000C000>;

                };

                slot0_partition: partition@c000 {

                        label = "image-0";

                        reg = <0x0000C000 0x000067000>;

                };

                slot1_partition: partition@73000 {

                        label = "image-1";

                        reg = <0x00073000 0x000067000>;

                };

                scratch_partition: partition@da000 {

                        label = "image-scratch";

                        reg = <0x000da000 0x0001c000>;

                };

                blob_partition: partition@f7000 {

                        label = "image-blob";

                        reg = <0x000f7000 0x00001000>;

                };

 

                /*

                 * The flash starting at 0x000f8000 and ending at (32kB)

                 * 0x000fffff is reserved for use by the application.

                 */

 

                /* Storage partition will be used by FCB/NFFS/NVS if enabled. */

                storage_partition: partition@f8000 {

                        label = "storage";

                        reg = <0x000f8000 0x00008000>;

                };

        };

};

 

As you can see this is almost exactly the same as the standard partitions except the scratch partition is 4k smaller, and I have added a 4k blob partition.

When I compile this and attempt to flash the code, the code goes into the wrong partition, because the dts.overlay file is ignored.

 

The CMakelists.txt file  looks reasonable, it should overlay the dts.overlay AND the nrf52840_mdk.overlay when building the dts file, but it doesn’t actually end up with two overlays.

 

I tried numerous combinations of adding an overlay or two on the west command line, but I couldn’t get it to work.

west build -b nrf52840_mdk -- -DDTC_OVERLAY_FILE=”whatever”

 

I eventually added the contents of the dts.overlay file to my nrf52840_mdk.overlay, and I commented out part of the CMakeLists.txt file to make it work, but I don’t think this is the right way to do it:

 

# Add a common dts overlay necessary to ensure mcuboot is linked into,

# and fits inside, the boot partition. (If the user specified a

# DTC_OVERLAY_FILE on the CMake command line, we need to append onto

# the list).

#if(DTC_OVERLAY_FILE)

#  set(DTC_OVERLAY_FILE

#    "${DTC_OVERLAY_FILE} ${CMAKE_CURRENT_LIST_DIR}/dts.overlay"

#    CACHE STRING "" FORCE

#    )

#else()

#  set(DTC_OVERLAY_FILE ${CMAKE_CURRENT_LIST_DIR}/dts.overlay)

#endif()

 

if (EXISTS ${CMAKE_CURRENT_LIST_DIR}/boards/${BOARD}.overlay)

  set(DTC_OVERLAY_FILE

    "${DTC_OVERLAY_FILE} ${CMAKE_CURRENT_LIST_DIR}/boards/${BOARD}.overlay"

    CACHE STRING "" FORCE

    )

endif()

 

What is the right way to get two overlays into the mcuboot build?

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Daniel Fox <danny.fox97@...>
 

Hi All,
Im currently working on my 3rd year engineering project and I need some help/guidance as I'm a complete beginner. My project is a home monitoring system and my plan is to use PIR motion sensors inside the house, using Bluetooth mesh.

I have a few BBC Microbits and I have managed to implement the Mesh demo example from zephyr v1.14.
My plan is to try and replace the switch functions (button_pressed .. etc) to allow the motion sensor connected to GPIO PIN 0 on the BBC micro bit board. So when motion is detected it would act like how the button press function works on the boards.

My issue is I'm not sure how to program this and read the GPIO 0 pin, I want something like if motion sensor = 1 send messaged to light LED to other BBC micro bits. If motion sensor=0 do nothing.

From the microbit.c file:
#define BUZZER_PIN     EXT_P0_GPIO_PIN  // replace buzzer_pin with motion sensor ???

static void button_pressed(struct device *dev, struct gpio_callback *cb,
   u32_t pins)
{
struct mb_display *disp = mb_display_get();
 
if (pins & BIT(SW0_GPIO_PIN)) {
k_work_submit(&button_work);
} else {
u16_t target = board_set_target();
 
if (target > 0x0009) {
mb_display_print(disp, MB_DISPLAY_MODE_SINGLE,
 K_SECONDS(2), "A");
} else {
mb_display_print(disp, MB_DISPLAY_MODE_SINGLE,
 K_SECONDS(2), "%X", (target & 0xf));
}
}
}
 
... 

void board_play_tune(const char *str)
{
while (*str) {
u32_t period, duration = 0U;
 
while (*str && !isdigit((unsigned char)*str)) {
str++;
}
 
while (isdigit((unsigned char)*str)) {
duration *= 10U;
duration += *str - '0';
str++;
}
 
if (!*str) {
break;
}
 
if (str[1] == '#') {
period = get_period(*str, true);
str += 2;
} else {
period = get_period(*str, false);
str++;
}
 
if (period) {
pwm_pin_set_usec(pwm, BUZZER_PIN, period, period / 2U); 
}
 
k_sleep(duration);
 
/* Disable the PWM */
pwm_pin_set_usec(pwm, BUZZER_PIN, 0, 0);
}
}
.....

static void configure_button(void)
{
static struct gpio_callback button_cb;
 
k_work_init(&button_work, button_send_pressed);
 
gpio = device_get_binding(SW0_GPIO_CONTROLLER);

gpio_pin_configure(gpio, SW0_GPIO_PIN,
   (GPIO_DIR_IN | GPIO_INT | GPIO_INT_EDGE |
    GPIO_INT_ACTIVE_LOW));
gpio_pin_configure(gpio, SW1_GPIO_PIN,
   (GPIO_DIR_IN | GPIO_INT | GPIO_INT_EDGE |
    GPIO_INT_ACTIVE_LOW));
 
gpio_init_callback(&button_cb, button_pressed,
   BIT(SW0_GPIO_PIN) | BIT(SW1_GPIO_PIN));
gpio_add_callback(gpio, &button_cb);
 
gpio_pin_enable_callback(gpio, SW0_GPIO_PIN);
gpio_pin_enable_callback(gpio, SW1_GPIO_PIN);
}
 
I appreciate any help that you could give me. Thanks!


Re: MCP2515 with nRF52832 using zephyr #dts #nrf52832

Lawrence King
 

I think you need a few more things turned on in your config file. To figure out what you need turned on I always use the menuconfig tool and diff the old and new .config files, then I take the changes and pit them in my prj.conf file

 

In this case I ran ‘ninja menuconfig’ in the build directory, turned on SPI, then CANBUS, then MCP25625, here is a diff between zephyr/.config.old and zephyr/.config:

 

> CONFIG_SPI=y

678a679,695

> # CONFIG_SPI_ASYNC is not set

> # CONFIG_SPI_SLAVE is not set

> CONFIG_SPI_INIT_PRIORITY=70

> # CONFIG_SPI_LOG_LEVEL_OFF is not set

> # CONFIG_SPI_LOG_LEVEL_ERR is not set

> # CONFIG_SPI_LOG_LEVEL_WRN is not set

> CONFIG_SPI_LOG_LEVEL_INF=y

> # CONFIG_SPI_LOG_LEVEL_DBG is not set

> CONFIG_SPI_LOG_LEVEL=3

> # CONFIG_SPI_0 is not set

> # CONFIG_SPI_1 is not set

> # CONFIG_SPI_2 is not set

> # CONFIG_SPI_3 is not set

> # CONFIG_SPI_4 is not set

> # CONFIG_SPI_5 is not set

> # CONFIG_SPI_6 is not set

> CONFIG_SPI_NRFX=y

749a767,768

> # CONFIG_SPI_NOR is not set

> # CONFIG_SPI_FLASH_W25QXXDV is not set

760c779,797

< # CONFIG_CAN is not set

---

> CONFIG_CAN=y

> # CONFIG_CAN_LOG_LEVEL_OFF is not set

> # CONFIG_CAN_LOG_LEVEL_ERR is not set

> # CONFIG_CAN_LOG_LEVEL_WRN is not set

> CONFIG_CAN_LOG_LEVEL_INF=y

> # CONFIG_CAN_LOG_LEVEL_DBG is not set

> CONFIG_CAN_LOG_LEVEL=3

> CONFIG_CAN_INIT_PRIORITY=80

> CONFIG_CAN_WORKQ_FRAMES_BUF_CNT=4

> CONFIG_CAN_0=y

> CONFIG_CAN_1=y

> CONFIG_CAN_MCP2515=y

> CONFIG_CAN_MCP2515_OSC_FREQ=8000000

> CONFIG_CAN_MCP2515_INT_THREAD_STACK_SIZE=512

> CONFIG_CAN_MCP2515_INT_THREAD_PRIO=2

> CONFIG_CAN_MCP2515_MAX_FILTER=5

> CONFIG_CAN_MCP2515_INIT_PRIORITY=80

> # CONFIG_CAN_LOOPBACK is not set

> # CONFIG_CAN_NET is not set

 

My guess is you are not finding the SPI bus because you haven’t configured it.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of christophhintz@...
Sent: Tuesday, November 19, 2019 5:19 AM
To: users@...
Subject: [Zephyr-users] MCP2515 with nRF52832 using zephyr #dts #nrf52832

 

Hi I had a question to setup the MCP2515 driver in the zephyr project.

We made a custom board for the decawave DWM1001 module, which uses a nRF52832 chip. They have a device tree file in the zephyr project for this module, so I started with that device tree and configured it for our setup, which is

NRF52832

MCP25625

P0.14

SPI_CS

P0.22

SPI_MISO

P0.31

SPI_MOSI

P0.30

SPI_SCK

P0.27

CAN_RESET

P0.03

CAN_INT

. I attached the devicetree and project file to this post.
The main project file I am using is the can example from zephyr. I only added the pull up for the CAN_RESET GPIO, which I can confirm works. I am not seeing any messages on the SPI pins, which make me suspect that the overlay is incorrect. I just added the mcp into the spi setup in the overlay, from a shield example, I am not to sure if it is correct and what sjw, prop-seg, phase-seg1 and phase-seg2 mean. Any help or pointers are appreciated. The program stops with debug messages "CAN: Device driver not found.".


About PSE completeness

Claudio Scordino <c.scordino@...>
 

Dear all,

I'd like to know if there is already a schedule about reaching PSE51 or PSE52 completeness (as far as I've understood, only subsets of such standards are currently implemented).

Thanks.

         Claudio 


API meeting: agenda

Carles Cufi
 

Hi all,

This week we will look at:

- PWM: Add support for inverted PWM signals
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/20657

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


MCP2515 with nRF52832 using zephyr #dts #nrf52832

christophhintz@...
 

Hi I had a question to setup the MCP2515 driver in the zephyr project.

We made a custom board for the decawave DWM1001 module, which uses a nRF52832 chip. They have a device tree file in the zephyr project for this module, so I started with that device tree and configured it for our setup, which is

NRF52832 MCP25625
P0.14 SPI_CS
P0.22 SPI_MISO
P0.31 SPI_MOSI
P0.30 SPI_SCK
P0.27 CAN_RESET
P0.03 CAN_INT

. I attached the devicetree and project file to this post.
The main project file I am using is the can example from zephyr. I only added the pull up for the CAN_RESET GPIO, which I can confirm works. I am not seeing any messages on the SPI pins, which make me suspect that the overlay is incorrect. I just added the mcp into the spi setup in the overlay, from a shield example, I am not to sure if it is correct and what sjw, prop-seg, phase-seg1 and phase-seg2 mean. Any help or pointers are appreciated. The program stops with debug messages "CAN: Device driver not found.".



Re: #stm32 pinmux.c compile failure STM32F407 #stm32

Erwan Gouriou
 

Hi Neo

I'd advise you to have a look to STM32 clock control driver.
It provides MCO support. It might not provide exactly the requested configuration, but at least it would be a working point that you can custom to your own need.

Erwan


On Fri, 8 Nov 2019 at 18:28, <nanjunneo@...> wrote:
Hello guys,

for the board STM32F407 I want to add pin PA8 25 MHz clk output to Etherent Phy. So that I add the following sentence (1)
 
HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_1)          into the pinmux.c.
 
The rest of code in pinmux.c I copied from stm32f4_dico, except I configure OTG_HS_DM / OTG_HS_DP as virtual port.
 
The compiling fails at the last step:  `HAL_GPIO_Init' is not defined.
[129/134] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf
.....
.....
/home/neo/ARM-GCC-Toolchain/gcc-arm-none-eabi-8-2019-q3-update-linux/gcc-arm-none-eabi-8-2019-q3-update/bin/../lib/gcc/arm-none-eabi/8.3.1/../../../../arm-none-eabi/bin/ld: modules/stm32/stm32cube/lib..__modules__hal__stm32__stm32cube.a(stm32f4xx_hal_rcc.c.obj): in function `HAL_RCC_MCOConfig':
/home/neo/zephyr_2_0_99/zephyrproject/modules/hal/stm32/stm32cube/stm32f4xx/drivers/src/stm32f4xx_hal_rcc.c:769: undefined reference to `HAL_GPIO_Init'
/home/neo/ARM-GCC-Toolchain/gcc-arm-none-eabi-8-2019-q3-update-linux/gcc-arm-none-eabi-8-2019-q3-update/bin/../lib/gcc/arm-none-eabi/8.3.1/../../../../arm-none-eabi/bin/ld: /home/neo/zephyr_2_0_99/zephyrproject/modules/hal/stm32/stm32cube/stm32f4xx/drivers/src/stm32f4xx_hal_rcc.c:793: undefined reference to `HAL_GPIO_Init'
collect2: error: ld returned 1 exit status
 
The pinmux.c is attaced here. the compile is successful without adding the sentence(1).
 
Do you have any idea? or how can I check it further?
Thank you!
------------------------------------------------------pinmux.c in board file-----------------------------------------------------------------
#include <kernel.h>
#include <device.h>
#include <init.h>
#include <drivers/pinmux.h>
#include <sys/sys_io.h>

#include "stm32f4xx.h"
#include <pinmux/stm32/pinmux_stm32.h>

/* pin assignments for STM32F4DISCOVERY board */
static const struct pin_config pinconf[] = {
 
#ifdef CONFIG_UART_1
{STM32_PIN_PB6, STM32F4_PINMUX_FUNC_PB6_USART1_TX},
{STM32_PIN_PB7, STM32F4_PINMUX_FUNC_PB7_USART1_RX},
#endif /* CONFIG_UART_1 */
 
#ifdef CONFIG_UART_2
{STM32_PIN_PA2, STM32F4_PINMUX_FUNC_PA2_USART2_TX},
{STM32_PIN_PA3, STM32F4_PINMUX_FUNC_PA3_USART2_RX},
#endif /* CONFIG_UART_2 */
 
#ifdef CONFIG_PWM_STM32_2
{STM32_PIN_PA0, STM32F4_PINMUX_FUNC_PA0_PWM2_CH1},
#endif /* CONFIG_PWM_STM32_2 */
 
#ifdef CONFIG_USB_DC_STM32
    { STM32_PIN_PB14, STM32F4_PINMUX_FUNC_PB14_OTG_HS_DM },
    { STM32_PIN_PB15, STM32F4_PINMUX_FUNC_PB15_OTG_HS_DP },
#endif  /* CONFIG_USB_DC_STM32 */
};

static int pinmux_stm32_init(struct device *port)
{
ARG_UNUSED(port);

HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_1); ----------------------------------------------------------------------(1)

stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

return 0;
}

SYS_INIT(pinmux_stm32_init, PRE_KERNEL_1,
CONFIG_PINMUX_STM32_DEVICE_INITIALIZATION_PRIORITY);

Best regards,
Neo


Tomorrow's API meeting: Agenda

Carles Cufi
 

Hi all,

This week we will look at:

- QSPI/jedec API proposal vs SPI API extension:
- https://github.com/zephyrproject-rtos/zephyr/pull/20069
vs
- https://github.com/zephyrproject-rtos/zephyr/pull/20564

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


#stm32 pinmux.c compile failure STM32F407 #stm32

nanjunneo@...
 

Hello guys,

for the board STM32F407 I want to add pin PA8 25 MHz clk output to Etherent Phy. So that I add the following sentence (1)
 
HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_1)          into the pinmux.c.
 
The rest of code in pinmux.c I copied from stm32f4_dico, except I configure OTG_HS_DM / OTG_HS_DP as virtual port.
 
The compiling fails at the last step:  `HAL_GPIO_Init' is not defined.
[129/134] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf
.....
.....
/home/neo/ARM-GCC-Toolchain/gcc-arm-none-eabi-8-2019-q3-update-linux/gcc-arm-none-eabi-8-2019-q3-update/bin/../lib/gcc/arm-none-eabi/8.3.1/../../../../arm-none-eabi/bin/ld: modules/stm32/stm32cube/lib..__modules__hal__stm32__stm32cube.a(stm32f4xx_hal_rcc.c.obj): in function `HAL_RCC_MCOConfig':
/home/neo/zephyr_2_0_99/zephyrproject/modules/hal/stm32/stm32cube/stm32f4xx/drivers/src/stm32f4xx_hal_rcc.c:769: undefined reference to `HAL_GPIO_Init'
/home/neo/ARM-GCC-Toolchain/gcc-arm-none-eabi-8-2019-q3-update-linux/gcc-arm-none-eabi-8-2019-q3-update/bin/../lib/gcc/arm-none-eabi/8.3.1/../../../../arm-none-eabi/bin/ld: /home/neo/zephyr_2_0_99/zephyrproject/modules/hal/stm32/stm32cube/stm32f4xx/drivers/src/stm32f4xx_hal_rcc.c:793: undefined reference to `HAL_GPIO_Init'
collect2: error: ld returned 1 exit status
 
The pinmux.c is attaced here. the compile is successful without adding the sentence(1).
 
Do you have any idea? or how can I check it further?
Thank you!
------------------------------------------------------pinmux.c in board file-----------------------------------------------------------------
#include <kernel.h>
#include <device.h>
#include <init.h>
#include <drivers/pinmux.h>
#include <sys/sys_io.h>

#include "stm32f4xx.h"
#include <pinmux/stm32/pinmux_stm32.h>

/* pin assignments for STM32F4DISCOVERY board */
static const struct pin_config pinconf[] = {
 
#ifdef CONFIG_UART_1
{STM32_PIN_PB6, STM32F4_PINMUX_FUNC_PB6_USART1_TX},
{STM32_PIN_PB7, STM32F4_PINMUX_FUNC_PB7_USART1_RX},
#endif /* CONFIG_UART_1 */
 
#ifdef CONFIG_UART_2
{STM32_PIN_PA2, STM32F4_PINMUX_FUNC_PA2_USART2_TX},
{STM32_PIN_PA3, STM32F4_PINMUX_FUNC_PA3_USART2_RX},
#endif /* CONFIG_UART_2 */
 
#ifdef CONFIG_PWM_STM32_2
{STM32_PIN_PA0, STM32F4_PINMUX_FUNC_PA0_PWM2_CH1},
#endif /* CONFIG_PWM_STM32_2 */
 
#ifdef CONFIG_USB_DC_STM32
    { STM32_PIN_PB14, STM32F4_PINMUX_FUNC_PB14_OTG_HS_DM },
    { STM32_PIN_PB15, STM32F4_PINMUX_FUNC_PB15_OTG_HS_DP },
#endif  /* CONFIG_USB_DC_STM32 */
};

static int pinmux_stm32_init(struct device *port)
{
ARG_UNUSED(port);

HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSE, RCC_MCODIV_1); ----------------------------------------------------------------------(1)

stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

return 0;
}

SYS_INIT(pinmux_stm32_init, PRE_KERNEL_1,
CONFIG_PINMUX_STM32_DEVICE_INITIALIZATION_PRIORITY);

Best regards,
Neo


Re: OpenOCD on STM32 boards

Lawrence King
 

Hi Marti:

Thanks, setting the udev rules did the trick.

Just so other people know what to do:

$ sudo cp ${HOME}/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d/
$ sudo udevadm control --reload-rules
$ sudo usermod -aG plugdev $USER

Hi Charles:

This probably should be added somewhere in the 'Getting Started' guide after the Zephyr SDK is installed. It should also be made clear that you don't need to use the compilers in the SDK, but you do need to install the SDK (see the first half of this thread) to get the working version of openocd. I had also put in the rules for pyOCD but these are part of the instructions from pyOCD:

$ git clone https://github.com/mbedmicro/pyOCD.git
$ sudo cp pyOCD/udev/*.rules /etc/udev/rules.d
$ sudo udevadm control --reload
$ sudo udevadm trigger

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...>
Sent: Tuesday, November 5, 2019 5:51 PM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: RE: [Zephyr-users] OpenOCD on STM32 boards

Lawrence King <lawrence.king@...> writes:

Hi Marti:

Thanks for your help.
Sure thing!


I had stopped using the zephyr-sdk because I was bisecting the kernel to find a problem, depending on where I was I needed 0.10.0, 0.10.1, 0.10.2 or 0.10.3 versions of the SDK to compile, however when I was using gnuarmemb it worked around this annoyance for me.

I removed openocd (and autoremoved the assorted packages) and installed SDK 0.10.3 into /opt/zephyr-sdk. I also set 'export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk' in my bashrc and started a new shell. Quick check and openocd is gone from my path.

The west build went cleanly, and now I have a new error from openocd:

lawrence@VM:~/workspace/rc-demo/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file:
/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zep
hyr.hex Open On-Chip Debugger 0.10.0+dev-00992-g3333261df-dirty
(2019-08-16-00:14) Licensed under GNU GPL v2 For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD adapter speed: 2000
kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
^^ judging from this, my guess is you need some udev rules to make the USB device accessible to your user.

Marti

Error: open failed


ERROR: command exited with status 1:
/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s
/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/script
s -f
/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/stm32
f746g_disco/support/openocd.cfg -c init -c targets -c 'reset halt' -c
'flash write_image erase
/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zep
hyr.hex' -c 'reset halt' -c 'verify_image
/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zep
hyr.hex' -c 'reset run' -c shutdown


This is 'better' than the missing files, but I still haven't successfully flashed the blinky program onto the Nucleo board. Anything else I missed?

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...>
Sent: Tuesday, November 5, 2019 4:55 PM
To: Lawrence King <lawrence.king@...>;
Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] OpenOCD on STM32 boards

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@...> writes:

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:
sudo apt-get install openocd
It's not always wise to trust in your distro's openocd. It has been hard to get support patches merged into upstream openocd, so the downstream version in the Zephyr SDK is usually the right one to use.

Obviously I am doing something silly wrong. Can anyone give me a hint?
Thanks
Use the openocd in the Zephyr SDK. You can do this even if you're not
using the Zephyr SDK's toolchain -- as long as ZEPHYR_SDK_INSTALL_DIR points at a Zephyr SDK install, the build system will use its host tools (like openocd) even if ZEPHYR_TOOLCHAIN_VARIANT != zephyr.


Re: Shell over WebUSB

Andrei
 

Hi Markus,

On Thu, Nov 07, 2019 at 07:59:02AM +0000, Becker Markus wrote:
Hi,

I have enjoyed the WebUSB sample application and it works nicely as
expected.

Is there a possibility to bind the Zephyr Shell to WebUSB?
Yes, I had some dirty hacks working, never went upstream, the JS part is
still here: https://github.com/finikorg/webusb-zephyr-demo

I saw that the webusb.c/.h files are in the samples directory. Is it
planned that they live in subsys/usb/class/ and can enabled in parallel to
e.g. CDC-ACM?
webusb defines interface with 2 endpoints just for tests, to put it to
class we need some Spec.

Probably for the shell you could implement subsys/shell/shell_webusb.c
similar to shell_telnet.c or shell_uart.c.

We can probably create also third endpoint for logs and have special log
screen...

I have created issue for that: https://github.com/zephyrproject-rtos/zephyr/issues/20409

Best regards
Andrei Emeltchenko


Shell over WebUSB

Becker Markus
 

Hi,

 

I have enjoyed the WebUSB sample application and it works nicely as expected.

 

Is there a possibility to bind the Zephyr Shell to WebUSB?

 

I saw that the webusb.c/.h files are in the samples directory. Is it planned that they live in subsys/usb/class/ and can enabled in parallel to e.g. CDC-ACM?

 

Thanks,

Markus


The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.


Re: OpenOCD on STM32 boards

Bolivar, Marti
 

Lawrence King <lawrence.king@...> writes:

Hi Marti:

Thanks for your help.
Sure thing!


I had stopped using the zephyr-sdk because I was bisecting the kernel to find a problem, depending on where I was I needed 0.10.0, 0.10.1, 0.10.2 or 0.10.3 versions of the SDK to compile, however when I was using gnuarmemb it worked around this annoyance for me.

I removed openocd (and autoremoved the assorted packages) and installed SDK 0.10.3 into /opt/zephyr-sdk. I also set 'export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk' in my bashrc and started a new shell. Quick check and openocd is gone from my path.

The west build went cleanly, and now I have a new error from openocd:

lawrence@VM:~/workspace/rc-demo/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.10.0+dev-00992-g3333261df-dirty (2019-08-16-00:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
^^ judging from this, my guess is you need some udev rules to make the
USB device accessible to your user.

Marti

Error: open failed


ERROR: command exited with status 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/stm32f746g_disco/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown


This is 'better' than the missing files, but I still haven't successfully flashed the blinky program onto the Nucleo board. Anything else I missed?

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...>
Sent: Tuesday, November 5, 2019 4:55 PM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] OpenOCD on STM32 boards

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@...> writes:

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:
sudo apt-get install openocd
It's not always wise to trust in your distro's openocd. It has been hard to get support patches merged into upstream openocd, so the downstream version in the Zephyr SDK is usually the right one to use.

Obviously I am doing something silly wrong. Can anyone give me a hint?
Thanks
Use the openocd in the Zephyr SDK. You can do this even if you're not using the Zephyr SDK's toolchain -- as long as ZEPHYR_SDK_INSTALL_DIR points at a Zephyr SDK install, the build system will use its host tools (like openocd) even if ZEPHYR_TOOLCHAIN_VARIANT != zephyr.


Re: OpenOCD on STM32 boards

Lawrence King
 

Hi Marti:

Thanks for your help.

I had stopped using the zephyr-sdk because I was bisecting the kernel to find a problem, depending on where I was I needed 0.10.0, 0.10.1, 0.10.2 or 0.10.3 versions of the SDK to compile, however when I was using gnuarmemb it worked around this annoyance for me.

I removed openocd (and autoremoved the assorted packages) and installed SDK 0.10.3 into /opt/zephyr-sdk. I also set 'export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk' in my bashrc and started a new shell. Quick check and openocd is gone from my path.

The west build went cleanly, and now I have a new error from openocd:

lawrence@VM:~/workspace/rc-demo/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.10.0+dev-00992-g3333261df-dirty (2019-08-16-00:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 2000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: open failed


ERROR: command exited with status 1: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/stm32f746g_disco/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown


This is 'better' than the missing files, but I still haven't successfully flashed the blinky program onto the Nucleo board. Anything else I missed?

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...>
Sent: Tuesday, November 5, 2019 4:55 PM
To: Lawrence King <lawrence.king@...>; Zephyr-users@...
Cc: users@...
Subject: Re: [Zephyr-users] OpenOCD on STM32 boards

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@...> writes:

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:
sudo apt-get install openocd
It's not always wise to trust in your distro's openocd. It has been hard to get support patches merged into upstream openocd, so the downstream version in the Zephyr SDK is usually the right one to use.

Obviously I am doing something silly wrong. Can anyone give me a hint?
Thanks
Use the openocd in the Zephyr SDK. You can do this even if you're not using the Zephyr SDK's toolchain -- as long as ZEPHYR_SDK_INSTALL_DIR points at a Zephyr SDK install, the build system will use its host tools (like openocd) even if ZEPHYR_TOOLCHAIN_VARIANT != zephyr.


Re: OpenOCD on STM32 boards

Bolivar, Marti
 

"Lawrence King via Lists.Zephyrproject.Org"
<lawrence.king=irdeto.com@...> writes:

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:
sudo apt-get install openocd
It's not always wise to trust in your distro's openocd. It has been hard
to get support patches merged into upstream openocd, so the downstream
version in the Zephyr SDK is usually the right one to use.

Obviously I am doing something silly wrong. Can anyone give me a hint?
Thanks
Use the openocd in the Zephyr SDK. You can do this even if you're not
using the Zephyr SDK's toolchain -- as long as ZEPHYR_SDK_INSTALL_DIR
points at a Zephyr SDK install, the build system will use its host tools
(like openocd) even if ZEPHYR_TOOLCHAIN_VARIANT != zephyr.


Zephyr Release 2.1: Status: Merge window closing this Friday, Nov 8th!

David Leach
 

A reminder that the feature merge window to Zephyr will be closing this Friday (November 8th). For more information on milestone dates please refer to the program management wiki page:

 

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

 

If there are outstanding PRs that the authors want in the 2.1 release than tag them with the “v2.1.0” milestone and work with the maintainers to approve and merge the PR.

 

Issues statistics:

 

Priority

Count

Change from last week

High

2

-

Medium

38

+1

Low

161

+9

No priority

2

-1

 

Over the last 4 weeks we have opened 99 new issues and closed 127 with 203 active issues.

 

Note that the release criteria includes zero high priority bugs and <20 medium priority bugs so if you are assigned a bug in these priority buckets please give them the appropriate attention.

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 


OpenOCD on STM32 boards

Lawrence King
 

Today I decided to bring up a STLML476 board, specifically the Nucleo-L476RG board.

 

Compile went cleanly

west build -b nucleo_l476rg samples/basic/blinky

Then after connecting the board I tried

              west flash

Of course I got complaints about OPENOCD-MISSING, OK, I can fix that:

              sudo apt-get install openocd

And openocd and a few other packages happily  installed.

 

Now ‘west flash’ complains:

-- west flash: rebuilding

ninja: no work to do.

-- west flash: using runner openocd

-- runners.openocd: Flashing file: /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex

Open On-Chip Debugger 0.10.0

Licensed under GNU GPL v2

For bug reports, read

              http://openocd.org/doc/doxygen/bugs.html

/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/nucleo_l476rg/support/openocd.cfg:1: Error: Can't find board/st_nucleo_l4.cfg

in procedure 'script'

at file "embedded:startup.tcl", line 60

at file "/home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/nucleo_l476rg/support/openocd.cfg", line 1

ERROR: command exited with status 1: /usr/bin/openocd -f /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/boards/arm/nucleo_l476rg/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'flash write_image erase /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset halt' -c 'verify_image /home/lawrence/workspace/rc-demo/zephyrproject/zephyr/build/zephyr/zephyr.hex' -c 'reset run' -c shutdown

 

 

The top of the openocd.cfg files (line 1) says:

source [find board/st_nucleo_l4.cfg]

 

I hunted around for the ‘missing’ file “board/st_nucleo_l4.cfg” to no avail. I also tried several other boards that use openocd and found similar missing include files.

 

I did confirm that the board is correctly connected and visible:

$ sudo lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 008: ID 0483:374b STMicroelectronics ST-LINK/V2.1 (Nucleo-F103RB)

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

 

Obviously I am doing something silly wrong. Can anyone give me a hint? Thanks

 

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


API meeting: agenda

Carles Cufi
 

Hi all,

This week we will look at GPIO:

- GPIO: Update on progress
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles