Date   

Re: K_NO_WAIT, K_FOREVER and kernel APIs

Luiz Augusto von Dentz
 

Hi Carles,

On Mon, Aug 21, 2017 at 2:28 PM, Cufi, Carles <Carles.Cufi@...> wrote:
Hi all,

We've had 2 different issues recently coming from the fact that K_NO_WAIT and K_FOREVER do not seem to work with all of the kernel APIs. They are the following:

1) Calling k_timer_start() with K_NO_WAIT, meaning that one desires the timer callback function to be executed as soon as possible. This is useful when one wants to synchronize execution context and start a cyclic timer from the same callback code.
I though k_timer wouldn't be that useful after k_work/k_delayed_work
was introduced, especially given its blocking nature it usually much
easier to just use the system work queue, though that shall not be
blocked.

2) Calling k_sleep() with K_FOREVER as a parameter. This looks reasonable to the developer since it simplifies the typical idling loop that one finds in Zephyr using k_cpu_idle(). Instead the kernel returns immediately, which is unexpected.
And would be awaken by k_wakeup?

I think that, due to the fact that both of those issues have confused our kernel API consumers already, we could consider making K_NO_WAIT and K_FOREVER compatible with all of the kernel APIs.

Thoughts?

Thanks,

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


--
Luiz Augusto von Dentz


Re: K_NO_WAIT, K_FOREVER and kernel APIs

Tomasz Bursztyka
 

Hi Carles,

As you describe the behavior it sounds like a bug to me that, indeed, needs a fix.

Tomasz

Hi all,

We've had 2 different issues recently coming from the fact that K_NO_WAIT and K_FOREVER do not seem to work with all of the kernel APIs. They are the following:

1) Calling k_timer_start() with K_NO_WAIT, meaning that one desires the timer callback function to be executed as soon as possible. This is useful when one wants to synchronize execution context and start a cyclic timer from the same callback code.

2) Calling k_sleep() with K_FOREVER as a parameter. This looks reasonable to the developer since it simplifies the typical idling loop that one finds in Zephyr using k_cpu_idle(). Instead the kernel returns immediately, which is unexpected.

I think that, due to the fact that both of those issues have confused our kernel API consumers already, we could consider making K_NO_WAIT and K_FOREVER compatible with all of the kernel APIs.

Thoughts?

Thanks,

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


Re: Direct flash access from filesystem

Carles Cufi
 

Hi,

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Paul Sokolovsky
Sent: 21 August 2017 11:01
To: Andrzej Kaczmarek <andrzej.kaczmarek@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Direct flash access from filesystem

Hello Andrzej,

On Mon, 21 Aug 2017 10:31:26 +0200
Andrzej Kaczmarek <andrzej.kaczmarek@...> wrote:

Hi all,

I'm porting NFFS (Newtron Flash File System) from Mynewt to Zephyr.
The original fs implementation has direct access to flash, i.e. it
will read, write and erase data to/from flash directly using flash
HAL. But existing fs implementation in Zephyr (FAT12) is using disk
subsystem to access flash so I wanted to do the same in NFFS, however
it does not seem to be useful here because:
- NFFS needs byte-level access to flash - disk subsystem allows
sector-level access only
- NFFS takes case of erasing sectors itself, when required - disk
subsystem does this during writes

​So does it make sense to try to adjust NFFS and/or disk subsystem to
work together? ​Or it's actually better to let NFFS access flash
directly, just as it does in Mynewt?
Well, NFFS is a *flash* filesystem, it's expected that it would require
more specific underlying device type than a generic FS like FAT which
can work on any block device. The situation is similar to Linux, where
JFFS2, etc. require not just a block device, but /dev/mtd (memory
technology device).

So, I wouldn't be surprised that such a requirement arises, but how to
deal with it - extend existing block device interface in Zephyr,
introduce a separate MTD interface, or just work on top of existing
flash drivers, if they are generic enough - that's what more
experienced folks may suggest, I hope.
I think that working directly on top of (standard) flash drivers for a flash filesystem is quite reasonable, since there is no reason to have an additional layer in this particular case. Whether that might have consequences in the future if multiple filesystems are mounted I do not know.

Regards,

Carles


K_NO_WAIT, K_FOREVER and kernel APIs

Carles Cufi
 

Hi all,

We've had 2 different issues recently coming from the fact that K_NO_WAIT and K_FOREVER do not seem to work with all of the kernel APIs. They are the following:

