devel@lists.zephyrproject.org

Re: Driver model, ISRs and concurrent access

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

By Piotr Mienkowski · #843 ·

Re: Driver model, ISRs and concurrent access

Hi Carles, 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

By Tomasz Bursztyka · #842 ·

Driver model, ISRs and concurrent access

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

By Carles Cufi · #841 ·

Comments about a particular IC in a generic API.

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

By Michał Kruszewski <mkru@...> · #840 ·

Re: K_NO_WAIT, K_FOREVER and kernel APIs

Hi Luiz,

By Carles Cufi · #839 ·

Re: K_NO_WAIT, K_FOREVER and kernel APIs

Hi Tomasz,

By Carles Cufi · #838 ·

Re: K_NO_WAIT, K_FOREVER and kernel APIs

Hi Carles, 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

By Luiz Augusto von Dentz · #837 ·

Re: 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. Tomasz

By Tomasz Bursztyka · #836 ·

Re: Direct flash access from filesystem

Hi,

By Carles Cufi · #835 ·

K_NO_WAIT, K_FOREVER and kernel APIs

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

By Carles Cufi · #834 ·

Re: Direct flash access from filesystem

Hello Andrzej, Andrzej Kaczmarek <andrzej.kaczmarek@...> wrote: Well, NFFS is a *flash* filesystem, it's expected that it would require more specific underlying device type than a generic FS

By Paul Sokolovsky · #833 ·

Direct flash access from filesystem

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

By Andrzej Kaczmarek · #832 ·

Re: ADC driver and power management API

By the way, is ADC API going to be revised soon or is it actual and sufficient? Michał Kruszewski Sent with ProtonMail Secure Email.

By Michał Kruszewski <mkru@...> · #831 ·

A question for the default value of config option in Kconfig

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

By Wayne Ren · #830 ·

Zephyr 1.9.0-rc1 tagged

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

By Nashif, Anas · #829 ·

RFCv2: Replacing Make/Kbuild with CMake

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

By Carles Cufi · #828 ·

Re: ADC driver and power management API

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.

By Tomasz Bursztyka · #827 ·

ADC driver and power management API

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

By Piotr Mienkowski · #826 ·

Re: Nucleo f030r8 fails at QEMU Cortex M3 test

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

By Boie, Andrew P · #825 ·

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

By Nashif, Anas · #824 ·

Messages