Date   

Re: RFC: Watchdog API update.

Michał Kruszewski <mkru@...>
 

I have updated Watchdog API RFC.
I am waiting for feedback!

Michał Kruszewski


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: [Zephyr-devel] RFC: Watchdog API update.
Local Time: August 25, 2017 5:01 PM
UTC Time: August 25, 2017 3:01 PM
From: Michal.Kruszewski@...
To: zephyr-devel@... <zephyr-devel@...>


Hello developers,


As current watchdog API looks like legacy from QMSI I would like to propose some refresh.

My RFC adds support for watchdogs with multiple reload channels. It also enables configuring watchdog timer behavior when CPU is in sleep state as well as when it is halted by the debugger.

The biggest advantage is that it enables  setting watchdog timeout value in human friendly unit of microseconds.


Here is my PR: https://github.com/zephyrproject-rtos/zephyr/pull/1260


I am waiting for feedback!


Regards,

Michał Kruszewski



Re: Remove/change fs_truncate() API

David Brown
 

On Mon, Sep 04, 2017 at 09:27:30AM +0200, Andrzej Kaczmarek wrote:

I was trying to implement fs_truncate() for NFFS but this does not
seem to be possible in a reasonable way, at least not with current
NFFS API. The only option I see now is to copy contents to new file
and unlink old one, but this has obvious disadvantages: it's slow, we
may easily run out of space etc.
If your goal is posix compliance, this isn't going to be right anyway.
truncate is required to be atomic.

The POSIX truncate call is also allowed to be used to extend the size
of a file.

So do we really need option to truncate any opened file to any size?
In Mynewt there's only option to truncate file to 0 when opening it by
specifying flag to fs_open() and this seems to be just enough. There
seems to be not many references to fs API right now (actually
Bluetooth subsystem is the only one) so perhaps we could just remove
fs_truncate() and allow truncate to 0 using something else?

My proposal would be one of:
- add flag to fs_open()
- make fs_truncate() truncate file specified by *path* to 0

The reason why I'd prefer to have truncation done by *path* instead of
*fp* is because it's simpler to implement in NFFS since what needs to
be done is to unlink old file and create new one. The API to create
new file takes full path as a parameter so having fp only makes it a
bit more complicated.
I think it would be better to return ENOTSUP than to implement it in a
non-compliant way. My suggestion would be to document it as not
supported, and make a ticket to add support to NFFS for truncation
later.

David


Re: info about device tree for stm32f412zg

Erwan Gouriou
 

Hi,

According to stm32f412zg datasheet, usart2_pin_c is actually supported on stm32f412zg, so I don't see issue to populate it in stm32f4-pinctrl.dtsi.
Besides, as mentioned by Andy, it's not a problem to be defined in a generic file.
Though you need to take care to enable only what is supported by your board in you project.

This being said, I know we didn't address yet the problem of different packages of a same SoC (64, 100, 144 pins).
In this case it is possible we'll have pins defined for a soc not supported on the smallest package of this SoC.
This does not trigger issues since what matters is the configurations you actually define on your board/project,
but maybe we could split -pinctrl files in -64.dsti, -100.dsti, -144.dtsi files to have a fully clean dts description.
We'll see if this is required.

Erwan


