That's great. I'll definitely take a look at it. Can you check if drivers in the patchset that I posted are useful for you? Specifically, the UART driver might be reusable across a larger number of

Hej Maciek, I added stm32f4 support to your stm32 patch: https://gerrit.zephyrproject.org/r/#/c/671/ Code is tested to run on Nucleo board included it the patch. Cheers, Pawel

Hi Andre, Tomasz, Jesus, Thanks for your feedbacks. I updated the API with these feedbacks. Please correct or if I missed any part that needed to be reflected. The updated API looks like

Hi all, Quoting Jesus Sanchez-Palencia (2016-03-02 16:03:22) Yes, this is the idea. Back then, I reviewed the error codes usages and this was what I had in mind: DEV_OK = 0 DEV_FAIL =

Hi everyone, Benjamin Walsh <benjamin.walsh(a)windriver.com> wrote: After all the feedback so far (thanks, btw!), the updated list now looks like: DEV_OK = 0 DEV_FAIL =

I think -ENOTSUP is a 1-1 match here: ENOTSUP Operation not supported (POSIX.1)

Do you have a particular use case in mind, w.r.t. UART, that requires user data? At this point, the patch is to simply move the IRQ setup code into the UART drivers. This is not a callback in generic

<maciek.borzecki(a)gmail.com> wrote: Pawel spotted that the linker script was missing. This would prevent people from actually building the code. I've pushed an update

<tomasz.bursztyka(a)linux.intel.com> wrote: Thanks for the comments. I'll wait for everyone to post theirs and try to resolve the issues over the weekend. Cheers, -- Maciek Borzecki

Hi Daniel, I am a bit late on that one. I fully agree on such addition. 1 comment below: Could be wise to add a void *user_data private pointer through the callback. It's something we are missing

Hi Maciek, Thanks for the patches, they are very nicely sliced down. It's quite easy to follow. Just be aware of the code style we apply. Basically the 2 main errors are the missing {} (even for

Hi! You can start by reading our documentation: https://www.zephyrproject.org/doc/collaboration/collaboration.html Any question, just ask in users(a)lists.zephyrproject.org or in

Hi Daniel, <daniel.kalowsky(a)intel.com> wrote:

Hi Daniel, Quoting Daniel Leung (2016-03-02 22:35:24) No, I don't have anything in particular. Probably the bluetooth drivers and the console_uart driver are a good source of use cases. For

Hi everyone, I have uploaded a new iteration of the sensor API patches to Gerrit, you can find them at [1]. We hope to address some of the concerns regarding memory consumption of sensor

I'm sure all of you already got their emails with incoming review request. For others who might be interested as well, I've posted a series of patches to

Hi Andre, I missed the idea that DEV_* will anyway be mapped to errno, so keep DEV_* yes. Actually, follow Jesus's comment. counter_set_alarm() should not star the counter. If you are using 1

Hi Jesus, Quoting Jesus Sanchez-Palencia (2016-03-03 09:52:43) I don't think DEV_NO_SUPPORT will be ever returned by the counter_start API since this is a very basic API and all counter must support

Hi Tomasz, Quoting Tomasz Bursztyka (2016-03-03 05:24:12) Yes, we'll move to errno codes any time soon. I'd prefer we go with the current error code convention (DEV_*) at the moment and fix all

Aloha, Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> wrote: Probably better here to: @retval DEV_NO_SUPPORT if the device doesn't support starting the