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