1) Calling k_timer_start() with K_NO_WAIT, meaning that one desires the timer callback function to be executed as soon as possible. This is useful when one wants to synchronize execution context and start a cyclic timer from the same callback code.

2) Calling k_sleep() with K_FOREVER as a parameter. This looks reasonable to the developer since it simplifies the typical idling loop that one finds in Zephyr using k_cpu_idle(). Instead the kernel returns immediately, which is unexpected.

I think that, due to the fact that both of those issues have confused our kernel API consumers already, we could consider making K_NO_WAIT and K_FOREVER compatible with all of the kernel APIs.

Thoughts?

Thanks,

Carles


Re: Direct flash access from filesystem

Paul Sokolovsky
 

Hello Andrzej,

On Mon, 21 Aug 2017 10:31:26 +0200
Andrzej Kaczmarek <andrzej.kaczmarek@...> wrote:

Hi all,

I'm porting NFFS (Newtron Flash File System) from Mynewt to Zephyr.
The original fs implementation has direct access to flash, i.e. it
will read, write and erase data to/from flash directly using flash
HAL. But existing fs implementation in Zephyr (FAT12) is using disk
subsystem to access flash so I wanted to do the same in NFFS, however
it does not seem to be useful here because:
- NFFS needs byte-level access to flash - disk subsystem allows
sector-level access only
- NFFS takes case of erasing sectors itself, when required - disk
subsystem does this during writes

​So does it make sense to try to adjust NFFS and/or disk subsystem to
work together? ​Or it's actually better to let NFFS access flash
directly, just as it does in Mynewt?
Well, NFFS is a *flash* filesystem, it's expected that it would
require more specific underlying device type than a generic FS like
FAT which can work on any block device. The situation is similar to
Linux, where JFFS2, etc. require not just a block device,
but /dev/mtd (memory technology device).

So, I wouldn't be surprised that such a requirement arises, but how
to deal with it - extend existing block device interface in Zephyr,
introduce a separate MTD interface, or just work on top of existing
flash drivers, if they are generic enough - that's what more
experienced folks may suggest, I hope.

I opt for the latter as it makes
porting quite easy. The NFFS partition would be defined in DTS so
this is the only area NFFS code can access. Also all flash operations
are extracted to glue layer so they can be implemented in a different
ways in future, for example if one needs to have NFFS in RAM (which
disk subsystem would allow) for some reason this won't be a problem.

​Comments?​

​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


Direct flash access from filesystem

Andrzej Kaczmarek
 

Hi all,

I'm porting NFFS (Newtron Flash File System) from Mynewt to Zephyr. The original fs implementation has direct access to flash, i.e. it will read, write and erase data to/from flash directly using flash HAL. But existing fs implementation in Zephyr (FAT12) is using disk subsystem to access flash so I wanted to do the same in NFFS, however it does not seem to be useful here because:
- NFFS needs byte-level access to flash - disk subsystem allows sector-level access only
- NFFS takes case of erasing sectors itself, when required - disk subsystem does this during writes

​So does it make sense to try to adjust NFFS and/or disk subsystem to work together? ​Or it's actually better to let NFFS access flash directly, just as it does in Mynewt? I opt for the latter as it makes porting quite easy. The NFFS partition would be defined in DTS so this is the only area NFFS code can access. Also all flash operations are extracted to glue layer so they can be implemented in a different ways in future, for example if one needs to have NFFS in RAM (which disk subsystem would allow) for some reason this won't be a problem.

​Comments?​

​Best regards,
Andrzej​


Re: ADC driver and power management API

Michał Kruszewski <mkru@...>
 

By the way, is ADC API going to be revised soon or is it actual and sufficient?

Michał Kruszewski


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [Zephyr-devel] ADC driver and power management API
Local Time: August 17, 2017 8:09 AM
UTC Time: August 17, 2017 6:09 AM
From: tomasz.bursztyka@...
To: zephyr-devel@...


Hi Piotr,

Good point. ADC API was designed some months before PM one, and was not revised once the later came in.

Sounds like you can throw a PR to remove these.

Thanks,

Tomasz

Hi all,

The ADC driver API specifies adc_enable / adc_disable functions. The doxygen documentation of adc_enable function states: "This routine enables the ADC hardware block for data sampling for the specified device".

This seems to be redundant / conflicts with Zephyr's power management subsystem API. Shouldn't the adc_enable / adc_disable functions be removed?

