|
Re: RFC: return type of functions passed to DEVICE_INIT()
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
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
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2247
·
|
|
Re: [RFC] Add DEV_NOT_IMPLEMENTED error code
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
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
|
By
Andre Guedes <andre.guedes@...>
·
#2248
·
|
|
Re: [RFC] Add DEV_NOT_IMPLEMENTED error code
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
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
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2249
·
|
|
6LoWPAN Stack
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
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
|
By
Joakim Eriksson
·
#2250
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
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
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
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2251
·
|
|
Zephyr SDK and building
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
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
|
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2252
·
|
|
RFC: Use error codes from errno.h
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
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
|
By
Andre Guedes <andre.guedes@...>
·
#2253
·
|
|
compile error for ARM build
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
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
|
By
Ravi Sahita <rsahita@...>
·
#2254
·
|
|
Re: compile error for ARM build
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,
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,
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2255
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
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
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
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2256
·
|
|
RFC: Microkernel tasks pending on nanokernel objects
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.
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.
|
By
Mitsis, Peter <Peter.Mitsis@...>
·
#2257
·
|
|
How to setup git-review
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:
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:
|
By
Andre Guedes <andre.guedes@...>
·
#2258
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
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
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
|
By
Thomas, Ramesh
·
#2259
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
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
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
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2260
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
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
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
|
By
Daniel Leung <daniel.leung@...>
·
#2261
·
|
|
RFC: Kernel's Object Tracing API
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
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
|
By
Cruz Alcaraz, Juan M <juan.m.cruz.alcaraz@...>
·
#2262
·
|
|
Re: compile error for ARM build
that worked - thanks Ben!
Ravi
that worked - thanks Ben!
Ravi
|
By
Ravi Sahita <rsahita@...>
·
#2263
·
|
|
Re: 6LoWPAN Stack
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 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
|
By
Jukka Rissanen
·
#2264
·
|
|
Re: RFC: make _fiber_start() return a handle on the fiber
Hi,
No comments -> no objects -> perhaps we can continue with this route
then?
Cheers,
Jukka
Hi,
No comments -> no objects -> perhaps we can continue with this route
then?
Cheers,
Jukka
|
By
Jukka Rissanen
·
#2265
·
|
|
Re: 6LoWPAN Stack
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
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
|
By
Joakim Eriksson
·
#2266
·
|