Hi Maciek, Would be great to generalize as much as possible now. At least for what's concerning stm32. For instance, maybe gpio/pinmuxer could be generalized as well that way. Tomasz

Hi, Quoting Nashif, Anas (2016-03-04 09:34:45) Nice, let's move on with this convention. I'll send patches to gerrit soon. Thanks all, Andre

Yes please, Thanks. Anas

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