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 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.

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.

--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