On Thu, Jan 7, 2021 at 8:20 PM Grr <gebbe...@gmail.com> wrote: > > I've been working towards creating a unified (character or SocketCAN) > driver model for SPI CAN controller MCP2515 and I found out that SPI_* > macro family allow platform-neutral SPI device control but there's one > thing I cannot find: > > Is it possible to abstract chip select (CS) definition and usage in a > similar way?
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 There is a case for each device on the SPI bus and with that the driver. > > Question arises from the fact that most SPI drivers are initialized (and > *de facto supported*) per board but many (if not most) boards offer SPI > external connectivity so any *collection* of SPI devices can be connected > to any such board > > Since most drivers are initialized *per board*, any given *supported* > device cannot be used in any given board without initialization being > "ported" to that board, something a basic user cannot do The MCP2515 dynamically allocates so this is not a problem: https://github.com/apache/incubator-nuttx/blob/c8ff295d59c0360943abcaf19177cd0556f37f47/drivers/can/mcp2515.c#L2529 The problem here is that it hard codes the chip select: https://github.com/apache/incubator-nuttx/blob/c8ff295d59c0360943abcaf19177cd0556f37f47/drivers/can/mcp2515.c#L333 This number (0) should be held by the driver structure and passed in at instantiation time. This would be a welcome change. Then you can in your boards spi logic I mentioned above have SPIDEV_CANBUS(0) and SPIDEV_CANBUS(1) and this will all just settle out. Does this address your concern? --Brennan
