NEW JIRA items within last 24 hours: 4 [ZEP-190] Failed to receive loopback packet. https://jira.zephyrproject.org/browse/ZEP-190 [ZEP-187] BLE APIs are not documented

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1360 : sensor: fix init driver_api - https://gerrit.zephyrproject.org/r/1357 : sensors: use SENSOR_G constant in all accelerometer

Hi Benjamin, Thus why we may enforce a version of the API vs a Zephyr version. And move on with a new one. If they want to get stuck with API 1.0 they could use Zephyr 1.2 (1.3 maybe) and that's

I already got feedback from people developing either drivers or sample application for Rocket, basically playing to role of customers of Zephyr, and I can already say that, for people used to writing

Hi Dmitriy, <dmitriy.korovkin(a)windriver.com> wrote: By kernel I guess you mean that each fiber has a capability to run timers, which is not useful in case of net subsystem since that requires each

Hi Daniel and Anas, Saving even a minimal amount of bytes is good to consider, as long as it does not reduce features etc... and that RFC is actually fixing things. How long are we supposed to

Hi Ramesh, The idea is to let the driver decide whether it is still functioning or not. Unusable state is a critical error to me. A non critical error, means it is still ok to work, thus the driver

Not sure how the method in the RFC differentiates between critical and non-critical errors. Isn't the driver also *not* passing on the non-critical error status to the app by not setting device_api =

Hi IMO the driver interface is still considered public APIs. Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers. Anas

I am not quite sure I understand the problem. Kernel keeps the track of nanokernel timers and timeouts. If needed, each fiber can wait on a timer (one fiber per timer). Not sure, what is the need for

Hi Juan,

Carles, Carles, thanks for digging into the issue. There is a JIRA report already reporting this behavior (ZEP-177). Please follow the development of ZEP-177 to get a resolution to the issue.

You can follow the link and go to the top message. The idea was first proposed by Benjamin Walsh to get rid of return values. This RFC was just a tiny part of that. The init change will be in another

NEW JIRA items within last 24 hours: 0 UPDATED JIRA items within last 24 hours: 0 CLOSED JIRA items within last 24 hours: 0 RESOLVED JIRA items within last 24 hours: 0

Hi there, I've followed the steps outlined here: https://www.zephyrproject.org/doc/getting_started/installation_win.html to compile Zephyr on Windows. The first problem I encountered was that the

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1341 : sensor: add driver for LSM9DS0 accel and magn - https://gerrit.zephyrproject.org/r/1340 : sensor: add the posibility to fetch

Hi Marcel, Do you have anything to add? Or is this something that came out while discussing with Daniel due to my MSR? <daniel.kalowsky(a)intel.com> wrote: -- Luiz Augusto von Dentz

Hi Daniel, Ok I missed that discussion. Your RFC patch was not clear about that. It would require to change the init function signature and all the existing drivers in one go as well. I hope we

NEW JIRA items within last 24 hours: 0 UPDATED JIRA items within last 24 hours: 0 CLOSED JIRA items within last 24 hours: 0 RESOLVED JIRA items within last 24 hours: 0