On 9 August 2017 at 19:14, Andy Gross <andy.gross@...> wrote:
On 9 August 2017 at 11:01, massimiliano cialdi
<massimiliano.cialdi@powersoft.it> wrote:
> Fo the nucleo_f412zg there is the file
>
> zephyr/dts/arm/nucleo_f412zg.dts
>
> that includes st/stm32f412.dtsi and then
> #include <st/stm32f412-pinctrl.dtsi>
> #include <st/stm32f411.dtsi>
>
> stm32f411.dtsi indirectly includes stm32f4-pinctrl.dtsi
>
> file stm32f4-pinctrl.dtsi contains
>
> usart2_pins_a: usart2@0 {
>   rx_tx {
>     rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
>   };
> };
> usart2_pins_b: usart2@1 {
>   rx_tx {
>     rx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
>   };
> };
> usart2_pins_c: usart2@2 {
>   rx_tx {
>     rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUPDR_NO_PULL)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_NOPULL)>;
>   };
> };
>
> and if I want to use USART2 I have to add to stm32f412-pinctrl.dtsi
>
> usart2_pins_a: usart2@0 {
>   rx_tx {
>     rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>     tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>   };
> };
> usart2_pins_b: usart2@1 {
>   rx_tx {
>     rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>     tx = <STM32_PIN_PD5 (STM32_PINMUX_ALT_FUNC_7 | STM32_PUSHPULL_PULLUP)>;
>   };
> };
>
> because chip has only those two mux for USART2.
>
> In the compiled dts there is also usart2_pins_c that it doen't actually
> exist in the chip, how to remove it?

So if there are pin differences between the two, then anything non
generic needs to be removed from the .dtsi and put inside a more
specific .dtsi file that is included.  The intent of the definitions
was to allow reuse and make it easier to choose things without having
to consult the manual.

The pins_c should only be appearing if it is defined and someone is using it.

>
> the file stm32f4-pinctrl.dtsi should be generic for stm32f4 family chips. So
> why it contains a specific multiplexing for the usart that has to be
> overridden by specific pinmux files?

If the f412 has differences in pinmuxing from the f4, then those
things needs to be separated out.  The entries in the -pinctrl.dtsi
are used in the actual nodes in the board specific files.  Just
because something is defined does not mean that it is used unless
there is a pinctrl-0/pinctrl-1/pinctrl-2 property in the node that
uses one of the definitions.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Zephyr SDK 0.9.2-rc1

Nashif, Anas
 

0.9.2 RC2 is now available from https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.2-rc2 with the following changes:

 

Changes since 0.9.2-rc1:

 

Anas

 

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Nashif, Anas
Sent: Wednesday, August 30, 2017 10:00 AM
To: Zephyr Devel <devel@...>
Subject: [Zephyr-devel] Zephyr SDK 0.9.2-rc1

 

Hi,

 

We have a new SDK release candidate available @ https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.2-rc1:

 

 

Following changes since 0.9.1:

 

* openocd 0.10.0

  * Zephyr support in openocd

* qemu 2.10.0-rc4

   * 2.10.0-rc4: x86, arm, nios, xtensa

   * 2.7.50: riscv32

* bossac tool update

 

Known Issues:

 

* qemu for NIOS is not compatible with the board configuration available in Zephyr. Work on a fix is in progress.

 

 

Please give it a try and report any issues.

 

Thanks

Anas

 

 


Re: Bluetooth mesh - error when proxy connected

laczenJMS
 

Hi Johan,

With the patch applied I am getting still getting the warning every 10 seconds.

Kind regards,

Jehudi

2017-09-03 8:57 GMT+02:00 Johan Hedberg <johan.hedberg@intel.com>:

Hi Jehudi,

On Sun, Sep 03, 2017, Johan Hedberg wrote:
On Sat, Sep 02, 2017, Laczen JMS wrote:
I am using bluetooth mesh on zephyr. As soon as I make a proxy
connection to a node I am getting errors:

[bt] [ERR] node_id_adv: Failed to advertise using Node ID (err -5)

and after some time this changes to:

[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)

I have set the configuration parameter: CONFIG_BT_MAX_CONN=1.
I think those errors are mostly harmless. What's happening is that the
code tries to re-enable connectable advertising, however since the
controller only supports one connection it results in a failure. We
should probably add an #ifdef somewhere so that the code doesn't attempt
this when BT_MAX_CONN=1.
You could try e.g. the attached patch. It should change the error into a
warning when the connection limit is reached.

Johan


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Yannis Damigos
 

@Bobby I missed that it is a pointer to const u32_t. It is fine.

On Mon, Sep 4, 2017 at 12:01 PM, Yannis Damigos
<giannis.damigos@gmail.com> wrote:
Hi Maciej and Bobby,

