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