Date   

Re: Driver model, ISRs and concurrent access

Tomasz Bursztyka
 

Hi Piotr,

1) In general, are driver function APIs supposed to be callable from
an ISR? This limits the amount of kernel primitives a driver
implementation can use, and as I mentioned there is some variation
there. If not all of the driver API functions are allowed to be
called from interrupt context, then should we mark those that are or
are not somehow in the documentation?
Some driver API calls are more prone (or even expected to) to be
called from ISR, whereas others are not, and I think we should make a
clear distinction.
You won't be able to call device drivers API from ISR context, usually.
Mostly because most of the drivers are interrupt based only. As well
as most of them use non-ISR proof kernel functions, as you noticed.
Only UART has a polling mode, which enables console output in ISR mode
as it's useful for debugging.

We thought to provide both modes in the very beginning, but that was
going against the whole preemptive working mode of Zephyr. It could
have been interesting if the kernel would provide a very minimalist
mode, a bit like Contiki does, I guess. Without that, it's more an
hassle of maintaining 2 modes in each drivers. Only UART in the end
has this dual mode for a good reason.

Anyway, if we had to provide polling APIs, the keyword "poll" would
have to be in the API functions names. It would self-document the
behavior. As UART does.
That all sounds reasonable but what about DMA driver? To support
continues, uninterrupted DMA transfer (e.g. audio data) starting the
transfer of the next data block will almost certainly have to happen in
DMA transfer complete callback which runs in ISR context. There is no
time to schedule this task in a work queue or thread. It is possible to
support continues DMA transfer outside of IRS by using DMA linked list
mode but not every DMA driver supports it.
Well, are there any limitation that prevent you from configuring a new DMA transfer on the same channel,
in ISR mode?

(current DMA API is quite tricky to use, but that's another issue).

I said "usually" your are not going to call a device API in ISR mode but I was too broad.
DMA seems a good candidate for being (re)configured in such context.

Sounds like I was too much interrupt vs polling mode based API in my answer, and too focused
on data transfer buses.

2) Is there an agreement on concurrent access to hardware resources
and internal driver data? Some of the drivers seem to protect its
internal data and in some cases through that to the hardware itself
through synchronization mechanisms, but many of those require calling
those APIs from a thread and not from ISR (k_sem_take() etc). Some
even expose this as a Kconfig option from what we can see.
Yep, no consensus on that. QMSI shim drivers introduced - only for
themselves - a re-entrance option.
For the SPI API update, it's made generic only on SPI drivers through
spi_context part. But still no nice and generic device driver way. And
that has been an issue for quite some time already.
Are we talking here about some framework similar to Zephyr's power
management subsystem or simply a well defined policy, e.g. if a call to
a driver API requires access to resources which are in use it should
return immediately with -EBUSY error?

The implementation in QMSI drivers seem to be different. Rather than
returning immediately when the resource is busy they block waiting
indefinitely until the resource becomes available.
A well defined policy, per-device types or per-API, would be nice maybe yes. Using
the same exact types/functions depending on the policy.

Many APIs are made of synchronous calls. Thus the blocking behavior.
But it depends also what type of device you are accessing to.

Handling -EBUSY can be quite a hassle in some. For instance in SPI or I2C it's not something you would like.
It would be then up to the caller to retry, and eventually get the chance to get the resource at some point.
That can be really annoying there.
On other device types, such as watchdog timers, if there is no free-slot for installing a configuration, then
-EBUSY sounds relevant. For instance.

So that behavior has to be defined per-API (and well documented).

Tomasz


Re: Driver model, ISRs and concurrent access

Piotr Mienkowski
 

1) In general, are driver function APIs supposed to be callable from
an ISR? This limits the amount of kernel primitives a driver
implementation can use, and as I mentioned there is some variation
there. If not all of the driver API functions are allowed to be
called from interrupt context, then should we mark those that are or
are not somehow in the documentation?
Some driver API calls are more prone (or even expected to) to be
called from ISR, whereas others are not, and I think we should make a
clear distinction.
You won't be able to call device drivers API from ISR context, usually.
Mostly because most of the drivers are interrupt based only. As well
as most of them use non-ISR proof kernel functions, as you noticed.
Only UART has a polling mode, which enables console output in ISR mode
as it's useful for debugging.

We thought to provide both modes in the very beginning, but that was
going against the whole preemptive working mode of Zephyr. It could
have been interesting if the kernel would provide a very minimalist
mode, a bit like Contiki does, I guess. Without that, it's more an
hassle of maintaining 2 modes in each drivers. Only UART in the end
has this dual mode for a good reason.

Anyway, if we had to provide polling APIs, the keyword "poll" would
have to be in the API functions names. It would self-document the
behavior. As UART does.
That all sounds reasonable but what about DMA driver? To support
continues, uninterrupted DMA transfer (e.g. audio data) starting the
transfer of the next data block will almost certainly have to happen in
DMA transfer complete callback which runs in ISR context. There is no
time to schedule this task in a work queue or thread. It is possible to
support continues DMA transfer outside of IRS by using DMA linked list
mode but not every DMA driver supports it.
2) Is there an agreement on concurrent access to hardware resources
and internal driver data? Some of the drivers seem to protect its
internal data and in some cases through that to the hardware itself
through synchronization mechanisms, but many of those require calling
those APIs from a thread and not from ISR (k_sem_take() etc). Some
even expose this as a Kconfig option from what we can see.
Yep, no consensus on that. QMSI shim drivers introduced - only for
themselves - a re-entrance option.
For the SPI API update, it's made generic only on SPI drivers through
spi_context part. But still no nice and generic device driver way. And
that has been an issue for quite some time already.
Are we talking here about some framework similar to Zephyr's power
management subsystem or simply a well defined policy, e.g. if a call to
a driver API requires access to resources which are in use it should
return immediately with -EBUSY error?

