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