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