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

Drivers' initialization routines can use __ASSERT() if they want to catch an error in a debug build.

See [Peter]

Folks, For some reason, the signature of functions passed to the DEVICE_INIT() <init_fn> parameter has a return type of 'int', but the return value is never checked within

Hello, please check this proposal and provide feedback if possible.   Background:   Currently several debugging options exists on Kconfig menu but they are not on a single debug submenu, e.g.: -