- Piotr



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




A question for the default value of config option in Kconfig

Wayne Ren
 

Hi

 

I am just working on ARC em starter_kit.  There are several configurations for em_starter_kit, em7d, em9d, em11d.

 

Different configurations have different parameters, i.e. the default value of config option in kconfig. These parameters are defined in the

arch/arc/soc/*/kconfig_defconfig.

 

The default configuration of em_starterkit is em9d.  

 

Then I type “make em_starterkit menuconfig” to get into menuconfig, and change the soc to em7d.

 

RGF_NUM_BANKS of em9d is 2,     of em7d is 1.  

 

When the soc option is changed to em7d,   the default value of RGF_NUM_BANKS  is still 2.

It seems this value only can be changed manually.  The definitions in kconfig_defconfig seems just work once.

 

Then I did another interesting experiment. 

1st step: make BOARD=qemu_x86 menuconfig

2nd step:   change the ARCH from x86 to ARC; select em_starterkit;  make a switch between em7d and em9d

 

I find these default values can change according the change of soc.  The definitions in kconfig_defconfig works as expected

 

 

The above issue is not only for ARC,   I also try other arch and boards, it seems all arch also have such a issue, i.e. the default values cannot change according to different kconfig_defconfig files.

 

 

I explored this issue for some time,  didn’t find a reason to explain this, and no solution.

 

Is it a design or a bug of kconfig?

 

Does anyone know this? or can provide hints?

 

 

Thanks

 

Wayne Ren.

 

 


Zephyr 1.9.0-rc1 tagged

Nashif, Anas
 

Hi all,

 

We have just tagged Zephyr 1.9.0 RC1 which mean we are feature frozen for the 1.9 release planned for the end of August.

Starting with RC1 we will only accept changes introducing bug fixes, documentation and test cases. Any features or enhancements will need to be approved by the TSC.

 

For the 1.9.0 release we will go back to releasing from master, meaning that all the development leading up to the 1.9.0 release will happen in master and not in a branch as we have done up to now. This will streamline development and developers will be submitting fixes to one place only reducing confusion of where to submit what fix. Once 1.9.0 is released we will create a release branch where further 1.9.0 related fixes can land after the release to driver dot releases.

 

Submitting new features for 1.10 can still continue on top of master, however all of the 1.10 changes will be queues until 1.9.0 is released. We however encourage everyone to focus on stabilizing any new features introduced in 1.9.0, write test cases and enhance documentation before we jump to 1.10 development right away.

 

Please review the release notes under doc/release-notes-1.9.rst and submit your input about features and changes you have introduced in the 1.9.0 development cycles ASAP.

 

We want to keep the freeze period as short as possible, so please make sure you submit any bug fixes to outstanding issues as early as possible.

 

Details log of changes since 1.8.0 can be found here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.9.0-rc1

 

We will have more details and release notes with the final release in few weeks time.

 

Thank you everyone for working and contributing to Zephyr.

 

 

Anas


RFCv2: Replacing Make/Kbuild with CMake

Carles Cufi
 

Hi all,

I am resending this email, slightly modified from its original version, since the work on the build system has resumed and we would like to fish for early feedback regarding the work that Sebastian (who has taken over from Joakim) from Nordic is currently undertaking to move from Make to CMake with the hope of improving it, making it run on all platforms and allowing advanced usage of it with different projects and models. In particular we would like to hear from developers who might have objections with the choice of CMake, since now would be the time to voice them and not once we have a complete port.

As some of you may know, our current build system based on Make and Kbuild doesn't play well with Windows hosts, forcing users wanting to build on Windows to install Unix emulation layers such as MinGW or MSYS2. In the search for a truly cross-platform build system CMake immediately arose as a potential candidate, and after some investigation we've come up with a draft of a proposal to use the CMake build system instead.

Here's a short list of reasons we chose CMake as a candidate to prototype:

* CMake is well-known and established, with good support and frequent releases
* It has reasonably strong support for cross-compilation
* It is fast
* Runs natively on all operating systems
* Supports generation of build files (Make, Ninja) as well as IDE projects
* Has a comprehensive set of cross-platform file utilities (cp, mkdir, rm, ...)
* It's easily extensible and configurable through its scripting system

It's important to state that Kconfig is kept unchanged, being invoked as before from the new build system.

Here is a GitHub PR with the initial prototype:

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

Sebastian has added a comprehensive list of limitations, usage guides and TODOs in the PR description, please do go over those before asking questions.

We welcome feedback and suggestions as well as patches to support other architectures, boards and samples.

Regards,

Carles


Re: ADC driver and power management API

Tomasz Bursztyka
 

Hi Piotr,

Good point. ADC API was designed some months before PM one, and was not revised once the later came in.

Sounds like you can throw a PR to remove these.

Thanks,

Tomasz

Hi all,

The ADC driver API specifies adc_enable / adc_disable functions. The doxygen documentation of adc_enable function states: "This routine enables the ADC hardware block for data sampling for the specified device".

This seems to be redundant / conflicts with Zephyr's power management subsystem API. Shouldn't the adc_enable / adc_disable functions be removed?

- Piotr



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



ADC driver and power management API

Piotr Mienkowski
 

Hi all,

The ADC driver API specifies adc_enable / adc_disable functions. The doxygen documentation of adc_enable function states: "This routine enables the ADC hardware block for data sampling for the specified device".

This seems to be redundant / conflicts with Zephyr's power management subsystem API. Shouldn't the adc_enable / adc_disable functions be removed?

- Piotr


Re: Nucleo f030r8 fails at QEMU Cortex M3 test

Boie, Andrew P
 

The deeper context here is that we have a number of timing-sensitive tests which sometimes fall over if the server running sanitycheck is heavily loaded. AFAICT, this is due to QEMU trying to synchronize the emulated system timer with the host workstation timer.

To date, nobody have been able to figure out a way to get QEMU to act differently. What we want is for the emulated system to be completely detached from the host system's sense of timing. Anyone who can figure this out, patches would be most welcome.

Andrew

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Nashif, Anas
Sent: Monday, August 14, 2017 8:39 AM
To: Paul Sokolovsky <paul.sokolovsky@...>; Maciej Debski <maciej.debski@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hi,
There was an issue in how we re-run sanitycheck on failed tests (retry) to eliminate false positive due to heavy load and Qemu not being able to deal with that. This is now fixed.

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Paul Sokolovsky
Sent: Monday, August 14, 2017 11:25 AM
To: Maciej Dębski <maciej.debski@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hello Maciej,

On Mon, 14 Aug 2017 11:31:44 +0200
Maciej Dębski <maciej.debski@...> wrote:

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure,
which is:
*Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test /
qemu_cortex_m3/tests/net/ieee802154/l2/test*

As far as I believe, this test is not related to my board. I am not
sure though. Could you give me some information on how I should react
to this? How can I correct this? What does the test mean? Is there a
way to not test my code with it?
*All* tests fail sooner or later, with or without a reason. (As Murphy would add, non-tests fail sooner or later too.) If you're sure it's random failure not related to your changes, then you just need to resubmit your pull request to trigger a new CI build. To resubmit a PR, its commit revisions should change. The easiest way to achieve that is to rebase on the latest master. If it happens that nobody pushed any new commits to master yet, then you can do something like:

git rebase --ignore-date HEAD^

This will update date of your last commit, thus changing its revision, and will allow to force-push the PR as usual.


Thank you for help,
Maciej Dębski


--
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 _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Nucleo f030r8 fails at QEMU Cortex M3 test

Nashif, Anas
 

Hi,
There was an issue in how we re-run sanitycheck on failed tests (retry) to eliminate false positive due to heavy load and Qemu not being able to deal with that. This is now fixed.

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Paul Sokolovsky
Sent: Monday, August 14, 2017 11:25 AM
To: Maciej Dębski <maciej.debski@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Nucleo f030r8 fails at QEMU Cortex M3 test

Hello Maciej,

On Mon, 14 Aug 2017 11:31:44 +0200
Maciej Dębski <maciej.debski@...> wrote:

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure,
which is:
*Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test /
qemu_cortex_m3/tests/net/ieee802154/l2/test*

As far as I believe, this test is not related to my board. I am not
sure though. Could you give me some information on how I should react
to this? How can I correct this? What does the test mean? Is there a
way to not test my code with it?
*All* tests fail sooner or later, with or without a reason. (As Murphy would add, non-tests fail sooner or later too.) If you're sure it's random failure not related to your changes, then you just need to resubmit your pull request to trigger a new CI build. To resubmit a PR, its commit revisions should change. The easiest way to achieve that is to rebase on the latest master. If it happens that nobody pushed any new commits to master yet, then you can do something like:

git rebase --ignore-date HEAD^

This will update date of your last commit, thus changing its revision, and will allow to force-push the PR as usual.


Thank you for help,
Maciej Dębski


--
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 _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Nucleo f030r8 fails at QEMU Cortex M3 test

Paul Sokolovsky
 

Hello Maciej,

On Mon, 14 Aug 2017 11:31:44 +0200
Maciej Dębski <maciej.debski@...> wrote:

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure,
which is:
*Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test /
qemu_cortex_m3/tests/net/ieee802154/l2/test*

As far as I believe, this test is not related to my board. I am not
sure though. Could you give me some information on how I should react
to this? How can I correct this? What does the test mean? Is there a
way to not test my code with it?
*All* tests fail sooner or later, with or without a reason. (As Murphy
would add, non-tests fail sooner or later too.) If you're sure it's
random failure not related to your changes, then you just need to
resubmit your pull request to trigger a new CI build. To resubmit a PR,
its commit revisions should change. The easiest way to achieve that is
to rebase on the latest master. If it happens that nobody pushed any
new commits to master yet, then you can do something like:

git rebase --ignore-date HEAD^

This will update date of your last commit, thus changing its revision,
and will allow to force-push the PR as usual.


Thank you for help,
Maciej Dębski


--
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


Nucleo f030r8 fails at QEMU Cortex M3 test

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

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure, which is:
Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test / qemu_cortex_m3/tests/net/ieee802154/l2/test

As far as I believe, this test is not related to my board. I am not sure though. Could you give me some information on how I should react to this?
How can I correct this? What does the test mean? Is there a way to not test my code with it?

Thank you for help,
Maciej Dębski


Nucleo f030r8 fails at QEMU Cortex M3 test

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

Hello,

I just posted a pull request for my nucleo f030r8 support. Here it is:
https://github.com/zephyrproject-rtos/zephyr/pull/1103

The shippable ran all the tests correctly, just one with a failure, which is:
Sanitycheck / qemu_cortex_m3:tests/net/ieee802154/l2/test / qemu_cortex_m3/tests/net/ieee802154/l2/test

As far as I believe, this test is not related to my board. I am not sure though. Could you give me some information on how I should react to this?
How can I correct this? What does the test mean? Is there a way to not test my code with it?

Thank you for help,
Maciej Dębski


Re: Bluetooth Mesh - configuration server client and helth server client models

Johan Hedberg
 

Hi Jehudi,

On Fri, Aug 11, 2017, Laczen JMS wrote:
In the bluetooth mesh samples it is shown how to set-up and use the
configuration server and health server root models. Is there also an
example on how to use the configuration client and health client model ?
What are the routines that need to be defined for these models ?
The Client models would typically be operated by a device with a rich &
interactive user interface. As something like that is rarely found on
Zephyr-based device only the Server models are currently implemented.
For implementing client-side models, you could e.g. take example from
the mesh_demo app, which sends configuration messages to the local node
for self-configuration).

Johan


Bluetooth Mesh - configuration server client and helth server client models

laczenJMS
 

Hi,

In the bluetooth mesh samples it is shown how to set-up and use the configuration server and health server root models. Is there also an example on how to use the configuration client and health client model ? What are the routines that need to be defined for these models ?

Thanks, and kind regards,

Jehudi


Re: How to figure out the stack size for a thread?

Li, Jun R
 

Great! Thank you, Mike and Andrew!

 

From: Michael Rosen <michael.r.rosen@...>
Date: Thursday, August 10, 2017 at 11:41
To: "Li, Jun R" <jun.r.li@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: RE: [Zephyr-devel] How to figure out the stack size for a thread?

 

Jun,

 

You can use CONFIG_STACK_USAGE to have the build system generate the .su files which summarize the stack usage (if computable at compile time) of all the functions in all the files. You can use this information to determine the max stack height a thread can reach so long as you know the deepest call path (and what functions are a part of it) but summing all of the static usages. I don’t know of an automated way to do this, but if someone else knows, please chime in!

 

For an experimental approach, see Andrew’s answer.

 

Mike

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Li, Jun R
Sent: Thursday, August 10, 2017 11:08 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] How to figure out the stack size for a thread?

 

 

Hi there,

I’m wondering by which means to figure out the static stack size for a thread? Thank you!

 

Jun Li

NTG | Intel Corporation | Santa Clara

 

5421 - 5440 of 8631