Hi Johan, I fully agree on that. It saves a pointer in case the user does not want to access any private data, and thus leaves space for adding pin mask in the struct. Tomasz

Hi Tomasz, A perhaps slightly more compact solution (and a pattern I see a log e.g. in Linux) is to take advantage of CONTAINER_OF. You'd first drop user_data from the gpio_callback and pass the

Hi, I would like to propose some changes to the public GPIO API. Addressing major 2 issues which I faced while writing some code using the API. And an third one, related to the consistency of the

Hi Andre, Looks like we are moving to Posix error codes, so it would be wise to do it here as well. (better now than after the API is upstream). Apply that to all. Set an alarm callback. If the

Hello zephyr team!!! I am Himanshu, I am junior undergrad at Indian Institute of Information Technology Design & Manufacturing Jabalpur . I have been looking for an opportunity for working in an OS

Hi, After resolving some issues with git and a slight delay, here is the first release candidate for Zephyr v1.1.0. Below you will find all the changes since v1.0.0. A summary of the changes since

This is something I have thought about, but there is no concrete plan. Is there anything particular you are looking for? Use cases would be a good start. This helps me to understand what needs to be

Hi Daniel, Quoting Daniel Leung (2016-03-01 21:04:02) This is actually a nice improvement on the UART API since it moves the burden of registering the ISR from the user layer to the driver

Hi Jesus, -EACCES? EAGAIN doesn't seem like the best match here. Johan

Jesus Sanchez-Palencia <jesus.sanchez-palencia(a)intel.com> wrote: I forgot to mention that whichever guidelines come out of this thread, I will move to QMSI so we are all aligned.

Hi guys, Quoting Tseng, Kuo-Lang (2016-02-26 17:29:17) As a generic API we should be able to address counters devices with different features such as counting up and counting down, free running,

Hi, Andre Guedes <andre.guedes(a)intel.com> wrote: Cool! +1 from my side, mainly so we don't need to discuss the addition of new error codes ever again :). I would say it's more about 3) and 4)

Because of the pointer dereference, the check for NULL and the function call ? It's probably OK. And you could turn the check into an __ASSERT() if you want to save a bit or both code space and

stm32 is very generic, we should consider placing the series at the top level under soc/ and have the supported SoCs below it. So for STM32 we will end up with stm32f0/

This could be implemented without a "global" category but providing an menu option to rise log level of every category lower than user input. Currently I have a "default" log level to deal with

I mean applications could rely on log API to report the most important messages even in a complete application (that's what I meant by production), it wouldn't make sense to expect a terminal in that

The main issue with this is the fact that stm32 extends all the way from M0 to M7, in total set of 11 series • STM32F0 Series • STM32F1 Series • STM32F2 Series • STM32F3 Series •