The implementation in QMSI drivers seem to be different. Rather than
returning immediately when the resource is busy they block waiting
indefinitely until the resource becomes available.

Piotr


Re: Driver model, ISRs and concurrent access

Tomasz Bursztyka
 

Hi Carles,

1) In general, are driver function APIs supposed to be callable from an ISR? This limits the amount of kernel primitives a driver implementation can use, and as I mentioned there is some variation there. If not all of the driver API functions are allowed to be called from interrupt context, then should we mark those that are or are not somehow in the documentation?
Some driver API calls are more prone (or even expected to) to be called from ISR, whereas others are not, and I think we should make a clear distinction.
You won't be able to call device drivers API from ISR context, usually.
Mostly because most of the drivers are interrupt based only. As well as most of them use non-ISR proof kernel functions, as you noticed.
Only UART has a polling mode, which enables console output in ISR mode as it's useful for debugging.

We thought to provide both modes in the very beginning, but that was going against the whole preemptive working mode of Zephyr.
It could have been interesting if the kernel would provide a very minimalist mode, a bit like Contiki does, I guess. Without that, it's more an hassle
of maintaining 2 modes in each drivers. Only UART in the end has this dual mode for a good reason.

Anyway, if we had to provide polling APIs, the keyword "poll" would have to be in the API functions names. It would self-document the behavior.
As UART does.

2) Is there an agreement on concurrent access to hardware resources and internal driver data? Some of the drivers seem to protect its internal data and in some cases through that to the hardware itself through synchronization mechanisms, but many of those require calling those APIs from a thread and not from ISR (k_sem_take() etc). Some even expose this as a Kconfig option from what we can see.
Yep, no consensus on that. QMSI shim drivers introduced - only for themselves - a re-entrance option.
For the SPI API update, it's made generic only on SPI drivers through spi_context part. But still no nice and generic device driver way.
And that has been an issue for quite some time already.

Fact that it requires to be called from non-ISR mode goes back to your question 1.

Tomasz


Driver model, ISRs and concurrent access

Carles Cufi
 

Hi there,

We were wondering today about 2 simple questions regarding the Zephyr driver model in general, since there seems to be a mix of approaches in different drivers regarding those and we wanted to clarify them with the developer community:

1) In general, are driver function APIs supposed to be callable from an ISR? This limits the amount of kernel primitives a driver implementation can use, and as I mentioned there is some variation there. If not all of the driver API functions are allowed to be called from interrupt context, then should we mark those that are or are not somehow in the documentation?
Some driver API calls are more prone (or even expected to) to be called from ISR, whereas others are not, and I think we should make a clear distinction.

2) Is there an agreement on concurrent access to hardware resources and internal driver data? Some of the drivers seem to protect its internal data and in some cases through that to the hardware itself through synchronization mechanisms, but many of those require calling those APIs from a thread and not from ISR (k_sem_take() etc). Some even expose this as a Kconfig option from what we can see.

Let me know your thoughts about this.

Regards,

Carles


Comments about a particular IC in a generic API.

Michał Kruszewski <mkru@...>
 

I have implemented driver for nRF RTC. Its internal hardware counter is 24 bit long and it needs software extension. Due to that and some other hardware restrictions setting an alarm is not always possible. I would like to document that IC specific issue in API header file and I am not sure if it is allowed. Here is what I would like to add to function description:

* @retval -ECANCELED if alarm can not be set due to some specific reasons.
* @retval Negative errno code if failure.
*
* @note Nordic Semiconductor SoCs: -ECANCELED is returned if alarm value is
* closer to the current RTC counter value than RTC_MIN_DELTA, or alarm
* value is greater than the current RTC counter value + UINT32_MAX/2.
*/

 Is it permitted or should I add the above documentation in some other place?

Michał Kruszewski

Sent with ProtonMail Secure Email.


Re: K_NO_WAIT, K_FOREVER and kernel APIs

Carles Cufi
 

Hi Luiz,

-----Original Message-----
From: Luiz Augusto von Dentz [mailto:luiz.dentz@...]
Sent: 21 August 2017 13:43
To: Cufi, Carles <Carles.Cufi@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] K_NO_WAIT, K_FOREVER and kernel APIs

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.
Well, I can't really speak to that, but the fact is that an experienced kernel developer (Johan) chose to use k_timer when he implemented the BBC micro:bit display driver. I expect users will make use of those APIs as well.


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?
Yes, I don't see why not. For me the semantics of K_FOREVER imply the amount of time the thread will sleep if left alone, but if a second thread wakes it up I see no reason for it not to wake up.

Thanks,

Carles


Re: K_NO_WAIT, K_FOREVER and kernel APIs

Carles Cufi
 

Hi Tomasz,

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Tomasz Bursztyka
Sent: 21 August 2017 13:41
To: zephyr-devel@...
Subject: Re: [Zephyr-devel] K_NO_WAIT, K_FOREVER and kernel APIs

Hi Carles,

As you describe the behavior it sounds like a bug to me that, indeed,
needs a fix.
I forgot to mention that k_sleep(K_FOREVER) does include an __ASSERT() in the kernel, but since those statements need to be enabled, they will likely not be detected by the average user, who will simply see it return immediately. So yes, I still consider it either a "bug" or something we need to reconsider.

Thanks,

Carles


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

5561 - 5580 of 8778