1. users@lists.zephyrproject.org
   Date   
API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow's topics:

- RFC: Require system clock stability on startup:
- https://github.com/zephyrproject-rtos/zephyr/issues/22758

- RFC: API change: Add I2C bus recovery API:
- https://github.com/zephyrproject-rtos/zephyr/issues/23441

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
trying to add support for STM32F334 discovery

Daniel McBrearty <danielmcbrearty@...>
 

hello all,

I am new to Zephyr, just want to give it a try. I don't have any of the supported boards, but I have a STM32F334 Discovery which is close to several supported ones. I thought I'd see if I could add support by making a copy of STM32F3 Discovery. I also used some settings from Nucleo STM32F334R8 which seems to have a very similar chip.

I can build and flashing seems to work, but no blinking LED (the red user LED should be assigned to led0).

My build / flash output:

============

daniel@daniel-dev-laptop:~/work/zephyrproject/zephyr$ west build -p auto -b stm32f334_disco samples/basic/blinky/
[0/1] Re-running CMake...
-- Application: /home/daniel/work/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.2.99
-- Board: stm32f334_disco
-- Found west: /home/daniel/.local/bin/west (found suitable version "0.7.2", minimum required is "0.6.0")
-- Found toolchain: zephyr (/home/daniel/zephyr-sdk-0.11.2)
-- Loading /home/daniel/work/zephyrproject/zephyr/boards/arm/stm32f334_disco/stm32f334_disco.dts as base
Devicetree header saved to '/home/daniel/work/zephyrproject/zephyr/build/zephyr/include/generated/devicetree_unfixed.h'
Parsing /home/daniel/work/zephyrproject/zephyr/Kconfig
Loaded configuration '/home/daniel/work/zephyrproject/zephyr/build/zephyr/.config'
No change to configuration in '/home/daniel/work/zephyrproject/zephyr/build/zephyr/.config'
No change to Kconfig header in '/home/daniel/work/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h'
-- Cache files will be written to: /home/daniel/.cache/zephyr
-- Configuring done
-- Generating done
-- Build files have been written to: /home/daniel/work/zephyrproject/zephyr/build
[52/82] Building C object zephyr/drivers...les/drivers__serial.dir/uart_stm32.c.obj
/home/daniel/work/zephyrproject/zephyr/drivers/serial/uart_stm32.c:653:12: warning: 'uart_stm32_init' defined but not used [-Wunused-function]
  653 | static int uart_stm32_init(struct device *dev)
      |            ^~~~~~~~~~~~~~~
/home/daniel/work/zephyrproject/zephyr/drivers/serial/uart_stm32.c:619:37: warning: 'uart_stm32_driver_api' defined but not used [-Wunused-const-variable=]
  619 | static const struct uart_driver_api uart_stm32_driver_api = {
      |                                     ^~~~~~~~~~~~~~~~~~~~~
[78/82] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       11160 B        64 KB     17.03%
            SRAM:        4100 B        12 KB     33.37%
        IDT_LIST:         120 B         2 KB      5.86%
[82/82] Linking C executable zephyr/zephyr.elf


daniel@daniel-dev-laptop:~/work/zephyrproject/zephyr$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/daniel/work/zephyrproject/zephyr/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.10.0+dev-01340-ga0e8edc4e-dirty (2020-02-14-05:38)
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
Info : clock speed 1000 kHz
Info : STLINK V2J25M13 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.221011
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
    TargetName         Type       Endian TapName            State      
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32f3x.cpu       hla_target little stm32f3x.cpu       running

Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800100c msp: 0x200005f8
Info : device id = 0x10016438
Info : flash size = 64kbytes
auto erase enabled
wrote 12288 bytes from file /home/daniel/work/zephyrproject/zephyr/build/zephyr/zephyr.hex in 0.750689s (15.985 KiB/s)

Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800100c msp: 0x200005f8
verified 11160 bytes in 0.215123s (50.661 KiB/s)

Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
shutdown command invoked

================

A few warnings but I think it is progrming the board OK - I see the interface LED flash and from the above, OCD seems to verify the code.

The only thing I wonder about is which include file to use in my dts file. At the moment I have:

==========

/*
 * Copyright (c) 2017 I-SENSE group of ICCS
 *
 * SPDX-License-Identifier: Apache-2.0
 */

/dts-v1/;
#include <st/f3/stm32f334X8.dtsi>

/ {
model = "STMicroelectronics STM32F334DISCOVERY board";
compatible = "st,stm32f334discovery", "st,stm32f334";

chosen {
zephyr,console = &usart2;
zephyr,shell-uart = &usart2;
zephyr,sram = &sram0;
zephyr,flash = &flash0;
};

leds {
compatible = "gpio-leds";
red_led_U: led_3 {
gpios = <&gpiob 6 GPIO_ACTIVE_HIGH>;
label = "User LD3";
};
blue_led_D: led_6 {
gpios = <&gpiob 7 GPIO_ACTIVE_HIGH>;
label = "User LD6";
};
orange_led_L: led_4 {
gpios = <&gpiob 8 GPIO_ACTIVE_HIGH>;
label = "User LD4";
};
green_led_R: led_5 {
gpios = <&gpiob 9 GPIO_ACTIVE_HIGH>;
label = "User LD5";
};
};

gpio_keys {
compatible = "gpio-keys";
user_button: button {
label = "User";
gpios = <&gpioa 0 GPIO_ACTIVE_LOW>;
};
};

aliases {
led0 = &red_led_U;
sw0 = &user_button;
can-primary = &can1;
};
};
.
.
.
&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>;

/* Set 6Kb of storage at the end of the 64Kb of flash */
storage_partition: partition@e800 {
label = "storage";
reg = <0x0000e800 0x00001800>;
};
};
};

