> -----Original Message-----
> From: Grr <gebbe...@gmail.com>
> Sent: Friday, February 5, 2021 11:56 PM
> To: dev@nuttx.apache.org
> Subject: Re: Proper handling of arch header files
>
> >
>
> > We achieve this by:
> >
> > 1. Chip driver implement io expander driver to encapsulate the gpio
> > hardware
> > 2. Generic driver control the gpio through the io expander driver
> > directly e.g.:
> >
> >
> >
> > https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L72-L74
> > int lcd_ili9486_register(FAR const struct lcd_ili9486_config_s
> > *config, FAR struct spi_dev_s *spi, FAR struct ioexpander_dev_s *ioe);
> > Another method is that the generic driver calls the callback provided
> > by the board file to do the custom specific logic.
> >
>
> Struct ioexpander_dev_s can't store pin & port number, pin type or memory
> address
>
> My idea is something like
>
> struct gpiodev_s
> {
> uint8_t num; /* GPIO device number
> */
> uint8_t type; /* GPIO device type
> */
> uint8_t pin; /* Pin number
> */
> uint8_t port; /* A=1, B=2, etc
> */
> uint32_t address; /* Output register adress
> */
>
> FAR const struct gpioops_s *ops;
> };
>
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?
> And there's also the issue of where GPIO devices are registered so user can
> configure several drivers in a compatible way
>
> For example, I have F4Discovery, BluePill and BlackPill boards, and I want to
> connect a couple of SPI CAN devices, a display and a DAQ
> system in different configurations without too much hassle
>
>
> > > > Common code shouldn't reference arch or board specific header
> > > > files,
> > only
> > > > source code under boards/ or arch/ can reference them.
> > > >
> > >
> > > I mean the other way around: board.h referencing common platform
> > > header files, needed for memory definitions
> > >
> >
> > The platform could put the public header files under
> > arch/archx/include/chipy/ and then boards/archx/chipy/boardz can
> > reference these header files.
> >
>
> Most header files are not in include/ but in src/. I couldn't find a simple
> way to fix that, hence my question
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
