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 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

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

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

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

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

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

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 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,

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

The following is proposed to permit microkernel tasks to pend on nanokernel objects. Background: ----------- When the nanokernel's background task must wait for a nanokernel object (N.O.) it polls.

Hi all, I was having some trouble to submit a change to Gerrit which depends on someone else's change. If I use the 'git push' command as described in [1], I get the following error: remote: ERROR:

How about a CONFIG option to determine if kernel should abort boot? The behavior should be determined by the kind of application. Some can live with less features while for others it is all or

OK, following your proposal below, what we could put in place is standardizing on error codes that init routines must return if they want the kernel init system to automatically trigger a fatal

For those non-fatal errors, what should we do for runtime driver behaviors? Should the drivers themselves fail API calls? Or should we let device_get_binding() return NULL? ----- Daniel Leung

Zephyr kernel provides debug hooks to allow debugging tools to access nanokernel and microkernel objects (FIFO, LIFO, semaphores, etc.) and display their attributes for content

that worked - thanks Ben! Ravi

Hi Joakim, The plan is to sync it from Contiki when applicable. If you look the code, we needed to make lot of changes to uIP stack in order to make it work in Zephyr. The biggest change is that the

Hi, No comments -> no objects -> perhaps we can continue with this route then? Cheers, Jukka

Hi Jukka! Ok, yes - I expected that there would be quite som changes. But I guess that they will be the same changes at each sync! I will take a look at the codebase and see how much differences you