> 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 >
I'm thinking maybe the confusion is I said "arch specific" when I meant "chip specific". I always talked about stm32 (which should be "subarch", not "chip" to have "chip" referring to stm32f407|stm32f103|whatever. Semantics) What I mean is there should be no problem at all calling STM32 header files from a STM32 board (except for the fact they're not in include/ but in src/) And for my purposes, it's needed 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. > I already explained why ioexpander doesn't cut it > > > > > > > > > > --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 > > > > > >