==========


If I change the include file:

#include <st/f3/stm32f334.dtsi>

I now get a build error:
daniel@daniel-dev-laptop:~/work/zephyrproject/zephyr$ west build -p auto -b stm32f334_disco samples/basic/blinky/
[0/1] Re-running CMake...
-- Application: /home/daniel/work/zephyrproject/zephyr/samples/basic/blinky
-- Zephyr version: 2.2.99
-- Board: stm32f334_disco
-- Found west: /home/daniel/.local/bin/west (found suitable version "0.7.2", minimum required is "0.6.0")
-- Found toolchain: zephyr (/home/daniel/zephyr-sdk-0.11.2)
-- Loading /home/daniel/work/zephyrproject/zephyr/boards/arm/stm32f334_disco/stm32f334_disco.dts as base
stm32f334_disco.dts.pre.tmp:49.26-54.6: ERROR (unit_address_vs_reg): /soc/flash-controller@40022000/flash@8000000: node has a unit name, but no reg property
  also defined at stm32f334_disco.dts.pre.tmp:409.9-419.3
stm32f334_disco.dts.pre.tmp:38.25-40.4: ERROR (unit_address_vs_reg): /memory@20000000: node has a unit name, but no reg property
ERROR: Input tree has errors, aborting (use -f to force output)
CMake Error at /home/daniel/work/zephyrproject/zephyr/cmake/dts.cmake:188 (message):
  command failed with return code: 2
Call Stack (most recent call first):
  /home/daniel/work/zephyrproject/zephyr/cmake/app/boilerplate.cmake:465 (include)
  CMakeLists.txt:4 (include)


-- Configuring incomplete, errors occurred!

=====
and the CMakeError is:
/home/daniel/zephyr-sdk-0.11.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: /home/daniel/zephyr-sdk-0.11.2/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/lib/libc.a(lib_a-exit.o): in function `exit':
exit.c:(.text.exit+0x60): undefined reference to `_exit'
collect2: error: ld returned 1 exit status

====

I'm not sure if this the rason that I cannot seem to get blnky running on this board. Ideas? Thank you.

Daniel
Re: Enable traces on Serial Wire Output #debugging

Erwan Gouriou
 

Hi David,

I'm not a SWO user myself but I'm suspecting a clock set up issue.
On FreeRTOS, what was the clock configuration you were using ?

Cheers


On Wed, 11 Mar 2020 at 12:13, Cufi, Carles <Carles.Cufi@...> wrote:

+ Erwan, Simen, Krzysztof, Andrzej

 

As mentioned in an earlier email (to which you replied without context so I had to start a new thread), RTT does work across reboots without problems, at least on Nordic platforms.

 

You wrote:

> Hi, thanks for your feedback ! I have a STM32F746ZE-based board and using west with jlink runner to flash it. I have the same issue when I reset the target via JLink Commander.

 

I do not know whether Zephyr does anything at all to the SWO pin connected to the debugger chip, and especially not on an STM32 platform (I copied Erwan who maintains these boards), but I might be wrong.

 

Carles

 

