I'm not entirely following the problem, but it sounds like you could
decouple your arch-independent driver logic in an upper-half and then have
a lower-half per-arch, using board-common drivers (ie.
boards/stm32/drivers). The lower-half would then be able to use stm32
internal headers. In this scenario, you don't need to replicate things
per-board, only per-arch (which I guess is the minimum you could do if
you're using stm32 specific pin handling).
Best,
Matias
On Fri, Feb 5, 2021, at 23:13, Grr wrote:
Is this helpful?
https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
Maybe but I think it would obscure things. I explain:
Per my idea, exporting available GPIOs is done from board.h like this:
#ifdef CONFIG_GPIO_1
# if defined(CONFIG_GPIO_1_OUT)
# define GPIO_1_TYPE GPIO_OUTPUT_PIN
# elif defined(CONFIG_GPIO_1_IN)
# define GPIO_1_TYPE GPIO_INPUT_PIN
# else /* CONFIG_GPIO_1_IRQ */
# define GPIO_1_TYPE GPIO_INTERRUPT_PIN
# endif
# define GPIO_1_PIN 2
# define GPIO_1_PORT 5
# define GPIO_1_ADDR STM32_GPIOE_BASE
#endif /* CONFIG_GPIO_1 */
That means I should be able to access
arch/arm/src/stm32/hardware/stm32f40xxx_memorymap.h from board.h, which
is
no dangerous at all, except that it's not easy
Why not follow that page advice and do it from the C file? Because next C
file is a system-wide file in drivers/ that fills system-wide GPIO struct
with board information. Otherwise, I'd have to make a board function that
fills system-wide struct and replicate that for every board thus
recreating
the problem I want to fix.
If STM32 header files were in include/, there would be no problem, so I'm
almost convinced that will be the best solution
On 2/5/2021 7:34 PM, Brennan Ashton wrote:
On Fri, Feb 5, 2021, 4:40 PM Grr <gebbe...@gmail.com> wrote:
You cannot include arch specific headers in board.h like that!
That
will
break a lot of things.
board.h is arch specific
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
The expectation is that you pass the interfaces that you need into
the
drivers. If you have a particular "module" which contains multiple
devices
that you want to support across different boards then just create a
thin
driver that wraps everything else inside of it. Bypassing things
like
the
existing SPI CS or interrupt infrastructure is asking for trouble.
Combining my example (I forgot to mention ESP32) with that technique
means
creating at least 10 thin
You should not need to do that. Here is an example of how GPIO is
normally
attached. Note this be done in per arch common code but it is arch
specific.
https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32_gs2200m.c
You could also create a shim for the driver to talk to the generic
GPIO
interface as we suggested earlier, but I'm not convinced that we
would
gain
much with that.
For example I have a breakout module with a touchscreen, keyboard,
and
SD
card. This requires the I2C bus, SPI bus, and GPIO for card
detection
and
chip select. I just define a common name for the IO on the device
and
then
map that in board.h and then add the callbacks for the GPIO
interrupt
and
the chip select. This in total is about 50 lines of actual board
code
and
that is if you are not already using things like the SPI chip
select.
My idea goes like this:
1-Board exports available GPIOs (among other things)
2-Menuconfig offer GPIOs to user for selection. Selected ones become
available to drivers
3-User configures needed drivers with selected GPIOs, also in
Menuconfig
4-Compiles
5-If developing, user can test with incorporated char driver that
allows to
turn on and off selected GPIOs from a system testing utility
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.
--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
