On Fri, Feb 5, 2021, 7:32 PM Grr <gebbe...@gmail.com> wrote:
> If board.h defining a bunch of macros is violating modularity principle,
> then pretty much all NuttX header files are living in sin
>
> What I proposed is _not_ violating modularity more than
> stm32f40xxx_memorymap.h defining STM32_GPIOE_BASE
>
I'm very confused why you want to expose the base address for a GPIO perf
of a _chip_ everywhere. Everything in drivers/ is architecture agnostic so
nothing in there would be able to do anything with it the only thing that
knows what to do with that information is under arch/
What you could do is expose GPIO to a driver via an arch agnostic
interface. Take this example we have two sensors that need GPIO.
There is a single interface that needs to be implemented for the two MCUs.
The board.h file can then indicate which pin of the GPIO to use without any
arch specific information. 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.
IMU. GPS
| |
GPIO--------|
|
[STM32 GPIO]
IMU. GPS
| |
GPIO--------|
|
[ESP32 GPIO]
