Delving into the realm of the hypothetical :-) What about devices that have drivers in the system but are not present (pluggable) or can't initialize because some resource external to the device

Hi Ravi, You probably built for one target, then built for a different one without cleaning up the first build. e.g. $ make <- x86 by default $ make BOARD=qemu_cortex_m3 <- bombs Be default,

anyone else run into this error? thanks, Ravi rlsahita(a)ubuntu:~/zeph/zephyr-project/samples/hello_world/microkernel$ make BOARD=qemu_cortex_m3 ARCH=arm make[1]: Entering directory

Hi all, While we were discussing about adding a new error code for device.h (see "[RFC] Add DEV_NOT_IMPLEMENTED error code" thread), we had an initial agreement that it does make sense to use error

Because my main dev box has been in a steady state of failing for a while now, I moved everything over to a new (to me) development machine (dleung’s dregs, thanks Daniel!) with a fresh install of

For the kind of systems we are targeting, do we really expect the application to handle devices not initializing correctly, being designed so that parts are disabled if some parts of the

Hello! I just cloned the Zephyr repository and saw that the 6LoWPAN stack was the same as the one I am used to - e,g, the Contiki 6LoWPAN stack. How are you planning to develop it further? Are you

A good first step is to redefine DEV_* in terms of -E* error codes :-) Adding the include of errno.h and the removal of DEV_* can happen at our leisure :-) The apps will be getting a consistent set

Hi Jesus, Quoting Jesus Sanchez-Palencia (2016-02-18 12:42:07) Yes. I already had this in mind and I'm going to send the errno.h RFC later today. I was basically replying Daniel's comment and took

Sorry for the slow response. I agree with Peter here I think we should be checking the return value and doing something useful with the result. Maybe not _NanoFatalErrorHandler() but something

Hi, Andre Guedes <andre.guedes(a)intel.com> wrote: Just so we avoid mixing two different topics, it looks like this deserves a separate RFC. The original problem I raised on that code review a few

Hi Daniel, Quoting Kalowsky, Daniel (2016-02-17 05:09:07) I think ENOSYS would perfectly match what we want here since it means "Function not implemented" (as Peter pointed in the other

Fine by me, on both accounts.

I have not received any other feedback w.r.t. this: silence implies consent ? :)

Your proposal seems the simplest to me, the only advantage I see on the more complex one is flexibility, presets could provide settings for multiple scenarios rather than on|off. I would add your

Folks, When we start a fiber via the _fiber_start() API family, we don't get back a handle on the created fiber. The fiber identifier is actually the start of the fiber's stack. This hasn't been a

Hi, I have a problem with minnowboard and it's uart (I use btshell sample for testing and trying to communicate with Bluetooth module using H5 protocol). The problem is, that there is no

Hi Dirk, Quoting Dirk Brandewie (2016-02-12 13:32:31) Yes, sure. If we can use this 'null' implementation in drivers that don't properly implement the suspend/resume callbacks (yet), this will fix