|
Re: RFC[2/2] Common logging infrastructure and API
Hi Genaro,
The idea is nice, at least it will prevent to declare debug macros
everywhere.
However, split the patch:
- first provide a patch with the logging.h and it's related Kconfig file
- and
Hi Genaro,
The idea is nice, at least it will prevent to declare debug macros
everywhere.
However, split the patch:
- first provide a patch with the logging.h and it's related Kconfig file
- and
|
By
Tomasz Bursztyka
·
#2327
·
|
|
Re: Pinmux driver model: per board vs. unified
yeah better idea :-D when the quark_se gets more design wins things
would get crowded.
Now the question is who is signing up to do the refactoring? :-)
yeah better idea :-D when the quark_se gets more design wins things
would get crowded.
Now the question is who is signing up to do the refactoring? :-)
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2328
·
|
|
Re: Pinmux driver model: per board vs. unified
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes:
[...]
I already started this. Hoping to have something to show later today or
tomorrow.
Cheers,
--
Vinicius
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes:
[...]
I already started this. Hoping to have something to show later today or
tomorrow.
Cheers,
--
Vinicius
|
By
Vinicius Costa Gomes
·
#2329
·
|
|
Re: RFC[2/2] Common logging infrastructure and API
I like this in general we need a common set of debug output macros
that all drivers can use. Currently we have a *bunch* of different
versions of the same thing in use throughout the driver tree.
I
I like this in general we need a common set of debug output macros
that all drivers can use. Currently we have a *bunch* of different
versions of the same thing in use throughout the driver tree.
I
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2330
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
If get binding fails the app will know the device failed or is
otherwise unavailable. The return code from init() tells the kernel
whether it's a fatal error and to call _NanoFatalErrorHandler()
If get binding fails the app will know the device failed or is
otherwise unavailable. The return code from init() tells the kernel
whether it's a fatal error and to call _NanoFatalErrorHandler()
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2331
·
|
|
Re: RFC[2/2] Common logging infrastructure and API
Again, do we want to take over _another_ namespace ? Maybe it should be
sys_debug or sys_dbg or sys_dbg_log ?
The sample implementation is adding all these in logging.h, which is a
public API file:
Again, do we want to take over _another_ namespace ? Maybe it should be
sys_debug or sys_dbg or sys_dbg_log ?
The sample implementation is adding all these in logging.h, which is a
public API file:
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2333
·
|
|
Re: RFC[2/2] Common logging infrastructure and API
It's the MACRO names the need fixed up IMO. Any functions that are
added should be in the sys_* space sure. I didn't see any new C
functions being added.
It's the MACRO names the need fixed up IMO. Any functions that are
added should be in the sys_* space sure. I didn't see any new C
functions being added.
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2332
·
|
|
Re: Pinmux driver model: per board vs. unified
Hi all,
Quoting Vinicius Costa Gomes (2016-02-24 18:34:16)
Yes, I also like this proposal and I think we should move with it instead
of with the proposal I did.
I have just one comment regarding the
Hi all,
Quoting Vinicius Costa Gomes (2016-02-24 18:34:16)
Yes, I also like this proposal and I think we should move with it instead
of with the proposal I did.
I have just one comment regarding the
|
By
Andre Guedes <andre.guedes@...>
·
#2334
·
|
|
Re: Pinmux driver model: per board vs. unified
It would be good to have design changes for pinmux outlined in one text. Are we talking about code consolidation for Quark SE/D2000 or the global change for all pinmuxes? Are we touching the part
It would be good to have design changes for pinmux outlined in one text. Are we talking about code consolidation for Quark SE/D2000 or the global change for all pinmuxes? Are we touching the part
|
By
Dmitriy Korovkin
·
#2335
·
|
|
Re: Pinmux driver model: per board vs. unified
Hi Dmitriy,
Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes:
Good idea, this is going to be useful to see if what I have in mind is
aligned with what other's have.
This is a rough sketch
Hi Dmitriy,
Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes:
Good idea, this is going to be useful to see if what I have in mind is
aligned with what other's have.
This is a rough sketch
|
By
Vinicius Costa Gomes
·
#2336
·
|
|
Re: Pinmux driver model: per board vs. unified
I agree, Galileo is a special case and it's initialization code may/will
share enough code with development part. I think, pinmux_galileo_priv.c
will implement those common functions, am I
I agree, Galileo is a special case and it's initialization code may/will
share enough code with development part. I think, pinmux_galileo_priv.c
will implement those common functions, am I
|
By
Dmitriy Korovkin
·
#2337
·
|
|
[RFC] Nanokernel timers rework proposal
Problem: there are two similar mechanisms in nanokernel: nano_timers and
nano_timeouts. In order to optimize codeand space it's better to have one
mechanism for both.
Proposal: Implement nano_timer
Problem: there are two similar mechanisms in nanokernel: nano_timers and
nano_timeouts. In order to optimize codeand space it's better to have one
mechanism for both.
Proposal: Implement nano_timer
|
By
Dmitriy Korovkin
·
#2338
·
|
|
Re: Pinmux driver model: per board vs. unified
Hi,
Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes:
Exactly, from what I can see, it will be only one common function.
I see. I wouldn't like that these _priv.{c,h} idiom would become
Hi,
Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes:
Exactly, from what I can see, it will be only one common function.
I see. I wouldn't like that these _priv.{c,h} idiom would become
|
By
Vinicius Costa Gomes
·
#2339
·
|
|
STM32F103x port
Hi list,
I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is
hardcoded. The MCU is configured to use internal HSI
Hi list,
I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is
hardcoded. The MCU is configured to use internal HSI
|
By
Maciek Borzecki <maciek.borzecki@...>
·
#2340
·
|
|
Re: STM32F103x port
Hi Maciek,
Very cool!
Cortex-M4 should work as well, since the M4 is a superset of the M3. The
first board we supported is the Freescale FRDM-K64F, which is an M4.
For M0, you have to do an arch
Hi Maciek,
Very cool!
Cortex-M4 should work as well, since the M4 is a superset of the M3. The
first board we supported is the Freescale FRDM-K64F, which is an M4.
For M0, you have to do an arch
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2341
·
|
|
Re: STM32F103x port
Hi Maciek,
This is great stuff, it's totally worth working on porting Zephyr for STM32.
I actually recently got the Nucleo boards F103, F030 and F334 as I was
planning to
play with Zephyr on it.
Hi Maciek,
This is great stuff, it's totally worth working on porting Zephyr for STM32.
I actually recently got the Nucleo boards F103, F030 and F334 as I was
planning to
play with Zephyr on it.
|
By
Tomasz Bursztyka
·
#2342
·
|
|
Re: STM32F103x port
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2343
·
|
|
Re: STM32F103x port
<tomasz.bursztyka(a)linux.intel.com> wrote:
The problem with the dev board that I used is that it's not really
available anymore. To the best of my knowledge, the unit I have is an
older version of
<tomasz.bursztyka(a)linux.intel.com> wrote:
The problem with the dev board that I used is that it's not really
available anymore. To the best of my knowledge, the unit I have is an
older version of
|
By
Maciek Borzecki <maciek.borzecki@...>
·
#2344
·
|
|
RFC: Counter driver API
Hi,
As per suggestion from Gerrit comment, moving the discussion to mailing list.
Background
--------------
On Quark (SE and D2000), there are Always On Counter (free running) and Always ON
Hi,
As per suggestion from Gerrit comment, moving the discussion to mailing list.
Background
--------------
On Quark (SE and D2000), there are Always On Counter (free running) and Always ON
|
By
Tseng, Kuo-Lang <kuo-lang.tseng@...>
·
#2345
·
|
|
Re: STM32F103x port
There is an effort going on right now, details will be provided soon.
Anas
There is an effort going on right now, details will be provided soon.
Anas
|
By
Nashif, Anas
·
#2346
·
|