From: users@... <users@...> On Behalf Of David K via Lists.Zephyrproject.Org
Sent: 10 March 2020 17:13
To: users@...
Cc: users@...
Subject: Re: [Zephyr-users] Enable traces on Serial Wire Output #debugging

 

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks
Re: Enable traces on Serial Wire Output #debugging

William Fish
 
Edited

Hi all,
I use segger ozone to do debugging via RTT it's free download which may be helpful.   
It does have swo trace and STM32 JTAG configuration inbuilt it may be something to consider. 

But I work with Nordic silicon so not sure about the STM chips. 

Billy..
Zephyr+BLE dongle: Maping a USB port and full stack inside

Imóveis Nacionais
 

Hi
This is my first contact with Zephyr project. My question is about good or wrong direction:
I need a BLE 5 "autonomous" dongle similar to BLED112 BLE 4 one. It maps a USB PORT on the computer and 100% hides BLE stack inside (no need for BLE stack on the host computer).
I have already a nRF52840 dongle. I am aware of the Zephyr HCI_USB sample but that sample warns reader that it needs BLUEZ on the host computer (sure because it needs to "speak HCI with the dongle"). So its seems not the right sample on the one handle but the interesting one in order to change it to reach my objective.
I am asking to experienced Zephyr users and programmers about the good direction, tips...

Thanks you
Alex
Re: Enable traces on Serial Wire Output #debugging

Carles Cufi
 

+ Erwan, Simen, Krzysztof, Andrzej

 

As mentioned in an earlier email (to which you replied without context so I had to start a new thread), RTT does work across reboots without problems, at least on Nordic platforms.

 

You wrote:

> Hi, thanks for your feedback ! I have a STM32F746ZE-based board and using west with jlink runner to flash it. I have the same issue when I reset the target via JLink Commander.

 

I do not know whether Zephyr does anything at all to the SWO pin connected to the debugger chip, and especially not on an STM32 platform (I copied Erwan who maintains these boards), but I might be wrong.

 

Carles

 

From: users@... <users@...> On Behalf Of David K via Lists.Zephyrproject.Org
Sent: 10 March 2020 17:13
To: users@...
Cc: users@...
Subject: Re: [Zephyr-users] Enable traces on Serial Wire Output #debugging

 

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks
Re: Enable traces on Serial Wire Output #debugging

David K
 

Hi, thanks for your feedback ! I have a STM32F746ZE-based board and using west with jlink runner to flash it. I have the same issue when I reset the target via JLink Commander.
Re: Enable traces on Serial Wire Output #debugging

Carles Cufi
 

Hi there,

 

We don’t use SWO but RTT (also from Segger) and we don’t need to reset the JLinkRTTViewer/Logger when we reset the target.

Could it be that the way Zephr flashes and then resets the target (pin reset vs software reset) is different from FreeRTOS?

 

In theory this is all handled by the on-board debugger chip so it should make no difference.

 

Which board are you using?

 

Carles

 

From: users@... <users@...> On Behalf Of David K via Lists.Zephyrproject.Org
Sent: 10 March 2020 17:13
To: users@...
Cc: users@...
Subject: Re: [Zephyr-users] Enable traces on Serial Wire Output #debugging

 

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks
Re: Enable traces on Serial Wire Output #debugging

David K
 

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks
Re: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Carles Cufi
 

Hi all,

Due to the switch to summer time in the US, the meeting today is at 17h CET/8AM PDT, so in 15min.

Regards,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 10 March 2020 15:36
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Just a friendly reminder that today's API meeting will be dedicated to
watchdog handling in Zephyr.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 05 March 2020 09:51
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to
watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a
temporary solution to what is ultimately a wider problem that requires
a discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the
CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and
document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and
- Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles
Re: API meeting next week: Focusing on watchdogs

Carles Cufi
 

Hi all,

Just a friendly reminder that today's API meeting will be dedicated to watchdog handling in Zephyr.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 05 March 2020 09:51
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to
watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a
temporary solution to what is ultimately a wider problem that requires a
discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the
CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and
document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-
Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles
Re: Opinions / experiences requested regarding choosing the right IoT embedded OS

Carles Cufi
 

Hi Noëlle,

 

Since I have participated in similar comparison efforts in the past, I thought I may post my two cents here.

Please do bear in mind the following disclaimers:

  • I work for a company that contributes to Zephyr
  • I have been involved with Zephyr for a number of years
  • My knowledge of other open source RTOS is limited to very basic use and examination of the codebase, as well as feedback from experience users
  • ThreadX is currently (still) proprietary and, AFAIK, there’s no way to inspect its source code

 

