> One problem was I didn't understand current CS definition. I thought > #define GPIO_MCP2515_CS (GPIO_OUTPUT|GPIO_CNF_OUTPP|GPIO_MODE_50MHz|\ > GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4) > created a bitmask named GPIO_MCP2515_CS but no, it creates an ASCII string > that does its magic in stm32_configgpio()
That doesn't create an ASCII string. GPIOs follow a simple encoding that changes from chip to chip depending on the capabilities of the chip. The CS pin isn't part of the chip driver because it's (for the most cases) a normal GPIO that changes from board to board. The board logic that adds a CS pin is very simple and doesn't require deep kernel knowledge. On Fri, Jan 8, 2021 at 4:45 PM Grr <gebbe...@gmail.com> wrote: > > Thank you for the response > > Hi, > > some of the points you mention about drivers being tied to board logic and > > the fact that initialization is "hard coded" is something I once tried to > > improve > > when I worked on "device tree" support (discussion at > > https://github.com/apache/incubator-nuttx/issues/1020). However as this > > was > > quite a big undertaking it was shelved for the time being. In that regard, > > what I can say is: > > > > - With the introduction of "common board logic", drivers support can be > > implemented > > at the board-family level (e.g.: stm32). This reduces the necessary code > > to support > > the driver in another board of the family to a single initialization call > > and pin definitions > > > > - Right now NuttX usually ties resource definition ("does the bard have > > device X") to driver > > support ("is driver for device X enabled") by conditional compilation on > > board logic initialization. > > So, multiple instances of a device require custom handling (besides the > > fact that the driver needs > > to indeed support multiple instances). > > > > As a result of the above, indeed trying to expose a device usually > > requires changing code > > in board logic. With devicetree I tried to tackle that but I realized > > previous steps were > > required to improve this in NuttX (first one was to reduce duplicated > > code). For this reason > > I still have on my bucket list to improve general handling of device > > drivers. > > > The way I envisioned > > is to go towards an unified driver model/interface based on callbacks > > (register, initialize, uninitialize). > > If all drivers implement this, initialization can be handled by generic > > code invoking the callbacks > > (from all instances of drivers defined in a constant array) at a higher > > level than board logic. > > > > You mean what spi_ops_s already does but in a general way. That sounds > great and I was considering something like that to generalize Peter van der > Perk's SocketCAN driver and use it with different CAN controllers > > struct spi_ops_s > { > CODE int (*lock)(FAR struct spi_dev_s *dev, bool lock); > CODE void (*select)(FAR struct spi_dev_s *dev, uint32_t devid, > bool selected); > CODE uint32_t (*setfrequency)(FAR struct spi_dev_s *dev, > uint32_t frequency); > CODE int (*setdelay)(FAR struct spi_dev_s *dev, uint32_t a, > uint32_t b, uint32_t c); > ... > } > > The final step to handle all previous mentioned limitations would be to use > > device tree to declare > > existing resources and generate the driver-instance array automatically. > > As device trees naturally > > handle overlaying, this would allow for a base resource definition for all > > on-board devices and then > > have the user to extend/override this with some user-defined device tree. > > In there you could add off-board > > devices, which also enables support for multiple instances. > > > > That's exactly what I want, albeit not as ambitious. My guess is it can be > half accomplished right now with CS abstraction, Kconfig magic and defining > a standard model for driver structure to which existing drivers can be > slowly migrated > > One problem was I didn't understand current CS definition. I thought > > #define GPIO_MCP2515_CS (GPIO_OUTPUT|GPIO_CNF_OUTPP|GPIO_MODE_50MHz|\ > GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4) > > created a bitmask named GPIO_MCP2515_CS but no, it creates an ASCII string > that does its magic in stm32_configgpio() > > My question is if the whole *_configgpio() family does the same everywhere > so GPIO_MCP2515_CS can be applied correctly to any _configgpio() function > and it's only a matter of generalizing the existing structure. In that case > Brennan is correct it's already abstracted and it's only a matter of using > it to avoid board "lock-in". > > > > > Hopefully sometime in the future we can discuss something along these > > lines to be added to NuttX as > > I think it would be very valuable. > > > > Maybe we could start now by creating the seed of the driver model and the > user config part. That would be very nice and, I hope, very achievable > > TIA > Grr > > > Best, > > Matias > > > > > > > > > On Fri, Jan 8, 2021, at 01:19, Grr 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? > > > > > > 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 > > > > > > Another related problem (discussed between Gregory Nutt and Sebastien > > > Lorquet in > > > > > https://nuttx.yahoogroups.narkive.com/7qv88uHr/proposal-support-multiple-spi-devices-of-same-type > > ) > > > is support of multiple similar devices in the same bus > > > > > > The solution to problem A is to have an abstraction mechanism for CS that > > > can be used not only in driver code but in menuconfig so user is able to > > > configure any possible combination of boards and *external* busses and > > > devices to exploit NuttX device support. > > > > > > Is there or could be such abstraction mechanism to complement SPI_*? > > > > > > For problem B, I've seen hints in Bob Feretich's ADXL372 driver but > > > couldn't find use of it to learn how. I've seen device IDs have an index > > > but I still don't know how its used > > > > > > Any hint or opinion is greatly appreciated > > > > > > TIA > > > > > > Grr > > > > >