you can collaborate on Maciej github repository and push this commit
as a PR there and then to Zephyr's repo.

@Booby You declare vector_table_src as constant and the you change its
value. Does the compiler give you a warning for undefined behavior?

Yannis


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Yannis Damigos
 

Hi Maciej and Bobby,

you can collaborate on Maciej github repository and push this commit
as a PR there and then to Zephyr's repo.

@Booby You declare vector_table_src as constant and the you change its
value. Does the compiler give you a warning for undefined behavior?

Yannis


Re: how to conditionally link a static library in Zephyr?

Paul Sokolovsky
 

Hello,

On Sun, 3 Sep 2017 06:28:52 +0000
"Li, Jun R" <jun.r.li@intel.com> wrote:

Hi there,
I’m trying to build my zephyr app with a static library which is not
provided with its source code. I can achieve the goal by adding the
following two lines in my project’s Makefile:

export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/
export ALL_LIBS += mylib

However, I want to get the static library linked only when a specific
macro is defined, like below

Ifeq ($(CONFIG_ENABLE_MYLIB),y)
export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/
export ALL_LIBS += mylib
endif


Here `CONFIG_ENABLE_MYLIB` is a macro defined in a Kconfig file
somewhere.
Well, that's not specific enough. It's not enough to define a config
option "in a Kconfig file somewhere" for it to be actually available in
Zephyr build process. Nor you explain which Makefile contains
ifeq/endif snippet above.

However, the static library can’t be linked if I used the conditional
option even though the macro CONFIG_ENABLE_MYLIB is enabled in my
“prj.conf”.
With the (sparse) info above, I'd suggest checking that
outdir/$BOARD/.config actually contains CONFIG_ENABLE_MYLIB=y.


So, I’m wondering if anybody has done the similar work and can you
share the experience? Thank you very much!

Regards,
Jun


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Maciej Dębski <maciej.debski@...>
 

Hello Bobby,

amazing, thank you for doing this!
Yes, it works on my Nucleo-F030R8, hello world and blinky, both are fine.

Try to emphasize that this is related to my patch, so these should be released together.
If anyone knows what the procedure is in such cases, please, let me know. Should I just wait?

Thank you,
Maciej Dębski


On Sun, Sep 3, 2017 at 7:22 PM, b0661 <b0661n0e17e@...> wrote:
Hello Maciej,

I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way  execution.

The commit "arch: arm: core: fix vector table relocate write to flash"
https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).

I do not have a board that needs the relocation. So this is untested for such boards.
Nevertheless the commit passes my local sanity check.

If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.

Bobby


2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@...>:
Gentlemen,

thank you for your quick responses!

As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.

Here is the commit:
And here are the specific changes causing problem:

diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
 #include <linker/linker-defs.h>
 #include <nano_internal.h>
 #include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
 
 #ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+    !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+       size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+       memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
 #elif defined(CONFIG_ARMV7_M)
 #ifdef CONFIG_XIP
 #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \


When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?

Thank you!

Yours faithfully,
Maciej Dębski




On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@...> wrote:
Hello,

I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.

I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.

I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!

I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?


This is my pull request. I would focus on dts/arm and include/dt-bindings.

Yours faithfully,
Maciej Dębski


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel




Re: Remove/change fs_truncate() API

Paul Sokolovsky
 

Hello,

On Mon, 4 Sep 2017 09:27:30 +0200
Andrzej Kaczmarek <andrzej.kaczmarek@codecoup.pl> wrote:

Hi,

I was trying to implement fs_truncate() for NFFS but this does not
seem to be possible in a reasonable way, at least not with current
NFFS API. The only option I see now is to copy contents to new file
and unlink old one, but this has obvious disadvantages: it's slow, we
may easily run out of space etc.
ENOTSUP is your friend (except Linux thinks it should be EPERM, see
below).

So do we really need option to truncate any opened file to any size?
POSIX has it:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/ftruncate.html , so we
apparently need it too.