Trying to reply to your questions here:

 

  1. Yes, there is quite a big difference. Without any hard numbers to support that statement (though those should be easy to collect from commit logs), I believe the situation is quite different for both projects
    1. Contributions to Zephyr tend to come from silicon vendors (Intel, NXP, Nordic and others), from organizations that work closely with silicon vendors (Linaro) or from companies that use Zephyr as an RTOS in their products
    2. Contributions to RIOT seem to come more often from Universities (FU Berlin, INRIA and HAW Hamburg mainly)
    3. The Zephyr contributor base seems to be about 3x the one in RIOT (as per GitHub)
    4. When it comes to advantages and disadvantages, I think the obvious advantage for Zephyr is that silicon vendors tend to know their ICs very well, which makes optimizing for their hardware is more easily achieved. I assume the advantage with more research-oriented contributions (i.e. for RIOT) is the possibility to get access to more innovative (proven or unproven) technologies in some cases
  2. Well, the license is completely different. Zephyr uses the Apache v2.0 license, which is much more permissive than RIOT’s LGPLv2. IANAL, but with RIOT any changes you make to the RTOS codebase you will be obliged to contribute back to the community. With Zephyr anyone can take the codebase at any point in time and modify it at will without any obligations (except for attribution)
  3. Don’t really know RIOT’s model today, but Zephyr uses proven technologies (Devicetree and Kconfig) to describe the hardware and configure the software. RIOT is actually currently working on integrating support for those very technologies in the RTOS, following Zephyr’s steps. Zephyr uses vendor-provided HAL libraries to implement drivers in most cases, which benefit from additional testing and maturity since those HALs are typically used in several other software products, not only Zephyr
  4. I am not sure if there’s a clear, stated goal in terms of using the RTOS, but from experience the goal of the different companies using it seems to be to use it in actual, real-world products. In our case we use it as a building block for our SDK, which is the provided to our customers. Those customers end up making end-products which, by extension, run Zephyr
  5. Yes, power management in particular is under heavy development. I cannot compare to RIOT since I don’t know how much it supports. There are also upcoming changes identified as important by the community such as better timeout handling in the kernel, multiple improvements to the various driver APIs and more.
  6. Likely a few in some areas, but again, without an in-depth comparison it is difficult to share. There are likely some technical advantages to RIOT as well (especially in the area of networking, since RIOT seems to focus more on that).  Typically things like userspace support, multiple architecture support (including Xtensa and now Cortex-A), TEE support are features that are not common in other RTOS outside Zephyr.

 

Thanks,

 

Carles

 

 

From: users@... <users@...> On Behalf Of Noëlle Clement via Lists.Zephyrproject.Org
Sent: 09 March 2020 13:21
To: users@...
Cc: users@...
Subject: [Zephyr-users] Opinions / experiences requested regarding choosing the right IoT embedded OS

 

Hi users part of the Zephyr project!

 

My team is looking into the possibility to transition from a bare-metal application to an OS for our embedded controllers. We develop IoT and wireless sensors solutions, for which we have also developed our own controller and platform. A lot of in-house development and maintenance!

 

Would some of you be willing to answer some questions about why Zephyr OS would be a good choice for us? (The main comparison right now is between Zephyr Project, RIOT-OS and ThreadX)

 

To give a summary of the reasons for even looking into a more advanced architecture: there are a few features common in embedded (IoT) OS' that would be very convenient for future development of the controller. Things like hardware abstraction and task scheduling are very welcome. In general we want to make it easier to maintain the code (pre- and post release) and decrease time-to-market for new controller versions (with new/upgraded hardware modules). A common requirement that also applies to us are the resource constraints and the ultra low power features (we need to be able to use the low power modes for the STM32L151CC, but that can be added in the port). Real-time isn’t a priority for us at all, although the priority (pre-emptive)-based scheduling would be very useful.

The controller is part of the in-house developed IoT system, which currently is mostly used for Smart Waste and Smart Silo products (detecting fill rates in both).

 

A few questions that popped up during my own research on this (mostly about Zephyr vs RIOT):

1) Are there advantages / disadvantages to the different kinds of groups supporting and contributing to Zephyr vs RIOT  (US/Europe, industry/academic, ?/?)

2) Are there advantages / disadvantages I should be aware of for using the OS commercially (compared to RIOT)

