Is this helpful?
https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
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
