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
> >
>
