On Thu, Jan 7, 2021 at 9:51 PM Grr <gebbe...@gmail.com> wrote: > > It is abstracted, for example see this file. > > > > > https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140 > > > > You mean GPIO_MCP2515_CS? I don't quite understand its definition > > #define GPIO_MCP2515_CS (GPIO_OUTPUT|GPIO_OTYPER_PP(0)|GPIO_SPEED_2MHz|\ > GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4) > > I guess it's a way to combine different configuration bits with pin 4. > > Problem is it's only defined for pin 4 and only in a handful of STM32 > boards.
This is board and arch specific and cannot be more generalized than that. They will have different requirements for pullups, speed, etc. The define should also start with BOARD_ but some use GPIO_. This is the case for all PINs including UART, GPIO, SPI, USB, etc... Most systems besides SPI or GPIO you wont have to directly pass this pin config you just define something like #define BOARD_UART_0_TX_PIN (GPIO_INPUT | GPIO_PULLUP | GPIO_FUNC_UART | GPIO_PIN16) #define BOARD_UART_1_RX_PIN (GPIO_INPUT | GPIO_PULLUP | GPIO_FUNC_UART | GPIO_PIN3) and the drivers will already have conditionals on those being defined. SPI is just a little special because you dont _need_ a CS gpio pin, but frequently you want it. So you end up with the board specific hooks for what pin to turn on. as is here https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140 SPI drivers cannot depend on a fixed name for the CS pin because you may have multiple instances (what I thought you were asking to support) > > What happens if I want to use that driver with a PIC32MX board and I'm not > a kernel developer? > What happens if pin 4 is already used and I *need* to use pin 5 and again > I'm not a kernel developer? You just update the define in your board.h file to include a mapping for what is wired up to pin 5. When you are bringing up your board one of the first things you should do is define the pins in your board.h > > My idea is to bring that level of configuration ability into menuconfig > > Are those GPIO_* macros work across architectures so they can be brought to > menuconfig and combined there in a newbie-friendly way? It seems > GPIO_OUTPUT exists in all architectures but I don't know it if works the > same way everywhere Changing how pins are defined would break everyone so that is unlikely to change, and it is also not really something that can easily be mapped to Kconfig. You already have to add the initialization logic and this is just another step in that. --Brennan
