Just a final explanation: "why you want to expose the base address for a GPIO perf of a _chip_ everywhere"
It's _not_ everywhere, just the code that includes board.h, just like _any_ other header file And I want gpiodev_s to store specific arch information (the _more_ specific, the better) because gpio_setpin() is no time to look things up or decode complicated schemas. When a driver issues a pin change, it wants it to change NOW, not some time in the future when the bureaucracy is ok with it. For example, in the case of STM32, I intend to use BSRR instead of read/modify/write ODR. So the challenge is to design a single structure that can accommodate the most detailed information of any arch and use the fastest way for pin input or output That's why I want STM32_GPIOE_BASE (or any other arch specific address) in gpiodev_s El vie, 5 feb 2021 a las 22:18, Grr (<gebbe...@gmail.com>) escribió: > > What you could do is expose GPIO to a driver via an arch agnostic >> interface. > > > That's exactly what I'm doing: board.h exposes (or exports) GPIO > parameters and the arch agnostic interface populates corresponding struct > gpiodev_s, accessible via struct gpioops_s functions, just like many other > NuttX systems do > > >> The board.h file can then indicate which pin of the GPIO to use without >> any >> arch specific information > > > That's hardwiring the driver and it's what I'm trying to avoid > > >> The arch specific GPIO interface implemention >> worried about how to read/write etc for pin1, whatever pin1 actually is on >> the chip/board what you have. Doing this let's you write almost no board >> specific code. This is very much how device trees look like in Linux. >> > > Yes, the arch specific GPIO interface called via gpioops_s functions > > So we're always been in agreement >