In Mynewt there's only option to truncate file to 0 when opening it by
specifying flag to fs_open() and this seems to be just enough.There
seems to be not many references to fs API right now (actually
Bluetooth subsystem is the only one) so perhaps we could just remove
fs_truncate() and allow truncate to 0 using something else?
In a Linux system, only 0.0001% or so of the source code belongs to the
kernel. With that ratio in mind, how many Zephyr applications have you
considered?

My proposal would be one of:
- add flag to fs_open()
- make fs_truncate() truncate file specified by *path* to 0
Let's have a look at https://linux.die.net/man/2/ftruncate :

truncate(): /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
ftruncate(): /* Since glibc 2.3.5: */ _POSIX_C_SOURCE >= 200112L

So, ftruncate() was categorized in glibc since the break of the century,
while truncate()-by-path is much more of a novelty, which should set
a priority of the order of their support.

The reason why I'd prefer to have truncation done by *path* instead of
*fp* is because it's simpler to implement in NFFS since what needs to
be done is to unlink old file and create new one. The API to create
new file takes full path as a parameter so having fp only makes it a
bit more complicated.
This seems like a logical fallacy: you have a problem with a single
thing on your hands (NFFS) and you want to change the world around it
(Zephyr API). Just accepting that NFFS is a novel, unproven,
underdeveloped and undertested filesystem should give enough of a
solution: just treat ftruncate operation as unsupported on it. Another
solution of course is to fix NFFS to support a standard POSIX
filesystem operation repertoire.

Let's look at https://linux.die.net/man/2/ftruncate again:

EPERM
The underlying file system does not support extending a file beyond its
current size.

However, my local man has more of it:

EPERM The underlying filesystem does not support extending
a file beyond its current size.

EPERM The operation was prevented by a file seal; see fcntl(2).

So, in Linux, EPERM is ambiguous. There's actually a better error code
- ENOTSUP. Arguably, it's the same "POSIX drama" as with EPERM vs
EACCESS, vividly explained here:
http://blog.unclesniper.org/archives/2-Linux-programmers,-learn-the-difference-between-EACCES-and-EPERM-already!.html
Following the same logic, I'd recommend to use ENOTSUP here (then wait
until Zephyr's POSIX subsystem matures, apps getting ported, and break
because of the "non-Linuxy" error code is used, then we switch it to
EPERM).


Best regards,
Andrzej


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Remove/change fs_truncate() API

Andrzej Kaczmarek
 

Hi,

I was trying to implement fs_truncate() for NFFS but this does not
seem to be possible in a reasonable way, at least not with current
NFFS API. The only option I see now is to copy contents to new file
and unlink old one, but this has obvious disadvantages: it's slow, we
may easily run out of space etc.

So do we really need option to truncate any opened file to any size?
In Mynewt there's only option to truncate file to 0 when opening it by
specifying flag to fs_open() and this seems to be just enough. There
seems to be not many references to fs API right now (actually
Bluetooth subsystem is the only one) so perhaps we could just remove
fs_truncate() and allow truncate to 0 using something else?

My proposal would be one of:
- add flag to fs_open()
- make fs_truncate() truncate file specified by *path* to 0

The reason why I'd prefer to have truncation done by *path* instead of
*fp* is because it's simpler to implement in NFFS since what needs to
be done is to unlink old file and create new one. The API to create
new file takes full path as a parameter so having fp only makes it a
bit more complicated.

Best regards,
Andrzej


Re: Adding Nucleo-F030R8 support to Zephyr - runtime error

Bobby
 

Hello Maciej,

I assume the problem is - as Yannis pointed out - the code triggers a write to flash which stops in some way  execution.

The commit "arch: arm: core: fix vector table relocate write to flash"
https://github.com/b0661/zephyr/commit/f171c8ca1b2e7398c97d2423c146392bc8e3c314
works for me on NUCLEO F091RC and I do not see any side effects (but who knows?).

I do not have a board that needs the relocation. So this is untested for such boards.
Nevertheless the commit passes my local sanity check.

If it works for Nucleo-F030R8 too I can prepare a pull request and see whether it passes CI.

Bobby


