|
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,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. -- Luiz Augusto von Dentz
|
|
|
|
Re: K_NO_WAIT, K_FOREVER and kernel APIs
Tomasz Bursztyka
Hi Carles,
toggle quoted messageShow quoted text
As you describe the behavior it sounds like a bug to me that, indeed, needs a fix. Tomasz
Hi all,
|
|
|
|
Re: Direct flash access from filesystem
Carles Cufi
Hi,
toggle quoted messageShow quoted text
-----Original Message-----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,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 -- 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?
|
|
|
|
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
|
|
|
|
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.
toggle quoted messageShow quoted text
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,*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.
-- 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,
toggle quoted messageShow quoted text
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,*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.
-- 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,*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.
-- 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/ Sanitycheck / qemu_cortex_m3:tests/net/ 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 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
Hi Jehudi,
On Fri, Aug 11, 2017, Laczen JMS wrote: In the bluetooth mesh samples it is shown how to set-up and use theThe 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@...>
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
|
|
|