3) Are there advantages / disadvantages to the hardware abstraction method Zephyr OS uses (DTS vs HAL?)

4) What is the goal of the development of the OS (use by industry, academic, educational use, hobby projects)?

5) Any technical limitations I should be aware of?

6) Any technical advantages (over RIOT)?

 

Any help is really appreciated!

 

All the best,

Noelle
Re: Opinions / experiences requested regarding choosing the right IoT embedded OS

Lee Courtney <leec2124@...>
 

Hi Noelle,

I'd be interested in contributing to this survey, which is directly applicable to us also. But, only if you collate and publish the results back to the list. Thanks!

--
Lee Courtney
Opinions / experiences requested regarding choosing the right IoT embedded OS

Noëlle Clement
 

Hi users part of the Zephyr project!

My team is looking into the possibility to transition from a bare-metal application to an OS for our embedded controllers. We develop IoT and wireless sensors solutions, for which we have also developed our own controller and platform. A lot of in-house development and maintenance!

Would some of you be willing to answer some questions about why Zephyr OS would be a good choice for us? (The main comparison right now is between Zephyr Project, RIOT-OS and ThreadX)

To give a summary of the reasons for even looking into a more advanced architecture: there are a few features common in embedded (IoT) OS' that would be very convenient for future development of the controller. Things like hardware abstraction and task scheduling are very welcome. In general we want to make it easier to maintain the code (pre- and post release) and decrease time-to-market for new controller versions (with new/upgraded hardware modules). A common requirement that also applies to us are the resource constraints and the ultra low power features (we need to be able to use the low power modes for the STM32L151CC, but that can be added in the port). Real-time isn’t a priority for us at all, although the priority (pre-emptive)-based scheduling would be very useful.
The controller is part of the in-house developed IoT system, which currently is mostly used for Smart Waste and Smart Silo products (detecting fill rates in both).

A few questions that popped up during my own research on this (mostly about Zephyr vs RIOT):
1) Are there advantages / disadvantages to the different kinds of groups supporting and contributing to Zephyr vs RIOT  (US/Europe, industry/academic, ?/?)
2) Are there advantages / disadvantages I should be aware of for using the OS commercially (compared to RIOT)
3) Are there advantages / disadvantages to the hardware abstraction method Zephyr OS uses (DTS vs HAL?)
4) What is the goal of the development of the OS (use by industry, academic, educational use, hobby projects)?
5) Any technical limitations I should be aware of?
6) Any technical advantages (over RIOT)?

Any help is really appreciated!

All the best,
Noelle
Re: Questions about Dynamic Threads

Boie, Andrew P
 

1. Is there any support for runtime creation of a new thread's stack in
k_thread_create(), through the likes of malloc()? I only see
K_THREAD_STACK_DEFINE(), which allocate it at compile-time. I'm porting an
existing library to Zephyr that creates threads (and their
stacks) on-demand, and having compile-time-only stacks would mean that I
have to do some ugly changes to the APIs where stack pointers get passed all
the way through multiple API layers.
There isn't, due to the lack of a memory allocator which returns aligned pointers.

2. I currently work around this by creating "stack pools" through
K_THREAD_STACK_ARRAY_DEFINE(), where each stack can be reused by
another thread once one has finished executing (that's a bit of a waste of
memory though). I do this by locking and releasing these stacks through an
atomic in-use flag. It gets set for the stack before the thread starts, and gets
cleared by the parent thread right after the thread's main function releases a
semaphore at the end of execution in a join-like operation. However, this
fails when a new thread reuses the stack right after the old thread has
released it with a message of "Illegal load of EXC_RETURN into PC". I assume
that's because the previous thread still needs the stack for a while even after
the last instruction in its main function (the release of the join semaphore)
was executed. It's "fixed" by sleeping for a short while before starting a new
thread with the stack, but that's obviously a very unsafe hack. So how would
I know when it's safe to reuse the stack? Does Zephyr allow reusing stacks in
this way at all?
You sound like a good customer for the k_thread_join() API I recently sent a PR for:

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

-Andrew
Questions about Dynamic Threads

David Lerch
 

Hi,

I'm using Zephyr for the first time with the NRF9160, and I have a few
questions about Zephyr's support of threads:

1. Is there any support for runtime creation of a new thread's stack
in k_thread_create(), through the likes of malloc()? I only see
K_THREAD_STACK_DEFINE(), which allocate it at compile-time. I'm
porting an existing library to Zephyr that creates threads (and their
stacks) on-demand, and having compile-time-only stacks would mean that
I have to do some ugly changes to the APIs where stack pointers get
passed all the way through multiple API layers.

