> Moreover, Kconfig does not (easily/nicely) allow for multiple instances of
> a
> same driver.
>
Having multiple instances of same driver is no different from having
multiple instances of same bus type
menuconfig MCP2515
bool "Microchip MCP2515 CAN Driver Support"
default n
if MCP2515
config M
> DTS mean huge changes and maybe even ditching Kconfig
DTS does not replace Kconfig. Kconfig enables OS options and support
for features. DTS describes presence of resources and how they are
mapped to on-board/on-chip resources (CS line to GPIO is one such example).
Moreover, Kconfig does not (e
El sáb, 6 feb 2021 a las 9:53, Matias N. () escribió:
> That is a separate issue from what we're discussing (arch independent GPIO
> handling) and I agree
> with you. I would like to eventually move to a different initialization
> system based on callbacks
> and a hierarchical resource description
On Sat, Feb 6, 2021 at 7:38 AM Gregory Nutt wrote:
>
> > I am using NuttX-v10.0.1.
> > This is fixed in 625eef20f00fbe9bdb4995ad9dfb24b71227e954, which came at
> a
> > later time.
>
> Hmm.. I guess I still don't understand the failure. That change was:
>
> #ifdef CONFIG_STACK_COLORATION
>
That is a separate issue from what we're discussing (arch independent GPIO
handling) and I agree
with you. I would like to eventually move to a different initialization system
based on callbacks
and a hierarchical resource description strategy which can describe on-board
devices but can be
exten
>
>
> The board would initialize this device as:
>
What if device is external to board? You need to hack code to include
something that's not in any board
That's the proof GPIO subsystem must be configured outside of board logic
I am using NuttX-v10.0.1.
This is fixed in 625eef20f00fbe9bdb4995ad9dfb24b71227e954, which came at a
later time.
Hmm.. I guess I still don't understand the failure. That change was:
#ifdef CONFIG_STACK_COLORATION
- if (tcb->pid != 0)
- {
- memset(tcb->stack_alloc_ptr,
Well.. it's not strange at all :)
I am using NuttX-v10.0.1.
This is fixed in 625eef20f00fbe9bdb4995ad9dfb24b71227e954, which came at a
later time.
I just tried master, which brought the expected results.
Thank you.
Στις Σάβ, 6 Φεβ 2021 στις 5:27 μ.μ., ο/η Gregory Nutt
έγραψε:
> On 2/6/2021 9:
On 2/6/2021 9:13 AM, Fotis Panagiotopoulos wrote:
Indeed I was expecting arm_usestack() to do the colorization, but
apparently it doesn't.
That is what is confusing because it does do the coloration:
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/common/arm_usestack.c#L153
On Sat, Feb 6, 2021, at 12:06, Grr wrote:
> > No, you wouldn't need that. The device driver will receive a generic GPIO
> > handling
> > interface and it would simply assert/deassert CS line without knowing the
> > specifics
> > of the GPIO impementation on the given architecture.
>
>
> That's n
> Those are sources of generic information passed to the drivers. Not
> intrinsic data of the SoC (like its memory map).
>
Then you say the problem was mixing sensitive memory map that breaks
modularity if exposed with GPIO port addresses, absolute requirement for
any GPIO subsystem
No, I think t
On 2/6/2021 9:12 AM, Grr wrote:
It is very non-modular if it exposes internal data. Tha must be
strictly avoided and prohibited in all cases.
So you mean exposing STM32_BOARD_XTAL and STM32_SYSCLK_FREQUENCY is OK but
exposing board IO port address violates modularity
That logic escapes me
T
And the reason arm_usestack() fails to color the stack is because the
following check fails:
if (tcb->pid != 0)
During the task initialization, pid is still 0 so stack is not colored.
Στις Σάβ, 6 Φεβ 2021 στις 5:13 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:
> Indeed I was
Those are sources of generic information passed to the drivers. Not
intrinsic data of the SoC (like its memory map).
-Original Message-
From: Grr [mailto:gebbe...@gmail.com]
Sent: Saturday, February 06, 2021 7:12 AM
To: dev@nuttx.apache.org
Subject: Re: Proper handling of arch header files
Indeed I was expecting arm_usestack() to do the colorization, but
apparently it doesn't.
I cannot have my application code to colorize the stack, as a call to
arm_stack_color() is needed. This is not exposed to the application as far
as i can tell.
> Also Assuming ARM it has to be 8 byte aligned.
> It is very non-modular if it exposes internal data. Tha must be
> strictly avoided and prohibited in all cases.
>
So you mean exposing STM32_BOARD_XTAL and STM32_SYSCLK_FREQUENCY is OK but
exposing board IO port address violates modularity
That logic escapes me
> No, you wouldn't need that. The device driver will receive a generic GPIO
> handling
> interface and it would simply assert/deassert CS line without knowing the
> specifics
> of the GPIO impementation on the given architecture.
That's not what you said. You said:
"In other words, make a SPI de
On 2/6/2021 9:01 AM, Grr wrote:
El sáb, 6 feb 2021 a las 8:57, Gregory Nutt ()
escribió:
A new system, thought from the ground up to solve a problem, doesn't
break
modularity per se
Replacing a correct, modular interface with bad non-modular interlace is
a very bad idea an in opposition to t
El sáb, 6 feb 2021 a las 8:57, Gregory Nutt ()
escribió:
>
> > A new system, thought from the ground up to solve a problem, doesn't
> break
> > modularity per se
>
> Replacing a correct, modular interface with bad non-modular interlace is
> a very bad idea an in opposition to the INVIOLABLES.md th
> That's moving the same problem from one place to another instead of
> eliminating it: you need to rewrite some part of the driver for each
> chip/subchip.
No, you wouldn't need that. The device driver will receive a generic GPIO
handling
interface and it would simply assert/deassert CS line w
A new system, thought from the ground up to solve a problem, doesn't break
modularity per se
Replacing a correct, modular interface with bad non-modular interlace is
a very bad idea an in opposition to the INVIOLABLES.md that guild the
NuttX architecture:
## Modular Architecture
You have to init the memory used for the stack:
Have a look in the normal tasking init , and you will see the call out to
init the stack, that you neeed to call.
arm_usestack() should be called in this case and won't that initialize
(colorize) the stack?
You have to init the memory used for the stack:
Have a look in the normal tasking init , and you will see the call out to
init the stack, that you neeed to call.
Also Assuming ARM it has to be 8 byte aligned. So you need attributes on
your variable called stack to set the alignment.
David
-O
> I understand you are looking for a generic API that can be used from
> drivers to access GPIOs, right?
> I understand this may come up in situations like handling CS lines from
> SPI driver.
Right.
> Currently we handle this by delegating the select line handling to board
> logic completely.
I understand you are looking for a generic API that can be used from drivers to
access GPIOs, right?
I understand this may come up in situations like handling CS lines from SPI
driver. Currently we handle this by delegating the select line handling to
board logic completely.
I thought about thi
Hi,
I am trying to create a new task using a statically allocated stack.
Here is my code:
static struct task_tcb_s tcb;
static uint8_t stack[CONFIG_NETWORK_THREAD_STACKSIZE]
void start_my_thread()
{
memset(&tcb, 0, sizeof(struct task_tcb_s));
tcb.cmn.flags = TCB_FLAG_TTYPE_TASK;
El vie, 5 feb 2021 a las 23:15, Brennan Ashton ()
escribió:
> On Fri, Feb 5, 2021, 8:43 PM Grr wrote:
>
>
> Arch specific ones are not allowed in arch/ or your application
There is no reason to provide your application
>
GPIO system is _not_ my application
We are talking in circles here at t
27 matches
Mail list logo
