> 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
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
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
, I think the problem is somewhere else
>
> -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
>
> > It is very non-modular if it
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
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
> 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
> 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
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
On Fri, Feb 5, 2021, 8:43 PM Grr wrote:
> Just a final explanation:
>
> "why you want to expose the base address for a GPIO perf
> of a _chip_ everywhere"
>
> It's _not_ everywhere, just the code that includes board.h, just like _any_
> other header file
> gpio_setpin()
Arch specific ones are
Just a final explanation:
"why you want to expose the base address for a GPIO perf
of a _chip_ everywhere"
It's _not_ everywhere, just the code that includes board.h, just like _any_
other header file
And I want gpiodev_s to store specific arch information (the _more_
specific, the better) becau
> What you could do is expose GPIO to a driver via an arch agnostic
> interface.
That's exactly what I'm doing: board.h exposes (or exports) GPIO parameters
and the arch agnostic interface populates corresponding struct gpiodev_s,
accessible via struct gpioops_s functions, just like many other Nu
On Fri, Feb 5, 2021, 7:32 PM Grr wrote:
> If board.h defining a bunch of macros is violating modularity principle,
> then pretty much all NuttX header files are living in sin
>
> What I proposed is _not_ violating modularity more than
> stm32f40xxx_memorymap.h defining STM32_GPIOE_BASE
>
I'm ver
If board.h defining a bunch of macros is violating modularity principle,
then pretty much all NuttX header files are living in sin
What I proposed is _not_ violating modularity more than
stm32f40xxx_memorymap.h defining STM32_GPIOE_BASE
El vie, 5 feb 2021 a las 21:05, Gregory Nutt ()
escribió:
A good modular design should strive to hide information behind
interfaces and not expose that information globally. Global anything is
the path to spaghetti code:
Google for "information hiding in modular design"
* https://john.cs.olemiss.edu/~hcc/csci450/notes/ModularDesign.html
* https://e
Per arch is better but not enough if the goal is to keep header files in
src/ instead of include/, where every interested party would access them
easily
El vie, 5 feb 2021 a las 20:21, Matias N. () escribió:
> I'm not entirely following the problem, but it sounds like you could
> decouple your ar
I'm not entirely following the problem, but it sounds like you could decouple
your arch-independent driver logic in an upper-half and then have a lower-half
per-arch, using board-common drivers (ie. boards/stm32/drivers). The lower-half
would then be able to use stm32 internal headers. In this s
> But there is a problem with it, which is why it's hard to do this. Please
> read the wiki page Greg posted which explains why you cannot include chip
> specific headers in board.h
>
> What is it that must go in there?
>
All this comes from my idea of solving driver balkanization. It's illogical
> Is this helpful?
>
> https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
Maybe but I think it would obscure things. I explain:
Per my idea, exporting available GPIOs is done from board.h like this:
#ifdef CONFIG_GPIO_1
# if defined(CONFIG_GPIO_1_OUT)
# define GPIO_1_
On Fri, Feb 5, 2021, 5:55 PM Grr wrote:
> > It absolutely is not including arch headers will break things.
> >
> > board.h:
> >
> >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
> >
> > And the arch specific board configura
> It absolutely is not including arch headers will break things.
>
> board.h:
>
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
>
> And the arch specific board configuration:
>
> https://www.github.com/apache/incubator-nuttx/tr
Is this helpful?
https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
On 2/5/2021 7:34 PM, Brennan Ashton wrote:
On Fri, Feb 5, 2021, 4:40 PM Grr wrote:
You cannot include arch specific headers in board.h like that! That will
break a lot of things.
board.h is arch
On Fri, Feb 5, 2021, 4:40 PM Grr wrote:
> > You cannot include arch specific headers in board.h like that! That will
> > break a lot of things.
> >
>
> board.h is arch specific
> It absolutely is not including arch headers will break things.
board.h:
https://www.github.com/apache/incubator-nu
> You cannot include arch specific headers in board.h like that! That will
> break a lot of things.
>
board.h is arch specific
> The expectation is that you pass the interfaces that you need into the
> drivers. If you have a particular "module" which contains multiple devices
> that you want t
You cannot include arch specific headers in board.h like that! That will
break a lot of things.
The expectation is that you pass the interfaces that you need into the
drivers. If you have a particular "module" which contains multiple devices
that you want to support across different boards then
>
> Yes, we need an additional struct for port number:
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L49-L57
> struct lcd_ili9486_config_s
> {
> uint8_t power_gpio;
> uint8_t rst_gpio;
> uint8_t spi_cs_num;
> uint8_t spi_rs_gpio;
> uint32_t spi_fre
> -Original Message-
> From: Grr
> Sent: Friday, February 5, 2021 11:56 PM
> To: dev@nuttx.apache.org
> Subject: Re: Proper handling of arch header files
>
> >
>
> > We achieve this by:
> >
> >1. Chip driver implement io expander d
>
> We achieve this by:
>
>1. Chip driver implement io expander driver to encapsulate the gpio
>hardware
>2. Generic driver control the gpio through the io expander driver
>directly e.g.:
>
>
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L72
On Fri, Feb 5, 2021 at 12:26 PM Grr wrote:
> > NuttX already support pinctrl and gpio peripheral:
> >
> >
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/ioexpander.h
> >
> >
> >
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/gpio
> NuttX already support pinctrl and gpio peripheral:
>
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/ioexpander.h
>
>
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/gpio.h
> We can reuse and improve them.
>
I don't mean IO expand
On Fri, Feb 5, 2021 at 3:49 AM Grr wrote:
> Hello to all
>
> I'm developing a Linux-like GPIO system and I need to reach arch
> definitions (for example STM32_GPIOE_BSRR) in a portable way
>
>
NuttX already support pinctrl and gpio peripheral:
https://github.com/apache/incubator-nuttx/blob/master
Hello to all
I'm developing a Linux-like GPIO system and I need to reach arch
definitions (for example STM32_GPIOE_BSRR) in a portable way
Obvious choice is arch/board/board.h but in the case of STM32, there's not
an elegant way to reach arch/arm/src/stm32/stm32.h from there
What would be the pr
41 matches
Mail list logo