2017-08-25 14:24 GMT+02:00 Maciej Dębski <maciej.debski@...>:

Gentlemen,

thank you for your quick responses!

As I wanted to provide more info and debug output, I accidentally found the issue.
This little change in arch/arm/core/cortex_m/prep_c.c caused sys fatal error on my f0 board, even before the stm32f0_init.

Here is the commit:
And here are the specific changes causing problem:

diff --git a/arch/arm/core/cortex_m/prep_c.c b/arch/arm/core/cortex_m/prep_c.c
index d23dd8b..1382379 100644
--- a/arch/arm/core/cortex_m/prep_c.c
+++ b/arch/arm/core/cortex_m/prep_c.c
@@ -22,9 +22,20 @@
 #include <linker/linker-defs.h>
 #include <nano_internal.h>
 #include <arch/arm/cortex_m/cmsis.h>
+#include <string.h>
 
 #ifdef CONFIG_ARMV6_M
-static inline void relocate_vector_table(void) { /* do nothing */ }
+
+#define VECTOR_ADDRESS 0
+static inline void relocate_vector_table(void)
+{
+#if defined(CONFIG_XIP) && (CONFIG_FLASH_BASE_ADDRESS != 0) || \
+    !defined(CONFIG_XIP) && (CONFIG_SRAM_BASE_ADDRESS != 0)
+       size_t vector_size = (size_t)_vector_end - (size_t)_vector_start;
+       memcpy(VECTOR_ADDRESS, _vector_start, vector_size);
+#endif
+}
+
 #elif defined(CONFIG_ARMV7_M)
 #ifdef CONFIG_XIP
 #define VECTOR_ADDRESS ((uintptr_t)&_image_rom_start + \


When I deleted the new body of the relocate_vector_table function (to do nothing as it was) - blinky and hello world started to work fine again.
What should I do now? How to report it properly?

Thank you!

Yours faithfully,
Maciej Dębski




On Wed, Aug 23, 2017 at 10:47 AM, Maciej Dębski <maciej.debski@...> wrote:
Hello,

I am developing support for nucleo board, with stm32f030r8 MCU. The goal was to compile and run the samples provided with Zephyr, blinky and hello_world.

I managed to finish the job, all was good, so I have done a pull request. Then, one of the reviewers pointed out that new approach to pinctrl nodes and uart pinctrl configuration in stm32 socs DT files was introduced. I was asked to do appropriate changes.

I modified my code to fit the Zephyr master. Sadly, blinky and hello_world have stopped working. The code itself is compiling and flashing fine. Just the board is reporting a fatal error before even my code is executed.
After checking the code over and over, I think I need help!

I believe most of the values are correct. I just do not fully understand the new dts/arm file structure, which is in Python, maybe I have missed something. Would you be so kind as to look at my code and help me find the issue?


This is my pull request. I would focus on dts/arm and include/dt-bindings.

Yours faithfully,
Maciej Dębski


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: Bluetooth mesh - error when proxy connected

Johan Hedberg
 

Hi Jehudi,

On Sun, Sep 03, 2017, Johan Hedberg wrote:
On Sat, Sep 02, 2017, Laczen JMS wrote:
I am using bluetooth mesh on zephyr. As soon as I make a proxy
connection to a node I am getting errors:

[bt] [ERR] node_id_adv: Failed to advertise using Node ID (err -5)

and after some time this changes to:

[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)

I have set the configuration parameter: CONFIG_BT_MAX_CONN=1.
I think those errors are mostly harmless. What's happening is that the
code tries to re-enable connectable advertising, however since the
controller only supports one connection it results in a failure. We
should probably add an #ifdef somewhere so that the code doesn't attempt
this when BT_MAX_CONN=1.
You could try e.g. the attached patch. It should change the error into a
warning when the connection limit is reached.

Johan


how to conditionally link a static library in Zephyr?

Li, Jun R
 

Hi there,

I’m trying to build my zephyr app with a static library which is not provided with its source code. I can achieve the goal by adding the following two lines in my project’s Makefile:

 