2. I currently work around this by creating "stack pools" through
K_THREAD_STACK_ARRAY_DEFINE(), where each stack can be reused by
another thread once one has finished executing (that's a bit of a
waste of memory though). I do this by locking and releasing these
stacks through an atomic in-use flag. It gets set for the stack before
the thread starts, and gets cleared by the parent thread right after
the thread's main function releases a semaphore at the end of
execution in a join-like operation. However, this fails when a new
thread reuses the stack right after the old thread has released it
with a message of "Illegal load of EXC_RETURN into PC". I assume
that's because the previous thread still needs the stack for a while
even after the last instruction in its main function (the release of
the join semaphore) was executed. It's "fixed" by sleeping for a short
while before starting a new thread with the stack, but that's
obviously a very unsafe hack. So how would I know when it's safe to
reuse the stack? Does Zephyr allow reusing stacks in this way at all?


Thanks,

David
API meeting next week: Focusing on watchdogs

Carles Cufi
 

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a temporary solution to what is ultimately a wider problem that requires a discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles
API meeting: agenda

Carles Cufi
 

Hi all,

The topics for today:

- PR: Fix handling of WDT_DISABLE_AT_BOOT option
- https://github.com/zephyrproject-rtos/zephyr/pull/22859

- PR (cont): generalize async notification and add queued operation manager
- https://github.com/zephyrproject-rtos/zephyr/pull/22853

- PR (RFC): asynchronous sequence manager (assuming the relevant stakeholders are present)
- https://github.com/zephyrproject-rtos/zephyr/pull/23075

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
Re: Enable traces on Serial Wire Output #debugging

David K
 

Replying to my own issue:

First I misunderstood module registration:

#include <logging/log.h>
// Must be done outside the function
LOG_MODULE_REGISTER(toto, LOG_LEVEL_DBG);

void main(void)
{
    //...
    LOG_INF("Hello World ! %s\n", CONFIG_BOARD);
    // ...
}

Then, I used west build -t menuconfig to enable:

[*] Logging-->    // This one was not enabled
    [*] Enable Serial Wire Output (SWO) backend
    (0)     Set SWO output frequency

After that I managed to get traces via the JLINK SWO Viewer.

However, it only works if I launch the SWO viewer AFTER my application is launched. If I trigger a reset of the target during a swoview session, I lost traces. I have to re-launch the swo viewer to get the logs again, meaning that I cannot have traces of a reboot for example and I cannot figure out why because the file log_backend_swo_init has the procedure described in JLINK User guide (3.8.4 Configure SWO output after device reset)
Re: simple coap client-server communication of two posix applications #coap

Jukka Rissanen
 

Hi Stefan,

I have had similar issues when zephyr tries to send data to host. In
all cases my firewall was blocking the connection. If this is the case
here, then just allow incoming packets from zeth. In Fedora, I just
mark the zeth as trusted interface in Firewall program.


Cheers,
Jukka

On Fri, 2020-02-28 at 01:19 -0800, Stefan Hristozov wrote:
Hi,
I want to set up a simple setup of two posix projects -- one running
a simple coap server and other running a simple coap client.

What I did so far:

1) I build both
/zephyrproject/zephyr/samples/net/sockets/coap_client and
zephyrproject/zephyr/samples/net/sockets/coap_server without any
changes.



2) I executed ./net-setup.sh. With sudo ifconfig I can see the new
zeth interface:
zeth: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.0.2.2 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 2001:db8::2 prefixlen 128 scopeid 0x0<global>
ether 00:00:5e:00:53:ff txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



3) I started the coap server posix program and tested it by sending a
get request to the core1 resource (I used the coap-cli tool
https://www.npmjs.com/package/coap-cli):

coap get coap://[2001:db8::1]/core1

to which the server replied with:

(2.05) Just a test

So the server works as expected. In addition I used wireshark
sniffing on the zeth interface --> The CoAP get request and the
response was there.



4)I started the client -- on the consol I see:

***** Booting Zephyr OS build v2.0.0-rc2 *****

CoAP client GET

but I cannot see any packets send in wireshark. I think something is
not properly configured probably the zeth interface?

How to test the coap_client sample when running it as a posix
application?

Best regards,
Stefan
541 - 560 of 2455