|
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
·
|
|
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: 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
·
|
|
[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
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
·
|
|
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
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 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: 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: 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: 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
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: 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: 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: 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: RFC[2/2] Common logging infrastructure and API
Hi Genaro,
<genaro.saucedo.tejada(a)intel.com> wrote:
I welcome these changes but Im not so sure logging levels are actually
necessary if one can define different domains, at least in case
Hi Genaro,
<genaro.saucedo.tejada(a)intel.com> wrote:
I welcome these changes but Im not so sure logging levels are actually
necessary if one can define different domains, at least in case
|
By
Luiz Augusto von Dentz
·
#2326
·
|
|
RFC[2/2] Common logging infrastructure and API
From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001
From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com>
Date: Fri, 19 February 2016 23:10:28 +0000
Subject: [PATCH] Log
From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001
From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com>
Date: Fri, 19 February 2016 23:10:28 +0000
Subject: [PATCH] Log
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2325
·
|
|
RFC[1/2] Common logging infrastructure and API
Hello, please review this proposal and provide feedback if possible.
This email should be followed by a patch containing a prototype
implementation for reference but not meant to be
Hello, please review this proposal and provide feedback if possible.
This email should be followed by a patch containing a prototype
implementation for reference but not meant to be
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2324
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
Thanks for pointing out the facts and issues :-) I agree it cannot be
used as a replacement for proper handling of resume() by devices.
Thanks for pointing out the facts and issues :-) I agree it cannot be
used as a replacement for proper handling of resume() by devices.
|
By
Thomas, Ramesh
·
#2323
·
|
|
Re: Pinmux driver model: per board vs. unified
Hi Dirk,
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes:
[...]
I like it.
The only thing I am thinking about is polluting the drivers/pinmux/
directory when there are more than a couple of
Hi Dirk,
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes:
[...]
I like it.
The only thing I am thinking about is polluting the drivers/pinmux/
directory when there are more than a couple of
|
By
Vinicius Costa Gomes
·
#2322
·
|