export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/

export ALL_LIBS += mylib

 

However, I want to get the static library linked only when a specific macro is defined, like below

 

Ifeq ($(CONFIG_ENABLE_MYLIB),y)

export LDFLAGS_zephyr += -L$(SOURCE_DIR)/mylib/

export ALL_LIBS += mylib

endif

 

 

Here `CONFIG_ENABLE_MYLIB` is a macro defined in a Kconfig file somewhere.

 

However, the static library can’t be linked if I used the conditional option even though the macro CONFIG_ENABLE_MYLIB is enabled in my “prj.conf”.

 

So, I’m wondering if anybody has done the similar work and can you share the experience? Thank you very much!

 

Regards,

Jun

 


Re: Bluetooth mesh - error when proxy connected

Johan Hedberg
 

Hi Jehudi,

On Sat, Sep 02, 2017, Laczen JMS wrote:
I am using bluetooth mesh on zephyr. As soon as I make a proxy
connection to a node I am getting errors:

[bt] [ERR] node_id_adv: Failed to advertise using Node ID (err -5)

and after some time this changes to:

[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)

I have set the configuration parameter: CONFIG_BT_MAX_CONN=1.
I think those errors are mostly harmless. What's happening is that the
code tries to re-enable connectable advertising, however since the
controller only supports one connection it results in a failure. We
should probably add an #ifdef somewhere so that the code doesn't attempt
this when BT_MAX_CONN=1.

Johan


Bluetooth mesh - error when proxy connected

laczenJMS
 

Hi,

I am using bluetooth mesh on zephyr. As soon as I make a proxy
connection to a node I am getting errors:

[bt] [ERR] node_id_adv: Failed to advertise using Node ID (err -5)

and after some time this changes to:

[bt] [ERR] net_id_adv: Failed to advertise using Network ID (err -5)

I have set the configuration parameter: CONFIG_BT_MAX_CONN=1.

Kind regards,

Jehudi


Re: Counter API ambiguity.

Tseng, Kuo-Lang
 

Hi,


From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Michal Kruszewski via Zephyr-devel
Sent: Monday, August 28, 2017 1:51 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Counter API ambiguity.

In the counter API we can find following function with its description:

/**
* @brief Set an alarm.
* @param dev Pointer to the device structure for the driver instance.
* @param callback Pointer to the callback function. if this is NULL,
*                 this function unsets the alarm.
* @param count Number of counter ticks.
* @param user_data Pointer to user data.
*
* @retval 0 If successful.
* @retval -ENOTSUP if the counter was not started yet.
* @retval -ENODEV if the device doesn't support interrupt (e.g. free
*                        running counters).
* @retval Negative errno code if failure.
*/
static inline int counter_set_alarm(struct device *dev,
    counter_callback_t callback,
    u32_t count, void *user_data)
{
const struct counter_driver_api *api = dev->driver_api;

return api->set_alarm(dev, callback, count, user_data); }

Description: * @param count Number of counter ticks is misleading because it is
not explicitly defined if it is relative count (relative to current counter value) or
absolute counter count value.
Baohong can correct me. I believe this is the number of counter ticks for the counter to send a notification. User would not need to know what current counter value is; when the API is called, the counter would start counting this number of ticks and when it reaches to that many ticks, it would generate a notification, i.e. the callback will be invoked.


Can anyone clarify it and can we make PR to add that information to API so that
application developers do not interpret it in wrong way?

Michał Kruszewski

Sent with ProtonMail Secure Email.


Re: Counter API ambiguity.

Boie, Andrew P
 

Baohong,

 

I see you contributed these APIs to Zephyr, can you help us understand the intention with the "count" parameter to count_set_alarm()?

 

From: Cufi, Carles [mailto:Carles.Cufi@...]
Sent: Friday, September 1, 2017 2:30 AM
To: Michał Kruszewski <mkru@...>; zephyr-devel@...; Tomasz Bursztyka <tomasz.bursztyka@...>; Boie, Andrew P <andrew.p.boie@...>
Subject: RE: [Zephyr-devel] Counter API ambiguity.

 

