|
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
·
|
|
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
·
|
|
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
·
|
|
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
·
|
|
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
·
|
|
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
·
|
|
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] 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
·
|
|
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: 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,
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,
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
|
By
Jesus Sanchez-Palencia <jesus.sanchez-palencia@...>
·
#2246
·
|
|
Re: [RFC] Add DEV_NOT_IMPLEMENTED error code
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
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
|
By
Andre Guedes <andre.guedes@...>
·
#2245
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
Fine by me, on both accounts.
Fine by me, on both accounts.
|
By
Iván Briano <ivan.briano at intel.com...>
·
#2244
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
I have not received any other feedback w.r.t. this: silence implies
consent ? :)
I have not received any other feedback w.r.t. this: silence implies
consent ? :)
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2243
·
|
|
Re: [RFC] Simplifying disable of Kconfig Debugging options
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
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
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2242
·
|
|
Re: [RFC] Add DEV_NOT_IMPLEMENTED error code
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2241
·
|
|
Re: [RFC] Simplifying disable of Kconfig Debugging options
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2240
·
|
|
RFC: make _fiber_start() return a handle on the fiber
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
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
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2239
·
|
|
UART on Minnowboard
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,
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
|
By
Szymon Janc <ext.szymon.janc@...>
·
#2238
·
|
|
Re: [RFC] Add DEV_NOT_IMPLEMENTED error code
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
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
|
By
Andre Guedes <andre.guedes@...>
·
#2237
·
|