> 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_TYPE     GPIO_OUTPUT_PIN
# elif defined(CONFIG_GPIO_1_IN)
#  define GPIO_1_TYPE     GPIO_INPUT_PIN
# else /* CONFIG_GPIO_1_IRQ */
#  define GPIO_1_TYPE     GPIO_INTERRUPT_PIN
# endif
# define GPIO_1_PIN       2
# define GPIO_1_PORT      5
# define GPIO_1_ADDR      STM32_GPIOE_BASE
#endif  /* CONFIG_GPIO_1      */

That means I should be able to access
arch/arm/src/stm32/hardware/stm32f40xxx_memorymap.h from board.h, which is
no dangerous at all, except that it's not easy

Why not follow that page advice and do it from the C file? Because next C
file is a system-wide file in drivers/ that fills system-wide GPIO struct
with board information. Otherwise, I'd have to make a board function that
fills system-wide struct and replicate that for every board thus recreating
the problem I want to fix.

If STM32 header files were in include/, there would be no problem, so I'm
almost convinced that will be the best solution


>
> On 2/5/2021 7:34 PM, Brennan Ashton wrote:
> > On Fri, Feb 5, 2021, 4:40 PM Grr <gebbe...@gmail.com> 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-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
> >
> > And the arch specific board configuration:
> >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32f4discovery.h
> >
> >
> >
> >>
> >>> 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 just create a
> thin
> >>> driver that wraps everything else inside of it. Bypassing things like
> the
> >>> existing SPI CS or interrupt infrastructure is asking for trouble.
> >>>
> >> Combining my example (I forgot to mention ESP32) with that technique
> means
> >> creating at least 10 thin
> >>
> > You should not need to do that.  Here is an example of how GPIO is
> normally
> > attached. Note this be done in per arch common code but it is arch
> specific.
> >
> >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32_gs2200m.c
> >
> > You could also create a shim for the driver to talk to the generic GPIO
> > interface as we suggested earlier, but I'm not convinced that we would
> gain
> > much with that.
> >
> >
> >>> For example I have a breakout module with a touchscreen, keyboard, and
> SD
> >>> card. This requires the I2C bus, SPI bus, and GPIO for card detection
> and
> >>> chip select.  I just define a common name for the IO on the device and
> >> then
> >>> map that in board.h and then add the callbacks for the GPIO interrupt
> and
> >>> the chip select.  This in total is about 50 lines of actual board code
> >> and
> >>> that is if you are not already using things like the SPI chip select.
> >>>
> >> My idea goes like this:
> >>
> >> 1-Board exports available GPIOs (among other things)
> >> 2-Menuconfig offer GPIOs to user for selection. Selected ones become
> >> available to drivers
> >> 3-User configures needed drivers with selected GPIOs, also in Menuconfig
> >> 4-Compiles
> >> 5-If developing, user can test with incorporated char driver that
> allows to
> >> turn on and off selected GPIOs from a system testing utility
> >
> > To do this you would use the ioexpander/GPIO interface that was
> mentioned.
> > It can provide that functionality but you would still have to write lower
> > half shims for the drivers that would consume GPIO this way.
> >
> >
> >>> --Brennan
> >>>
> >>> On Fri, Feb 5, 2021, 3:08 PM Grr <gebbe...@gmail.com> wrote:
> >>>
> >>>>> 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_freq;
> >>>>>    uint8_t spi_nbits;
> >>>>> };
> >>>>> But, we can reuse ioexpander_dev_s or gpio_dev_s, what's benefit to
> >>> add a
> >>>>> new gpioops_s?
> >>>>>
> >>>> I mean GPIO port, not SPÎ port. I mentioned SPI because GPIOs are
> >> needed
> >>> as
> >>>> chip selects, resets and interrupt inputs for SPI devices
> >>>>
> >>>> But that's only my particular case. Point is to have GPIOs that can be
> >>> used
> >>>> anywhere for anything in a standard way
> >>>>
> >>>> We can add the public interface to arch/archx/include/chipy/chip.h,
> >> like
> >>>>> this:
> >>>>>
> >>>>>
> >>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/arch/arm/include/song/chip.h#L75-L84
> >>>>
> >>>> My question is how to reach arch/arm/src/stm32/stm32.h from
> >>>> include/arch/board/board.h and sort the hardwired assumption of the
> >> rest
> >>> of
> >>>> headers being local. It seems to me that only reasonable solution is
> >>> moving
> >>>> all header files to include/arch/ but I may be wrong
>

Reply via email to