Hi Tomasz, Andrew

 

Do you have any feedback for Michal regarding the issue below?

 

Thanks!

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Michal Kruszewski via Zephyr-devel
Sent: 28 August 2017 10:51
To: zephyr-devel@...
Subject: [Zephyr-devel] Counter API ambiguity.

 

In the counter API we can find following function with its description:

 

/**

* @brief Set an alarm.

* @param dev Pointer to the device structure for the driver instance.

* @param callback Pointer to the callback function. if this is NULL,

*                 this function unsets the alarm.

* @param count Number of counter ticks.

* @param user_data Pointer to user data.

*

* @retval 0 If successful.

* @retval -ENOTSUP if the counter was not started yet.

* @retval -ENODEV if the device doesn't support interrupt (e.g. free

*                        running counters).

* @retval Negative errno code if failure.

*/

static inline int counter_set_alarm(struct device *dev,

    counter_callback_t callback,

    u32_t count, void *user_data)

{

const struct counter_driver_api *api = dev->driver_api;

 

return api->set_alarm(dev, callback, count, user_data);

}

 

Description: * @param count Number of counter ticks is misleading because it is not explicitly defined if it is relative count (relative to current counter value) or absolute counter count value.

 

Can anyone clarify it and can we make PR to add that information to API so that application developers do not interpret it in wrong way?

 

Michał Kruszewski

 

Sent with ProtonMail Secure Email.

 


Re: Zephyr DFU protocol

Carles Cufi
 

Hi David,

-----Original Message-----
From: David Brown [mailto:david.brown@linaro.org]
Sent: 31 August 2017 17:40
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr DFU protocol

On Wed, Aug 30, 2017 at 09:38:44AM +0000, Cufi, Carles wrote:

That would be my preference as well, but it might not be as trivial as
it sounds. I need to discuss this further with the Mynewt developers,
because some of the abstractions (namely mbuf) might not be easy to
port. Once we choose a protocol, and if this ends up being NMP, I would
like to start those discussions ASAP with the contributions of the
Mynewt community.
I think we should go ahead and start the conversation with them, on
mailing lists.

Unfortunately, the Mynewt mailing lists add a Reply-to header, which
causes that list to "steal" replies that are cross posted. So, you if
you send to both the Zephyr and the Mynewt list, the replies will
randomly discard the Zephyr list, which tends to fork threads (randomly
because it depends on which mailing list server replies quicker, and
which message a given recipient's mail system decides to use, gmail
tends to use the first one, for example).

Feel free to help me apply pressure to get their list configuration
fixed.
I've copied Sterling to see if he can do something about this before we start cross-list conversations.

Regards,

Carles


Re: Bluetooth mesh - provisioning with static OOB

laczenJMS
 

Hi Johan,

The patch solves the issue.

Kind regards,

Jehudi

2017-09-01 12:18 GMT+02:00 Johan Hedberg <johan.hedberg@intel.com>:

Hi,

On Fri, Sep 01, 2017, Johan Hedberg wrote:
On Fri, Sep 01, 2017, Laczen JMS wrote:
I would like to create a zephyr bluetooth mesh node with a public key
using static OOB provisioning. I tried using

static uint8_t static_key[16] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xab,
0xcd, 0xef, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef,};

static const struct bt_mesh_prov prov = {
.uuid = dev_uuid,
.static_val = static_key,
.static_val_len = 16,
.complete = prov_complete,
};

The provisioner (meshctl) never asks for the public key when
provisioning and provisioning fails. Is this the correct way to setup
static OOB ?
I took a look at the Zephyr prov.c code, and it looks like there's a
possible off-by-one error in setting the Static OOB type value in the
Provisioning Capabilities PDU. Does the attached patch help?
After cross-checking with the Mesh spec this does look like a clear bug
to me, so I've opened a PR for it:

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

If things still don't work after this I'd start looking at meshctl code.

Johan

4521 - 4540 of 7817